KR102361002B1 - System and method for third party application activity data collection - Google Patents

Abstract

The system comprises at least one hub for coordinating at least one activity message having a standardized format between the website and at least one third party application, and for listening to the at least one activity message and extracting data from the at least one message. an activity coordinator for at least adding to a stream associated with at least one of the identified contact and the anonymous contact, wherein at least one of the identified contact and the anonymous contact is a user of the website. The system also retrieves and analyzes contact-related information from the stream and at least one that stores activity streams and contact-related information for use by the contact and by the website and the contact coordinator that enhances previously held information about the contact. includes a database of

Description

SYSTEM AND METHOD FOR THIRD PARTY APPLICATION ACTIVITY DATA COLLECTION

The present invention relates to online applications and in particular the use of online applications by an embedded third party application.

CROSS REFERENCE TO RELATED APPLICATIONS

This application was filed on December 4, 2013, and claims the benefit from US Provisional Patent Application No. 61/911,485, which application is hereby incorporated by reference in its entirety.

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

These website building systems are hosted on a server or servers that are connected to the Internet and are fully on-line accessed using Internet communication protocols such as hypertext transfer protocol (HTTP). It can be released in different configurations, such as website building systems. The creation, editing and deployment of these website building systems are all performed on-line directly with the servers.

Website building systems may also be partially online or sometimes even entirely offline. In the case of partial online systems, website editing is performed locally on the user's machine and later uploaded to a central server or servers for deployment. Once uploaded, these website building systems behave in the same way as all online website building systems.

Website building systems have an internal data architecture for organizing data and elements within the system. This architecture may be different from the external view of the site as the user sees it, and may also differ from the way typical hypertext markup language (HTML) pages are sent to the browser. For example, the internal data architecture adds essential to editing and maintaining the site within the website building system for each element on the page (creator, creation time, access permissions, links to templates, etc.) It may contain properties, but not externally visible to the end user (or even some editing users). A typical architecture for a website building system-based site is composed of components (eg, single and multi-page containers containing shape components, image components, text components, mini-pages, etc.) It may be composed of pages including

Elements may have no content, such as a star shape (although it may have color, size, position, and any other properties) that has no internal content, or may have internal content, such as a text paragraph element. This internal content includes not only the displayed text, but also font, formatting, and layout information. This content can of course vary from case to case of each element of a text paragraph.

Designers using such website building systems can design new creations from scratch (starting with a blank screen), or a dictionary created by the designers themselves, by the system generators, or by the designers community. It may depend on prescribed application templates. A website building system supports templates that are simple collections of components, complete pages (or mini pages) or even sets of pages, and complete websites.

Once an application template is provided, the designer is free to customize it - adding, removing or modifying all elements of the template to create his own version of the template. Such customization may be implemented by creating a modified version of the template (separate from and separate from the template). Alternatively, the website building system may maintain a link with the original template and thus apply customizations through an inheritance-type mechanism that will reflect changes made to the template later.

Website building systems can also be extended using third party applications and components embedded therein. Such third party applications may be included in the website building system design environment or through a number of distribution mechanisms, for example, from an application store (AppStore) integrated within the website building system or from the web website building system (WBS) separately purchased from a separate, web-based or standalone application repository (or app store) operated by a vendor or by another entity ( or obtained in another way). 3rd party applications can also be obtained directly from 3rd party application vendors (either through the App Store or not) - which will provide the actual installation module or just an activation code or access code.

The third party application may include any combination of front-end (display) elements and back-office elements (not part of the visual website display). Third-party applications may be entirely back-office (ie, do not include display elements), entirely front-end (ie only activated within the context of using the website), or a combination of the two.

The back office component of the third party application may include functions such as database communications, external update options, and the like. For example, a blog 3rd party application may provide updates from non-human sources (eg, RSS news feeds from major news services) as well as human sources not associated with the website. It may include a back office element that enables it to be received from (eg, a standalone smartphone application capable of submission of blog entries).

Incorporation into a web site that includes a visual element of a third party application can be done in a number of ways. Widget-type third-party applications may be embedded as components within a website page, whereas section-type third-party applications may be added as additional pages or pages to the website.

Moreover, third party applications (both widgets and sections) may be single page third party applications or multi page third party applications (with internal mini pages represented as internal URL structures). The system may implement any or all of the four possible combinations (widget or section, single page or multiple pages).

Multi-page third-party applications typically have a default which may be a launch page, a specific internal mini-page (eg, the most recent blog entry in a blog third-party application), a mini-page selection screen, or some other mini-page. ) provides a "landing" mini-page.

The use of third party applications in website building system based web sites is done through third party application instances. The website building system enables a single third party application instance across the entire website; Enables multiple instances of third party applications to be created within a website (but no more than one instance of any given third party application) and multiple instances of multiple third party applications Multiple uses for 3rd party applications can be supported at multiple levels, such as enabling creation but no more than one instance per given page. This may also enable multiple instances per page of component third-party applications but not per page of section third-party applications and also that multiple instances of multiple third-party applications may contain an amount of third-party application instances. , can be created without any restrictions on multiplicity or location.

A third party application instance may have content specific to the instance. For example, an e-Shop third-party application may have a product database associated with a particular instance, which may have a product database associated with the same e-Shop third-party application (either on the same site or at different sites). ) is different from the product database associated with other instances of

For purposes of discussion, a website page (or mini-page) comprising a third-party application and its mini-pages or elements (ie, a “wrapper page”) is referred to as a containing web page and It will be advertised as the main site on the entire web site. The integrated page that is displayed to the user - including the main page and embedded third party application (TPA) mini pages/components - will be referred to as a combined page. For section type 3rd party applications, the "virtual page" containing the 3rd party application will act as the containing web page.

Third party applications are typically deployed on website building system vendor servers, on third party application vendor servers, on external (fourth party) servers, or any combination thereof. Third party applications may also contain elements that actually run on the end user machine, such as a statically installed browser extension, or JavaScript run within the website building system client-side code as shown in Figure 1 to which reference is now made. (JavaScript) components can be launched dynamically.

The website building system vendor's servers act as contact points for end users and respond to requests (possibly connected to third party application vendor's servers to receive necessary information). The website building system may create direct connections (as needed) between the client computer and the third party application vendor's servers, for example when video streaming is required.

Included third party application instances may have their own internal content similar to the way regular components contain internal content. Third party applications can manage this content independent of the website building system and the website being created 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 content shared, eg, two e-shop instances on two separate website pages are identical You can refer to the product database.

Output from embedded third-party applications can be incorporated into the embedded web page in a number of ways, including:

Server-side processing : In this alternative as shown in Figure 3 to which reference is now made, the third-party application [a] (including design and display elements) and user-specific third-party application data [b] are It is merged by third party application server code [c] running on the vendors' servers [d]. These are transmitted to the website building system server code [f] via the communication medium [e], which server code [f] merges them with the containing web page information [g] and then converts them to the user client station [h] Transmit to display on.

Client-Side Processing : In this alternative as shown in Fig. 4 to which reference is now made, the third-party application [a] (including design and display elements) and user-specific third-party application data [b] are It is merged by third-party application server code [c] running on the vendors' servers [d]. These are transmitted via the communication medium [e] to the client-side processing component [h]. The website building system server code [f] sends the embedded web page information [g] to this client-side processing component [h]. The client-side processing component [h] performs the merging of the two sources of information and provides the integrated application to the browser (or other client agent) [i].

iFrame inclusion: in this alternative as shown in Figure 5 to which reference is now made, the third-party application [a] (including design and display elements) and user-specific third-party application data [b] ] is merged by third-party application server code [c] running on server [d] of third-party application vendors. These are transmitted via the communication medium [e] to the browser-based application [h] running within the user agent (eg web browser) [i]. The website building system server code [f] sends the embedded web page information [g] to this browser-based application [h]. The containing web page is realized as a web page containing one or more iframe directives containing content from a third party application server [d]. Additional and alternative methods may also be applicable.

It is an object of the present invention to provide online applications and in particular the use of online applications by means of an included third party application.

According to a preferred embodiment of the present invention, there is provided a system implementable on a website through a client/server system having at least one processor, wherein the processor processes instructions defining the system. The system comprises at least one hub for 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. . The system also includes an activity coordinator that listens for at least one activity message and at least adds data extracted from the at least one message to a stream associated with at least one of an identified contact and an anonymous contact. ), wherein at least one of the identified contact and the anonymous contact is a user of the website. The system also retrieves and analyzes contact-related information from the streams, and for use by contacts and by contact coordinators and websites that enrich information previously held about the contact and activity streams and contact-related information. at least one database for storing

Furthermore, according to a preferred embodiment of the present invention, the at least one hub comprises: a router and tracker for routing and tracking at least one activity message between the website and at least one third party application, the website and a privacy policy enforcer for enforcing a privacy policy between the at least one third-party application, and at least one message transformation and content adaptation rule pre-specified between the website and the at least one third-party application. a personal data proxy that implements at least one of a converter and adapter, a personal data proxy and a personal data substitution, and enforces user permission field restrictions between the website and at least one third party application; and at least verify the signature of the at least one activity message using the incoming key of the one third-party application, convert an external ID associated with the at least one activity message comprising the internal website ID, and at least one and at least one of a verifier and a signer for signing at least one activity message that is retrieved using an outgoing key of a third-party application of

Moreover, according to a preferred embodiment of the present invention the activity coordinator comprises: a stream generator which identifies a contact associated with the at least one activity message and generates a stream of data if the associated contact does not exist, the data from the at least one activity message at least one of a stream merger that merges into an existing stream and data from at least two of the activity streams into a single stream and a log creator that logs activity data from the activity stream into at least one database. include

Moreover, according to a preferred embodiment of the present invention, the contact coordinator comprises: a data extractor for extracting contact related information from at least one of at least one activity message, stream, other contacts and external sources, recording at least two contact information A data merger that merges the contacts - records have associations with the same identified contact - and merges the extracted contact-related information with information about the existing contacts according to predefined merging rules, identifiable new contacts and anonymous and at least one of a contact processor for generating at least one of the contacts and tracking contact activity during a session of the website, and a data and permission processor for handling privacy protection and permissions of the extracted contact-related information.

Additionally, according to a preferred embodiment of the present invention, the router and tracker support routing of at least one activity message using listening queries specified by at least one third party application.

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

Moreover, according to a preferred embodiment of the present invention, the stream-to-stream merger is a horizontal stream merger that merges at least two separate streams according to an identified common contact, and a stream created for an anonymous contact and a registered and at least one of a vertical stream merger for merging a stream generated for an anonymous contact upon registration or login capable of concatenating a stream associated with the contact user with a stream associated with the registered contact user.

Furthermore, according to a preferred embodiment of the present invention, the data merger: locates identical primary ID field values in at least two of the contact information records, and when normalized to 1 in at least two of the same contact information records locating primary key field values, using cookies to identify site users, using site login for registered users to identify site users, and social for site users having accounts associated with social networks. and at least one of a contact identifier that at least one of identifying the site user through login. The data aggregator also uses at least one of language, syntax, text analysis, and consultation to external data sources and services to resolve inconsistencies between contact records, an aggregator that aggregates contact information using predefined rules. a contradiction resolver that resolves according to ; A list value generator that creates list value fields to define unambiguous priority between contact records, a horizontal contact merger that merges two unrelated contacts due to a common primary ID being detected, and an anonymous contact and registered and a vertical contact merger for merging anonymous contacts with contacts associated with the registered user upon registration or login capable of associating contacts associated with the user.

Further, according to a preferred embodiment according to the present invention, a horizontal contact merger maintains at least two contact records separately and links at least two contact records to each other such that the at least two contact records are marked as representing the same contact. Includes virtual mergers.

Furthermore, in accordance with a preferred embodiment of the present invention, the vertical contact merger keeps the anonymous contact and the contact associated with the registered user separate, and marks the anonymous contact and the contact associated with the registered user as representing the same contact. Preferably, a virtual merger is included that links the anonymous contact and the contact associated with the registered user to each other.

Moreover, according to a preferred embodiment of the present invention, the user permission field is at least one of the determined website and the determined website owner.

Moreover, according to a preferred embodiment of the present invention, the standardized format is defined by a predefined schema, inheritance, call back link, and by at least one third-party application or At least one of those defined and encoded based on an external regular industry or de facto standard.

According to a preferred embodiment of the present invention, there is provided a method implementable on a website through a client/server system having at least one processor, wherein the processor processes instructions defining the method. The method comprises reconciling 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, reconciling, listening to the at least one activity 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, wherein at least one of the identified contact and the anonymous contact is a user of the website. including adding. The method also includes the steps of retrieving and analyzing the contact-related information from the stream and enriching previously held information for the contact and storing the activity streams and the contact-related information for use by the website and by the contact. includes

Furthermore, according to a preferred embodiment of the present invention, coordinating comprises: routing and tracking at least one activity message between the website and the at least one third-party application, the website and the at least one third-party application at least one of enforcing a privacy policy between the website and the at least one third party application, applying at least one predefined message transformation and content adaptation rules between the website and the at least one third party application, a personal data proxy and a personal data substitution. implementing 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 using the entry key of the at least one third-party application; converting an external ID associated with the at least one activity message having the site ID and signing the at least one activity message to be retrieved using a retrieval key of the at least one third party application.

Furthermore, according to a preferred embodiment of the present invention, listening and at least adding comprises: identifying a contact associated with the at least one activity message and creating a stream of data if the associated contact does not exist, the at least one activity merging data from the message into an existing stream and data from at least two of the activity streams into a single stream and logging activity data from the activity stream into at least one database.

Moreover, according to a preferred embodiment of the present invention, the retrieving and analyzing comprises: extracting contact-related information from at least one of at least one activity message, stream, other contacts and external sources; at least one of merging at least two contact information records—the records have an association with the same identified contact—and merging the extracted contact-related information with information about an existing contact according to predefined merging rules. include The retrieving and analyzing step also includes creating at least one of a new identifiable contact and an anonymous contact, tracking contact activity during a session of the website, and processing privacy protections and permissions of the extracted contact-related information.

Moreover, according to a preferred embodiment of the present invention, the routing and tracking steps support routing of at least one activity message using listening queries specified by at least one third party application.

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

