CN111859128A

CN111859128A - System and method for third party application activity data collection

Info

Publication number: CN111859128A
Application number: CN202010671229.3A
Authority: CN
Inventors: Y·亚拉哈米; K·布洛赫; N·阿赫萨夫
Original assignee: Wix com Ltd
Current assignee: Wix com Ltd
Priority date: 2013-12-04
Filing date: 2014-12-04
Publication date: 2020-10-30
Anticipated expiration: 2034-12-04
Also published as: KR20160092021A; CA2932286C; KR20220018101A; JP2020191123A; EA201691088A1; AU2019264558A1; EA036433B1; JP2019133700A; IL245992A0; EP3077920A4; JP7387779B2; KR102361002B1; MX2016007301A; AU2014358700A1; IL292474A; CA2932286A1; IL273052A; CN105940391A; JP6746746B2; JP2017502392A

Abstract

A system comprising: at least one hub for coordinating at least one activity message between a website and at least one third-party application, wherein the at least one activity message has a standardized format; and an activity coordinator to listen to the at least one activity message and add at least data extracted from the at least one message to a stream associated with at least one of the identified contact and the anonymous contact, and wherein the at least one of the identified contact and the anonymous contact is a user of the website. The system further includes a contact coordinator to retrieve and analyze contact related information from the stream and enrich previously saved information for the contact; and at least one database for storing the activity stream and the contact related information for use by the website and the contacts.

Description

System and method for third party application activity data collection

This application is a divisional application of a co-named patent application with application number 201480074482.3 filed on 12, month 4, 2014.

Technical Field

The present invention relates to online applications and in particular to their use with third party applications involved.

Cross Reference to Related Applications

The present application claims the benefit of U.S. provisional patent application No.61/911,485, filed 2013, 12, month 4, the entire disclosure of which is incorporated herein by reference.

Background

There are many commercially available website building systems and other interactive application building tools that can be used to create and edit websites and other online applications. End users may access such websites using client software on a variety of different platforms, such as conventional personal computers, smart phones, tablet computers, and other desktop or mobile devices.

These website building systems may have different configurations, for example, a fully online website building system that hosts one or more servers connected to the internet and that are accessed using an internet communication protocol such as hypertext transfer protocol (HTTP). The website building systems are created, edited and deployed all directly on line through a server.

The website building system may also be partially online or even sometimes completely offline. For some online systems, website creation is performed locally on the user's machine and later uploaded to one or more central servers for deployment. Once uploaded, these website building systems will operate in the same manner as fully online website building systems.

The website building system has an internal data architecture to organize data and elements within the system. The architecture may be different from the external view of the site in question that the user sees, and may also be different from the way typical hypertext markup language (HTML) pages are sent to the browser. For example, the internal data schema may contain additional attributes for each element on the page (creator, creation time, access permissions, links to templates, etc.) that are necessary to edit and maintain the site within the website building system, but not externally visible to the end user (or even to some editing users). Sites based on a typical architecture of a website building system may include pages that contain components (e.g., shape components, graphical components, text components, single and multi-page containers containing mini pages, etc.).

A part may be content-free, e.g., a star, which does not have any internal content (but which has color, size, location, and some other attributes); or may have internal content such as a text passage component that includes the displayed text as well as font, format, and layout information. The content may naturally vary from one instance of the text passage part to another.

Designers using such website building systems may design new creations from scratch (starting from blank screens) or may rely on pre-defined application templates created by the designer himself or the system creator or by a team of designers. The website building system may support templates, which may be just a collection of parts, a complete page (or mini page), or even a collection of pages and a complete website.

When an application template is provided, the designer is free to customize — add, remove, or modify all elements of the template to create his or her version of the template. Such customization may be accomplished by creating a modified version of the template (which is different and separate from the template). Alternatively, the website building system may apply the customization through an inheritance class mechanism that maintains a connection to the original template and thus reflects subsequent changes made to the template.

The website building system may also be extended with third party applications and components embedded therein. Such third party applications may be included in the website building system design environment or may be purchased (or otherwise obtained) separately through multiple distribution facilities, such as from an application store (AppStore) integrated into the website building system, or from a separate, web-based or standalone application repository (or AppStore) operated by a Website Building System (WBS) provider or another entity. The third party application may also be obtained directly from the third party application provider (with or without app store) -this will provide the actual installation module, or activation or access code.

The third-party application may include any combination of front-end (display) elements and background business elements that are not part of the visual website display. The third-party application may be entirely background-business (i.e., not including a display element), entirely front-end (i.e., activated only in the context of website usage), or a combination of both.

The background business elements of the third party application may include functionality such as database communication, external update options, and the like. For example, the blog third-party application may include a background business element that allows for receiving updates from non-human sources (e.g., RSS news fed from a major news service) and from human resources unrelated to the web site (e.g., a standalone smartphone application that allows for submission of blog entries).

The visual elements of the third party application may be integrated into the containing website in a variety of ways. The widget-type third-party application may be embedded as a component into a website page, while the segment-type third-party application may be added to the website as one or more additional pages.

Further, the third-party applications (widgets and segments) may be single-page third-party applications or multi-page third-party applications (which have internal mini-pages represented as internal URL structures). The system may implement any or all of the four possible combinations (widgets or sections, single or multi-page).

The multi-page third-party application typically provides a default "landing" mini-page, which may be a start page, a specific internal mini-page (e.g., the most recent blog entry in a blog third-party application). A mini page selection screen or some other mini page.

And the third-party application is used in the website based on the website building system through the third-party application example. The website building system may support multiple uses of the third-party application at multiple levels, for example, allowing a single third-party application instance throughout the website; allowing multiple instances of a third-party application to be created in a website (but no more than one instance of any given third-party application); and allowing multiple instances of multiple third party applications to be created, but no more than one instance per given page. It is also possible to allow multiple instances of each page component third party application, but not segment third party applications, and also to allow multiple instances of multiple third party applications to be created without limiting the number, variety, or location of third party application instances.

The third party application instance may have instance-specific content. For example, an e-store third-party application may have a product database associated with a particular instance that is different from product databases associated with other instances of the same e-store third-party application (at the same site or at other sites).

For purposes of discussion, the website page (or mini page) containing the third party application and its mini pages or elements (i.e., "wrapper pages") are known to contain web pages and are the primary site for the entire website. The integrated page (including the main page and the embedded TPA mini page/component) shown to the user will be referred to as a combined page. For a segment-type third-party application, a "virtual page" containing the third-party application will be used as the containing web page.

The third-party application is typically deployed on a website building system provider server, on a third-party application provider server, on an external (fourth party) server, or any combination thereof. The third party application may also include elements that actually run on the end user machine, such as a statically installed browser extension or a dynamically running JavaScript component that runs within the website building system client side code, as shown in FIG. 1 to which reference is now made.

The website building system provider's server acts as the point of contact for the end user and responds to the request (possibly connecting to a third party application provider's server to receive the required information). For example, when video streaming is required, the website building system may (as needed) create a direct connection between the client computer and the server of the third party application provider.

The third party application instance included may have its own internal content, similar to the way conventional components include internal content. The third party application may manage the content independently of the website building system and independently of the website generated using the website building system as shown in fig. 2, to which reference is now made. Multiple third-party application instances (of a single or multiple third-party applications) may have shared content, e.g., two electronic store instances in two separate web pages may relate to the same product database.

Output from the contained third-party application can be integrated into the contained web page in a number of ways, such as:

and (3) server side processing:in this alternative, illustrated in FIG. 3 to which reference is now made, a third party application [ a ]](including design and display elements) and user-specific third-party applications [ b]By a server [ d ] at a third party application provider]Third party application server code [ c ] running on]And (6) merging. Over a communication medium [ e ]]Send them to website building system server code f]The code associates them with the contained web page information [ g ]]Merge and send them for use at the customer site h]Is shown.

Client side processing:in this alternative, illustrated in FIG. 4 to which reference is now made, a third party application [ a ] ](including design and display elements) and user-specific third-party applications [ b]By a server [ d ] at a third party application provider]Third party application server code [ c ] running on]And (6) merging. Over a communication medium [ e ]]Send them to the client side processing component h]. Website construction system server code [ f]Will contain the web page information g]Sent to the client side processing component h]. Client side processing component [ h]Performing merging of two sources of informationAnd [ i ] to the browser (or other client agent) [ i ]]A unified application is presented.

The iFrame contains:in this alternative, illustrated in FIG. 5 to which reference is now made, a third party application [ a ]](including design and display elements) and user-specific third-party applications [ b]By a server [ d ] at a third party application provider]Third party application server code [ c ] running on]And (6) merging. Over a communication medium [ e ]]Send them to the user agent (e.g., web browser) [ i ]]Run-in browser-based application h]. Website construction system server code [ f]Will contain the web page information g]Send to the browser-based application h]. Containing web page serving as a web page containing one or more iframe instructions, including instructions from a third party application server d ]The content of (1). Additional and alternative methods may also be applied.

Disclosure of Invention

There is provided in accordance with a preferred embodiment of the present invention a system implemented on a website via a client/server system having at least one processor for processing instructions defining the system. The system comprises: at least one hub for coordinating at least one activity message between a website and at least one third-party application, wherein the at least one activity message has a standardized format. The system further includes an activity coordinator to listen to the at least one activity message and add at least data extracted from the at least one message to a stream associated with at least one of the identified contact and the anonymous contact, and wherein the at least one of the identified contact and the anonymous contact is a user of the website. The system further includes a contact coordinator to retrieve and analyze contact related information from the stream and enrich previously saved information for the contact; and at least one database for storing the activity stream and the contact related information for use by the website and the contacts.

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 to route and track the at least one active message between the website and the at least one third-party application; a private policy enforcer to enforce a privacy policy between the website and the at least one third-party application; a converter and adapter for applying at least one pre-specified message conversion and content adaptation rule between the website and the at least one third-party application; a private data agent for implementing at least one of a private data agent and a private data replacement and for enforcing user permission field restrictions between the website and the at least one third-party application; and a verifier and signer for verifying a signature of the at least one activity message using an input key of the at least one third-party application, for converting an external ID associated with the at least one activity message with an internal website ID, and for signing the at least one activity message that is output using an output key of the at least one third-party application.

Further in accordance with a preferred embodiment of the present invention, the activity coordinator includes at least one of: a stream creator for identifying the contact associated with the at least one activity message and for creating the data stream when no associated contact exists; a stream merger for merging data from the at least one active message into an existing stream and merging data from at least two of the active streams into a single stream; and a log creator for recording activity data from the activity stream into the at least one database.

Further in accordance with a preferred embodiment of the present invention, the contact coordinator includes at least one of: a data extractor for extracting contact-related information from at least one of the at least one activity message, the stream, other contacts, and an external source; a data merger for merging at least two contact information records, wherein the records are associated with the same identified contact and for merging the extracted contact related information into contact related information of an existing contact according to a predefined merging rule; a contact processor for creating at least one of new contacts and anonymous contacts that are identifiable, and for tracking contact activity during a session of the website; and a data and permission processor for processing privacy protection and permission of the extracted contact-related information.

Additionally in accordance with a preferred embodiment of the present invention the router and tracker supports routing the at least one active message with the at least one third party application specific listen query.

Furthermore in accordance with a preferred embodiment of the present invention the stream merger comprises an activity-to-stream merger to merge the data into the stream associated with the identified contact and a stream-to-stream merger to merge at least two separate streams into a single stream.

Further in accordance with a preferred embodiment of the present invention the stream-to-stream merger comprises at least one of a horizontal stream merger for merging the at least two separate streams in accordance with the identified common contact and a vertical stream merger for merging the stream created for the anonymous contact and the stream associated with the registered contact user when connecting the anonymous contact and the login or registration of the registered contact user.

Further in accordance with a preferred embodiment of the present invention, the data merger includes at least one of: a contact identifier to at least one of: the method may include locating a same primary ID field value in at least two of the contact information records, locating a same primary key field value when normalized in at least two of the contact information records, identifying a site user with a network tracker, identifying a site user with a site login for a registered user, and identifying a site user by social login for a site user with an account associated with a social network. The data consolidator further includes a consolidator for consolidating contact information using at least one of language, grammar, text analysis, and consultation with external data sources and services; a conflict resolver for resolving conflicts between contact records according to predefined rules; a list value creator for creating a list value field to define a net precedence between the contact records; a horizontal contact merger for merging two unrelated contacts due to the detected common primary ID; and a vertical contact merger for merging the anonymous contact with a contact associated with the registered user upon connecting the anonymous contact with the login or registration of the registered user.

Additionally in accordance with a preferred embodiment of the present invention the horizontal contact merger comprises a virtual merger for maintaining at least two contact records as separate and linked together so as to be marked as representing the same contact.

Further in accordance with a preferred embodiment of the present invention the vertical contact merger comprises a virtual merger for maintaining anonymous contacts and contacts associated with registered users as separate and linked together so as to be marked as representing the same contact.

Further in accordance with a preferred embodiment of the present invention the user permission field is at least one of determined by the website and determined by the website owner.

Furthermore, in accordance with a preferred embodiment of the present invention, the standardized format is at least one of: defined by a predefined scheme, inheritance, callback link, encoded and defined by the at least one third party application, or based on an externally official industry or fact standard.

In accordance with a preferred embodiment of the present invention, there is provided a method implemented on a website via a client/server system having at least one processor for processing instructions defining the method. The method comprises the following steps: coordinating at least one activity message between the website and at least one third-party application, wherein the at least one activity message has a standardized format; listening for the at least one active message and adding at least data extracted from the at least one message to a stream associated with at least one of the identified contact and the anonymous contact, and wherein the at least one of the contact and the anonymous contact is a user of the website. The method further includes retrieving and analyzing contact related information from the stream and enriching previously saved information for the contact; and storing the activity stream and the contact related information for use by the website and the contact.