Furthermore, according to a preferred embodiment of the present invention, the steps of merging data into a stream associated with the identified contact and merging the at least two separate streams into a single stream are performed according to at least two separate streams according to the identified common contact. merging the streams horizontally and associating the stream generated for the anonymous contact with the registered contact user upon registration or login, which can associate the stream generated for the anonymous contact and the stream associated with the registered contact user. and merging vertically with the stream being

Furthermore, according to a preferred embodiment of the present invention, the step of merging at least two contact information records comprises: locating identical primary ID field values in at least two of the contact information records and, when normalized, the same contact information record locating primary key field values in at least two of them; using cookies to identify site users; and at least one of identifying the site user via a social login for the site users. Merging the at least two contact information records also includes consolidating the contact information using at least one of language, syntax, text analysis and reference to external data sources and services; resolving according to prescribed rules, creating list value fields to define a clear priority between contact records, horizontally merging two unrelated contacts due to a common primary ID being detected. and vertically merging the anonymous contact with the contact associated with the registered user upon registration or login capable of associating the anonymous contact with the contact associated with the registered user.

Moreover, according to a preferred embodiment of the present invention, the step of merging horizontally comprises a virtual merging to keep the at least two contact records separate and at least two contact records such that the at least two contact records are marked as representing the same contact. linking them to each other.

Moreover, in accordance with a preferred embodiment of the present invention, the step of merging vertically comprises a virtual merging in order to keep the anonymous contacts and the contacts associated with the registered user separate and the anonymous contacts and the contacts associated with the registered user are separated. and linking the anonymous contact and the contact associated with the registered user to each other so as to be marked as representing the same contact.

Further, according to a preferred embodiment of the present invention, the user permission field is at least one of the determined website and the determined website owner.

Furthermore, according to a preferred embodiment of the present invention, the standardized format is defined by predefined schemas, inheritance, callback links, and defined by at least one third-party application or on the basis of external regular industry or de facto standards. and at least one of which is encoded.

The patented subject matter regarded as the present invention is particularly pointed out and is explicitly claimed at the end of the specification. However, the present invention may best be understood when read in conjunction with the accompanying drawings, by reference to the following detailed description, both as to its organization and method of operation, and in addition to its objects, features and advantages:
1 is a schematic diagram of deployment configurations between a website building system and a third party application;
2 is a schematic diagram of a third-party application internal content management;
3 is a schematic diagram of third-party application nesting within an embedding web page via server-side processing;
4 is a schematic diagram of third-party application nesting within an embedding web page via client-side processing;
Figure 5 is a schematic diagram of third party application nesting within an embedding web page via iframe nesting;
6 is a schematic diagram of existing and non-optimal third party application displays during page layout change;
7A and 7B are schematic diagrams of a system incorporating 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 component model;
9 is a schematic diagram of a sample multi-part blog 3rd party application;
10 is a schematic diagram of a sample modular vending third party application;
11A and 11B are schematic diagrams of different implementations of a communication hub constructed and operative in accordance with the present invention;
11C is a schematic diagram of elements of the communication hub of FIGS. 11A and 11B constructed and operative in accordance with the present invention;
Fig. 12 is a schematic diagram of a communication translation scenario performed by the communication hub of Figs. 11A and 11B constructed and operative in accordance with the present invention;
Figure 13 is a schematic diagram of an embedded web page processing a third party application having an associated template, constructed and operative in accordance with the present invention; and
14 is a schematic diagram of an embedded web page comprising a third party application having an associated template within a mini page, constructed and operative in accordance with the present invention;
15 is a schematic diagram of a system for coordinating and collecting data from different messages exchanged between one or more embedded third-party applications and a website building system, constructed and operative in accordance with the present invention;
16A, 16B, 16C and 16D are schematic diagrams of elements of the system of FIG. 15, constructed and operative in accordance with the present invention;
17 is a schematic diagram of a sample graphical user interface for displaying an activity stream associated with a contact, constructed and operative in accordance with the present invention;
18 is a schematic diagram of client-side and server-side third-party application activity message delivery; and
Fig. 19 is a schematic diagram of handling login/logout during a user website session;
It will be appreciated that, for the sake of simplicity and clarity of description, elements shown in the drawings 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. Moreover, where deemed appropriate, reference numerals may be repeated between the figures to indicate corresponding or analogous elements.

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 one of ordinary skill 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 recognize that there are many limitations to current methods in the manner in which third party applications are typically integrated into website building systems and in the way the integrated third party applications and website building systems interact. did

These restrictions include that third party application display is limited to a single rectangular area within the containing web page, which area is contained within an iframe. These restrictions also limit the third-party application's size and position of its own window, as well as visual elements outside the actual third-party application display window (eg, specialized display frames around the third-party application window). includes the ability to control.

The third party application may have its own display styles (color schemes, fonts, text sizes, etc.). These styles may be good for some embedding web pages, but can be visually problematic or inconsistent for other embedding web pages.

Another limitation is the rigidity of the third party application display in terms of the containing site. If this site needs to be modified visually (for example, due to placement on platforms with different screen sizes or due to dynamic layout events), the embedding web page may need to change the size of the window assigned to the third-party application. there may be In such a case, the third party application display may be clipped and it will be necessary to scroll through the scroll bars to reach different sub-areas within the third party application. Now the containing web page [a] is resized, the area allocated to the e-shop 3rd party application [b] is reduced and the "buy" button [c] cannot be shown with the contents of the shopping cart [d]. Reference is made to FIG. 6 which shows one example of what can happen when - requiring multiple scrolling actions to complete the purchase, making the purchase actually less likely to be completed.

It will be appreciated that third party applications cannot interact with other components within the containing web page, and such interaction is sometimes necessary to achieve complex functionality. In particular, there is no way a third-party application will perform differently depending on the content and type of components within the containing web page. One example of this could be a website that streams online cooking classes. In the background watching his movie, a user may wish to have a small area of his screen dedicated to the news feed and weather updated (such as a live stream from CNN) in other areas of his screen. A user may wish to automatically pause his/her study section when a weather report for his/her area of residence is initiated.

There is also no clear standard way for them to cooperate with each other, especially when multiple 3rd party applications are provided by different vendors. Therefore, designers do not have a clear way to combine multiple 3rd party applications from different vendors. One example of this is where an e-commerce website operates a module from a third party ordering system and a different module to a shipping system. It may be desirable to order supplies according to a shipping schedule or the like.

Applicants claim structured two-way communication between a website building system and third party application instances contained therein and between different third party application instances that may be implemented within the same containment page. It was recognized that this consolidation could be achieved by using channels. These channels can also carry information about layout, style and additional information.

The discussion below will focus on the iframe nesting method, and it will be recognized that this is the preferred method since iframes are built and integrated within modern browsers and do not require the generation of special integration code. iframe nesting also provides intrinsic protection against browser-assisted encapsulation and sandboxing, as well as hacking techniques such as cross-site scripting attacks that can be used by malicious third-party applications. can provide

Reference is now made to FIGS. 7A and 7B , which illustrate a system 100 incorporating a website building system and one or more third party applications, in accordance with one embodiment of the present invention. 7A shows the system 100 in the design phase and FIG. 7B shows the system 100 in runtime. As can be seen in FIG. 7A , the system 100 includes a client 10 , a website building system 30 installed on a website building system (WBS) server 20 , and one or more products. one or more third party applications 40 installed on third party application servers 50 . The website building system 30 includes a WBS coordinator 21 , an application repository 22 , a WBS side TPA property sheet 23 , a third party application (TPA) coordinator 24 and an app store. (25) (which may include explorer 26). The client 10 includes a page composer 12 and a client side view of the TPA property sheet 23 . In some embodiments, the client 10 may also include a client-side view of the App Store 25 . The page builder 12 includes a linker 13, which is described in more detail herein below. The third-party server 50 includes a third-party application 40, an external TPA coordinator 51 and a TPA database 52 that stores third-party application 40 components, templates, etc. for use. . It is noted that system 100 may include multiple third party servers 50 belonging to multiple third party application 40 vendors.

It will be appreciated that the TPA properties sheet 23 may be invoked when attributes are specified for a given third party application 40 instance. It will be further appreciated that when invoked, the TPA properties sheet 23 may appear on the client 10 as a client-side view of the TPA properties sheet 23 . It will also be further appreciated that there may not be a TPA property sheet 23 or a repository thereof as offline embodiments may have their property sheets as part of the installed client software.

The designer or end user 5 on the client 10 side has a page builder 12 to create website pages and interactions (inter-page as well as intra-page). ) can be used to create your own web pages (or any other online application). Designer 5 may select components, templates, etc. that are part of website building system 30 stored in application repository 22 via WBS coordinator 21 . Designer 5 also embeds third party application 40 instances from third party applications 40 that may have been pre-purchased and whose templates, components, etc. may be stored in application repository 22 . It is possible to create an embedded web page 203 of In an alternative embodiment, purchased templates, components, etc. may be stored in the TPA database 52 and accessed via an external TPA coordinator 51 . In another embodiment, third party application 40 templates, components, etc. may be purchased through the App Store 25 as needed. The property sheet 23 may be specified by the designer 5 and as will be described in further detail herein below information regarding third party application 40 instances that have been purchased, such as licenses, installation instructions, payment, etc. can hold The designer 5 may also use the linker 23 to manually designate (if necessary) arbitrary communication channels between the included third party applications 40 . The linker 23 may also provide any specific links between the embedded web page on which the designer 5 is built and the embedded third-party application 40 instances, such as concurrently viewed movies and CNN news reports, as detailed herein. It will also be appreciated to enable specifying communication connections and rules. It will be appreciated that links generated by linker 23 may be modified through the lifetime of the web site.

It is acknowledged that the designer 5 may obtain the third party application 40 through channels external to the app store 25, such as an external app store operated by a third party application 40 vendor or an external party. will be In such a case, the website building system 30 initially registers the third party application 40 and its configuration data and the third party application 40 communicates with the designer 5 via the website building system 30 . It is installed on the website created by

In order to provide the linker 23 with the ability to set up potential communication channels, the third-party application 40 includes components within the containing web page 203 (with which the third-party application wishes to communicate)- It will be appreciated that there is a need to properly recognize and identify other third party application 40 instances - including. For components based on the associated template (described in more detail herein below), identification is performed in advance by the third party application 40 vendor. Components in the associated templates may be provided with specific reference IDs which may be used by the third party application 40 when communicating with these components.

In the case of a multi-part third-party application 40 (described in more detail herein below), i.e. a single third-party application 40 that spans multiple iframes, how the multiple parts communicate with each other It will be further appreciated that it is possible to automatically recognize

For embedded website page components that are not included in the associated template (as described in more detail herein below), the third party application 40 must be present in order for it to function (mandatory and optional). ) may include a list of included web page 203 components. This list is stored within the properties sheet 23 and may include unique IDs, description and component details (eg, should it be a text component, will be used as a blog talkback label). have. The list may be detailed as a third-party application 40 has entered the App Store 25 , and the designer 5 creates a component on an embedding web page 203 that meets the third-party application 40 requirements. A linker 23 may be used to specify fields (fields). The website building system 30 can dynamically create the included web page 203 components missing when the third party application 40 instance is created, and the designer 5 later moves them and resizes them. It will be appreciated that it may be possible to coordinate and fully specify.

Alternatively, the website building system 30 may expose a full or partial component model of the embedding web page 203 to a third party application 40 included in the embedding web page 203 . It will be appreciated that this may be a component model and may not be the Document Object Model (DOM) of the containing web page 203 . The embedding web page 203 DOM can be much more complex and granular than the component model, because the actual embedding web page 203 is either part of the website building system 30 infrastructure or constitutes the embedding web page 203 . It can contain any number of HTML elements supporting elements - both hidden and visible. The component model would therefore be much simpler.

Text component [a] now contains multiple HTML constructs (enclosing div tag [b], inner div tag [c], frame "mini widgets" [d1]..[d5] etc. Reference is made to FIG. 8 , which shows how it can be implemented using ). The DOM model [e] for the containing web page 203 may include separate DOM tree nodes for each element of these sub-elements. The component model [f] is much simpler, and can contain only a single component node [g].

System 100 can also support exposing optional components - designer 5 can specify via linker 23 which components should be exposed to 3rd party application 40, only this component It will be appreciated that only elements (including possibly a “containment path” leading to them) may be included within the simplified component model visible to third party applications 40 . This above can be done by explicitly marking the components to be included, depending on their type or any other properties of the website building system 30 . The third party application 40 may then review the containing web page 203 component model and locate the necessary components.

Links between the containing web page 203 and the third-party application 40 instances are also broadcast linking through which the third-party application 40 can send communications during runtime to record specific events. It will also be appreciated that it can be automatically generated as This communication may be optional or mandatory (i.e., the third-party application 40 may not function or may be installed without a matching third-party application 40 that is linked to receive such messages. none). For example, a third-party application 40 may broadcast information packets about the activities it performs, and any installed logging third-party applications 40 receive these information packets. can do.

Newly created pages, now complete with settings, may be stored in the application repository 22 (via the WBS coordinator 21 ) to be called at runtime as described in more detail herein below.

Reference is now again made to FIG. 7B . The elements in this embodiment are the same as those in FIG. 7A except for the elements of the client 10 . During runtime, the client 10 includes a viewer 201 for displaying the containing web pages 203 . The viewer 201 includes a number of view ports 202 to each display a different instance of the third-party application 40 (instances derived from one or more third-party applications 40 ). It will be acknowledged that The client 10 also includes a communication hub 205 to facilitate communication and embedding with any communication necessary between the hosted third party applications 40 without any connection to the associated embedding web page 203 . It provides a back channel between the web page 203 and any third party applications 40 it is hosting. The function of hub 205 will be described in more detail herein below.

The hub 205 is the interactive part of a web site that can be viewed by both the containing web page 203 and any third party application 40 inclusions and their communication must not be delayed by client-server round trips, so the client It will be appreciated that it can be implemented in (10). In an alternative embodiment, the hub 205 is a website where the 3rd party application servers 40 need to exchange a lot of data and it is more desirable not to route them through the client 10 . It may be implemented in the building system server 20 .

It is recognized that the communication hub 205 may 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 . will be For example, the hub 205 may enable a third party application 40 to request the website building system 30 to switch to another page within the main site. Communication hub 205 may also enable third party applications 40 to request resizing of their own windows, possibly affecting the layout of the containing page. This may be done through dynamic layout processing, which is described in more detail herein below. Alternatively, the containing web page 203 may request the third party application 40 to switch to a different version if (eg) a switch to a different version is required to accommodate changes in the display. This two-way communication also includes communication between a third party application 40 component and a website building system 30 component associated with the third party application 40 displaying additional information as described hereinabove. It will be appreciated that as well as allowing communication between elements of multi-part third party applications 40 and modular third party applications to be initiated.

System 100 may also be implemented using both online and offline website building system 30 , which includes client-side components, website building system 30 vendor servers, third party application 40 vendor servers, and so on. It will further be appreciated that any combination of hosting methods may be used, such as servers and other third party servers. It will be appreciated that for an offline embodiment, a server may still need to implement system 100 as described hereinabove.

System 100 may also be hosted on a different set of servers (not operated by a website building system vendor), such as a private site hosting arrangement for a large organization.

System 100 may also support the full gamut of optional including third party application 40 instances from third party applications 40 as described hereinabove. However, system 100 may also support only a subset of these options or may place restrictions on third party application 40 instance nesting possibilities.

System 100 may also implement multi-part third party applications 40 . The multi-part third party application 40 may include multiple display regions, each of which is processed using a separate iframe. These regions may also cooperate (as needed) via communication hub 205 as described in more detail herein below.

Reference is now made to FIG. 9 , which shows one example of a multi-part third party application 40 . As shown, the blog third-party application [a] obtained from the app store [b] is placed on the containing web page 203 [c]. The blog third party application [a] includes three areas as follows: a blog entry area [d]; tag cloud area [e]; News update area [f]. A multi-part third-party application is a multi-part always visible multiple of its multiple areas, such as as multiple concurrently resident parts of a single application - as in the blog example above - or as multiple optional resident parts of a single application. It will be appreciated that it can be used in a number of ways, including having regions of The display of the selection areas may be controlled by the third party application 40 or by the designer 5 (which determines how to configure the third party application when containing it). The display may also be used as supporting functional areas, such as configuration or additional dialog areas; to be controlled as an alternative display to multi-version third-party applications (eg, having small and large versions of third-party applications or having portrait and landscape versions of third-party applications); can

It will be appreciated that the functionality described above may be implemented by using iframes for third party application 40 element display to obtain the encapsulation and security advantages of an iframe based architecture.

Implementation of multi-part third-party applications 40 includes third-party applications 40 (within their own iframes) to control the display (eg, their visibility) of the various iframes. , size and location) will be further added. It will be further appreciated that the communication hub 205 may enable this display as described in more detail herein below.

Even when the multi-part third-party application 40 is (visually) composed of multiple elements and areas, it is still in terms of purchase (eg, in the App Store 25), installation, configuration, etc. It will also be appreciated what is considered a single third party application 40 .

In existing systems, each third-party application 40 can be considered a separate entity and can be used between two third-party applications 40 (from the same vendor or from otherwise cooperating vendors). Any collaboration should develop ad hoc on a case-by-case basis. It will be appreciated that system 100 may also support modular third party applications 40 comprising a number of cooperative sub-modules that may be purchased and installed individually.

The modular sales management third party application [a] now has the following sub-modules: CRM module [b]; Reference is made to FIG. 10 , which shows how it may include a lead management module [c] and an e-commerce module [d]; A single 3rd party application vendor may provide all necessary 3rd party application modules. Alternatively, a third party application vendor provides a subset (and functionality) of the third party application 40 modules and the designer purchases/installs complementary third party application modules from the same or additional third party application vendors. can make it possible to Although a multi-part third-party application is acquired and installed as a single third-party application from a single vendor, this only happens to occupy multiple screen areas, whereas a modular third-party application can be acquired and installed separately. It will be appreciated that it may be possible to include multiple modules and include modules from multiple third party application vendors. To provide the ability to integrate multiple third-party application modules from multiple vendors, each third-party application module includes a list of interfaces/functions it needs and the interfaces/functions it provides. You must provide a list of This may be done, for example, by using lists of interface names based on the layer's dot-separated name convention (eg My_CRM_TPA.NewClient.GetInfo) and the interface parameter specification.

3rd party application 40 modules may implement the necessary interfaces either as mandatory (i.e. the module will not work without them) or optional (i.e. the module will work but may provide reduced or modified functionality). can be specified. Therefore, the parameters provided for each interface are: an interface unique name; interface description - visible to the designer 5 , who will (for example) be aware of the functionality handled by the missing interfaces; forced/selected status; Interface parameter list and type. It will be appreciated that each third party application module still resides in a separate iframe (or set of iframes). The operation of the interface is based on the communication channels described in more detail herein below.

It will be appreciated that third party application 40 modules may be assembled during the website design phase. The website building system 30 may resolve interface references as additional third party application 40 modules are added - where new third party application 40 modules are Resolves the necessary interfaces of

It will also be appreciated that the designer 5 can edit and operate the finished web site while the mandatory (and optional) interfaces are still unresolved. However, the designer 5 may not publish the web site that is created until all the forcing interfaces have been resolved and the designer may have a third party application module where the hub 205 still has unresolved forcing interfaces. This designer will be prompted to try a function that may be required to activate it.

It will be further appreciated that the app store 25 may include a navigator 26 that may locate third party application modules resolving the necessary third party application module interfaces. The searcher 26 may search for a specific third-party application module(s) or search all third-party application modules based on unresolved interfaces. The searcher 26 may also search for interfaces that are currently unresolved, or even interfaces that have already been resolved, as well as types of interfaces that are mandatory, selective, or both. It will be appreciated that the explorer 26 may also be limited to resolving interfaces that a particular third-party application has not resolved and may be limited to discovering certain third-party application vendors. Searcher 26 performs a first-level search (ie, modules satisfy currently unresolved interfaces) or multi-level search (ie, performs an iterative search, and also finds (finding modules that satisfy unresolved interfaces to be added when considering third-party application modules) may be performed.

System 100 may use interface techniques to inform designer 5 about the importance of proceeding with any missing interfaces. Hub 205 may provide interface translation between incompatible third party applications that still need to communicate. This may be done by the website building system 30 provider or by an adapter module added by an external party that adapts any required interface to a different format.

System 100 is also applicable to online application editing systems that use the Internet (or any other network connection) to view the created online application and use non-browser client-side software. Such a system does not need to use specific technologies (eg, IP communication, HTTP, HTML, etc.) when used by a regular web 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 messages. Using HTML5 Windows.Postmessage, messages can be safely sent between windows, iframes and the main HTML document, even when they belong to different domains. PostMessage provides tools for sending iframes to specify the domain to which the message is sent, and tools for receiving iframes to verify the domain from which the message was sent.

URL fragment identifier for messages : This method relies on using a URL fragment identifier to transmit message data from one endpoint to another. The data is encoded in plain text and appended (as site identifier) to the URL used to invoke a service on the target endpoint domain or a hidden iframe within the target endpoint iframe. The site identifier is then decoded by the code in the target service or iframe.

Specialized Communication Web Service : The website building system 30 provides a specialized web hosted on the website building system server 20 . Various communication endpoints connect to this server - sending messages or checking pending messages. This is a pre-HTML5 Comet set of techniques, HTML5-based WebSockets or any other queuing, polling, server push or similar technique known in the art. This can be done through known methods.

HTML5 local storage : HTML5 provides a structured local storage facility that can be used to store queued messages. However, local storage can only be accessed by web content belonging to the same domain as the storage iframe. In the art, a Meebo XAuth product—now owned by Google Inc.—that a small server provides support for creating the necessary intermediate iframes to enable domain-specific local storage to be accessed from iframes based on foreign domains. Solutions have been developed, such as the underlying technique used by Hamm.

HTML5 Local File System Access Application Programming Interfaces (APIs) : Similar to the use of local storage described above, the cross-iframe communication channel is via HTML5 file access APIs (File API, FileWirter API, and FileReader API). It can be configured using local files in the local storage of the user agent being accessed. However, it is noted that the sandboxed local file system created by the HTML5 file system access APIs is still origin-private, so an intermediate iframe/server component will be needed to fill the same-origin limit.

Specialized Browser Plug-ins : A specialized browser (or other user agent) plug-in can be created to manage cross-iframe message queues. Such a plug-in would have to be installed (at all levels) by users of the website building system 30 and would provide the necessary services to all iframes and the main website building system 30 pages. .

It will be appreciated that communication hub 205 acts as a broker for all inter-iframe communications using any of the transmission methods discussed above herein. The hub 205 may be fully aware of the 3rd party application 40 details and the containing web page 203 structure as provided by the 3rd party application 40 vendor and stored in the property sheet 23 . This will be more appreciated. The third party application 40 may also have different parameters when included within different applications and for different instances of nesting within the same application (as described above herein). Such parameters may include a unique instance name that may be used for smart addressing (described in more detail herein below). It will also be appreciated that the hub 205 may also be aware of additional third party application 40 details that may not be stored within the properties sheet 23 .

The hub 205 also facilitates smart addressing and identification, verifies communication sources, enforces communication policies, resolves third-party application 40 incompatibility issues, and also configures configuration from third-party applications 40 . It will also be appreciated that elements can be redirected. The hub 205 may also enable dynamic updates of the layout within the third party application 40 based on changes made to the containing web page 203 as described in more detail herein below.

Reference is now made to FIGS. 11A and 11B , which show different implementations of the hub 205 , and FIG. 11C , which shows the functionality of the different elements of the hub.

The hub 205 is a smart identifer and addresser 310 , a sender verifier 320 , a communication policy enforcer 330 , a protocol converter 340 , a redirector 350 , and a dynamic layout updater. 360 , a configuration manager 370 , a generic updater 380 , and a hosted application programming interface (API) wrapper 390 . The function of these elements will be described in detail herein below. It will be appreciated that all functions are 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 . will be.

11A, now referenced, shows an exemplary embodiment for a hub 205 via an intermediate iframe [a] using an internal communications application programming interface (API) to contact the website building system 30 . In this way messages [c] (using communication API modules [f] and [g], respectively) sent from TPA [d] to TPA [e] (for example) apply application specific information may be analyzed, verified or modified.

An alternative embodiment as shown in Fig. 11B, to which reference is now made, does not use an intermediate iframe, but rather embeds it within communication API modules [a] and [b] (third party applications [c] and [d], respectively). ) or both use cross-domain communication. Modules [a] and [b] interact directly with website building system 30 to receive application-specific information and use this information when processing communication messages [f]. This embodiment indicates that a significant amount of website building system 30 level information may be processed within modules that are included within third party applications and this information may be accessed (or even modified) by malicious third party applications. Therefore, it has a disadvantage (compared to the embodiment shown in Fig. 11a).

As described herein above, in all cross-communication methods described herein above, iframe addressing not only includes the origin of the iframe (including the source domain, protocol and port, i.e., when sending the message (specifying the recipient)) rather than directly based on the 3rd party application 40 addressing when receiving the message (as the sender's name provided to the recipient). In addition, sending a message requires the sender to specify a target iframe window (using JavaScript's call to document.getElementById("...").contentWindow or any other method). Thus, in existing systems, each third-party application 40 has complete and specific details (domain, protocol, port, and iframe ID) of any other third-party application 40 with which it can communicate. should contain).

It will be appreciated that this type of direct addressing can be inconvenient to handle in the environment of system 100 . Although the designer 5 integrates 3rd party applications 40 from multiple uncoordinated 3rd party application 40 vendors, the 3rd party application 40 vendors are hosted in a given domain but later It is possible to provide third party applications 40 that are moved to a different domain or sub-domain. The third party application 40 vendor 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 these can occur in third party applications 40 used on web sites that are running and accessed by numerous users. Moreover, a single containing web page 203 may contain multiple instances of one third party application 40 that may serve different functions. For example, a single page within a product support website may contain two chat 3rd party application 40 instances - one for user-to-user chats and forums and one with the vendor's support person when available for purchase. used to converse.

The address and identifier 310 includes the structure of the containing web page 203 and details of the third-party application 40 (as provided to the website building system 30 by the third-party application 40 vendor). It will be recognized that the same) is fully perceptible. Addresser and identifier 310 may provide addressing of source or target third party applications 40 to each other using any one of the following: Third party application 40 unique name (AppStore 25 ) ) as registered in ); A third party application 40 instance descriptive that enables addressing of multiple instances of the same third party application 40 by being added to each third party application 40 instance within the containing web page 203 . ID); Generic identifier for the required 3rd party application type/class (eg "I want to send message <x> to any event logging 3rd party application (40) instance on the containing web page (203)") . Such an identifier may also describe particular services that should be supported by the third party application 40 . Address and identifier 310 may also indicate version eg: "I want to send transaction <x> to an instance of accounting package <y>, but only if it belongs to version <z> You can use".

During runtime, the third party applications 40 only communicate with the hub 205 and thus only need to know the direct address of the hub 205 and the direct address of any other third party application 40 . It will be admitted that there is no need to know. This one direct address is provided by the website building system 30 to the third party application 40 provider in the communication API wrapper (communication modules f and g as shown in FIG. 11a and communication modules f and g as shown in FIG. 11b ). may be encapsulated by the communication modules (a and b)) as The calling third-party application 40 may provide application-aware third-party application 40 descriptive addresses (as described above) and the addresser and identifier 310 may direct these to the third-party The application 40 may translate into addresses and perform routing. In this way, the third-party application 40 does not need to maintain a table of absolute addresses of all possible third-party applications 40 with which it communicates.

Message originator verification is very important, otherwise it will be appreciated that a receiving third party application 40 may receive a message from a hostile third party application 40 . Since all communications may occur through the hub 205 , the sender verifier 320 may check the authenticity of all incoming messages from third party applications. The sender verifier 320 may also provide additional information that may be added to the message and used for further verification. Since the website building system 30 registers all third party applications 40 included in the app store 25 and used by the system 100 , the hub 205 is It will be appreciated that it is possible to verify that a unique sender ID that may be included in a message matches the origin of the message (domain, port, etc.).