Further in accordance with a preferred embodiment of the present invention, the coordinating includes at least one of: routing and tracking the at least one active 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 and content adaptation rule between the website and the at least one third-party application; implementing at least one of a private data proxy and a private data replacement and enforcing user permission field restrictions between the website and the at least one third-party application; and verifying the signature of the at least one activity message by using an input key of the at least one third-party application, converting an external ID associated with the at least one activity message with the internal website ID, and signing the at least one activity message output by using an output key of the at least one third-party application.

Further in accordance with a preferred embodiment of the present invention, the listening and the at least adding comprise at least one of: identifying the contact associated with the at least one activity message and creating the data stream when no associated contact exists; merging data from the at least one active message into an existing stream and merging data from at least two of the active streams into a single stream; and recording activity data from the activity stream into the at least one database.

Further in accordance with a preferred embodiment of the present invention, wherein the retrieving and analyzing comprises at least one of: extracting contact-related information from at least one of the at least one activity message, the stream, other contacts, and an external source; merging at least two contact information records, wherein the records are associated with the same identified contact, and merging the extracted contact related information into contact related information of an existing contact according to a predefined merging rule. The retrieving and analyzing further comprises creating at least one of new contacts and anonymous contacts that are identifiable and tracking contact activity during a session of the website; and privacy protection and permissions to process the extracted contact-related information.

Further in accordance with a preferred embodiment of the present invention the routing and tracking supports routing the at least one active message with the at least one third party application specific listening queries.

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

Furthermore, in accordance with a preferred embodiment of the present invention, merging the data into the stream associated with the identified contact and merging at least two separate streams into a single stream includes at least one of horizontal merging that merges the at least two separate streams in accordance with the identified common contact and vertical merging that merges the stream created for the anonymous contact and the stream associated with the registered contact user at the time of connecting the anonymous contact and the login or registration of the registered contact user.

Furthermore, in accordance with a preferred embodiment of the present invention, the merging of the at least two contact information records includes at least one of: the method may include locating a same primary ID field value in at least two of the contact information records, locating a same primary key field value when normalized in at least two of the contact information records, identifying a site user with a network tracker, identifying a site user with a site login for a registered user, and identifying a site user by social login for a site user with an account associated with a social network. The merging of the at least two contact information records further comprises: syndicating contact information using at least one of language, grammar, text analysis, and consultation with external data sources and services; resolving conflicts between contact records according to predefined rules; creating a list value field to define a net precedence between the contact records; merging two unrelated contacts due to the detected common primary ID level; and vertically merging the anonymous contact with a contact associated with the registered user when connecting the anonymous contact with the login or registration of the registered user.

Further in accordance with a preferred embodiment of the present invention the horizontal merging includes a virtual merging to maintain at least two contact records as separate and linked together so as to be marked as representing the same contact.

Further in accordance with a preferred embodiment of the present invention, the vertical merge includes a virtual merge to maintain anonymous contacts and contacts associated with registered users as separate and linked together to mark them as representing the same contact.

Further in accordance with a preferred embodiment of the present invention the user permission field is at least one of the website determined and the website owner determined.

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

Drawings

The subject matter regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The organization and method of operation, however, together with objects, features, and advantages thereof, may best be understood by reference to the following detailed description when read with the accompanying drawings in which:

FIG. 1 is a schematic diagram of a deployment configuration between a website building system and a third party application;

FIG. 2 is a schematic diagram of third party application internal content management;

FIG. 3 is a schematic diagram of third party applications contained in a web page processed by the server side;

FIG. 4 is a schematic diagram of third party applications contained in a contained web page being processed by the client side;

FIG. 5 is a schematic diagram of a third party application contained in an include web page by an iframe contain;

FIG. 6 is a schematic illustration of existing and non-optimal third party application displays during a page layout change;

FIGS. 7A and 7B are schematic illustrations of a system for integrating a website building system and one or more third party applications, constructed and operative in accordance with the present invention;

FIG. 8 is a schematic diagram of a document object model compared to a part model;

FIG. 9 is a schematic diagram of a sample multi-party blog third-party application;

FIG. 10 is a schematic diagram of a sample modular sales third party application;

11A and 11B are schematic illustrations of different implementations of a communications center constructed and operative in accordance with the present invention;

FIG. 11C is a schematic illustration of elements of the communications center of FIGS. 11A and 11B constructed and operative in accordance with the present invention;

FIG. 12 is a schematic illustration of a communication translation scenario executed by the communication center of FIGS. 11A and 11B, constructed and operative in accordance with the present invention;

FIG. 13 is a schematic illustration of a containing web page processing a third party application having an associated template constructed and operative in accordance with the present invention; and

FIG. 14 is a schematic illustration of a containing web page including a third party application having an associated template within a mini page, constructed and operative in accordance with the present invention;

FIG. 15 is a schematic illustration of a system for coordinating and collecting data from different messages exchanged between a website building system and one or more embedded third party applications, constructed and operative in accordance with the present invention;

16A, 16B, 16C and 16D are schematic illustrations of elements of the system of FIG. 15 constructed and operative in accordance with the present invention;

FIG. 17 is a schematic illustration of a sample graphical user interface displaying an activity flow associated with a contact, constructed and operative in accordance with the present invention;

FIG. 18 is a schematic diagram of client-side and server-side third party application activity messaging; and

fig. 19 is a schematic diagram of a login/logoff process during a user website session.

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 of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.

Detailed Description

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. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the present invention.

Applicants have recognized that the current approach has several limitations in the following ways: third party applications are typically integrated into the website building system and the manner in which the integrated third party applications and website building system interact.

These limitations include the limitation that the third party application display is limited to containing a single rectangular area within the web page, which is contained within the iframe. They also include the ability of third party applications to control their own window size and position, as well as visual elements outside of the actual third party application display window (e.g., a specialized display frame around the third party application window).

The third party application may have its own display style (color scheme, font, character size, etc.). These styles may be good for some containing web pages, but may be visually problematic or discordant for other containing web pages.

Another limitation is the rigidity of the third party application display from the perspective of the encompassing site. If a site must be visually modified (e.g., due to deployment to a platform with a different screen size or due to a dynamic layout event), the inclusion of a web page may be required to change the size of a window assigned to a third party application. In this case, the third party application display will be cropped and required to scroll to a different sub-region in the third party application via the scroll bar. Referring now to FIG. 6, which illustrates an example of a scenario that occurs when a web page [ a ] is resized to include, the area allocated to the e-store third party application [ b ] is reduced and the contents of the "buy" button [ c ] and shopping cart [ d ] cannot be seen simultaneously-multiple scroll actions are required to complete the purchase and less likely to make the purchase actually complete.

It will be appreciated that third party applications cannot interact with other components within the contained web page, and such interaction is sometimes required to implement complex functionality. In particular, it is not possible for third-party applications to perform differently depending on the type and content of the components in the contained web page. An example of this is a web site that streams an online cooking process. The user wishes to watch his movie in the background, a smaller area of his screen dedicated to feeding news and updating weather (e.g., live streaming from CNN) in another area of his screen. He may want to automatically suspend the session he learns when the weather forecast for his residential area starts.

There is also no clear, standard way for multiple third party applications to collaborate with each other, especially when they are provided by different vendors. Thus, there is no clear way for designers to combine multiple third party applications from different vendors. An example of this would be an e-commerce website running modules from a third party ordering system and different modules of a delivery system. It is desirable to order supplies according to a delivery schedule or the like.

Applicants have recognized that this integration can be achieved through the use of structured, bi-directional communication channels between the website building system and the third-party application instances contained therein, as well as between different third-party application instances implemented in the same contained page. These channels may also convey information about layout, style, and additional information.

It will be appreciated that the following discussion focuses on the iframe containment method, which is a preferred method of building in and integrating with modern browsers, and does not require the creation of special integration code. Iframe contains also provides browser support packaging and sandboxing, as well as inherent protection from hacking techniques such as cross-site scripting attacks that may be employed by malicious third party applications.

Referring now to fig. 7A and 7B, a system 100 for integrating a website building system and one or more third party applications in accordance with the present invention is shown. Fig. 7A shows system 100 at the design stage, while fig. 7B shows system 100 at runtime. As shown 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. Website building system 30 includes WBS coordinator 21, application repository 22, WBS-side TPA attribute form 23, Third Party Application (TPA) coordinator 24, and AppStore 25 (which may include searcher 26). The client 10 includes a client-side view of the page orchestrator 12 and the TPA properties form 23. In some embodiments, the client 10 may also include a client side view of AppStore 25. The page composer 12 includes a linker 13, which will be described in more detail below. The third party server 50 comprises a third party application 40, an external TPA coordinator 51 and a TPA database 52, said TPA database 52 storing third party application 40 parts, templates, etc. for use. Note that the system 100 may include multiple third party servers 50, which may be termed multiple third party application 40 vendors.

It will be appreciated that TPA property form 23 may be invoked when properties are specified for a given third party application 40 instance. It will also be appreciated that TPA properties form 23, when invoked, may appear on client 10 as a client-side view of TPA properties form 23. It will also be appreciated that an offline embodiment may have its properties form as part of the installed client software and therefore will not have its TPA properties form 23 or its library.

It will be appreciated that a designer or end user 5 sitting at a client 10 may create his website (or any other online application) using the page composer 12 to create website pages and interactions (intermediate pages as well as internal pages). The designer 5 may select components, templates, etc. of a portion of the website building system 30 stored in the application repository 22 via the WBS coordinator 21. The designer 5 may also create a containing web page 203 that embeds third party application 40 instances from third party applications 40, which third party applications 40 have been purchased in advance and whose templates, parts, etc. may be stored on the application library 22. In an alternative embodiment, the purchased templates, parts, etc. may be stored on the TPA database 52 and accessed via the external TPA coordinator 51. In another embodiment, third party application 40 templates, components, etc. may be purchased via AppStore 25 as needed. The properties form 23 may be specified by the designer 5 and holds information about third party application 40 instances that have been purchased, e.g., permissions, installation instructions, payments, etc., as described in more detail below. The designer 5 may also use the linker 13 to manually specify any communication channels between the included third party applications 40 (if desired). It will also be appreciated that the linker 13 also allows the designer 5 to specify any particular communication connections and rules between the containing web page being built and the third party application 40 instance being contained (e.g., movies and CNN news stories shown simultaneously as described above). It will be appreciated that the link created by the linker 13 may be modified by the trial period of the website.

It is to be appreciated that designer 5 may obtain third party application 40 over a channel external to AppStore 25, such as an external AppStore operated by a third party application 40 vendor or an external party. In this 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 the website created by the designer 5 through the website building system 30.

It will be appreciated that in order for the linker 13 to provide the ability to establish a possible communication channel, the third party application 40 needs to be able to correctly identify and recognize the components (to which communication is likely to be made) within the containing web page 203-including other third party application 40 instances. For components based on the associated template (described in more detail below), the identification is performed in advance by the third party application 40 vendor. The components in the associated template may be given specific reference IDs, and these IDs may be used by the third party application 40 when communicating with them.

It will also be appreciated that for a multi-party third party application 40 (described in more detail below), i.e., a single third party application 40 that is respectively on multiple iframes, the parties can automatically know how to communicate with each other.

For web page-containing components that are not included in the associated template (as will be described in more detail below), the third-party application 40 may include a list of required (mandatory or optional) web page 203 components that should exist so as to be operational. The list may be stored in the library form 23 and include unique IDs, descriptions, and parts details (e.g., must be text parts, to be used as blog dialog tags). This list may be specified in the third party application 40 entering the AppStore 25, and the designer 5 may use the linker 13 to specify the components (fields) in the containing web page 203 required by the composite third party application 40. It will be appreciated that when creating third party application 40 instances, the website building system 30 may dynamically create missing contained web page 203 components and may allow the designer 5 to move, resize, and then fully specify them.

Alternatively, the website building system 30 may expose all or part of the components comprising the web page 203 to third party applications 40 included in the comprising web page 203. It will be appreciated that this may be a component model, rather than a Document Object Model (DOM) containing the web page 203. The containing web page 203DOM may be more complex and detailed than the component model because the actual containing web page 203 may contain (hidden and visible) a variety of HTML elements that are part of the website building system 30 infrastructure, or that support containing web page 203 components. The component model can thus be simpler.

Referring now to fig. 8, it shows how the text part [ a ] is implemented using multiple HTML constructs (e.g., closed div tag [ b ], internal div tag [ c ], framework "mini-widget" [ d1] - [ d5], etc.). The DOM model [ e ] for containing web page 203 may contain separate DOM tree nodes for each of these sub-elements. Component [ f ] is simpler, containing only a single component node [ g ].

It will be appreciated that the system 100 may also support selective component exposure-the designer 5 may specify via the linker 13 which components should be exposed to the third party application 40, and only these components (possibly including the "containment paths" leading to them) may be included in the simplified component model visible to the third party application 40. The designation may be performed by explicitly marking the included components, according to their type or any other website building system 30 attribute. The third party application 40 may then traverse the containing web page 203 part model and locate the required parts.

It will also be appreciated that the link between the containing web page 203 and the third party application 40 instance may also be created automatically, for example, a broadcast link in which the third party application 40 may send communications during runtime to record a particular event. This communication may be optional or mandatory (i.e., the third party application 40 may not function or install unless there is a matching third party application 40 that has linked to receive such messages). For example, the third party application 40 may broadcast message packets regarding the activities it performs, and any installed recording third party application 40 may receive these message packets.

The newly created web page, now completed by the setup, may be stored (via the WBS coordinator 21) in the application library 22 to be invoked at runtime, as described in more detail below.

Reference is now made back to fig. 7B. In this embodiment, the elements are the same as those of fig. 7A except for the elements of the client 10. During runtime, the client 10 includes a viewer 201 to display a containing web page 203. It will be appreciated that the viewer 201 may include multiple viewports 202, each of which displays a different instance of the third party application 40 (an instance derived from one or more third party applications 40). The client 10 also includes a communications center 205 to facilitate communications and provide a back channel between the containing web page 203 and any third party applications 40 that are hosted with any communications required between the hosted third party applications 40 without any connection to the relevant containing web page 203. The function of the hub 205 will be described in more detail below.