Third party applications 40 may define general communication policies that may depend on external information, embedded web page 203 information, and the like. The communication enforcer 330 may ensure that the corresponding communication policy is enforced without the need to handle nonconforming communication. For example, in a classified information processing website, third party applications may be tagged with a classification level field in their profile. A third-party application 40 that provides a back-end event logging database that is authenticated with classification level X may define a policy so that the third-party application 40 provides a classification level greater than X. It will not accept events for logging with . Communication enforcer 330 may, in such a situation, perform the necessary preliminary filtering and prevent messages that are classified higher from reaching even lower classification applications.

It will be further appreciated that the designer 5 may wish to include two (or more) 3rd party applications on the same creation website where they can collaborate if possible but do not actually do so due to some protocol compatibility issues. . For example, as shown in FIG. 12 to which reference is now made, the e-shop third-party application [a] sends purchase order messages to the same billing and shipping third-party application [b] (provided by a different vendor). May have the ability to post to third party applications. However, the information provided by the third-party application [a] may not include some fields required by the third-party application [b]. Such a situation can typically be addressed by 3rd party application vendors of involved 3rd party applications but in some cases such remediation is not possible (eg two 3rd party applications One of them is currently not updated for some reason). Protocol converter 340 may convert the relevant messages from [a] to [b] (eg, by providing additional necessary fields). Such conversion may be performed by the protocol converter 340 or may involve some interaction with the embedding web site and containing web page 203 where possible (eg, if additional information is desired). ).

The third party application 40 has certain capabilities that require it to send messages or receive messages from another third party application 40 (e-shop/charging third party application 40 pair described above). more will be appreciated. However, in some cases where part of this solution may be missing, it may occur that, in the above example, a matching or appropriate order processing third party application 40 does not exist. In such a case, the redirector 350 allows the designer 5 to allow certain messages to be routed to or from the containing web page 203 component and match capabilities to the containing web page 203 component. It may be possible to specify that page 203 may be addressed by a component and the functionality that the components may provide. This will make it possible to configure the entire web site without requiring the construction of a special purpose third party application 40 . Thus, transactions may be posted to a website building system 30 component that may perform logging of the transaction to a database, which may then be used to perform offline billing and shipping (separately). by the program of).

Third party applications 40 may provide multiple configurations using the same code base but with different capabilities, with different possible functions. For example, third party applications 40 provide basic functionality through a free version and provide additional functionality through a purchased premium version, multiple paid versions or additionally purchased third party applications 40 features. can do.

It will be appreciated that system 100 may include website building system 30 based management of third party application 40 purchase status per user (or indeed per designer). It will be further appreciated that designers can all be registered website building system 30 users and website building system 30 can therefore maintain a database of third party application 40 purchases for each designer 5 . will be. This information may be stored in the property sheet 23 by the TPA coordinator 24 during the design phase and by the configuration manager 370 during runtime. 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 consults the repository 22 or a locally stashed copy thereof and returns a response message to the third party application 40 containing information about the capabilities it should provide. can do.

In an alternative implementation, the website building system 30 does not require a previous query message, but via an alternative channel such as an encrypted iframe parameter, the third-party application 40 required by the third-party application 40 . ) can provide configuration information.

As discussed hereinabove, third party applications 40 may communicate directly with certain containing web page 203 components. The third party application 40 can communicate components with which to communicate in a number of ways: directly to components based on associated templates (described in more detail herein below); via an access ID explicitly provided to certain containing web page 203 components by the designer 5; This can be identified by examining the (possibly selectable) component model provided to the third party application 40 by the embedding web page 203 .

It will be appreciated that during runtime, the updater 380 may implement messages and responses between the containing web page 203 components and the third party application 40 . For example, a third party application 40 may affect or query the visual and display properties of the containing web page 203 components (their location, size, color, transparency, etc.) . The updater 380 may also enable a third-party application 40 to read or write the content of the containing web page 203 components and also configure the third-party application 40 to perform media functions. It may enable an element to be instructed, for example, to post a given audio or video segment to the media player component, or to request the media player component to pause playback for a given period of time.

Updater 380 may also facilitate website building system 30 components specifying the types of access they can make—access permission bits or access control lists (ACLs). ) is similar to how they function for file protection in modern operating systems. Such permissions may be defined on a per component basis to apply to all third party applications 40 , from particular vendors or to particular third party applications 40 . For example, the third party application 40 may be allowed to access text fields that are part of the containing web page 203 external to the third party application 40 . This text field can be used to edit the blog entry against the blog 3rd party application 40 to provide more screen real estate than can be provided within the blog 3rd party application 40 area itself. In the case of third-party applications 40 that are embedded as specific mini-pages in a multi-page container, the website building system 30 directs the access of the third-party application 40 to components only on the specific mini-page. It will be appreciated that there may be limitations.

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

The updater 380 may also enable the website building system 30 to influence the style and display of the third party application 40 . The updater 380 may implement calls by which the website building system 30 may provide formatting and style guidelines to the third party application 40 . These include colors and color schemes; fonts, character sizes; transparency; It may include properties such as animations and special effects (eg, blurring). The color scheme may in particular include a normal color scheme (eg use of the following x colors) or high-level color (eg use color x for text and color y for frames).

It is recognized that one preferred way to express complex style information is to use Cascading Style Sheets (CSS), which can express a combination of multiple style instructions including fonts, sizes, colors, etc. will be The updater 380 may send such CSS-based messages to the third party application 40 . The style sheets may be generic in nature, or such that the website building system 30 may provide better guidelines to the third party application 40 (eg, the style sheet is specific to the third party application 40 ). specific style names defined by the third party application 40 (to be able to refer to elements and provide guidelines for them).

The third party application 40 then uses these guidelines to better adapt its own look and feel to the containing web page 203 . This is particularly important for third party applications 40 that are viewable or included from multiple embedded web pages 203 within the same site (multi-port nesting as noted above). Many of the containing pages use different color schemes or general designs. The third party application 40 uses the information provided to it through these style messages and adapts its own display colors and style to better fit each containing page and color dissonant compared to the containing page. It can prevent displaying schemes or look and feel.

The dynamic layout updater 360 uses the website building system 30/third-party application 40 or third-party application 40 and a secondary third-party application to handle display changes resulting from a dynamic layout event. It will be appreciated that it may be possible to have them cooperate. The website building system 30 may change the size and position of components within the page to preserve the page design under events that change some of the components within the page. These dynamic layout events include, for example: viewing a website on screens having different sizes; rotate the display device between portrait and landscape modes; changing the size or position of some of the components and changing the content of certain components (in such a way that the components need to change their size). Dynamic layout events may also include component updates resulting from server-based content updates or content changes by other concurrent users of the same website - for example information from a data feed. In the component that displays it. It will also be appreciated that dynamic layout events can occur in the design environment as well as the runtime environment. In particular, some components and third party applications 40 are capable of component content change or size/position change during runtime (by the end user, and not just by the designers).

It will also be appreciated that dynamic layout events may also be generated by third party applications 40 . For example, the e-shop third party application 40 may request a size change when the user moves from the product catalog view to the shopping cart view (which has a different size). As another example, the product catalog third party application 40 may include an option to highlight products, which will cause them to display a larger catalog page containing more content. A third example is a multi-region third party application 40 that can start or stop displaying additional regions.

Existing systems typically do this by clipping a third-party application display, adding scroll bars to the display, or just resizing the display as a pop-up window that hides other page components, as shown in FIG. 6 , which is now referenced again. handle situations like (at least) The dynamic layout updater 360 may implement a cooperative dynamic layout that maintains the basic design of the containing web page 203 and cooperates with the website building system 30 and third party applications 40 to perform the dynamic layout. have. The functionality of dynamic layout is further described in US Patent Application Serial No. 13/771,119, filed on February 20, 2013 and assigned to the common assignees of the present invention. However, even in a cooperative dynamic layout support system, the dynamic layout mechanism in the containing web page 203 does not control the entire internal layout of the third party application 40 . Moreover, the website building system 30 widgets can be designed such that they can be resized to any arbitrary size (within a certain range), although third party applications 40 support arbitrary resizing. may not Third party application 40 may, for example, provide any combination of: multiple display configurations with different sizes (eg, display more or fewer details); The ability to resize some of its internal elements using multiple font sizes and the ability to display some of its internal text elements.

The third party application 40 may still provide a limited number of possible display sizes and may have a full range of possible sizes. Therefore, [included web page 203 → 3rd party application 40] resizing request may result in 3rd party application 40 being converted to the closest possible size or list of possible 3rd party application 40 sizes. by providing (and allowing the website building system 30 to select a suitable size for use).

The dynamic layout updater 360 may implement the [containing web page 203 → third party application 40] cooperative dynamic layout using the following sequences.

For example, a third party application 40 that is embedded in an embedded web page 203 may need to be resized to some desired size (eg, X1*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 predetermined desired size (X1*Y1). Third party applications 40 may be scaled to the above sizes - by using alternative display configurations, internal resizing, internal dynamic layout processing or any other means. It will be further appreciated that the containing web page 203 may resize the external iframe window containing the third party application 40 to a new size (X1*Y1).

It will also be appreciated that the third party application 40 may only be capable of a limited set of resizable sizes (eg, certain user interface configurations). Therefore, the dynamic layout updater 360 may use the following alternative algorithm capable of providing a set of possible sizes for the third party application 40 .

The embedding web page 203 is resized and the dynamic layout updater 360 tells the third party application 40 to resize its content to some desired size (X1*Y1). Send a message requesting The third party application 40 then determines the nearest possible size (eg, X2*Y2 pixels) and uses an alternative display configuration, internal resizing, internal dynamic layout processing or any other means accordingly. by doing so can be resized. The updater 380 may then send to the containing web page 203 a response message confirming the resizing and provide the actual new size (X2*Y2). The containing web page 203 may resize the external iframe window containing the third party application 40 to the actual new size (X2*Y2). The containing web page 203 may continue dynamic layout processing based on the actual new size (X2*Y2).

It will be appreciated that other embodiments are also applicable, particularly if there are multiple third party applications 40 (or multi-domain third party applications 40 ) within the containing web page 203 . The embedding web page 203 in this embodiment will attempt to optimize the look and feel of the embedded third-party applications 40 taking into account a number of options for the number of third-party applications 40 . It is possible to query these embedded third party applications 40 to obtain a list of display sizes. This embodiment may also be suitable where third party applications 40 are displayed across multiple areas.

The embedding web page 203 performs dynamic layout processing so that one or more third-party applications 40 (TPA[1] to TPA[n]) are embedded in the embedding web page 203 using the following algorithm. You may find that it needs to be resized:

Loop from 1 to n over i:

Determined for each TPA[i]

Minimum size Xmin[i] * Ymin[i];

max size Xmax[i] * Ymax[i];

Optimal size Xopt[i] * Yopt[i];

The dynamic layout updater 360 may send a message to the TPA[i], detailing the request information for the above min/max/optimal sizes and possible 3rd party application 40 sizes.

The third party application 40 may provide the dynamic updater 380 with a set of possible size options it may take, Xposs[i][j]*Yposs[i][j].

Based on the Xposs[][]/Yposs[][] information gathered above, the containing web page 203 (eg) a full evaluation of all possible third-party application size combinations, linear programming techniques or dynamic layout Any other technique used by the algorithm may be used to compute a solution to the dynamic layout calculation.

For all TPAs, we store the results in Xfinal[i]/Yfinal[i] and

Loop from 1 to n over i:

The containing web page 203 may then send a resizing message containing Xfinal[i]/Yfinal[i] to the TPA[i].

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

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

It will be appreciated that dynamic layout processing typically requires moving third party applications 40 and not merely resizing them. However, the third party application 40 must not change the exact position of its frame within the containing web page 203 .

As discussed hereinabove, third party applications 40 may also need to change their display window size from time to time. Since the size of the window displaying the iframe is managed by the hosting page (ie, the containing web page 203 ), third party application 40 window resizing must be performed by the containing web page 203 - where The third party application 40 requests to change the window size from the containing web page 203 (via the dynamic layout updater 360 ).

It will also be appreciated that third party applications 40 may also request (via dynamic layout updater 360 ) to change their location within the containing web page 203 . This may not affect the third party application 40 internally (as resizing does), but requires display changes within the containing web page 203 . The dynamic layout updater 360 may incorporate this request with the dynamic layout. The embedding web page 203 changes the third party application 40 window size (and possibly its position) and uses the dynamic layout updater 360 to confirm the size and position change back to the third party application 40 . ) can be activated.

The hub 205 may also include the website building system 30 itself, certain containing web pages 203 , or additional third party applications 40 from which secondary third party applications 40 may affect third party applications 40 . It will be appreciated that the third party application 40 may implement class specific or third party application specific messages. For example, the blog third party application 40 may define an incoming message that may post a new blog entry or a new talk-back to the current blog entry. Such a message may be used by the containing web page 203 (eg, as a way of posting blog entries from a large edit field outside of a third party application area). It may also be used for higher-level application-to-application linking, enabling, for example, a supporting third-party application to post blog entries to a blog third-party application.

It will be appreciated that third party applications 40 often require a wide range of complex services - designers using third party applications 40 for internal use with third party applications 40 or at their sites. for use downstream by them. Such services may include user management, billing and shipping management. A website building system 30 vendor may not be able to provide such services as part of a website building system (eg, due to technical or business considerations). Moreover, these services on their own may not be suitable for “packaging” as a third party application 40 . In addition, the third-party application 40 vendor provides a number of such services (eg, a number of third-party charging APIs) to designers using the third-party application 40 - and Designers 5 may need options that allow them to choose the ones suitable for their use.

For example, an API hosted by Paypal ^™ may be provided within the website building system 30 and used directly by the third party application 40 or may be used by designers by the third party application 40 using it. (5) may be provided. The third party application 40 also provides its own set of options (ie, uses a specific charging type such as lump sum, recurring, or revenue transfer), and implements these options by calling the hosted Paypal API. can

Thus, a designer 5 using the website building system 30 may develop a specific offering (such as a song-selling e-store) that uses evolved billing. Developers 5 can avoid having to negotiate specific authorization or merchant agreements with the charging API provider by using a hosted charging API - either directly or by providing an additional level of abstraction (or layer). Through third party applications 40 . In this sense, the website building system 30 may be a distributor to hosted API vendors.

Hosted API wrapper 390 may facilitate this communication between different parts of the system (eg, website building system 30, hosted API code, and included third party applications 40). can It will be appreciated that the API wrapper layer and the actual API implementation may reside within the website building system 30 itself or other third party applications 40 . A third party application 40 vendor (or designer 5) may use the hosted API via the hosted API wrapper 390 without being aware of how the actual underlying API is implemented.

In an alternative and complementary embodiment of the present invention, Applicants also note that smart integration between website building system 30 and one or more third-party applications 40 also provides additional website building system tablets and components. It has been recognized that this can be achieved by using an integration model that is associated with third party applications at the level of the App Store 25 as well as associated third party application instances. Third party applications 40 may also communicate with these components (as well as unassociated components) to exchange data and control messages. As discussed hereinabove, the third party application areas 40 within the containing web page 203 may have their content in separate domains (third party application vendors or otherwise)—the domain where the main site is hosted. They are separate iframes hosted in different-. Therefore, communication between different iframes is subject to the browser's "same origin policy" and requires the use of techniques as described above herein.

Existing systems are monolithic, which are rigid objects that do not include third party applications 40 in the containing web page 203 or otherwise affect the look and feel of the containing web page 203 itself. implemented as a monolithic). A third party 40 instance is placed within an area (typically rectangular) and performs all of its activities within this area.

Applicants believe that this concept can be extended by having an (optional) additional website building system 30 template associated with a third party application 40, referred to as an association template according to one embodiment of the present invention. It was also recognized that This association may be performed during the development and publication of third-party applications 40 and provides designers 5 with third-party applications 40 selection/purchase processors (from App Store 25) and third-party applications ( 40) It will be appreciated that may be provided as part of the instance creation. The TPA coordinator 24 may retrieve a template associated with the third party application 40 (part of the application repository managed by the app store 25 or otherwise provided by the third party application 40 vendor). as) the template may be stored in the repository 22 for later use as described hereinabove.

It will be appreciated that the system 100 can support the publication of third party applications 40 having multiple associated templates - enabling the designer 5 to select a template that best suits his or her needs. .

Upon creating an instance of the third party application 40 on any containing web page 203 , the components in the associated template may be merged with the containing web page 203 and any other within the containing web page 203 . It will be appreciated that the components may be displayed together.

Reference is now made to FIG. 13 , which illustrates one example of the use of an association template in accordance with one embodiment of the present invention. As shown, the third-party application [a] is deployed in the app store [b] with an associated template [c] comprising components [d] and [e]. When the third-party application [a] is included in the embedding web page 203 [f], the third-party application [a] is displayed within its designated area [g] inside the page [f] and the components [ It will be appreciated that instances [d'] and [e'] of d] and [e] can be displayed on page [f] together with components [h] and [i] of the wire rod.

It will be appreciated that system 100 may support a variety of ways in which associative template component instances (eg, [d'] and [e'] above) are placed in containing web page 203 [f]. will be. These include: absolute positioning (ie using the size and position specified in the association template [c] for the original [d] and [e]); target relative placement (ie, resizing and positioning the new instances [d'] and [e'] according to the containing web page 203 [f]); and the third-party application 40-related deployment (ie, the size and location of new instances [d'] and [e'] in the third-party application instance [g] within the containing web page 203 [f]. Adjusted with respect to the size and position stated against). The determination of a specific placement method can be made on the basis of the settings enclosed with the associated template [c], allowing the designer 5 to override this if possible.

It will be further appreciated that the designer 5 can modify instances of [f] of elements [d] and [e] that are inherited from template [c]. Changes can only be applied to the use of [d] and [e] in [f] (and pages inheriting from the website building system 30 supporting cross-page inheritance where possible), but not in the App Store [b]. It may not affect the "circle" template [c] associated with the 3rd party application [a].

It will be appreciated that changes to instances [d] and [e] above may include: in particular assigning specific content (text, images, etc.) to field instances - as well as regular property changes - will be. It will be further appreciated that if a third party application 40 is contained within a mini-page, then the associated template is applied to the particular mini-page in which the third party application 40 is contained, as shown in FIG. 14 to which it is now referenced. As shown, the third-party application 40 is contained within the mini-page [x] so that the components [c] and [d] are added to [x] but additional mini-pages of the same multi-page container [g]. It is not added to [y] and [z].

In the case of sectioned mini-pages, it will be further appreciated that the associated template (if any) applies to a virtual (and empty) containing web page 203 that is created to contain the third-party application 40 .

In an alternative embodiment, the pre-generated association template may be applied to a newly created page or mini-page that is “parallel” to the containing web page 203 it contains. This newly created page or mini-page can be initialized with a template, which can then be modified as desired.

The website building system 30 may also enable multi-port nesting - where the same third party application 40 instance can be viewed from and "resides" on multiple pages of the main site. ". This may be different from the multiple nesting of a given third party application 40 at the main site, which creates multiple instances of the third party application 40 . The third party application 40 content - specific to the instance - is therefore shared among multiple views of the same multi-port third party application 40 .

In such multi-port nesting, the association template may be applied separately to each of the pages and mini-pages to which the third-party application 40 instance is added.

As described hereinabove, system 100 may provide a two-way communication link between third party application 40 and components within containing web page 203 . It will be appreciated that this includes components not related to any such associative template, as well as containing web page 203 components resulting from the merging of associative templates from third party applications.

Therefore, it will be appreciated that a third party application 40 vendor may create a number of templates associated with third party applications 40 typically produced by the vendor. These templates may include test, development, and other templates in addition to the templates that are actually being distributed (ie associated with the currently distributed versions of third-party applications).

As described hereinabove, third party applications 40 may be distributed through the App Store 25 and also through alternative channels not associated with or managed by the website building system 30 vendor. can be distributed. However, associative templates that are distributed to third party applications 40 may be highly associated with or associated with the application repository 22 , because they contain components managed by the website building system 30 , This is because it is built using base templates and other elements.

Moreover, the website building system 30 elements underlying such separately distributed associative templates may have to be modified or deleted - possibly "breaking" the associative template. To address this problem, the system 100 may implement these associated templates in a separate area within the application repository 22 (possibly per 3rd party application 40 vendor). The website building system 30 may manage these templates in the same manner as other website building system 30 templates.

The third party application 40 vendor may be provided with a unique ID (development ID) for each template created and this third party application 40 will use this ID during the third party application 40 development and testing process. It will also be appreciated that Once the 3rd party application 40 can be published/distributed, the 3rd party application 40 vendor needs to apply for and receive an alternative unique ID (publish ID) and the published 3rd party application 40 You can refer to this in Once a publication ID is provided, a separate locked copy of the template is created. This is the copy referenced by the third party application 40 and used when creating instances of the third party application 40 . In this way, the third-party application 40 vendor cannot inadvertently modify the template associated with the “live” third-party application 40 (included by the designers) and maintain referential integrity. (integrity) is preserved. Moreover, system 100 may cross-reference such locked templates and relationships between underlying components and base templates. This cross-reference may refer to, for example, if any component of the website building system 30 or the base template included in such a locked template is to be modified (and such modification is in some way a template or a third party application). (40) can be used to provide a warning to the staff of the website building system (30).

The system 100 can therefore provide two-way communication channels between the third party applications 40 , components within the containing web page 203 , and the website building system 30 . The containing web page 203 components may be based on template(s) associated with a third party application, based on other website building system 30 templates, or not associated with any template.

As described hereinabove, the communication hub 205 may facilitate communication and provide a back channel between the containing web page and any third party applications 40 . Applicants have further recognized that data flowing backward and forward between the containing web page and any third party applications 40 can be useful once collected, processed and integrated.

For example, web site owners need to manage a user population or members per their site that can be distinguished from the registered user base of the associated web site building system 30 . Web site users may or may not be registered (anonymous) and the website may provide different levels of capabilities to different levels of users. Moreover, users often receive personal or contact information (even anonymous users, ) can be provided as a contact form. It will be appreciated that this information may be entered directly into the site being created or made available as part of an interaction with third party applications 40 embedded within the site.

It will be further appreciated that these pieces of information may be disorganized, uncorrelated, potentially inconsistent and many times not stored at all. For example, a single given user may enter their personal email into a contact form (operated directly by the site) and submit their work email into a separate subscription form (administered directly by the site) within the same session. may be entered into a third party application (operated by 40).

Moreover, the “floating” portions of the information may include different permissions for their own use. For example, users who fill out a subscription form with their email address fully expect to receive email-based subscriptions to which they have subscribed and possibly related email newsletters. On the other hand, a user who supplies an e-mail address as a registration ID may not wish to receive any e-mails to his/her registration address except for e-mails related to his/her account processing, security alerts, and the like.

Reference is now made to FIG. 15 , which illustrates a system 200 for coordinating and gathering data from different messages exchanged between a website building system 30 and one or more embedded third-party applications 40 . The system 200 includes a client hub 210 installed on a client 220 and a server hub 230 installed on a server 260 , a contact coordinator 240 , an activity coordinator 250 , a contact database 245 and an activity stream database 255 . The hubs 210 and 230 differ between the website building system 30 and a number of third party applications 40 installed on the servers 270 and as described above with respect to the hub 205 herein. It will be appreciated that it may facilitate communication between third party applications 40 . Contacts database 245 and activity stream database 255 may hold contact/activity information and information extracted into message streams as described in more detail herein below.

Reference is now made to FIG. 16A , which shows elements of a client hub 210 , and FIG. 16B , which shows elements of a server hub 230 , contact coordinator 240 and activity coordinator 250 . The client hub 210 includes a router 211 , a converter and adapter 212 , and a privacy policy enforcer 213 . The server hub 230 includes a router and tracker 231 , a converter and adapter 232 , a privacy policy enforcer 233 , a personal data proxy 234 and a verifier and signer 235 . The contact coordinator 240 includes a data extractor 241 , a contact processor 242 , a data merger 243 , and a data and permission processor 244 . Activity coordinator 250 includes a stream generator 251 , a stream merger 252 , and a log generator 253 . The function of these elements is described in more detail herein below.

Reference is now made to FIG. 16C , which shows elements of stream merger 252 , and FIG. 16D , which shows elements of data merger 243 . The stream merger 252 includes an activity-to-stream merger 261 and a stream-to-stream merger 262 . The stream-to-stream merger 262 further includes a horizontal stream merger 263 and a vertical stream merger 264 . The data merger 243 includes a contact identifier 272 , an aggregator 273 , a discrepancy resolver 274 , a list value generator 275 , a vertical contact merger 276 and a horizontal contact merger 277 . do. The horizontal contact merger 277 further includes a virtual horizontal merger 278 . The vertical contact merger 276 further includes a virtual vertical merger 279 . The function of these elements is described in more detail herein below.

System 200 is a system that organizes active messages by streams, stores active message histories, delivers multilevel active messages, uses side channels for active messages, converts active messages, and adapts content as described in detail herein below. , it may be possible to forward messages between the system 200 and a number of third-party applications 40 while providing a variety of capabilities including dynamic message routing using active message validation and signature and listener queries. will be acknowledged

Moreover, the system 200 may extract and merge user-related information - incorporating information already present in the system 200 as well as information from multiple sources. This can be done through merging rules that disparate and possibly reconcile inconsistent information. The aggregated information may be stored in the contact database 245 . This information may also include permission fields that control the permitted use of the collected information as described in more detail herein below.

In alternative embodiments to the present invention, only the client hub 210 and the server hub 230 will be used to communicate with a number of third party applications 40 installed on the servers 270 . can It will be appreciated that in situations where only the client hub 210 is used, the contact coordinator 240, activity coordinator 250, along with databases 245 and 255, may be installed locally on the relevant client.

The system 200 allows third-party applications 40 to manage activities with which the user contacts (eg, mass mailing of newsletters) while enforcing usage restrictions set by the users themselves. It will be further appreciated that it may include additional components that enable it. Such components can even isolate user personal data from third party applications 40 - so that third party applications 40 can perform their actions without actually accessing personal user data. . Such capabilities may be implemented, for example, using personal data proxy 234 as described in more detail herein below.

It will also be appreciated that the contacts database 245 may be specific to each site. However, the website building system 30 defines a meta site/project level containing a collection of web sites (owned by the same site owner) and rather than a single site level. It may be possible to specify at the meta site level that contacts are stored, processed and merged. Other site elements (such as included third party applications 40) may also be defined at the meta site rather than the site level. Other than meta-site support, system 200 typically does not share contacts (except as described below) or may not aggregate contact information between different sites or different site owners (a certain final to ensure that data provided by users to one site is not leaked to another).

As detailed herein, system 200 may support a number of interactions between website building system 30 and one or more third party applications 40 . Such interactions may be predefined activities such as making a purchase, adding an item to a shopping cart, populating contact information, and the like. The third party application 40 may specify which activities it will support and other third party applications 40 may "listen" to certain activities and based on the received activities and information associated with them. so you can act It will be appreciated that the lists of activities that are listened to for a given third party application 40 may be explicitly set to one or more activities as described in more detail herein below or may be determined by an activity listening query. will be.

It will be appreciated that each activity may be considered a message and each message may include an activity data structure. Activity data structures are predefined data types, but can be defined through inheritance between them and through third party applications 40 which may have the option to extend them by adding fields. These may be system specific, or may be based on or include standardized data structures. They can 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 a “description” field. This is a third party application 40 based description of the activity (which may be further detailed than is known in the website building system 30 ). For example, the VOIP communication third party application 40 may provide the activity description text of "Call John Smith at 999-555-1234 01:15".

The activity data structure may further include a callback link returned to the activity data structure, for example "more information". This is for: e-commerce activity structure: full order tracking information, history of orders, etc.; For the chat activity data structure: the full chat transcript and for the phone activity data structure: can be used to provide additional substantive information, such as the history of the call. Therefore, a sample complete activity data structure may contain the following fields: creation timestamp; activity type; source of activity (third party application 40/component ID); activity stream id; activity type specific information (depending on activity type); creation site ID; site member database ID; ID/URL of the site page where the activity occurred; activity descriptions provided by third party applications 40; Links to more information used by third party applications 40 and user details captured, etc.