It will be appreciated that the hub 205 may be implemented on the client 10 because the containing web page 203 and any third party applications 40 contain interactive portions that are both visible web sites and their communications should be delayed by both client-server passes. In an alternative embodiment, the hub 205 may be implemented on the website building system server 20 in situations where third party application servers 40 need to exchange large amounts of data and preferably will not be routed through the client 10.

It is to be appreciated that the communication center 205 can support different combinations of communication between the website building system 30 and one or more third-party applications 40, as well as between multiple third-party applications 40. For example, the hub 205 may cause the third party application 40 to request that the website building system 30 switch to another page of the host site. The communications center 205 may also cause the third party application 40 to request resizing of the window in which it may affect the page parts. This may be done by a dynamic layout process, which will be described in more detail below. Alternatively, the containing web page 203 may request, for example, the third-party application 40 to switch to a different version if needed to accommodate the change in display. It will be appreciated that this 2-way communication can also begin between third party application 40 components and website building system 30 components associated with the third party application 40, which display additional information and communications between the elements of the multi-party third party application 40 and the modular third party application, as described above.

It will also be appreciated that the system 100 may also be implemented using online and offline website building systems 30, and that it may also use any combination of hosted methods, such as client-side elements, website building system 30 provider servers, third party application 40 provider servers, and other fourth party servers. It will be appreciated that for the offline embodiment described above, a server may still be required to implement system 100.

The system 100 may also be hosted on a different set of servers (not operated by the website building system vendor), for example, a private site hosting arrangement for a larger organization.

The system 100 may also support third party application 40 instance inclusion options from the third party applications 40, as described above. However, the system 100 may also support a subset of these options, or may include probabilistic placement constraints for third party application 40 instances.

The system 100 may also implement a multi-party third party application 40. The multi-party third party application 40 may include multiple display areas, each of which is handled with a separate iframe. These areas may also cooperate (as needed) through the communication center 205, as described in more detail below.

Referring now to FIG. 9, an example of a multi-party third party application 40 is shown. As shown, a blog third-party application [ a ] obtained from AppStore [ b ] is placed in a contained web page 203[ c ]. The blog third-party application [ a ] includes three areas: a blog entry area [ d ], a tag cloud area [ e ], a news update area [ f ]. It will be appreciated that the multi-party third party application may use its multiple regions in a variety of ways, including as many concurrent resident portions of a single application as in the blog example described above or as there are multiple selectable resident portions of a single application, multiple regions always being visible, and multiple regions being selectable and displayed only when needed. The display of the selectable region may be controlled by the third party application 40 or by the designer 5 (who decides how to configure the third party application when included). The display may also be controlled as a support function area, such as a configuration or additional dialog area; or as an alternative display to multi-version third party applications (e.g., with smaller and larger versions of the third party application, or with portrait and landscape versions of the third party application).

It will be appreciated that the above functionality may be implemented using an iframe displayed for a third party application 40 component, thus increasing the encapsulation and security benefits of the iframe-based architecture.

It will also be appreciated that the implementation of the multi-party third party application 40 requires that the third party application 40 (within its iframes) control the display of the respective iframes (e.g., their visibility, size and position). It is also understood that the communications center 205 may support this display, as described in more detail below.

It will also be appreciated that even when a multi-party third party application 40 (visually) includes multiple elements and zones, it will still be considered a single third party application 40 in terms of purchase (e.g., in AppStore 25), installation, configuration, etc.

In existing systems, each third-party application 40 may be considered a separate entity, and any collaboration between two third-party applications 40 (from the same vendor or other collaborating vendors) is specifically developed on a one-by-one basis. It will be appreciated that the system 100 also supports a modular third party application 40 that includes a plurality of cooperating sub-modules that can be purchased and installed separately.