Activity coordinator 250 may be considered a logging element and may receive data from a forwarding message from hub 230 . Stream generator 251 may generate an initial stream, which may be considered a log or chain-like structure, and stream merger 252 may add any additional incoming activity to this stream, where each stream is a contact is unique to It will be appreciated that the stream generator 251 may not create a new stream for each individual activity included in different messages. It will be further appreciated that activities included within the stream may be out of sequence (eg, a third party application 40 may be delayed in reporting the activity). Stream merger 252 may merge these streams during operation if they belong to the same single contact and log generator 253 may store a log file in activity stream database 255 of all previously created activity streams. have.

As described herein above with respect to FIG. 16C , stream merger 252 includes an activity-to-stream merger 261 and stream-to-stream merger 262 . Activity-to-stream merger 261 may associate an activity into a stream associated with the identified contact and stream-to-stream merger 262 may convert the two separate streams into a single stream. Horizontal stream merger 263 can merge two unrelated streams due to the common primary ID being detected and vertical stream merger 264 can merge the stream created for anonymous contact and the one associated with registered user. You can merge the two at registration or login time to connect the streams. It will be appreciated that stream merger 252 can access previously created streams from activity streams database 255 when needed.

For example, an anonymous user fills out a contact form on the site. Stream generator 251 creates a new activity stream (with ID “anon 1”) and contact handler 242 creates a new contact (with ID “anon 1” as described in more detail herein below). can do. The same user can then chat with the site owner. Stream merger 252 then merges this activity into the “anon 1” activity stream and the contact “anon 1” is updated (as described in more detail herein below). The user uses a different browser and then fills out the schedule form. Since no correlation exists for the original user, stream generator 251 can create a new activity stream with ID “anon 2” and contact handler 242 creates a new contact with ID “anon 2”. can

The user then purchases something from the site. Stream merger 252 merges the new activity into the “anon 2” activity stream and the contact “anon 2” can be updated (eg, with a “customer” tag).

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

Afterwards, the user returns to another browser to chat with the site owner. Since the website does not have a cookie, stream generator 251 may create another new stream ID “anon 3” and contact handler 242 may create a new contact “anon 3”.

Now, the user logs into the website. At this time, there is a contact by ID "anon 3" and ID "user x". Data merger 243 is configured to point to activity streams “user x” and “anon 3” such that both the login activity in the “user x” stream and the login activity for the contact “user x” point to the contacts “anon 3”. " can be merged into "user x". Stream merger 252 may merge any additional actions performed by the user in this session into the “user x” activity stream. The log generator 253 may log all activity data from the streams and store a copy of the log in the activity database 255 .

It will be appreciated that the site owner may access a history of the activity stream for a given contact via an associated user interface provided by the website building system 30 as shown in FIG. 17 to which reference is now made. In the case of a single contact "Dani Bronstein", this person's website usage history 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 log information. It will be appreciated that activity logs may be used for optimization, user interface improvement, advertisement targeting, and the like.

At the same time, it will be further appreciated that contact coordinator 240 may gather information from data provided by activity streams (messages) to augment the contact profile of that user. Data extractor 241 may extract data from activity messages and streams, and data merger 243 may store the relevant data into a specific contact whose details are stored and can be accessed from contact database 245 . can be merged Contacts handler 242 may create new contacts, handle site user identity, anonymous users, etc. and data and permissions handler 244 may handle privacy protections and permissions of related data. As described hereinabove, the data merger 243 may include a horizontal contact merger 277 and a vertical contact merger 276 . The horizontal contact merger 277 may merge two unrelated contacts due to the common primary ID being detected and the vertical contact merger 276 may combine the anonymous contact and the contact associated with the registered user. You can merge the two upon registration or login. Horizontal contact merger 277 may also include a virtual horizontal merger 278 that keeps two contacts separate but links them together such that they are marked as representing the same contact - merging real contact information With or without merging -. Vertical contact merger 276 also maintains anonymous contacts and contacts associated with registered users separately, but uses vertical virtual merger 279 to link them together so that they are marked as representing the same contact. MAY include - with or without merging actual contact information. Data merger 243 may also merge contact information (typically extracted by data extractor 241) into existing contacts. It will be appreciated that contact identifier 272 may use cookies to track user identities and recognize contacts to be merged, as discussed in more detail herein below.

Referring again to FIGS. 15 , 16A and 16B , message delivery may be performed at the client 220 , the server 260 , or both. It will be appreciated that third party applications 40 typically have a client side component as well as a server side component or at least have a server side connection to the third party application 40 provider server 270 . . Hub 210 can process any messages between client 220 and third party applications 40 and hub 230 between server 260 and third party applications 40 . It will be appreciated that data received by hub 210 may be processed and sent to hub 230 for further processing as described in more detail herein below.

Reference is now made to FIG. 18 , which illustrates a message passing scenario between different platforms. User client machine X may be connected to website building system 30 on server Y. The website building system 30 may be implemented using the website building system 30 client component A' and the website building system 30 server component A. When the site being created is displayed, it may include client-side elements (data/code) (B') and server-side elements (B). The created site may also include three third party applications 40 - TPA1, TPA2 and ETPA3.

TPA1 may be implemented as a client-side component (D') and a server-side component (D) connected to the TPA1 vendor server (H). TPA2 may be implemented as a client-side component (E') and a server-side component (E) connected to the TPA2 vendor server (I). However, ETPA3 may be the only 3rd party application 40 on the server side implemented by the server side component G connected to the website building system 30 3rd party application 40 support backend F have. These two may communicate with a third party application 40 vendor server J.

It will be appreciated that TPA1 and TPA2 may exchange messages at the client (between components D' and E'), at the server (between components D and E), or both. . However, any communication with ETPA3 only has to be performed on the server. It will be further appreciated that there are advantages and disadvantages to either method. Sending client-side activity messages can be more interactive and provide faster user responses. Server-side active message sending is stronger, more reliable (eg, a user cannot close a browser window during processing), can better guarantee the correct order of receiving messages and also ensure that active messages are sent to the backend or application dash It may enable transmission to backend third party applications 40 installed on the dashboard. It will be appreciated that these backend third party applications 40 are not presented on the client side.

One example when using multiple third party applications 40 is that a user adds a product to a shopping cart in a third party application A (activity type is “change cart”). The third party application A may then send an activity message with the added product to the website building system 30 . The website building system 30 may then transmit this activity to all third party applications 40 registered for cart changes. A third-party application (B) is registered and therefore receives the activity. The third party application (B) may then display a message to the user such as "if you also add product X, you will get a discount" or "share this site to get a discount".

Another example would be something like a user "Like" (eg via Facebook) in a 3rd party application (A). The third party application A may then send an activity message with the activity type “Facebook Likes” to the website building system 30 . The website building system 30 may then send the activity to all third party applications 40 that are registered for “like” activities. A third-party application (B) is registered and therefore receives the activity. The 3rd party application (B) shows the user a re-engagement widget and asks "If you like this site, how about contacting the site owner?" Or it may display a message such as "Do you want a discount coupon?"

As discussed above herein, all communication 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 herein below.

The router and tracker 231 may route messages between the website and any third party applications 40 and may also track messages. It will be appreciated that third party applications 40 may also listen for messages at both the client and server. It will further be appreciated that the third party application 40 may explicitly specify one or more activities for which it listens, eg, for all “shopping cart-add item” activities. The third party application 40 may also specify activity classes to which it listens, eg, all Facebook related activities. Moreover, the third-party application may include a wild-card expression (applied to activity names) that is used to determine if the activity should be sent to the third-party application.

It will also be appreciated that third party applications 40 may use activity listener queries. Such a query may include user attributes (eg, registered users only, European users only, etc.), web site attributes or structure (eg, only predefined pages on pages derived from predefined page templates). ), user history (e.g., just listen to cart checkout activity if the user has purchased in excess of X in the past) containing information not normally available to third-party applications themselves, such as Additional system information may be mentioned. Such queries may be specified by the third party application 40 , but may also be editable by the designer.

The router and tracker 231 can therefore also keep track of messages being listened to by the third party application 40 . Such an activity listener query architecture may enable a website designer to perform customization and customization without requiring third party applications 40 to be highly programmed and user-customized, so the activity It will be appreciated that this may best be implemented at the routing level (instead of being done by API calls inside the 3rd party application 40). The router and tracker 231 can also help preserve user privacy, since the website designer does not need to provide additional information (necessary for routing decisions) to the accompanying third party applications 40 . Because. This may also save unnecessary invocations of communicating with third party applications 40 that are often hosted on separate servers.

It will be appreciated that it is the user (website visitor) who visits the website, registers and provides information to the website. The user is unaware that the website he is actually accessing is being built using a combination of the website building system 30 , components, configured websites and third party applications 40 . Therefore, responsibility for user privacy ultimately rests with the website owner (and also responsible for activities undertaken by third party applications 40 included in their website).

The user profile information is based on the privacy rules defined by the website building system 30 and is provided by third party applications 40 (and other website building systems) via APIs provided by the website building system 30 . (30) components) will be further appreciated. Moreover, the containing site, as well as third party applications 40 included therein, may use the contact information to communicate (via email or otherwise) with the user.

It will be appreciated that there may be three major privacy-related issues. The first is the interaction of the website and the website building system 30 with the third party application 40 provider. The website (and website building system 30) may not completely trust the third-party application 40 to use its user data, for example, the third-party application 40 You may not view (using site-provided user emails), send spam mail to users who have requested not to mail, or completely trust that you will not transmit your personal information to third parties. However, this can be addressed in the following ways:

A website building system 30 vendor may require third party application 40 providers to sign a Terms of Use (ToU) agreement when adding them to the website building system 30 application marketplace. can Such agreements specify that third party applications 40 (and third party application 40 vendors) will not misuse or further disclose the user's information. The website building system 30 vendor may then penalize the third party application provider if the third party application misuses the information (eg, disabling the third party application 40 , the third party exiting the application 40 from the website building system 30 application market, etc.). Privacy policy enforcers 213 and 233 and personal data proxy 234 may enforce privacy policies in third party applications 40 as described in more detail herein below.

A second privacy-related issue is the interaction with the website and the users (site visitors) of the website building system 30 . Websites must provide users with a clear understanding of how their personal data will be used, receive agreements from users and comply with the terms of use agreed by the users. The website building system 30 requires that all published sites provide the user with a ToU document stipulating the permitted use of personal information belonging to the user, and the user is asked to electronically sign the document. The Site must then comply with these Terms of Use and any permitted use. The website building system 30 may also include a sample ToU page in each website template it provides. Personal policy enforcers 213 and 233 may ensure that the conditions of use of the ToU document are observed. Personal policy enforcers 213 and 233 may also ensure that only permitted information is provided to the TPA by deleting or rearranging the relevant data.

A third privacy-related issue is the support of unsubscribe requests. The site must provide the user the option to unsubscribe from any marketing emails. This may be processed by data and permission processor 244 described in more detail herein below.

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

The personal data proxy 234 allows the website building system 30 (and websites built within the website building system 30) to store all or some of the personal data in a secure repository managed by the website building system 30 . may provide alternative unique IDs (instead of personal data) to a third party application that may be stored on the web site and used by the website building system 30 to retrieve hidden personal data. For example, the email address is replaced with an alternative “email address ID” provided to the third-party application 40 so that the third-party application 40 cannot access the actual email address.

Personal data proxy 234 may also provide a variety of functions that may be used by third party application 40 to contact/send messages to a user without the third party application 40 actually accessing personal data associated with the user. It may provide a set of interfaces for communication methods (eg, email, social network messaging, etc.). Such personal data includes (for example) any identification with which the user may be contacted, including name, address, email, telephone (including SMS/MMS), unified communications ID (Skype, etc.) and social network ID. It may include details.

The personal data proxy 234 can therefore enforce user permission field restrictions, enforce user unsubscribe requests and throttling user message transmission, e.g., any third party operating on a given site. You may only allow 100 emails per day for the application 40 . The personal data proxy 234 may define proxy parameters and define what personal data can be exposed and hidden to third-party applications - per third-party application 40-by specifying these in one field. It can be set based on one.

For third party applications 40 hosted on website building system 30 servers, personal data proxy 234 provides an alternative unique ID that is similar in shape to the original personal data (eg, the original You can "capture" the call (in this example) to use this information and send the email to the correct address. It can also be used to detect any third party applications 40 that exceed their granted privileges.

It will be appreciated that website owners may wish to provide limited or modified information to any particular third party application 40 . This may be due to, for example, general security-related issues, specific privacy entrustment with respect to certain elements of a user's data, or regulatory requirements specific to a specific industry or application. Personal policy enforcers 213 and 233 may implement any such changes made by the website owner and overwrite current settings.

One example would be a website that processes medical information, which website is interested in blocking some personal details from contact information when passing it on to a general geographic user distribution analysis third party application 40 . there may be In another example, the third party application 40 may have problems processing certain types of contact information. A website owner wishing to continue using the third party application 40 (despite known bugs) may wish to filter out known problematic contacts or modify the data so that it does not cause problems.

Converter and adapters 212 and 232 may apply pre-specified message transformation and content adaptation rules. Each such rule includes conditions such as which third party application(s) 40 this rule applies to, filtering criteria for selecting which messages this rule should apply to, transformation rules (predetermined messages) It may include transformations to be applied to certain fields or fields in the activity data structure, such as discarding (as far as the relevant third-party application 40 is concerned) or.

In this way, hubs 210 and 230 may pass different versions of activity data structures to different third-party applications 40 (or not at all) - subject to specifications made by the site owner. according to.

The relevant website building system 30 also supports verification and signing of messages to attempt man-in-the You can harden your system against (such as -middle attack). Therefore, each third party application 40 registered with the website building system 30 may have two sets of private/public keys: one from the third party application 40 to the website building system ( 30) the key used to decode messages sent to (incoming key) and one key used to encode messages sent from the website building system 30 to the third party application 40 (exit key) to be.

For example, the third party application A may send a message to the website building system 30 . The message may be sent with a 3rd party application ID for the site - a 3rd party application external ID (with 3rd party application scope) - which may be signed by the 3rd party application. The website building system 30 may receive the message. The verifier and signer 235 may verify the signature using the import 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 further messages are sent.

The verifier and signer 235 may translate an external ID associated with a message having an internal site ID. The verifier and signer 235 may ascertain which third party application(s) 40 should obtain the message.

For example, for each third-party application (B1..Bn), the verifier and signer 235 may find the external ID of the third-party application (B). The verifier and signer 235 may then generate a message to the third party application B and apply any applicable filtering and transformation rules as described hereinabove to the converter and adapters 212/232. can instruct The verifier and signer 235 then signs the message with the retrieval key to the third-party application B and sends this message through the router and tracker 231 (or router 211) to the third-party application ( B) can be sent. The third party application B can then receive the message and verify the signature. If the current verification fails, the message is reported as invalid and not further processed. It will be appreciated that verifier and signer 235 may perform only server-side processing and no client-side processing to ensure that secret verification data is not sent to untrusted clients.

As described above herein, system 200 may use multiple types of communication between website building system 30 and third party applications 40 . These types include, for example, control communication, eg, the website building system 30 instructing a third-party application 40 to shut down, functional communication, eg, a shopping cart third sending the total purchase amount to the billing third-party application 40 via the website building system 30 such that the third-party application 40 influences a payment or activity communication, an example discussed herein. It will be appreciated that these different types of communication have different profiles and requirements with respect to, for example, quantity, priority, robustness, response time requirements, etc. of messages transmitted.

In particular, the system 200 is responsible for very frequent (eg, when third party application 40 graphical user interface (GUI) events are retrofitted to reported third party application 40 activities). Reports may be included. Such many activity reports can overwhelm parts of the system that process more critical messages. Thus, system 200 may implement multiple communication channels (eg, using different ports, multiple concurrent sessions, etc.) such that each class of messages is transmitted on a separate channel. In this way, activity reporting uses a side channel and parallels command and function communication, but does not interfere with this command and function communication.

As described hereinabove, system 200 may collect activity information to analyze activity events associated with a particular contact, as well as to generate and enrich contact information via contact coordinator 240 and activity coordinator 250 . have. For each activity message routed through hubs 210 and 230 , contact coordinator 240 and activity coordinator 250 may process the information. Stream generator 251 may generate contact specific data streams from activity messages and elements of contact coordinator 240 may process the data before extracting and storing it on contacts database 245 .

Thus, each activity stream may have a constituent contact associated with it and may be progressively enhanced by data extracted from activities performed under the data stream. It will be appreciated that contact coordinator 240 may also be aware of the existence of related contacts - multiple contact records found describing the same person. Contact identifier 272 may recognize such records by matching primary ID fields, such as email, phone number, social security number, Facebook ID, and the like. It will be appreciated that some primary ID fields are multi-valued fields (eg, a person may have multiple identifying emails), while some are entirely single-valued fields (eg, social security number). will be.

The data merger 243 can therefore merge the contact fields extracted from the new activity into the currently configured contact and once the anonymous user has performed a login operation and has become an identified user, this anonymous user can be used during use of its website. A configuration contact that is configured for a user may be merged into a predefined stored contact (this may be known as a “vertical” merge). Horizontal contact merger 277 may also perform a “horizontal” merging of two different contacts (either configuration contact or store contacts) if it detects that there are related contacts that refer to the same user. As discussed hereinabove, such merging can be accomplished through physical merging (ie, converting two separate contacts into a single contact), merging one contact into another, or via virtual merging (ie, two contacts). keeping the contacts as separate contacts but linking them together so that they are marked as representing the same user (with or without merging the actual contact information and activity streams). It will also be appreciated that further added information can be added to multiple linked virtual merge contacts, even in a virtual merge.

Therefore, data extractor 241 may extract contact-type information from the relevant data activity structure and data merger 243 may incorporate contact-type information into a contact (anonymous or identified) associated with the activity streams. . If the contact type information I includes a primary ID field, the data merger 243 may check for related contacts based on the primary ID field value and, if found, merge these contacts. have. Data merger 243 may also check if the activity establishes the identity of the user on the site (eg, site login activity) and, if so, merges the anonymous contact with an existing contact record stored for the user. and make it an identified contact from now on.

Contact identifier 272 may, for example, use cookies to track sessions by a single anonymous user (who has not logged into the site), use site logins for registered users, or if their account is social Multiple identification of site users either through social login for site users associated with the network or by matching primary ID fields (such as email/phone) to identify two user profiles that describe the same user. It will be appreciated that methods may be implemented.

anonymous users whose details are stored in the contact database 245 are not registered with the site; It will be further appreciated that registered users and potential users may be classified as records (imported from external sources) of potential users who have not yet been officially registered with the site.

Since the relevant website may install persistent cookies that persist from session to session, multiple anonymous sessions that may run in the same browser on the same computer may continue to contribute information to the same contact history. Therefore, even an anonymous user can have significant context and contact information.

Registered users must provide a unique ID for a particular site. multiple, such as separate site-specific IDs (eg usernames), external identifiers such as email, phone numbers or social security numbers, or external identifiers provided by different systems, such as social network IDs, Google IDs, OpenID identifications, etc. The types of IDs of may be used.

A user who registers through a social network login may enable the site to use personal information available within the social network to populate the site profile of the same user. Data extractor 241 may also detect any changes to this personal information and revisit the social network profile, possibly to update the site user profile.

Registered users typically must log into the system to establish their identity, although the system offers the option to "keep access to this system". Such a login procedure may be explicit - in which the user invokes a login dialog - may be implicit - in which the user needs to provide some identifying details, for example when adding a talkback to a blog - or It may be external login based - the system invokes a login procedure associated with a different system, such as a social network login or OpenID login. The login procedure may also be via a physical device (eg, a security token connected directly to the system or via a wireless interface) or through the use of biometric information (the user's biometric parameters, eg, fingerprint). or both (including both iris scans as well as detection of a user's behavior such as typing pattern detection) or any combination of the methods described above.

It will also be appreciated that a social login procedure may interact with a regular login in both directions. For example, a social ID may be associated with a site member ID such that a social login implies a site login or the site member ID may be associated with one or more social network IDs such that the site login may also identify the user to one or more social networks. may be related to

When the user performs an explicit logout, the contact handler 242 generates a new anonymous user cookie and therefore opens a new anonymous session (or series of sessions) in which his activities will be stored under this new anonymous contact. can This new anonymous contact can possibly be merged with a later identified contact on further logins.

Reference is now made to FIG. 19 , which illustrates the login and logout process of an anonymous user. Users can start using the system anonymously. Contact handler 242 may create a contact and stream generator 251 may automatically generate an activity stream (anon 1) when a user performs a primary third-party application action (act1). Stream merger 252 may merge information from act1 and information from the following activities (act2 and act3) into user anon1.

Once the same user has logged in as user X, data merger 243 may merge the anon1 contact (and any other relevant contact data retrieved from the activity stream) into user X's contact information. It will be appreciated that stream merger 252 may also merge information extracted from additional actions act4 and act5 into a single stream and data extractor 241 may then extract user X's contact information. . If user X logs out, contact handler 242 may create a new cookie and isolate further activities from user X. Therefore, when a new activity (act6) is performed, contact handler 242 may create a new anonymous contact anon2 and data extractor 241 may generate its extracted contact details (and activities) into the newly created anonymous contact anon2. It can be stored under the contact of anon2.

When user anon2 performs a second login as user Y (as in scenario A), data merger 243 converts the contact information for user anon2 (as updated by act6 and act7) with any further activity. Together we can merge the contact details for user X (already updated to reflect act1 through act5).

It will be appreciated that an activity data structure associated with activities may also include contact details. Data extractor 241 may extract this information and send it to data merger 243, which may incorporate this information with existing contact information in contact database 245 and possibly enrich it. have. Data extractor 241 may extract details from specific activity messages, from full streams, from other contacts or from an external source, such as IP to geographic address translation services, as described in more detail herein below. It will be further acknowledged that As discussed hereinabove, contacts in contact database 245 may also be provided explicitly by a user to a website as part of a registration or signup process, or when subscribing to a website (via a social login/registration feature). may include contact details extracted from a social networking account used by the user or provided by the user when updating his or her user profile. Data extractor 241 may also retrieve contact information from an external source (eg, when the user specifies only a US zip code, and the full address from the external zip code it decodes the web service from). when used by the site to retrieve information).

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

B1 = B or A (as in "B|A"); Take B and take A if B is 0 or empty;

B1 = math-func(A, B); Important personal cases are:

B1 = A + B; eg visits, total purchases;

B1 = min(A, B); For example - the date of joining the site;

B1 = max(A, B); For example, date of last activity;

B1 = list-unit(B, A); Concatenate list A at the end of B, and remove elements in A that may be duplicates for elements in B (ie, B1 = B & (A-B)). Data merger 243 may determine replicas between list members according to the following rules:

For lists made up of regular values (ie, scalars), use regular value comparison;

For lists made up of structures, using a specific subfield of the structure as a comparison key. For example, an address type (home, business, delivery,...) in the website building system 30 that supports multiple addresses;

Normalized value comparison. See (for example) the handling of phone numbers below:

If structure A is a more detailed version of structure B, then incorporate A into B (described in more detail below herein) and

Higher certainty score—a value may have a certainty score assigned to it (eg, having a different certainty score for information provided directly by the user versus information inferred about the user). The data merger 243 may select the value with the higher certainty score.

It will be appreciated that some field types have a normalized format. For example, phone numbers can be normalized to a normalized US format (eg, (999)555-1234) or an international format (eg, +1-999-555-1234). Data merger 243 may convert the field value into a normalized format for comparison, such as when comparing primary contact keys (such as a phone number) and when checking for duplicates in merged lists.

Data merger 243 can compare two structured values having the same underlying structure - for example, an address value consisting of multiple subfields (country, state, house code, street, number, etc.) . If each of the non-empty fields in X has the same value as each of the same field in Y, i.e. Y contains all non-empty field values of X and possibly some additional field values, then structure Y is A detailed version of Structure X. Therefore, data merger 243 may merge A into B if A is a detailed version of B and A is not the same as B.

It will be appreciated that the data extractor 241 may infer the contact address from the IP address from which the activity originated. This is only used if the activity arrived from a browser session and the user does not have an address. Therefore, the data extractor 241 may extract state/country information according to the geographic information of the IP address. In this case, the address is denoted as an "estimated geographic IP address". This prevents future address merging - the address field contains an existing (and possibly incorrect) address based on the IP mapping, which will be stored in the contact database 245 with a detailed (but fundamentally different) address It may interfere with - so it is necessary to prevent it from doing so.

Data merger 243 may also handle tag conflicts for merged lists. It will be appreciated that, in the case of merging lists, it is possible to run into a situation where two entities exist: an entity from contact A, and a second entity from contact B, which has a different but identical tag. In this scenario, data merger 243 may merge the list by loading both entities with the same tag into the list.

So, the combination [{tag:"home", email:"a@b.com"}] + [{tag:"home", email:"c@d.com"}] would be [{tag:"home", You can create email:"a@b.com"},{tag:"home", email:"c@d.com"}]. This will be used if the fields being merged are marked as "Non-unique list tags allowed".

Data merger 243 may also use references to external data sources or services as well as language, syntax, or other text analysis methods when attempting to consolidate contact information. For example, a user may have entered his home address street name in two activity records in two different ways—but specified with the same home phone number, city and house code. The aggregator 273 may apply text analysis (eg, a soundex algorithm) when comparing the two entries, and also convert the two versions of the street name to a street name for a given city and zip code. can be compared with external sources of In such a case, aggregator 273 may select this orthodox street name if both addresses are similar (but probably not identical) and all other address data fields have appropriate values.

Data merger 243 may also merge contact information according to login/session information. A user can use the site without performing a login or registration, start a session, and perform some activities as part of and subsequent registration or login of this session - thus creating a session with a new or existing registered user profile (contact information can be associated with).

Once the user initiates a session (as anonymous), the contact identifier 272 can track the user during the session (using cookies, session ID, etc.) and the contact handler 242 can be used by the user during the anonymous session. A configuration contact may be created for a particular anonymous user based on the activities performed. The router and tracker 231 may also continue to track the anonymous user across multiple sessions from the same computer. This can be done by using a persistent cookie (rather than a session cookie).

When a user registers, data merger 243 may initially use the configuration contact information to populate the user profile. Once users log in, data merger 243 may initially integrate the configuration contact information with the existing user profile. The configuration contact information will be merged according to the user's site ID, as the data merger 243 may not have any other primary ID (such as email) for use in the configuration contact for merging. It will also be appreciated that any such merging may expose inconsistencies in the collected information. When merging anonymous configuration contacts with existing profile data, inconsistencies may arise and may be unavoidable. For example, an anonymous user fills out a data form (displayed by some third party application 40) under the command of John Smith and then logs into an account under the name Jane Doe (either the same or separate browser sessions). using). It is possible (for example) that subsequent logins were actually done by a second person using the same computer, or that the user used a pseudonym in the contact form to protect his or her privacy. The same may apply when data merger 243 merges multiple anonymous constituent contacts.

The inconsistency resolver 264 can typically handle inconsistencies automatically, as most fields are list fields that can contain multiple values (including primary key fields such as email and phone). This may only apply to multiple uses of the same underlying site. Any such discrepancy that cannot be resolved (eg, by merging multiple values into a list value) may be resolved by the site owner, by the end user (who can decide which value to use), or using other techniques. It can be flagged for possible manual handling.

Therefore, it is possible that the configuration contact information may reflect a single person as well as a combined set of users accessing the same site via the same computer.

As discussed hereinabove, data merger 243 typically merges contacts according to primary ID fields (such as email and phone numbers) whenever contacts are created or modified.

Input is a contact record (input contact C) having one or more primary ID field(s) having one or more values (eg, a contact record with two emails and three phone numbers). A number of primary ID fields are provided when a user may have (eg) a home/work/cellular phone number and home/work email - and the user may use any one of these interchangeably in a contact form When there is - it may be necessary.

Data merger 243 normalizes the primary key values and returns any of the normalized primary key values, e.g., "(Phone=P1 or Phone=P2) or (Email=E1 or Email=E2)" You can create a query for the contact history that contains it. Data merger 243 may additionally limit the query to contact database 245 for a particular site. Data merger 243 may query contact database 245 and retrieve matching contact list L (including input contact C).