Referring now to FIG. 10, it shows how the modular sales management third party application [ a ] includes the following sub-modules: CRM module [ b ], thread management module [ c ] and e-commerce module [ d ]. A single third party application provider may provide all required third party application modules. Alternatively, a third party application provider may provide a subset of the third party application 40 modules (and functionality) and allow the designer to purchase/install supplemental third party application modules from the same or additional third party application providers. It will be appreciated that the multi-party third party application is acquired and installed as a single third party application from a single vendor, which occurs only to occupy multiple screen areas, and that the modular third party application includes multiple modules that can be acquired and installed separately, and may include modules from multiple third party application vendors. In order to provide the ability to integrate multiple third party application modules from multiple vendors, each third party application module must provide a list of the interfaces/functions it acquires and the interfaces/functions it provides. This may be accomplished, for example, by using a list of interface name and interface parameter specifications that separate the naming specifications (e.g., My CRM tra.

The third party application 40 module may specify the required interfaces as mandatory (i.e., the module does not work without them) or as optional (i.e., the module may work but may provide reduced or modified functionality). Thus, the parameters provided for each interface are: the unique name of the interface; interface description-display to designer 5 so that he or she can know, for example, that the function handled by the interface is missing; a force/optional state; a list of interface parameters and a type. It will be appreciated that each third party application module still resides in a single iframe (or set of iframes). The operation of the interface is based on the communication channel described in more detail below.

It will be appreciated that the third party application 40 module may be assembled during the website design phase. The website building system 30 may resolve the interface reference when adding additional third party application 40 modules-a new third party application 40 module resolves an existing required interface, but may add a new (unresolved) required interface.

It will be appreciated that the designer 5 can edit and run the complete web site, but the mandatory (or alternative) interface is still not addressed. Designer 5 may not publish the created web site, however, until all mandatory interfaces are resolved, and prompt when attempting to have function claim center 205 activate a third party application module for an unresolved mandatory interface.

It will also be appreciated that AppStore 25 may include a searcher 26 that attempts to locate third party application modules that address the required third party application module interface. The searcher 26 may search for a particular third party application module or all third party application modules based on the unresolved interface. The searcher 26 may also search for interfaces that are not currently addressed or even for interfaces that are already addressed and search for mandatory, optional, or both types of interfaces. It will be appreciated that the searcher 26 may also be limited to resolving specific third party application unresolved interfaces, and all say specific third party application providers. The searcher 26 may perform a first level search (i.e., a module that satisfies a currently unresolved interface) or a multi-level search (i.e., perform an iterative search), also looking for modules that satisfy unresolved interfaces that were added when considering third party application modules discovered by a previous search cycle.

The system 100 may use the interface description to provide the designer 5 with information about the importance of some missing interfaces. The hub 205 may provide interface translation between incompatible, but still communicating, third party applications. This may be accomplished by an adapter module added by the website building system 30 provider or by adapting a given required interface to an external party in a different format.

The system 100 may also be applied to an offline application editing system that uses the internet (or any other network connection) and uses non-browser client-side software to view the created online application. Such a system does not require the use of the particular technology (e.g., IP communications, HTTP, HTML, etc.) used by conventional network infrastructure.

It will be appreciated that standard cross-domain communication methods known in the art may be used to facilitate cross-domain communication. These methods may include:

HTML5 PostMessage: this is a standard HTML5 feature that can be used to provide secure cross-domain messaging. Postmessage, with HTML5 window, messages can be securely sent between windows, iframes, and main HTML documents even when residing in different domains. The Postmessage provider tool is used to send iframes to specify the domain to which a message is sent and to receive iframes to validate the domain from which the message was sent.

URL segment identifier for a message: the method relies on using URL segment identifiers to send messages from one endpoint to another. The data is encoded in clear text and added (as a fragment identifier) to the URL for invoking the service on the target terminal domain or the hidden iframe within the target terminal iframe. The fragment identifier is then decoded by a code in the target service or iframe.

Private communication network service: website building system 30 provides a private network hosted on website building system server 20. Various communication endpoints connect to the server-either send messages or check for waiting messages. This may be accomplished via methods known in the art, such as the advanced HTML5 Comet set of technologies, WebSocket based on HTML5, or any other queuing, polling, server push, or similar technology.

HTML5 local store: HTML5 provides a structured local storage facility that can be used to store queuesA message. However, the local storage is only accessible through network content belonging to the same domain as the storage iframe. Solutions have been developed in the art, such as the underlying technology used by the Meebo XAuth product (now the term Google corporation), where a small server provides support for creating the required intermediate iframes that allow access to domain-specific local stores from heterogeneous based iframes.

HTML5 local file system Access Application Programming Interface (API): similar to using the local store described above, a cross-iframe communication channel may be constructed with local files on the user agent's local store accessed through HTML5 file access APIs (file API, FileWriter API, and FileReader API). However, it should be noted that the sandboxed local file system created by the HTML5 file system access API is still a private origin, and thus requires an intermediate iframe/server component to bridge the limitations of the same origin.

Special browser plug-in: a dedicated browser (or other user agent) plug-in may be created to manage the cross-iframe message queue. Such a plug-in would be installed by a user (of all levels) of the website building system 30 and would provide the necessary services to all iframe's host website building system 30 pages.

It is understood that the communications center 205 may act as a proxy for all inter-iframe communications utilizing any of the transmission methods discussed above. It will also be appreciated that the hub 205 is fully aware of the structure of the containing web page 203 and the third party application 40 details provided by the third party application 40 provider and stored in the property form 23. The third party application 40 may also have different parameters (as described above) when included in different applications and used for different included instances in the same application. Such parameters may include a unique instance name, which may be used for intelligent addressing (as described in more detail below). It will also be appreciated that the hub 205 may also be aware of additional third party application 40 details that are not stored in the property form 23.

It will also be appreciated that the hub 205 may also facilitate intelligent addressing and identification, verify origin of communication, enforce communication policies, resolve third party application 40 incompatibility issues, and also redirect to components from third party applications 40. The hub 205 may also enable dynamic updates to the layout in the third-party application 40 based on changes made to the containing web page 203, as described in more detail below.

Reference is now made to fig. 11A and 11B, which illustrate different implementation embodiments of the hub 205, and to fig. 11C, which illustrates the functionality of the different elements thereof.

The hub 205 may include an intelligent identifier and addressor 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 generic updater 380, and a managed application programming interface API wrapper 390. The function of these elements will be described in more detail below. It will be appreciated that all functionality is applicable to all cross-domain communication channels, such as a third party application 40 to website building system 30 channel and a third party application 40 to another third party application 40 channel.

FIG. 11A, to which reference is now made, illustrates an exemplary embodiment of a hub 205 through an intermediate iframe [ a ] that uses an internal communication Application Programming Interface (API) to contact the website building system 30. In this way, messages [ c ] sent from TPA [ d ] to TPA [ e ] (which use communication API modules [ f ] and [ g ], respectively) may be analyzed, validated, or modified in a manner that imposes proprietary knowledge.

The alternative embodiment shown in FIG. 11B, to which reference is now made, does not use an intermediate iframe, but uses cross-domain communication in one or both communication API modules [ a ] and [ B ] (embedded in third party applications [ c ] and [ d ], respectively). Modules [ a ] and [ b ] interact directly with the website building system 30 to receive the proprietary knowledge and process it when processing the communication message [ f ]. A disadvantage of this embodiment (compared to the embodiment described in fig. 11A) is that objective amounts of website building system 30 level information can be processed within modules contained in third party applications and can be accessed (or even modified) by malicious third party applications.

As mentioned above, in all of the cross-communication methods described herein above, iframe addressing is based on the origin of the iframe, including the source domain, protocol and port, i.e., direct third party application 40 addressing is used when sending a message (to specify the recipient) and when receiving a message (by the name of the sender provided to the recipient). Additionally, messaging requires the sender to specify a target iframe window (using java scirpt's document. getelementbyid ("…"). contentWindow call or any other method). Thus, in the prior art, each third party application 40 must contain all and specific details (including domain, protocol, port, and iframe ID) with which any other third party application 40 can communicate.

It will be appreciated that this type of direct addressing may be inconveniently used in the context of the system 100. Even though designer 5 may integrate third party applications 40 from multiple uncoordinated third party application 40 vendors, the third party application 40 vendors may supply third party applications 40 hosted in a given domain, but subsequently move them to a different or subdomain. The third party application 40 provider may change the protocol or port used to contact any given third party application. The designer 5 may be required to modify the design of the containing web page 203 containing the third party application 40. All of this may occur within third party applications 40 used in websites operated and accessed by multiple users. Additionally, a single containing web page 203 may include multiple instances of a third party application 40, which may serve multiple functions. For example, a single page in a product support network site contains two instances of the chat third party application 40-one for user-user and forum, and another for talking to the supplier's customer service personnel when available.

It will be appreciated that the intelligent identifier and addressor 310 may be fully aware of the structure comprising the web page 203 as well as the details of the third party application 40 (as provided to the website building system 30 by the third party application 40 provider). The smart identifier and addressor 310 may provide addressing of the source or target third party application 40 to each other using any of the following: a third party application 40 unique name (as registered in AppStore 25); a third party application 40 instance description ID added to each third party application 40 instance within the containing web page 203, allowing addressing of multiple instances of the same third party application 40; a generic identifier for the type/category of third party application required (e.g., "i want to send message < x > to any event record third party application 40 instance contained in web page 203"). Such identifiers may also describe the particular services that should be supported by the third party application 40. The intelligent identifier and addressor 310 may also use version identification such as: "I want to send transaction < x > to an instance of counting package < y >, but only if it is version < z >.

It will be appreciated that during 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 not any other third party application 40. Such a one-way address may be encapsulated by a communication API wrapper (e.g., communication modules f and g as shown in fig. 11A, and communication modules a and B as shown in fig. 11B) provided by the website building system 30 to the third-party application 40 provider. Invoking the third party application 40 may provide an application aware third party application 40 descriptive address (as described above) and the intelligent identifier and addressor 310 may convert it to a direct third party application 40 address and route it. In this way, the third party application 40 need not maintain a table of absolute addresses of all possible third party applications 40 with which it communicates.

It will be appreciated that message origin verification is critical, otherwise the receiving third party application 40 may receive messages from a hostile third party application 40. Because all communications may occur via the hub 205, the origin verifier 320 may check the authenticity of all incoming messages from third party applications. The origin verifier 320 may also provide additional information that may be added to the message and used for additional verification. It will be appreciated that because each third party application 40 included in AppSotre 25 and used by system 100 is registered with the website building system 30, the hub 205 can verify whether the unique origin ID contained in the message by the website building system 30 matches the message origin (domain, port, etc.).

The third party application 40 may define a generic communication policy, which may depend on external information, including web page 203 information, and the like. The communication policy enforcer 330 may ensure that the communication policy in question is enforced without having to deal with non-composite communications. For example, in a categorized information handling website, a third party application may have a category level field tagged in its profile. A third party application 40 providing a backend event record database, certified as a classification level X, may define a policy whereby registering events having a classification level greater than X is not accepted. In this case, the communication policy enforcer 330 may perform the required preliminary filtering and highly prevent classified messages from reaching even lower classified applications.

It will be appreciated that designer 5 may wish to include two (or more) third party applications in the same creative website that may cooperate, but that may not actually do so due to some protocol compatibility issues. For example, as shown in fig. 12, to which reference is now made, an electronic store third-party application [ a ] may be able to send a purchase order message to a fulfillment and shipping third-party application, such as third-party application [ b ] (provided by a different vendor). However, the information provided by the third party application [ a ] may not include some fields required by the third party application [ b ]. This situation is typically addressed by the third party application provider of the involved third party application, but in some cases such a solution is not feasible (e.g. one of the two third party applications is currently not updated for some reason). Protocol converter 340 may convert the relevant messages from [ a ] to [ b ] (e.g., by providing additional required fields). This conversion may be performed by the protocol converter 340 or may involve some interaction with the embedded website and the containing web page 203 (e.g., when additional information is needed).

It will also be appreciated that the third-party application 40 may have some capability that requires sending or receiving a message from another third-party application 40 (e.g., an electronic store/fulfillment third-party application 40 pair as described above). However, in some cases, a portion of the solution may be lost, and in the above example, it may happen that there is no match or proper fulfillment of the third party application 40. In this case, redirector 350 may allow designer 5 to specify that a given message may be routed to or from an included web page 203 component, and may resolve matching capabilities by including web page 203 components and the functionality that the components may provide. This may allow the construction of a full website without requiring the construction of a dedicated third party application 40. Thus, the transaction may be published to a website building system 30 component, which may record the transaction to a database, and which may later be used (by a separate program) to perform offline fulfillment and shipping.

The third party application 40 may provide multiple configurations, with different capabilities, utilizing the same code base but with different enabling functions. For example, the third party application 40 may provide basic functionality through a free version and additional functionality through a purchased advanced version, multiple paid versions, or additional purchased third party application 40 features.

It will be appreciated that the system 100 may include management of the website building system 30 based on the purchase status of each user (or indeed each designer) third party application 40. It will also be appreciated that the designers may all be registered website building system 30 users, and the website building system 30 may therefore manage the databases purchased by the third party applications 40 of each designer 5. This information may be stored in the property sheet 23 by the TPA coordinator 24 during the involved phases and during runtime by the configuration manager 370. For example, the third party application 40 may send a version query message to the website building system 30 client side element. The website building system 30 client side element may consult with the library 22 or with its locally cached copy and return a response message to the third party application 40 with information about the capabilities it should provide.

In an alternative embodiment, the website building system 30 may provide the third-party application 40 with the required third-party application 40 configuration information, such as encrypted iframe parameters, via an alternative channel without the need for a previous query message.

As discussed above, the third party application 40 may communicate directly with the specific containing web page 203 component. The third party application 40 may identify the communicating components in a number of ways: directly for components based on associated templates (described in more detail below); by the access ID explicitly provided by the designer 5 to the specific containing web page 203 component; by traversing the (possibly selected) part model provided by the containing web page 203 to the third party application 40.

It will be appreciated that during runtime, updater 380 may implement messages and responses between the components comprising web page 203 and third party applications 40. For example, the third-party application 40 may influence or query the visual and display properties (e.g., its location, size, color, transparency, etc.) of the containing web page 203 component. The updater 380 may also enable the third party application 40 to read or write content containing web page 203 components, and may also allow the third party application 40 to direct components that perform media functions, such as publishing a given audio or video clip to a media player component or requiring it to pause playback for a given period of time.

Updater 380 also facilitates website building system 30 components to specify the types of access they allow third party applications 40 to have-similar to access permission bits or Access Control List (ACL) functionality that protects files in modern operating systems. Such permissions may be defined for each component to apply for all third party applications 40 from a particular vendor or for a particular third party application 40. For example, the third party application 40 may be allowed to access a text field external to the third party application 40 that contains a portion of the web page 203. This text field may be used to edit the blog entry for the blog third-party application 40, providing more screen space than is provided within the blog third-party application 40 area itself. It is to be appreciated that for a third-party application 40 embedded in a particular mini page in a plurality of page containers, the website building system 30 may restrict access by the third-party application 40 alone to components in the particular mini page.

It will be appreciated that the updater 380 may also allow third party applications 40 to affect site global elements. This may include obtaining and setting attributes such as the current page in the site, the current mini page in the container containing third party application 40, and the page history. Updater 380 may also filter or limit such requests.

The updater 380 may also cause the website building system 30 to affect the style and display of third party applications 40. Updater 380 may implement a call by which website building system 30 may provide formatting and style guides to third party application 40. These may include the following attributes: color and color scheme, font, character size, transparency, animation, and special effects (e.g., blurring). In particular, the color scheme may include a generic color scheme (e.g., using the x color described below), or as a high-level color (e.g., using color x for text and color y for frame).

It will be appreciated that one preferred method of expressing complex style information is to use Cascading Style Sheets (CSS), which may express a combination of style indications including font, size, color, etc. The updater 380 may send such CSS-based messages to the third party application 40. The style sheet may be generic in nature or include specific style names defined by the third-party applications 40 so that the website building system 30 may provide better guidance for the third-party applications 40 (e.g., the style sheet may refer to and provide guidance for specific third-party application 40 elements).

The third party application 40 may then use these guidelines to make its own look and feel and better adapt to the containing web page 203. This is especially important for third party applications 40 that are contained at the same site or are visible from multiple contained web pages 203 in the same site (the multiport containment described above). The multiple containing pages may be of different color schemes or general designs. The third party application 40 can use the information provided to it through these style messages and adapt its own display color and style to better fit each containing page and avoid displaying an inharmonic color scheme or look and feel as compared to the containing page.

It will be appreciated that the dynamic layout updater 360 may enable the website building system 30/third party application 40 or the third party application 40 and secondary third party application collaboration to handle display changes caused by dynamic layout events. The website building system 30 may change the size and location of components in the page in order to prevent the page design from being in the event that some of the components in the page are changed. These dynamic component events may include, for example: viewing a website on screens having different sizes; rotating the display device between portrait and landscape modes; changing the size or position of some components and changing the content of a given component (in a manner that requires them to change their size). The dynamic layout events may also include component updates caused by server-based content updates (e.g., in component display information from a data feed), or component updates caused by content changes of another concurrent user of the same website. It will also be appreciated that dynamic layout events may occur in both the design environment as well as the runtime environment. In particular, some component and third party applications 40 may allow for component content changes or size/location changes during runtime (i.e., by an end user) rather than just by a designer.

It will also be appreciated that dynamic layout events may also be caused by third party applications 40. For example, the e-store third party application 40 may require a size change as the user moves from the catalog view to the shopping cart view (of a different size). As another example, the product catalog third-party application 40 may include options for product prominence that may cause them to display a larger catalog page that includes more content. A third example is a multi-region third party application 40 that can start or stop displaying additional regions.

Existing systems typically handle this situation (if it occurs) by clipping, adding a scroll bar to, or simply resizing the third party application display when the pop-up hides other page components as shown in fig. 6, which returns the current reference. The dynamic layout updater 360 may implement a collaborative dynamic component in which the website building system 30 and the third party application 40 collaborate to perform dynamic layout and maintain a base design comprising the web page 203. The functionality of the dynamic layout is further described in U.S. patent application 13/771,119, filed on 20/2/2013 and designated as the common assignee of the present invention. However, even in a collaborative dynamic part support system, the dynamic layout mechanism included in the web page 203 does not have full control over the internal layout of the third party application 40. In addition, the website building system 30 widgets may be designed so that they can be resized to any arbitrary size (within a given range), but the third party application 40 cannot support arbitrary resizing. The third party application 40 may, for example, provide any combination of: multiple display configurations with different sizes (e.g., displaying more or less detail); the ability to resize some of its internal elements, and the ability to display some of its internal text elements with multiple font sizes.

The third party application 40 still provides a limited number of possible display sizes and may have the full range of possible sizes. Thus, the [ include webpage 203 → third party application 40] resize request may be resolved by the third party application 40 to switch to the most recent possible size, or by providing a list of possible third party application 40 sizes (and allowing the website building system 30 to select the appropriate one for use).

The dynamic layout updater 360 may implement [ include webpage 203 → third party application 40] collaborative dynamic layout with the following sequence:

for example, the third party application 40 embedded in the containing web page 203 need not be resized to a given desired size (column, X1X Y1 pixels). The dynamic layout updater 360 may send a message to the third party application 40 requesting that the third party application 40 resize its content to a given desired size (X1X Y1). The third party application 40 may resize to the size by using alternate display configurations, internal resizing, internal dynamic layout processing, or any other means. It is also understood that the containing web page 203 may resize the external iframe window containing the third-party application 40 to a new size (X1 by Y1).

It will also be appreciated that the third party application 40 may only allow resizing to a limited set of possible sizes (e.g., a particular user interface configuration). Thus, the dynamic layout updater 360 may use the following alternative algorithms, which allow the third party application 40 to provide the possible set of sizes.

The containing web page 203 is resized and the dynamic layout updater 360 sends a message to the third party application 40 requesting the third party application 40 to resize its content to a given desired size (X1X Y1). The third party application 40 may then determine the most recent possible size (e.g., X2X Y2 pixels) and resize accordingly using an alternate display configuration, internal resizing, internal dynamic layout processing, or any other means. The updater 380 then sends a confirmation resize response message to the containing web page 203 and provides the actual new size (X2 by Y2). The containing web page 203 may resize the external iframe window containing the third-party application 40 to the actual new size (X2X Y2). The containing web page 203 may continue the dynamic layout process based on the actual new size (X2X Y2).

It will be appreciated that another embodiment is also applicable, particularly when there are multiple third-party applications 40 (or multiple third-party applications 40 with multiple regions) in the containing web page 203. In this embodiment, the containing web page 203 may query the embedded third party applications 40 for a list of display sizes so that they may attempt to optimize look and feel in view of multiple options for multiple third party applications 40. This embodiment is also relevant in case the third party application 40 is displayed on multiple areas.

The containing web page 203 may perform a dynamic layout process that discovers that one or more third party applications 40(TPA [1] to TPA [ n ]) are embedded within the containing web page 203 and should be resized using the following algorithm:

Loop on i from 1 to n:

For each TPA[i]determine

The minimal size Xmin[i]*Ymin[i]；

The maximal size Xman[i]*Ymanx[i]；

The optimal size Xopt[i]*Yopt[i]；

the dynamic layout updater 360 may send a message to TPA [ i ], detailing the above-mentioned min/max/opt size, and requesting information about the possible third party application 40 size.

The third party application 40 may provide a set of possible size options to the dynamic updater 380, which may assume Xposs [ i ] [ j ] Yposs [ i ] [ j ].

Based on the Xpos [ ]/Ypos [ ] information collected above, the inclusion web page 203 can calculate a solution for dynamic layout calculation using, for example, a comprehensive evaluation of all possible third party application size combinations, linear programming techniques, or any other technique used by dynamic layout algorithms.

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

Loop on i from 1 to n:

The containing page 203 may then send a resize message to the TPA [ i ] along with Xfinal [ i ]/Yfinal [ i ];

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

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

It will be appreciated that the dynamic layout process may generally require that the mobile third party application 40 not only be resized. However, the third party application 40 should not change its exact location of the frame within the contained web page 203.

As discussed above, the third party application 40 also needs to change its display window size from time to time. Because the size of the window displaying the iframe is managed by the hosting page (i.e., containing web page 203), the third party application 40 window size change must be executed by the containing web page 203 — the third party application 40 requests (via the dynamic layout updater 360) a change in window size from the containing web page 203.

It will also be appreciated that the third party application 40 may also request (via the dynamic layout updater 360) a change in its location within the containing web page 203. This may not affect the third party application 40 internally (as with the size change), but requires display changes within the containing web page 203. The dynamic layout updater 360 may integrate the request with the dynamic layout. The containment web page 203 may activate the dynamic layout updater 360 to change the third-party application 40 window size (and possibly its position) and confirm that the size and position changes back to the third-party application 40.

It will be appreciated that the hub 205 may also implement additional third party application 40 category specific or third party application specific messages by which the website building system 30 itself, the specific inclusion website 203, or the secondary third party applications 40 may influence the third party applications 40. For example, the blog third-party application 40 may define an incoming message that may publish a new blog entry, or a new dialog to the current blog entry. Such a message may be used by the containing web page 203 (e.g., as posting a blog entry from a larger edit field outside the third party application area). It may also be used for higher level application linking, for example, to allow third party applications to be supported to post blog entries to blog third party applications.

It will be appreciated that the third party application 40 typically requires a variety of complex services-either for internal use by the third party application 40 or for downstream use by the designer of the third party application 40 at its site. Such services may include user management, billing, and transportation management. The website building system 30 provider may not be able to provide such services as part of the website building system (e.g., due to technical or commercial considerations). Furthermore, these services may not be suitable for independently "packaging" as third party applications 40. Additionally, third party application 40 vendors may need an option to provide multiple such services to the designer using third party applications 40 (e.g., multiple third party billing APIs) and allow designer 5 to select the appropriate one for its use.

For example, Paypal may be provided in the website building system 30^TMThe API is hosted and may be used directly by the third party application 40 or provided to the designer 5 by the third party application 40 for use. The third party application 40 may also provide its own set of options (i.e., using a particular billing type, such as one-time, round robin, or revenue sharing) and implement these options by calling the hosted Paypal API.

Thus, a designer 5 utilizing website building system 30 may develop a particular offer (e.g., an electronic store selling songs) that uses pre-billing. Designer 5 may avoid negotiating a particular settlement or wholesale contract with the billing API provider by using a hosted billing API-providing an additional level (or layer) of abstraction, either directly or through third party application 40. In this case, the website building system 30 may become a dealer of the hosted API provider.

The managed API wrapper 390 may facilitate this communication between different parts of the system (e.g., the website building system 30, the managed API code, and the included third party applications 40). It will be appreciated that the API wrapper layer and the actual API implementation may reside in the website building system 30 itself or in another third party application 40. Third party application 40 vendors (or designers 5) can use the hosted API through the hosted API wrapper 390 without knowing the implementation of the actual underlying API.

In alternative and supplemental embodiments of the present invention, applicants have further recognized that intelligent integration between website building system 30 and one or more third party applications 40 can also be achieved through the use of an integration model in which additional website building system templates and components are associated with third party applications at the level of AppStore 25 and with related third party application instances. The third party application 40 may also communicate with these components (and unassociated components) to exchange data and control messages. As described above, the third party application area 40 within the containing web page 203 is a separate iframe, the contents of which are hosted in a separate domain (third party application provider or otherwise) -distinct from the domain hosting the host site. Thus, communication between different iframes is subject to the browser's "same source policy" and requires the use of the techniques described above.

Existing systems implement the third-party application 40 as a monolithic, rigid object that is contained within the containing web page 203, but does not affect the look and feel of the containing web page 203 itself. The third party 40 instance is placed in a (generally rectangular) area and performs all of its activities within that area.

Applicants have further recognized that, in accordance with embodiments of the present invention, this concept can be extended by associating (optional) additional website building system 30 templates with third-party applications 40 (referred to as association templates). It will also be appreciated that the association may be performed during development and publication of the third party application 40, and may be presented to the designer 5 as part of the third party application 40 selection/purchase process (from AppStore 25) and third party application 40 instance creation. TPA coordinator 24 may retrieve a template associated with third party application 40 (either as part of an application library managed by AppSotre 25 or provided by the third party application 40 vendor) and may store the template in library 22 for subsequent use, as described above.

It will be appreciated that the system 100 may support the disclosure of third party applications 40 having multiple associated templates — allowing the designer 5 to select the template that is best suited for its use.

It will be appreciated that when an instance of a third party application 40 is created in any of the contained web pages 203, the components in the associated template may be merged with the contained web page 203 and may be displayed with any other components in the contained web page 203.

Referring now to FIG. 13, an example of the use of an associated template is shown, in accordance with an embodiment of the present invention. As shown, the third party application [ a ] is placed in AppStore [ b ] with an associated template [ c ] that includes parts [ d ] and [ e ]. It will also be appreciated that when a third party application [ a ] is included in the containing web page 203[ f ], the third party application [ a ] may be displayed in its designated area [ g ] within the page [ f ], and instances [ d '] and [ e' ] of the components [ d ] and [ e ] may be displayed on the page [ f ] along with the existing components [ h ] and [ j ].

It is to be appreciated that the system 100 can support a variety of ways in which associated template component instances (e.g., [ d '] and [ e' ] above) are placed within the contained web page 203[ f ]. These may include: absolute placement (i.e., with dimensions and positions specified in the associated template [ c ] for the original [ d ] and [ e ]); target-related placement (i.e., resizing and positioning new instances [ d '] and [ e' ] according to the containing web page 203[ f ]); and the third-party application 40 is relatively positioned (i.e., the size and location of the new instances [ d '] and [ e' ] are picked relative to the size and location for the third-party application instance [ g ] within the containing web page 203[ f ]). Determining a particular placement method may be based on settings included with the associated template [ c ], possibly allowing the designer 5 to overwrite it.

It is also understood that the designer 5 can modify instances in [ f ] of parts [ d ] and [ e ] that are inherited from template [ c ]. Changes may only apply to pages using [ d ] and [ e ] in [ f ] (and possibly inheriting from the website building system 30 that supports inter-page inheritance), but may not affect the "original" template [ c ] associated with the third party application [ a ] in AppSotre [ b ].

It will be appreciated that the above-described changes to [ d ] and [ e ] instances may include, inter alia, assigning specific content (text, images, etc.) to field instances, and routine property changes. It will also be appreciated that if a third party application 40 is included within a mini page, the associated template is applied to the particular mini page that includes the third party application 40, as illustrated in FIG. 14 to which reference is now made. As shown, the third party application 40 is included in the minipage [ x ], thus adding components [ d ] and [ e ] to [ x ], but not to additional minipages [ y ] and [ z ] of the same multi-page container [ g ].

It will also be appreciated that for a section type of mini page, the associated template (if any) is applied to the virtual (and empty) containing web page 203 created to contain the third party application 40.

In an alternative embodiment, a pre-created associated template may be applied in the newly created paged user mini page "in parallel" with the included containing web page 203. The newly created page or mini page may be initialized with templates and then modified as needed.

The website building system 30 may also allow for multi-port containment in which the same third-party application 40 instance is visible from and "resides" in multiple pages of the host site. This is in contrast to multiple inclusions of a given third-party application 40 at the home site, which creates multiple instances of the third-party application 40. The (instance-specific) third party application 40 content is thus shared between multiple views of the same multi-port third party application 40.

In such multi-port inclusion, the associated template may be applied individually to each of the pages and mini-pages to which the third-party application 40 is added.

As described above, the system 100 may provide a 2-way communication link between the third-party application 40 and the components in the containing web page 203. It will be appreciated that this includes inclusion of web page 203 components resulting from merging associated templates from third party applications, as well as templates that are unrelated to any such associated templates.

Thus, it will be appreciated that a third party application 40 provider may typically create a plurality of templates associated with third party applications 40 produced by the provider. These templates may include testing, development, and other templates in addition to the templates that are actually distributed (i.e., associated with the currently distributed third party application version).

As noted above, the third party applications 40 may be distributed through AppStore 25, and may also be distributed through unrelated alternative channels or managed by the website building system 30 provider. However, the associated templates distributed with the third party applications 40 may be highly relevant and coupled to the application library 22 because they are built using components, base templates, and other elements managed by the website building system 30.

Furthermore, website building system 30 elements under such separately distributed associated templates may have to be modified or deleted, which may "destroy" the associated templates. To address this issue, the system 100 may implement these associated templates in separate areas (perhaps each third-party application 40 vendor) within the application library 22. The website building system 30 may manage these templates in the same manner as other website building system 30 templates.

It will also be appreciated that the third party application 40 vendor may be provided with a unique ID (development ID) for each created peony and that ID may be used during the third party application 40 development and testing process. Once the third party application 40 is to be published/distributed, the third party application 40 provider may be required to apply for and receive an alternative unique ID (published ID) and the ID may be referenced in the published third party application 40. Once the publication ID is provided, a separate locked copy of the template is created. This is a copy that is referenced by the third party application 40 and used when creating an instance of the third party application 40. In this way, the third party application 40 vendor cannot falsely modify the template associated with the "live" third party application 40 (being included by the designer) and preserve referential integrity. Further, the system 100 may cross-reference relationships between such locking templates and the root component and base template. Such cross-referencing may be used to provide alerts to website building system 30 personnel, for example, when a website building system 30 component or base template contained within such a locked template is modified (and such modification may somehow destroy the template or third party application 40).

Thus, the system 100 may provide a two-way communication channel between the third-party applications 40, the components contained within the web page 203, and the website building system 30. The contained web page 203 components may be based on templates associated with third party applications, based on other website building system 30 templates, or unrelated to any template.

As discussed above, the communication center 205 may facilitate communication and may provide a back channel between the containing web page and any third party applications 40. Applicants have further recognized that data moving forward and backward between the containing web page and any third party application 40 will be useful once collected, processed, and integrated.

For example, a website owner needs to manage each of its site user groups or members, which is different from the registered user base of the relevant website building system 30. Website users may or may not register (anonymous) and websites may provide different levels of capabilities to different levels of users. In addition, users may typically provide personal or contact information (even anonymous users), e.g., data in a contact form, when they activate instant messaging software to continue with the site owner, or when they connect to a social network as part of working with the site. It will be appreciated that this information may be entered into the created site or may be available as part of interacting with third party applications 40 embedded within the site.

It will also be appreciated that this information may be unorganized, unrelated, potentially contradictory, and many times not saved at all. For example, a single given user may enter his personal email on a contacts form (operated directly by the site) and his work email in a separate subscription form (operated by the third-party application 40) in the same session.

Further, those "floating" information may include different permissions for their use. For example, users populating email addresses in a form are fully willing to receive email-based subscriptions to which they subscribe, and possibly related email presentations. On the other hand, a user who provides an email address as a registration ID may not wish to receive any email at his registration address other than email related to his account handling, security alerts, etc.

Referring now to FIG. 15, a system 200 for coordinating and collecting data from different messages exchanged between a website building system 30 and one or more embedded third party applications 40 is shown. The system 200 includes a client center 210 installed in a client 220, and a server center 230, a contact coordinator 240, an activity coordinator 250, a contact database 245, and an activity flow database 255 installed in a server 260. It will be appreciated that the

centers

210 and 230 may facilitate communication between the website building system 30 and a plurality of third-party applications 40 installed on the server 270, as well as between different third-party applications 40 associated with the center 205 as described above. The contacts database 245 and the activity flow database 255 may store contact/activity information and information extracted from the message flow, as described in more detail below.

Referring now to fig. 16A and 16B, fig. 16A shows elements of client center 210, while fig. 16B shows elements of server center 230, contact coordinator 240, and activity coordinator 250. The client center 210 includes a router 211, a translator and adapter 212, and a privacy policy enforcer 213. The server center 230 includes a router and tracker 231, a translator and adapter 232, a privacy policy enforcer 233, a private data agent 234, and a verifier and signer 235. The contact coordinator 240 includes a data extractor 241, a contact blow-up 242, a data merge pre-243, and a data and permissions handler 244. The activity coordinator 250 includes a stream creator 251, a stream merge front 252, and a record creator 253. The function of these elements will be described in more detail below.

Referring now to fig. 16C and 16D, fig. 16C shows the elements before stream merging 252, while fig. 16D shows the elements before data merging 243. Stream merger 252 includes an activity-to-stream merger 261 and a stream-to-stream merger 262. The stream-to-stream combiner 262 also includes a horizontal stream combiner 263 and a vertical stream combiner 264. Data pre-merge 243 includes contact identifier 272, coalition 273, conflict resolver 274, list value creator 275, vertical contact merger 276, and horizontal contact merger 277. Horizontal contact merger 277 also includes a virtual horizontal merger 278. Vertical contact merger 276 also includes a virtual vertical merger 279. The function of these elements will be described in more detail below.

It will be appreciated that the system 200 may support the transfer of messages between the system 200 and a plurality of third-party applications 40 while providing various capabilities including active message organization through streaming, storing active message history, multi-level active message transfer, utilizing sideband channels for active messages, active message conversion and content adaptation, active message verification and signing, and dynamic active message routing utilizing listener queries as described in detail below.

Further, the system 200 can extract and merge user-related information — combine information from multiple sources as well as information already present in the system 200. This can be done by merging rules that reconcile different and possibly contradictory information. The information of the association may be stored in the contacts database 245. The information may also include a usage permission field that controls the usage of the collected information as allowed, as described in more detail below.

In an alternative embodiment of the present invention, the client center 210 and the server center 230 may be used separately to communicate with a plurality of third party applications 40 installed on the server 270. It will be appreciated that in the case where only client center 210 is used, the contact coordinator 240, the activity coordinator 250, along with

databases

245 and 255, may be locally installed in the relevant clients.

It will also be appreciated that the system 200 may include other components that may allow the third-party application 40 to manage user contact activities (e.g., mass mailing of a briefing) while enforcing usage restrictions set by the user himself. Such components may even isolate the user private data from the third party applications 40 — so that the third party applications 40 can perform their actions without actually having access to the private user data. This capability may be implemented, for example, by private data agent 234, as described in more detail below.

It will also be appreciated that the contacts database 245 may be specific to each site. However, the website building system 30 may define a meta-site/projection level that contains a collection of websites (owned by the same site owner) and allow for the designation of contacts to be stored, processed, and merged at the meta-site level rather than at the individual site level. Other site elements (e.g., included third party applications 40) may also be defined at the meta-site rather than at the site level. In addition to meta-site support, system 200 also typically does not share contacts (other than those described below), or integrate contact information between different sites or different site owners (so that data provided to one site by a given end user is not leaked to another site).

As described above, the system 200 may support a plurality of interactions between the website building system 30 and one or more third-party applications 40. Such interaction may be a predefined activity, such as purchasing, adding an item to a shopping cart, populating contact information, and the like. Third party applications 40 may specify which activities they support, and other third party applications 40 may "listen" to a particular activity and act upon receiving the activity and its associated information. It will be appreciated that the list of listening activities for a given third party application 40 may be explicitly set to one or more activities, or may be determined by the activities listening for queries, as described in more detail below.

It will be appreciated that each activity may be considered a message, and each message may include an activity data structure. The active data structure is a predefined data type, but can be defined by inheritance between them and by third party applications 40 having the option of extending it by adding fields. They may be system specific or may be based on or include standardized data structures. They may also be encoded in some way, such as XML, JSON data, or using a binary object encoding scheme.

The activity data structure may also include a third party application 40 provided in the "description" field. This is based on the activity description of the third-party application 40 (which may be more detailed than known by the website building system 30). For example, the VOIP communication third party application 40 may provide an activity description text of "Call John Smith at 999-.

The activity data structure may also include a callback link, e.g., "more info," which returns the activity data structure. This can be used to provide additional substantive information, for example, for e-commerce activity data structures: complete command tracking information, command history, etc.; for the chat activity data structure: a full chat transcript; and for the phone activity data structure: the call is recorded. Thus, the sample full activity data structure may contain the following fields: creating a timestamp; a type of activity; source of activity (third party application 40/part ID); an active flow ID; activity type specific information (depending on the activity type); creating a site ID; site member database ID; ID/URL of site page where activity occurs; a description of the activity provided by the third-party application 40; more information links used by the third party application 40 and captured user details, etc.

The activity coordinator 250 may be considered a recording element and may receive a delivery message from the center 230. Stream creator 251 may create an initial stream that is considered a record or a link-like structure, and stream merger 252 may add any additional input activity to it, each stream being unique to a contact. It will be appreciated that the stream creator 251 cannot create a new stream for each individual activity contained in a different message. It will also be appreciated that the activities contained in the stream may be out of order (e.g., the third party application 40 may delay reporting activities). The stream merger 252 may merge streams during operation when the streams belong to the same single contact, and the record creator 253 may save a record file on the activity stream database 255 for all previously created activity streams.

As discussed above with respect to fig. 16C, stream merger 252 includes activity-to-stream merger 261 and stream-to-stream merger 262. The activity-to-stream merger 261 can associate an activity with a stream associated with an identified contact, and the stream-to-stream merger 262 can convert two separate streams into a single stream. The horizontal stream merger 263 may merge two unrelated streams into a common initial ID detected, while the vertical stream merger 264 may merge a stream created for an anonymous contact and a stream associated with a registered user, which may connect the two when logging in or registering. It will be appreciated that the stream merger 252 may access previously created streams from the active stream database 255 as necessary.

For example, an anonymous user populates a contact table in a site. The stream creator 251 may create a new active stream (with ID "anon 1") and the contact processor 242 may create a new contact (with ID "anon 1", as described in more detail below). The same user can then chat with the site owner. The stream merger 252 may then merge the activity into the "anon 1" activity six and update the contact "anon 1" (as described in more detail below). The user using a different browser then populates the schedule. Because it is not relevant to the original user, the stream creator 251 can create a new activity stream with ID "anon 2" and the contact processor 242 can create a new contact with ID "anon 2".

The user then purchases the item from the site. The stream merger 252 merges the new activity into the "anon 2" activity stream and updates the contact "anon 2" (e.g., with a "customer" tag).

A user using another browser registers with the site. When registered, all users receive a "user x" ID from the site's member processor. At this point, the stream creator 251 may create a new activity stream (with ID "user x"), and the contact processor 242 may create a new contact (with the same ID "user x").

Later, the user returns from another browser and chats with the site owner. When the site does not have a cookie, the stream creator 251 may create yet another new stream ID "anon 3" and the contact processor 242 may create a new contact "anon 3".

Now, the user logs into the website. At this time, there is a contact with "anon 3" ID and "user x" ID. Before data merge 243, contact "anon 3" may be merged into "user x" so that both login activity in the "user x" stream and the login activity of contact "user x" point to the activity streams "user x" and "anon 3". Stream merger 252 may merge any additional actions performed by the user in the session into the "user x" activity stream. The log creator 253 may record all activity data from the stream and save a copy of the log in the activity database 255.

It will be appreciated that the site owner may access the history of activity streams for a given contact through the relevant user interface provided by the website building system 30, as shown in fig. 17 to which reference is now made. For a single contact, "dani bronstein," the history of his website can be easily accessed. It will also be appreciated that the website building system 30 or third party application 40 may also provide an API to access the log information. It will also be appreciated that the activity log may be used for optimization, user interface improvement, advertising targeting, and the like.

It will also be appreciated that, in parallel, the contact coordinator 240 may gather information from the data provided by the activity stream (message) to build the contact profile of the user in question. Data extractor 241 may extract data from the activity messages and streams and data merger 243 may merge the relevant data into a particular contact, the details of which are stored and accessible from contacts database 245. The contact processor 242 may create new contacts, handle site user identities, anonymous users, etc., and the data and permission processor 244 may handle privacy protection and permission related data. As discussed above, data merger 243 may include horizontal contact merger 277 and vertical contact merger 276. Horizontal contact merger 277 may merge two unrelated contacts due to the detected common primary ID and vertical contact merger 276 may merge anonymous contacts and contacts associated with registered users, both of which may be connected when logged on or registered. The horizontal contact merger 277 may also include a virtual horizontal merger 278 to maintain two contacts as separate, but to link them together so that they can be marked as representing the same contact-with or without merging actual contact information. Vertical contact merger 276 may also include a vertical virtual merger 279 to maintain anonymous contacts separate from contacts associated with registered users, but to link them together so that they are marked as representing the same contact-with or without merged actual contact information. The data merger 243 may also merge contact information (typically extracted by the data extractor 241) into existing contacts. It will also be appreciated that contact identifier 272 may utilize a cookie to track user identity and may identify contacts that should be merged, as discussed further below.

Referring back to fig. 15, 16A, and 16B, messaging may be performed on client 220, server 260, or both. It will be appreciated that the third party application 40 typically has a client side element as well as a server side element, or at least a server side connection to the third party application 40 provider server 270. The hub 210 may handle any messages between the client 220 and the

third party application

40 and 230 between the server 260 and the third party application 40. It will be appreciated that data received by hub 210 may be processed and forwarded to hub 230 for further processing, as described in more detail below.

Referring now to FIG. 18, a messaging scenario between different platforms is shown. User client machine X may connect to website building system 30 on server Y. The website building system 30 may be implemented using a client part a' of the website building system 30 and a server part a of the website building system 30. When a created site is real, it may include a client side element (data/code) B' and a server side element B. The created site may also include three third party applications 40-TPA 1, TPA2, and ETPA 3.

The TPA1 may be implemented by the client-side part D' and the server-side part D connected with the TPA1 vendor server H. The TPA2 may be implemented by the client-side part E' and the server-side part E connected with the TPA2 vendor server I. However, the EPTA3 may be a server-side only third-party application 40 implemented by the server-side component G that is connected to the website building system 30 third-party application 40 that supports the backend F. Both of which may communicate with the third party application 40 provider server J.

It will also be appreciated that TPA1 and TPA2 may exchange messages on the client (between components D 'and E'), on the server (between components D and E), or both. However, any communication with EPTA3 must only be done on the server. It will also be appreciated that advantages and disadvantages exist with either approach. Client-side active messaging may be more interactive and provide faster user responses. Server-side active messaging may be more robust, more reliable (e.g., the user cannot close the browser window in the middle of the process), provide better assurance of the correct order of message receipt, and may also allow active messages to be sent to a backend third-party application 40 installed on the backend or application dashboard.

An example of a situation where multiple third party applications 40 are utilized is where a user adds a product to a shopping cart in third party application A (the activity type is "cart change"). The third party application a may then send the campaign message with the added product to the website building system 30. The website building system 30 may then forward the activity to all third party applications 40 registered with the vehicle change. Since the third party application B is already registered, it receives activity. The third party application B may then display a message to the user, such as "if you also add product X you can get a discount" or "share the site for a discount".

Another example is that the user "likes" something in the third party application a (via, e.g., Facebook). The third party application a may then send the activity message to the website building system 30 with the activity type "Facebook like". The website building system may then forward the activity to all third party applications 40 registered to "like" the activity. Since the third party application B is already registered, it receives activity. The third party application B may display a re-intervention widget to the user and display a message such as "how do you contact the site owner if you like the site? "or" do you want to discount a coupon? "

As described above, all communications may occur via

hubs

210 and 230.

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

The router and tracker 231 routes messages between the web site and any third party application 40 and may also track messages. It will be appreciated that the third party application 40 also listens for messages on the client and server. It will also be appreciated that the third party application 40 may explicitly specify one or more activities it listens to, for example, listening to all "shopping cart-add items" activities. The third party application 40 may also specify the activity category it is listening to, for example, listening to all Facebook related activities. Further, the third party application may include a wildcard expression (applied to the campaign name) that is used to determine whether the campaign should be sent to the third party application.

It will also be appreciated that the third party application 40 may use an activity listener query. Such queries may refer to additional system information, including information not normally available to the third party application itself, such as: user attributes (e.g., only registered users, only european users, etc.), website attributes or structures (e.g., only listening to given activities on pages derived from a given page template), user history (e.g., only listening to shopping cart checkout activities when a user has purchased more than X in total), etc. Such queries may be specified by the third party application 40, but may also be edited by the designer.

Thus, the router and tracker 231 may also track messages that third party applications 40 are listening for. It will be appreciated that this activity listener query architecture is best implemented at the activity routing level (rather than by API calls internal to the third party application 40) because it may allow the website designer to perform tailoring and customization without requiring the third party application 40 to be highly programmable and customizable. The router and tracker 231 also helps to preserve user privacy because the website designer does not provide additional information (needed for routing decisions) to the involved third party applications 40. It may also save unwanted communication calls with third party applications 40, typically hosted on a separate server.

It is understood that a user (website visitor) accesses, registers, and provides information to a website. The user is effectively unaware that the website he or she visits is being built using a combination of the website building system 30, components, building websites, and third party applications 40. Thus, the responsibility for user privacy ultimately depends on the website owner (who is also responsible for the actions taken by the third-party applications 40 contained in his or her website).

It will also be appreciated that user profile information may be accessed by the third-party application 40 (and other website building system 30 components) based on privacy rules defined by the website building system 30 and the API provided by the website building system 30. Further, the inclusion site and the third party applications 40 included therein may use the contact information to communicate with the user (via email or otherwise).

It will be appreciated that there are three main privacy-related issues. The first is the interaction of the website and website building system 30 with the third party application 40 provider. The website (and website building system 30) may not have complete trust in the third party application 40 using its user data, e.g., the third party application 40 may not mass mail (using the user's e-mail provided by the website), request removal of spam users from the mail, or transfer user personal information to a fourth party. However, the solution can be made in the following manner:

The website building system 30 provider may require that the third party application 40 provider sign a terms of use (ToU) agreement when adding it to the website building system 30 application marketplace. Such a protocol may state that the third party application 40 (with the third party application 40 provider) cannot misuse or otherwise disclose the user's information. The website building system 30 provider may then penalize the third-party application provider if the third-party application provider abuses the information (e.g., disable the third-party application 40, remove the third-party application 40 from the website building system 30 application marketplace, etc.). The

privacy policy enforcers

213 and 233 and the private data agent 234 may enforce privacy policies on the third party applications 40, as described in more detail below.

A second privacy-related problem is the interaction of the website and website building system 30 with the user (site visitor). The website must provide the user with a clear understanding of how his or her personal data will be used, receive agreements from the user and comply with terms agreed to by the user. The website building system 30 requests all publishing sites to provide the user with ToU documents that define the allowed use of the term user's private information and requires the user to electronically sign the documents. The site must then comply with these terms and allow use. The website building system 30 may also include a sample ToU page in each of the website templates it provides. The

private policy enforcers

213 and 233 may ensure that the terms of use of the ToU document are maintained. The

private measurement enforcers

213 and 233 may also ensure that only allowed information is provided to the TPA by deleting or rearranging relevant data.

A third privacy-related problem is the support of unsubscribe requests. The site must provide the user with the option to cancel out any marketing emails. This may be handled by the data and permission processor 244, as described in more detail below.

Data and permissions processor 244 may also process different user permissions set by different users, as described in more detail below.

The private data agent 234 may allow the website building system 30 (and websites built in the meantime) to maintain all or some of the private data in a secure repository managed by the website building system 30, and may provide a substitute unique ID (instead of the private data) to third-party applications, which may be used by the website building system 30 to retrieve the hidden private data. For example, the email address is replaced by an alternate "email address ID" provided to the third party application 40, such that the third party application 40 cannot access the actual email address.

The private data broker 234 may also provide a set of interfaces for various communication methods (e.g., email, social network messaging, etc.) that may be used by the third-party application 40 to contact/send messages to the user without requiring the third-party application 40 to actually access the private data associated with the user. Such private data may include all identifying details by which a user may be contacted, including (for example): name, address, email, phone (including SMS/MMS), unified messaging ID (Skype, etc.), and social network ID.

Private data broker 234 may thus enforce user permission field restrictions, enforce a user to cancel a subscription request, and restrict user messaging, e.g., allow no more than 100 emails per day for a given third party application 40 working for a given site. The private data agent 234 may define agent parameters, and which private data to expose to third party applications and which to hide-based on each third party application 40 and set on a field-by-field basis.

For third-party applications 40 hosted on the website building system 30 server, the private data agent 234 may provide an alternate unique ID that is similar in form to the original private data (e.g., provide an alternate virtual email instead of the original private user email), and then "capture" the call using the information and forward the email (in this example) to the correct address. This can also be used to detect any third party application 40 that exceeds its permitted rights.

It will be appreciated that the website owner may wish to provide limited or modified information to any particular third party application 40. This may be due to, for example, general security concerns, specific privacy commitments regarding any element of user data, or management requirements specific to a particular industry or application.

Private policy enforcers

213 and 233 may implement any such changes made by the website owner and override the current settings.

An example may be a website that handles medical information that may be of interest in blocking some personal affiliations from contact information when passing to the general geographic user distribution analysis third party application 40. In another example, the third party application 40 may have problems handling certain types of contact information. A website owner who wants to continue using the third party application 40 (even if a known failure) may want to filter out contacts that trigger a known problem or modify the data so that no problem is triggered.

The converters and

adapters

212 and 232 may apply pre-specified message conversion and content adaptation rules. Each such rule may include conditions, such as its application to those third-party applications 40, selection of filtering criteria that it applies to those messages, transition rules (e.g., involving dropping a given message (with respect to the relevant third-party application 40)) or a transition to be applied to a given field or fields in the active data structure.

Thus, the

hubs

210 and 230 may deliver different versions of the active data structure (or none at all) to different third-party applications 40, depending on the specifications established by the site owner.

The relevant website building system 30 may also support verification and signing of messages to enhance the system against failure and interruption attempts (e.g., man-in-the-middle attacks that want to modify the third party application 40 message payload data). Thus, each third-party application 40 registered with the website building system 30 may have two sets of private/public keys: one set is used to decode messages sent from the third party application 40 to the website building system 30 (input keys) and the other set is used to encode messages sent from the website building system 30 to the third party application 40 (output keys).

For example, the third party application a may send a message to the website building system 30. The message may be sent with a third party application ID for the site that is external to the third party application (has a third party application scope) and that may be signed by the third party application. The website building system 30 may receive the message. The verifier and signer 235 may verify the signature using the input key of the third party application a. If the verification fails, the verifier and signer 235 may report the incoming message as invalid and no longer transmit the message.

The verifier and signer 235 may translate the external ID associated with the message using the internal site ID. The verifier and signer 235 may determine which third party applications 40 should obtain the message.

For example, for each third party application B1.. Bn, the verifier and signer 235 may discover the external ID of the third party application B. The verifier and signer 235 may then create a message to the third party application B and instruct the converter and adapter 212/232 to apply any applicable filtering and transformation rules as described above. The verifier and signer 235 may then sign the message with the output key of the third party application B and send the message to the third party application B via the router and tracker 231 (or the router 211). The third party application B may then receive the message and verify the signature. If the current authentication fails, the message is reported as invalid and is not processed further. It will be appreciated that the verifier and signer 235 may perform only server-side and not client-side processing to ensure that secret verification data is not sent to untrusted clients.

As discussed above, the system 200 may employ various types of communication between the website building system 30 and the third-party applications 40. These may include, for example, control communications, such as the website building system 30 commanding the third-party application 40 to close; functional communications, such as the shopping cart third party application 40 sending the total purchase amount to the billing third party application 40 through the website building system 30, affect the payment or activity communications of the examples discussed in this specification. It will be appreciated that these different kinds of communications have different profiles and requirements, for example in terms of message throughput, robustness, response time requirements, etc.

In particular, the system 200 may include very frequent activity reports (e.g., if a third-party application 40 Graphical User Interface (GUI) event is in the reported third-party application 40 activity). Such multiple activity reports may cover portions of the system that handle more critical messages. Thus, system 200 may implement multiple communication channels (e.g., utilizing different ports, multiple concurrent sessions, etc.) such that each type of message is sent via a separate channel. In this way, the activity report uses the sideband channel and is parallel to and does not interfere with command and function communications.

As discussed above, the system 200 may collect activity information to create and enhance contact information via the contact coordinator 240 and the activity coordinator 250 and to check for activity events associated with particular contacts. For each activity message routed through

centers

210 and 230, contact coordinator 240 and activity coordinator 250 may process the information. The stream creator 251 may create a contact-specific data stream from the activity message, and elements of the contact coordinator 240 may extract the data and process it before storing it in the contact database 245.

Thus, each activity stream may have structured contacts associated with it that may be enhanced by data extracted from the activities performed under the data stream. It will be appreciated that the contact coordinator 240 may also identify the presence of related contacts-multiple contact records found to describe the same person. Contact identifier 272 may identify such records by matching primary ID fields (e.g., email, phone number, social security number, Facebook ID, etc.). It will be appreciated that some primary ID fields are multi-valued fields (e.g., one may have multiple identifying emails), while some are strictly single-valued fields (e.g., social security numbers).

Thus, the data merger 243 may merge the contact fields extracted from the new activity into the currently constructed contacts and may merge the constructed contacts constructed for the anonymous user during use of the website into the predefined saved contacts once the anonymous user has performed a login operation and has become the identified user (this is known as a "vertical" merge). The horizontal contact merger 277 may also perform a "horizontal" merger of two different contacts (either constructed contacts or stored contacts) when these are detected to be related contacts involving the same user. As discussed above, such merging may be performed by an actual merging of one contact into another (i.e., converting two separate contacts into a single contact), or by a virtual merging (i.e., maintaining two contacts as separate but linking them together so they are marked as representing the same user — with or without merging actual contact information and activity streams). It will also be appreciated that even in virtual mergers, additional added information may be added to multiple linked virtual merged contacts.

Thus, the data extractor 241 may extract contact type information from the related data activity structure, and the data consolidator 243 may integrate the contact type information into the contacts (anonymous or identified) associated with the activity stream. If the contact type information I contains a primary ID field, the data merger 243 may check for relevant contacts based on the primary ID field value and, if found, merge the contacts. The data consolidator 243 may also check if the activity established the user identity in the site (e.g., site login activity), and if so, merge the anonymous contact with the existing contact record recorded for the user and make it the identified contact from there.

It will be appreciated that contact identifier 272 may implement a variety of methods to identify a site user, for example, by using a network tracker to track conversations of a single anonymous user (who is not logged into the site), utilizing a registered user's site login, a social login of a site user associated with a social network through an account, or by matching primary ID fields (e.g., email/phone) to identify two user profiles describing the same user.

It will also be appreciated that site users whose details are stored in the contacts database 245 may be classified as anonymous users that are not registered at the site; registered users and potential users — records (imported from external sources) of potential users that have not formally registered with the site.

Because the relevant web site may install a persistent cookie that persists from session to session, multiple anonymous sessions running on the same computer using the same browser may continue to record contribution information for the same contact. Thus, even anonymous users may have considerable text and contact information.

The registered user must provide an ID unique to a particular site. Multiple types of IDs may be used, such as a separate site-specific ID (e.g., a username), an external identifier (e.g., an email, a phone number, or a social security number), or an external identifier provided by a different system (e.g., a social network ID, OpenID identification, etc.).

Logging in a registered user through a social network may allow a site to populate the site profile of the same user with personal information available in the social network. The data extractor 241 may also revisit the social network profile to detect any changes to the personal information and may update the site user profile.

A registered user must typically log into the system in order to establish her or his identity, but the system may provide a "keep me connected to the system" option. Such login procedures are explicit (user invokes a login dialog), implicit (user is required to provide some identification details, e.g. when adding a dialog to a blog), or may be based on external login (system invokes a login procedure associated with a different system, e.g. a social network login or an OpenID login). The login process may also be influenced by a physical device (e.g. a security token connected to the system directly or via a wireless interface) or by biometric information usage (including biometric parameters of the user, such as a fingerprint or iris scan; and behavior detection of the user, such as typing pattern detection) or any combination of the above detailed methods.

It will also be appreciated that the social login process may interact with a conventional login in both directions. For example, the social ID may be associated with a site member ID, such that a social login would imply a site login, or the site member ID may be associated with one or more social network IDs, such that a site login may also identify a user of one or more social networks.

When the user performs an explicit logoff, the contact processor 242 may generate a new anonymous user cookie and thus open a new anonymous session (or series of sessions) whose activity will be preserved under the new anonymous contact. The new anonymous contact may be merged when a subsequently identified contact is logged in again.

Referring now to FIG. 19, a process for logging in and out of an anonymous user is shown. The user may begin using the system anonymously. The contact handler 242 may create a contact and the flow creator 251 may automatically create an activity flow anon1 when the user performs the first third party application action act 1. Stream merger 252 may merge information from act1 and from subsequent activities act2 and act3 to user anon 1.

Once the same user performs a login as user X, the data merger 243 merges the anon1 contact (and any other relevant contact data retrieved from the activity stream) into the contact information for user X. It will be appreciated that stream merger 252 may also merge information extracted from the other actions act4 and act5 into a single stream, and data extractor 241 may then extract contact information for user X. When user X performs a logoff, the contact processor 242 may create a new cookie, disassociating other activities from user X. Thus, when a new activity act6 is performed, the contact handler 242 may create a new anonymous contact anon2 and the data extractor 241 may save the extracted contact details (and activities) under the newly created anonymous contact anon 2.

If (as in scene A) user anon2 performs a second login as user Y, data consolidator 243 may consolidate contact anon2 (as updated by act6 and act 7) and any further activities into the contact details of identified user Y.

If (as in scene B) user anon2 performs a second login (repeated) as user X, data consolidator 243 may consolidate the contact information for user anon2 (as updated by act6 and act 7) along with any other activity into user X's contact details (which have been updated to reflect act1-act 5).

It will be appreciated that the activity data structure associated with an activity may also include contact details. The data extractor 241 may extract this information and forward it to the data consolidator 243, which data consolidator 243 may integrate it with existing contact information into a contact database 245, which may augment it. It is also understood that the data extractor 241 may extract details from a particular activity message, from the entire flow, from other contacts, or from an external source (e.g., IP) to a geographic address translation service, as described in more detail below. As discussed above, the contacts in contacts database 245 may also contain contact details that are explicitly provided by the user as part of the enrollment or registration process for the website, extracted from the social networking account used by the user when enrolling in to the website (via a social login/enrollment feature), or provided by the user when updating his or her profile. The data extractor 241 may also retrieve contact information from an external source (e.g., when the user specifies only the united states zip code, and this is used by the site to retrieve the full address information from an external zip code decoding web service).

As discussed above, the contact identifier 272 may identify two contacts as related based on a primary ID field (e.g., a user name, email, or phone number). Once contacts A (new) and B (existing) are found to be related, the data merger 243 may merge A into B (B is primary). This may be done using field merging rules such as:

b1 ═ B or a (e.g., "B | | a"); taking B, and if B is empty or empty, taking A;

b1 ═ math-func (a, B); important private situations are:

b1 ═ a + B; for example, number of visits, total number of purchases;

b1 ═ min (a, B); for example, date syndication sites;

b1 ═ max (a, B); for example, the last activity date;

b1 ═ list-unit (B, a); list a is concatenated at the end of B, removing the elements in a that duplicate the elements in B (i.e., B1 ═ B & (a-B)). The data merger 243 may determine duplicates among list members according to the following rules:

for lists that include regular values (i.e., scalars), regular value comparisons are used;

for lists that include structures, a particular subfield of the structure is used as a compare key. For example, the type of address in the website building system 30 that supports multiple addresses (home, office, delivery …);

And comparing normalized values. See, for example, the following processing telephone numbers:

if structure A is a more detailed version of structure B, then A is joined to B (described in more detail below), an

A higher certainty score-value may have a certainty score attached to it (e.g., having a different certainty score for information provided directly by the user than information inferred about the user). The data merger 243 may select a value with a higher certainty score.

It will be appreciated that some field types have a standardized format. For example, the telephone number may be normalized to a U.S. format (e.g., (999) 555-. The data merger 243 may translate field values into a normalized format for comparison, such as when comparing primary contact keys (e.g., phone numbers), and when checking for duplicates in a merged list.

The data merger 243 may compare two structure values having the same underlying structure-e.g., address values comprising a plurality of subfields (country, state, zip code, street, number, etc.). Structure Y is a detailed version of structure X if the values of the non-null fields within structure X are equal to the values of the same fields in structure Y, i.e., Y includes all the non-null field values of X and possibly some additional field values. Thus, if A is a detailed version of B and A is not identical to B, the data consolidator 243 consolidates A into B.

It will be appreciated that the data extractor 241 may infer the contact address from the IP address from which the activity came. This is only used when an activity has arrived from a browser session and the user does not have an address. Accordingly, the data extractor 241 may extract the state/country information according to the geographical information of the IP address. In this case, the address is labeled as "estimated geographic IP address". This is necessary so as not to interfere with future address mergers-this may prevent subsequent detailed (but substantially different) addresses from being saved to the contacts database 245 due to the IP mapping based address field containing existing (and possibly inaccurate) addresses.

The data merger 243 may also handle tag collisions for the merged list. It will be appreciated that in the case of a merged list, it is possible to enter a situation where there are two entities, one from contact a and the other from contact B, both different but having the same label. In this case, the data merger 243 may merge the lists by having both with the same tag in the list.

Thus, the combination [ { tag: "home", email: "a @ b.com" } ] + [ { tag: "home", email: "c @ d.com" } ] may create [ { tag: "home", email: "a @ b.com" } ], [ { tag: "home", email: "c @ d.com" }. This may be used when the merge field is marked as "allow non-unique list tag".

The data consolidator 243 may also use language, grammar, or other text parsing methods when attempting to syndicate contact information, as well as consultations with external data sources or services. For example, the user may also write his or her family street name in two different ways in two activity records, but specify the same family number, city, and zip code. The consolidator 273 may apply text analysis (e.g., a probe algorithm) when comparing two entities, and may also compare two versions of street names with external sources of street names for a given city and zip code. In this case, the joiner 273 may select a canonical street name if the two streets are similar to (but possibly different from) the canonical name and all other address data fields have the appropriate values.

The data consolidator 243 may also consolidate contact information based on login/session information. A user may use a site without logging in or registering, start a session, perform some activity as part of the session, and later register or log in, thus associating the session with a newly created or existing registered user profile (containing contact information).

Once the user begins a session (anonymous), contact identifier 272 may track the user during the session (using a cookie, session ID, etc.), and based on the activities the user performs during the anonymous session, contact processor 242 may create a constructed contact for the particular anonymous user. The router and tracker 231 may also continue to track anonymous users across multiple sessions from the same computer. This may be done by using a persistent network (rather than a session network tracker) tracker.

When the user registers, the data consolidator 243 may initially populate the user profile with the constructed contact information. If the user logs in, the data consolidator 243 may initially associate the constructed contact information with the existing user profile. It will be appreciated that the constructed contact information is consolidated based on the user's site ID, as the data consolidator 243 may not have any other primary IDs (e-mail, etc.) for the constructed contacts to consolidate. It will also be appreciated that any such combination may reveal inconsistencies in the information collected. When merging anonymously constructed contacts with existing profile data, conflicts can occur and are inevitable. For example, an anonymous user populates a data form (displayed by some third party application 40) with the name John Smith, and then later logs under the account of the name Jane Doe (using the same or a separate browser session). It is possible, for example, that later login is actually a second person using the same computer, or that the user uses a pseudonym in the contact table to preserve his or her privacy. The same situation may occur when the data merger 243 merges multiple anonymously constructed contacts.

The conflict resolver 274 can typically automatically handle conflicts because most fields (including major key fields such as email and phone) are list fields that may contain multiple values. This may only apply to multiple uses of the same root site. Any such inconsistencies that cannot be resolved (e.g., by incorporating multiple values into a list of values) may be flagged for manual processing by the site owner, perhaps by the end user (who may determine which value to use) or using other techniques.

Thus, it is possible that the structured contact information may reflect not only a single person, but a combined set of users accessing the same site via the same computer.

As discussed above, the data merger 243 typically merges contacts according to primary ID fields (e.g., email and phone number) when they are created or modified.

The input is a contact record (input contact C) that includes one or more primary ID fields having one or more values (e.g., a contact record having 2 emails and 3 phone numbers). Multiple primary ID fields may be required because the user may have, for example, a home/work/cell phone number and a home/work email, and the user may use either interchangeably in the contact table.

The data merger 243 may normalize the primary key value and create a query for contact records containing any normalized primary key value, e.g., "(phone P1 or phone P2) or (E-mail E1 or E2)". The data consolidator 243 may also restrict queries to the contact database 245 for a particular site. The data consolidator 243 may also query the contacts database 245 and retrieve the matching contacts list L (which includes the input contact C).

If the incoming contact is a registered site member (of a particular site), the data merger 243 may remove contact C from list L and merge all contacts remaining in list L into contact C. The data consolidator 243 may then save the updated contact C back to the contacts database 245 and remove all contacts remaining in list L from the contacts database 245. As discussed above, the data merger 234 may instead perform a virtual merge, concatenating all contact information (i.e., updating all contact records to contain all available information) and marking matching contact records as belonging to the same person (rather than deleting "duplicate" contact records). This may be required, for example, when third party applications 40 store or use internal IDs specific to contact records, so that deleting contact records will cause these third party applications 40 to fail. The same process (i.e., marking contacts as related rather than deleting contacts) may be applied in other scenarios discussed in more detail below.

If the incoming contact is not a registered site member, the data consolidator 243 may check how many site member contacts are present in the list L. If there are 0 site members, contact C may be removed from list L and all contacts remaining in list L merged into contact C. The data consolidator 243 may then save the updated contact C back to the contacts database 245 and remove all contacts remaining in list L from the contacts database 245.

If there are 1 site member (contact D), data merger 243 may remove contact D from list L and merge all contacts remaining in list L (including contact C) into contact D. The data consolidator 243 may then save the updated contact D back to the contacts database 245 and remove all contacts remaining in the list L from the contacts database 245.

If there are two or more site member contacts (D, D1, D2 …), the data consolidator 243 may select contact D from the site member contacts found in (D, D1, D2 …) and remove contact D from the list L. A sub-list LL may then be created from the list L of contacts included in the list L that are not members of the site. Data merger 243 may then merge all contacts remaining on list LL into contact D. Data merger 243 may then save updated contact D to contacts database 245 and remove all contacts remaining in list LL from contacts database 245.

As discussed above for login merging, inconsistencies in the data may occur. However, since the list value creator 275 may create a list value field (having a plurality of values) and may define a net precedence (clearpriority) between contacts, no problem occurs in most cases.

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

Contact1＝[Phone1,em1]；

Contact2＝[Phone1,em2]；

Contact3＝[Phone2,em2]；

a combined contact may be generated:

Combined-Contact＝[Phone＝[Phone1,Phone2],Email＝[em1,em2]]。

it will be appreciated that the contact database 245 may include contact information from multiple sources and have different levels of permissions for use. The following discussion designs an email; however, the discussion and techniques apply to any type of information (phone, fax, Skype ID, instant messaging ID, social network ID, etc.) used to contact a user as described above.

For example, the manner in which the email address is provided to the site may indicate different permissions for use. Some possible sources for email addresses are: registering the ID; contact form, presentation registration and unsubscribe request. The email address may also differ in terms of an "allowed usage protocol" that is electronically signed by the user.

It will be appreciated that the website building system 30 typically has information about the allowed use for a given email. However, the website owner may have different, independent, or additional information. For example, due to the nature of different registration formats in the site, or due to having contacts in the system that are entered by the website from different sources including additional use license information.

The data and permission processor 244 may enforce the correct usage policy on third party applications 40 used in the site to help the website owner manage the information.

Thus, a contact record for a related contact may include two fields of information. The first field is a website permissions field containing derived or suggested permissions calculated by the website from user activity. The contacts table implies only function emails, while the subscription table may imply loop emails. The second field is a site owner permission field based on the site permission field value. The site owner can change the site recommendations and do anything he or she likes, but he or she is responsible for any usage that exceeds the permissions defined by the site permissions field.

It can be appreciated that the website permission field value represents the best knowledge of the website the user intended. The site owner permission value is a value assigned by the website and is used by the third party application 40 and other parts of the system (e.g., by the third party application 40 providing the presentation delivery).

Data and permissions processor 244 may use these permissions fields to define permissions in a variety of ways. For example, the data and permission processor 244 may implement any one of the following codes (for email and other contact IDs), or a combination or variation thereof:

Unknown-email is extracted from an unknown source and cannot be used for any email transmission.

Email ID-email provided for registration purposes. It cannot be used for any e-mail delivery except for registration related issues such as confirmation of registration, forgetting a password and suspected security breach notification.

Function email-email is provided for a specific function and allows for one-time email. For example, a purchase confirmation email, or an email provided for a particular contact form.

Looping email-allowing a particular web site to send multiple and periodic subscriptions and advertisements. This requires explicit subscription/approval.

Shareable email-allows websites and their partners (third party applications 40, fourth parties) to send multiple and periodic subscriptions and advertisements. This requires explicit subscription/approval and may include detailed information about the allowed sharing.

Opt-out-the user explicitly unsubscribes. No email is sent to the user (except for possible opt-out notifications).

It will be appreciated that the data and permission processor 244 may use alternative methods, such as permission bitmasks (similar to those used on UNIX and Linux systems) or ACL (access control list) mechanisms. Data and permissions processor 244 may also implement separate permissions fields (e.g., email, instant messenger address, social network ID, etc.) for separate portions of the contact information.

A typical usage scenario is where the contacts database 245 contains collections from contact tablesAnd a second group collected from the subscription request. The website may invoke the briefing sending third party application 40 knowing that the third party application 40 will beOnly byAn email is sent to the user belonging to the second group (who sends the subscription request).

Advantages of such a system include better (technical and legal) protection of websites and website owners from accidental spam or private information abuse by users, and the practical enforcement of privacy policies when used in conjunction with the private data broker 234 as described above. It can also be ensured that the unsubscribe request is more strictly enforced.

Thus, the user can generate a stream of activities between the relevant website building system 30 and any relevant third party applications 40. Such a flow may be known as an active flow. Each activity stream may serve as an information source for a single contact. If it can be determined that different activity streams come from the same source, the activity data structures of the individual streams can also be merged to form a contact. For example, a single user may work anonymously through two devices (e.g., a mobile device and a personal computer). Such a user may create two anonymous streams that may store messages. Once the streams have been identified as being associated with the same user, they may be merged.

The processes and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the desired method. The desired structure for a variety of these systems will appear from the description above. In addition, 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 may be used to implement the teachings of the invention as described herein.

Unless specifically stated otherwise as apparent from the preceding discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing," "computing," "calculating," "determining," or the like, refer to the action and/or processes of a computer, computing system, or similar electronic computing device, that manipulate and/or transform data represented as physical (e.g., electronic) quantities within the computing system's registers and/or memories into other data similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices.

Embodiments of the present invention may include apparatuses for performing the operations herein. The apparatus may be constructed for the desired purpose or it may comprise a general purpose computer selectively activated or configured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, magneto-optical disks, and read-only memories (ROMs). Compact disc 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 cards, flash memory, or any other type of media suitable for storing electronic instructions and capable of being coupled to a computer system bus.

While certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents may occur 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 as fall within the true spirit of the invention.

Claims

1. A system for a website, the system comprising:

a database for storing at least current contact information for a user of the website;

An activity coordinator to receive at least one activity message exchanged between the website and at least one third-party application embedded in the website;

a contact coordinator to collect contact related information for at least one of the following from the at least one activity message: the contact is a new contact and the contact is an anonymous contact, and a contact profile of the user is constructed; and

wherein the contact coordinator augments the current contact related information to the database using the contact profile.

2. The system according to claim 1 and wherein said activity coordinator comprises at least one of:

a stream creator for identifying the contact associated with the at least one activity message and for creating an activity stream of data if no associated contact exists; and

a stream merger to merge data from the at least one active message into existing streams and to merge data from at least two of the active streams into a single stream.

3. The system of claim 2 and wherein the contact coordinator comprises at least one of:

A data extractor for extracting the contact-related information from at least one of: the at least one activity message, the activity stream, the current contact information for the contact, and an external source;

a data merger for merging at least two contact information records, wherein the records are associated with the same identified contact and for merging the extracted contact related information into contact related information of an existing contact according to a predefined merging rule;

a contact processor for creating at least one of a new contact and an anonymous contact that can be identified, and for tracking contact activity during a session of the website; and

a data and permission processor for processing privacy protection and permission of the extracted contact-related information.

4. The system of claim 1 and wherein said system is implementable on a client.

5. The system of claim 1, wherein the at least one third-party application is at least one of: a social network, and an interface to the social network, an interface to social network messaging software, and an instant messaging system.

6. A system according to claim 2 and wherein said data extractor saves its extracted contact details under a newly created anonymous contact.

7. The system according to claim 3 and wherein said data merger comprises at least one of:

a contact identifier to perform at least one of: locating a same primary ID field value in at least two of the contact information records, locating a same primary key field value when normalized in at least two of the contact information records, identifying a site user with a network tracker, identifying a site user with a site login for a registered user, and identifying a site user through a social login for a site user having an account associated with a social network;

a federator for federating contact information using at least one of language, grammar, text analysis, and consultation with external data sources and services;

a conflict resolver for resolving conflicts between contact records according to predefined rules;

a list value creator for creating a list value field to define a net precedence between the contact records;

A horizontal contact merger for merging two unrelated contacts due to the detected common primary ID; and

a vertical contact merger to merge anonymous contacts with contacts associated with registered users when a login or registration is enabled that connects the anonymous contacts with the contacts associated with the registered users.

8. The system of claim 2, wherein the stream merger comprises an activity-to-stream merger to merge the data into the stream associated with the identified contact, and a stream-to-stream merger to merge at least two separate streams into a single stream.

9. A system according to claim 8 and wherein said stream-to-stream merger comprises at least one of a horizontal stream merger for merging said at least two separate streams according to an identified common contact and a vertical stream merger for merging a stream created for an anonymous contact with a stream associated with a registered contact user when a login or registration of said anonymous contact and said registered contact user can be connected.

10. The system of claim 7 and wherein said horizontal contact merger comprises a virtual merger for maintaining at least two contact records as separate and linking them together, thereby marking them as representing the same contact.

11. A system according to claim 7 and wherein said vertical contact merger comprises a virtual merger for maintaining an anonymous contact and a contact associated with a registered user as separate and linking together said anonymous contact and said contact associated with a registered user so as to mark said anonymous contact and said contact associated with a registered user as representing the same contact.

12. The system according to claim 2 and wherein user permission field is at least one of said website determined and said website owner determined.

13. A method for a website, the method comprising:

storing at least current contact information for a user of the website;

receiving at least one activity message exchanged between the website and at least one third-party application embedded in the website;

collecting contact-related information for at least one of the following from the at least one activity message: the contact is a new contact and the contact is an anonymous contact, and a contact profile of the user is constructed; and

wherein the collecting utilizes the contact profile to augment a database with current contact related information.

14. The method of claim 13 and wherein receiving at least one activity message comprises at least one of:

identifying the contact associated with the at least one activity message and creating an activity stream of data if no associated contact exists; and

merging data from the at least one active message into existing streams, and merging data from at least two of the active streams into a single stream.

15. The method of claim 14 and wherein collecting contact-related information comprises at least one of:

extracting the contact-related information from at least one of: the at least one activity message, the activity stream, the current contact information for the contact, and an external source;

merging at least two contact information records, wherein the records have an association with the same identified contact, and merging the extracted contact related information into contact related information of an existing contact according to a predefined merging rule;

creating at least one of a new contact and an anonymous contact that can be identified and tracking contact activity during a session of the website; and

Privacy protection and permissions of the extracted contact-related information are processed.

16. The method of claim 13 and wherein said system is implementable on a client.

17. The method of claim 13, wherein the at least one third party application is at least one of: a social network, and an interface to the social network, an interface to social network messaging software, and an instant messaging system.

18. The method of claim 14 and wherein extracting the contact-related information saves the extracted contact details under a newly created anonymous contact.

19. The method of claim 15 and wherein merging at least two contact information records and merging the extracted contact-related information comprises at least one of:

performing at least one of: locating a same primary ID field value in at least two of the contact information records, locating a same primary key field value when normalized in at least two of the contact information records, identifying a site user with a network tracker, identifying a site user with a site login for a registered user, and identifying a site user through a social login for a site user having an account associated with a social network;

Syndicating contact information using at least one of language, grammar, text analysis, and consultation with external data sources and services;

resolving conflicts between contact records according to predefined rules;

creating a list value field to define a net precedence between the contact records;

merging two unrelated contacts due to the detected common primary ID; and

merging an anonymous contact and a contact associated with a registered user when a login or registration that can connect the anonymous contact and the contact associated with the registered user.

20. The method of claim 14, wherein merging data from the at least one active message into existing flows and merging data from at least two of the active flows into a single flow further comprises: merging the data into the stream associated with the identified contact, and merging at least two separate streams into a single stream.

21. The method according to claim 20 and wherein merging at least two separate streams into a single stream comprises at least one of: merging the at least two separate streams according to the identified common contact, and merging a stream created for an anonymous contact and a stream associated with a registered contact user when login or registration of the anonymous contact and the registered contact user can be connected.

22. The method of claim 19 and wherein merging two unrelated contacts comprises maintaining at least two contact records as separate and linking the at least two contact records together, thereby marking the at least two contact records as representing the same contact.

23. The method of claim 19 and wherein merging anonymous contacts comprises maintaining anonymous contacts separate from contacts associated with registered users and linking the anonymous contacts and the contacts associated with registered users together, thereby marking the anonymous contacts and the contacts associated with registered users as representing the same contacts.

24. The method according to claim 14 and wherein user permission field is at least one of said website determined and said website owner determined.