If the input contact is a registered site member (of a specific site), data merger 243 may remove contact C from list L and merge all remaining contacts in list L into contact C. have. Data merger 243 may then store updated contact C back to contact database 245 and remove all remaining contacts in list L from contact database 245 . As discussed hereinabove, data merger 234 alternatively virtual merges, merges all contact information (ie, updates all contact records to include all available information) and matches matched contact records to the same Marking as belonging to a person (instead of deleting "replicated" contact records) can be done. This may be necessary, for example, if third-party applications 40 store or use internal IDs specific to contact records, and therefore deleting the contact records would cause this third-party application 40 to fail. . The same treatment (ie, marking contacts as relevant rather than deleting them) may apply to other cases discussed in greater detail herein below.

If the input contact is not a registered site member, data merger 243 may check to see how many site member contacts are in list L. If there are zero site members, it may remove contact C from list L and merge all remaining contacts in list L into contact C. Data merger 243 may then store updated contact C back to contact database 245 and remove all remaining contacts in list L from contact database 245 .

If there is one site member (contact D), data merger 243 removes contact D from list L and removes all remaining contacts in L (including contact C) from contact D ) can be merged into Data merger 243 may then store updated contact D back to contact database 245 and remove all remaining contacts in list L from contact database 245 .

If there are more than one site member contacts D, D1, D2,... You can select and remove a contact (D) from the list (L). Data merger 243 may then create a sub-list LL from list L, including contacts in list L who are not site members. Data merger 243 may then merge all remaining contacts on list LL into contact D. The data merger 243 may then store the updated contact D back to the contact database 245 and remove all remaining contacts in the list LL from the contact database 245 .

As discussed above for login merging herein, inconsistencies may arise in the data. However, since the list value generator 275 can generate list value fields (having multiple values) and define a clear precedence between contacts, the problem may not arise in most cases. .

For example, data merger 243 merges the following contacts:

Contact1 = [Phone1, Email1];

Contact2 = [Phone1, Email2];

Contact3 = [Phone2, Email2];

This can result in a combined contact:

Combine - Contact = [Phone = [Phone1, Phone2], Email = [Email1, Email2]].

It will be appreciated that the contact database 245 may contain contact information from multiple sources and having different levels of permissions for its use. The following discussion refers to emails; However, this discussion and technique applies to any type of information used to contact a user as noted above (telephone, fax, Skype ID, instant messaging ID, social network ID, etc.).

For example, the manner in which an email address was provided to a site may indicate different permissions for its use. Some possible sources for email addresses include registration ID; Contact forms, newsletter signup and unsubscribe requests. Email addresses may be further different in terms of an “accepted user agreement” that is electronically signed by the user.

It will be appreciated that the website building system 30 typically has information regarding permitted uses for a given email. However, the website owner may be different, separate, or additional can have information.

The data and permissions processor 244 may enforce rights user policies on third party applications 40 used on the site to assist the website owner in managing this information.

Therefore, a contact record for a related contact may contain two fields of information. The first field is a website permission field containing derived or suggested permissions calculated from user activity by the website. A contact form can only imply functional emails, whereas a subscriber form can imply recurring emails. The second field is a site owner permission field based on the website permission field value. The site owner may change the website recommendations and do whatever he likes, but he is responsible for any use that exceeds the permissions stipulated by the website permissions field.

It will be appreciated that the website permission field value represents the best information of the website about the intent of the users. The site owner permission value is a value assigned by the website and used by the third party application 40 and other parts of the system (eg, by the third party application 40 providing newsletter transmission). to be.

The data and permission processor 244 may use these permission fields to define permissions in a number of ways. For example, data and permission processor 244 may implement any of the following codes or combinations and variations thereof (for email as well as other contact IDs).

Unknown - Email has been extracted from unknown sources and cannot be used to send any email.

Email ID - Email provided for registration purposes. It cannot be used to send any e-mail except for registration-related issues such as registration confirmation, forgotten passwords and notification of suspected security breaches.

Functional Emails - Provided for specific functions and allow one-time emails. For example, purchase confirmation emails or emails provided for specific contact forms.

Recurring Email - Allows multiple and periodic subscriptions and advertisements to be sent by a particular website. This requires explicit subscription/approval.

Shareable Email - Allows multiple and periodic subscriptions and advertisements to be sent by the website as well as its partners (third party applications 40, fourth parties). This requires explicit subscription/approval and may include detailed information about allowed shares.

opt out - user explicitly unsubscribed. No e-mails may be sent to the user (with the exception of possibly opt-out notices).

It will be appreciated that the data and permission handler 244 may use alternative methods, such as a permission bit mask (similar to that used in UNIX and Linux systems) or an Access Control List (ACL) mechanism. Data and permission processor 244 may also implement separate permission fields for distinct portions of contact information (eg, email, instant messenger address, social network ID, etc.).

A typical usage scenario is one in which the contacts database 245 includes a first set of emails collected from contact forms and a second set of emails from subscription requests. The website calls the newsletter sending third party application 40 to indicate that the third party application 40 will only send emails to users belonging to the second set of users (users who have sent subscription requests). can recognize

Advantages of such a system include better protection (both technical and legal) for users (both technical and legal) from non-essential spam sending or misuse of personal information for users - for both the website and the website owner - as well as being described herein. includes the ability to actually enforce privacy policies when used in conjunction with personal data proxy 234 as described above. This may also ensure that unsubscribe requests are enforced more strictly.

A user may thus generate a stream of activities between the relevant website building system 30 and any relevant third party applications 40 . These streams may be known as activity streams. Each activity stream can be used as an information source for a single contact. The activity data structures of the individual streams may also be merged to form a contact if it can be determined that the different activity streams are from the same source. For example, a single user may work anonymously across two devices, such as a mobile device and a personal computer. Such a user can create two anonymous streams in which messages can be stored. Once the streams have been identified as being associated with the same user, they can 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 more specialized devices to perform the desired method. From the above description will emerge the desired structure for a variety of these systems. Moreover, embodiments of the present invention are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the subject matter as described herein.

As is apparent from the preceding discussions, unless specifically stated otherwise, throughout the specification, discussions utilizing terms such as "processing", "compute", "compute", "determining", etc. refer to the former and the Manipulate and/or manipulate data represented in physical quantities within registers and/or memories of the computing system, such as memory, registers, or other such information storage, transmission or display devices of the computing system It will be appreciated that the act and/or processes of a computer, computing system, or similar electronic computing device that converts it into other data that is similarly expressed in physical quantities within.

Embodiments of the present invention may include apparatus for performing the operations herein. This apparatus may be specially constructed for the desired purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, for example, any type of disk including floppy disks, optical disks, magneto-optical disks, read-only memories (ROMs), compact compact disc ROMs (CD-ROMs), random access memories (RAMs), electrically programmable read only memories (EPROMs), electrically erasable and programmable read only may be stored in electrically erasable and programmable ROM (EPPROM), magnetic or optical cards, flash memory or any other tangible medium suitable for storing electronic instructions and capable of being coupled to a computer system bus, but is not limited to does not

Although specific features of the invention have been described and described herein, many modifications, substitutions, changes and equivalents may occur to those skilled in the art. It is therefore to be understood that the appended claims are intended to cover all such modifications and variations that fall within the true spirit of the present invention.

Claims (24)

A system for a website, comprising:
a database storing current contact information for at least users of the website;
an activity coordinator for receiving at least one activity message exchanged between the website and at least one third-party application embedded in the website; and
a contact coordinator that aggregates contact-related information for at least one of a user, a new user, and an anonymous user of the website from the at least one activity message to augment a contact profile accordingly.
including,
wherein the contact coordinator updates the database with current contact-related information updated for the user from the contact profile, and generates new contact information for the new user and the anonymous user from the contact profile.
system. According to claim 1,
The activity coordinator is
a stream generator that identifies the user associated with the at least one activity message and generates an activity stream of data if an associated contact does not exist; and
merging data from the at least one activity message into an existing stream and merging data from at least two of the activity streams into a single stream.
comprising at least one of
system. 3. The method of claim 2,
The contact coordinator,
a data extractor for extracting the contact-related information from at least one of at least one activity message, the activity stream, current contact information for the user, and external sources;
A data merger that merges at least two contact information records and merges the extracted contact related information with the existing user's contact related information according to predefined merging rules, the records having an association with the same identified user -;
a contact handler that creates at least one of a new identifiable contact and an anonymous contact and tracks contact activity during a session of the website; and
Data and permission processor, handling privacy protection and permissions of extracted contact-related information
comprising at least one of
system. According to claim 1,
The system can be implemented on a client,
system. According to claim 1,
wherein the at least one third-party application is at least one of a social network, an interface to a social network, an interface to social network messaging software, and an instant messaging system;
system. 4. The method of claim 3,
wherein the data extractor stores the extracted contact details under the newly created anonymous contact;
system. 4. The method of claim 3,
The data merger,
locating the same primary ID field values in at least two of the contact information records, locating primary key field values in at least two of the contact information records that are identical when normalized, using a cookie to identify site users by way of a method, to identify site users using site logins for registered users, and to identify site users through social logins for site users having accounts associated with social networks; at least one of: a contact identifier;
an aggregator that aggregates contact information using at least one of language, syntax, text analysis, and consultation to external data sources and services;
a contradiction resolver, resolving inconsistencies between contact records according to predefined rules;
a list value generator for generating list value fields for defining an explicit priority among the contact records;
a horizontal contact merger, which merges two unrelated contacts due to a detected common primary ID; and
A vertical contact merger that merges the anonymous contact with a contact associated with the registered user upon registration or login capable of associating an anonymous contact with a contact associated with a registered user.
comprising at least one of
system. 3. The method of claim 2,
The stream merger,
an activity-to-stream merger that merges the data into the stream associated with the identified user, and
A stream-to-stream merger that merges at least two separate streams into a single stream.
containing
system. 9. The method of claim 8,
The stream-to-stream merger comprises:
a horizontal stream merger that merges the at least two separate streams according to an identified common user, and
A vertical stream for merging the stream generated for the anonymous user with the stream associated with the registered user upon registration or login capable of concatenating the stream generated for the anonymous user and the stream associated with the registered user merger
comprising at least one of
system. 8. The method of claim 7,
wherein the horizontal contact merger comprises a virtual merger that maintains at least two contact records separately and links the at least two contact records together such that the at least two contact records are marked as representing the same user.
system. 8. The method of claim 7,
The vertical contact merger is configured to keep an anonymous contact and a contact associated with a registered user separate and such that the anonymous contact and the contact associated with the registered user are marked as representing the same user. a virtual merger that links together contacts associated with registered users;
system. 3. The method of claim 2,
the user permission field is at least one of the determined website and the determined owner of the website;
system. A method for a website in which each step is performed by a computing system, the method comprising:
storing current contact information for at least users of the website in a database;
receiving at least one activity message exchanged between the website and at least one third-party application embedded in the website; and
aggregating from the at least one activity message contact-related information for at least one of a user of the website, a new user, and an anonymous user, and augmenting a contact profile accordingly;
including,
augmenting the contact profile comprises updating the database with current contact-related information updated for the user from the contact profile, and generating new contact information for the new user and the anonymous user from the contact profile.
Way. 14. The method of claim 13,
Receiving the at least one activity message comprises:
identifying the user associated with the at least one activity message and generating an activity stream of data if an associated contact does not exist; and
merging data from the at least one activity message into an existing stream and merging data from at least two of the activity streams into a single stream;
comprising at least one of
Way. 15. The method of claim 14,
The step of collecting the contact-related information and enhancing the contact profile comprises:
extracting the contact-related information from at least one of the at least one activity message, the activity stream, current contact information for the user, and external sources;
merging at least two contact information records and merging the extracted contact related information with contact related information of an existing user according to predefined merging rules, wherein the records have an association with the same identified user;
creating at least one of a new identifiable contact and an anonymous contact and tracking contact activity during a session of the website; and
processing the privacy protection and permissions of the extracted contact-related information;
comprising at least one of
Way. 14. The method of claim 13,
The method can be implemented on a client,
Way. 14. The method of claim 13,
wherein the at least one third-party application is at least one of a social network, an interface to a social network, an interface to social network messaging software, and an instant messaging system;
Way. 15. The method of claim 14,
The step of extracting the contact-related information includes storing the extracted contact details under the newly created anonymous contact,
Way. 16. The method of claim 15,
Merging the at least two contact information records and merging the extracted contact information includes:
locating the same primary ID field values in at least two of the contact information records, locating primary key field values in at least two of the contact information records that are identical when normalized, using a cookie identifying site users by means of a method, identifying site users using site logins for registered users, and identifying site users through social logins for site users having accounts associated with social networks. performing at least one;
aggregating contact information using at least one of language, syntax, text analysis, and references to external data sources and services;
resolving inconsistencies between contact records according to predefined rules;
creating list value fields to define an explicit priority among the contact records;
merging two unrelated contacts due to a detected common primary ID; and
merging the anonymous contact with a contact associated with the registered user upon registration or login capable of associating the anonymous contact with a contact associated with the registered user;
comprising at least one of
Way. 15. The method of claim 14,
merging data from the at least one activity message into an existing stream and merging data from at least two of the activity streams into a single stream, comprising:
merging the data into the stream associated with the identified user, and merging at least two separate streams into a single stream.
Way. 21. The method of claim 20,
Merging the at least two separate streams into a single stream comprises:
merging the at least two separate streams according to an identified common user; and
Merging the stream generated for the anonymous user with the stream associated with the registered user at the time of registration or login, which can connect the stream generated for the anonymous user and the stream associated with the registered user
comprising at least one of
Way. 20. The method of claim 19,
Merging the two unrelated contacts comprises:
maintaining at least two contact records separately and linking the at least two contact records to each other such that the at least two contact records are marked as representing the same user;
Way. 20. The method of claim 19,
The step of merging the anonymous contact may include keeping the anonymous contact and the contact associated with the registered user separate and such that the anonymous contact and the contact associated with the registered user are marked as representing the same user. linking a contact of and a contact associated with the registered user to each other,
Way. 15. The method of claim 14,
the user permission field is at least one of the determined website and the determined owner of the website;
Way.

Images