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

Abstract

A system includes at least one hub to coordinate at least one activity message between a website and at least one third party application where the at least one activity message has a standardized format, and an activity coordinator to listen to the at least one activity message and at least to add data extracted from the at least one message to a stream associated with at least one of an identified contact and an anonymous contact and where the at least one of an identified contact and an anonymous contact is a user of the website. The system also includes a contacts coordinator to retrieve and analyze contact related information from the stream and to enrich previously held information for the contact and at least one database to store the activity streams and the contact related information for use by the website and by the contact.

Description

Technology area

The present invention relates to online applications, in particular to their use in combination with third-party applications.

Cross-references to related tickets

This application refers to the priority of US Provisional Patent Application No. 61/911485, which was filed December 4, 2013 and is incorporated herein by reference in its entirety.

Background of the invention

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

Website building systems can be supplied in a variety of configurations, such as fully online server-based website building systems or servers that are connected to the Internet and accessed using Internet communication protocols such as as a hypertext transfer protocol (HTTP). The creation, editing and deployment of such systems for building websites is carried out exclusively online with direct interaction with the servers.

Website building systems can also be only partially online or, in some cases, even completely offline. In the case of partially online systems, the website is edited on the local user's machine and then the data is uploaded to a central server, or server, for deployment. Once the data is uploaded, such website building systems function in a manner similar to fully online website building systems.

Systems for building websites have an internal data architecture used to organize the data and the building blocks of the system. The internal architecture may differ from the way the web site is designed to be displayed to the user, and may also differ from the standard methods of sending hypertext markup language (HTML) pages to the browser. For example, the internal data architecture may contain additional properties for each element on the page (creator, creation time, permissions, links to templates, etc.) that are necessary for editing and administering a website in the website building system, however not visible to the external end user (and possibly also hidden from some editor users). A typical architecture for a website built with a website building system might include pages that contain various components (for example, shape components, image components, text components, single-page and multi-page containers containing mini-pages, etc.).

Components may have no content, for example in the case of a star shape that has no internal content (but has color, size, position, and some other attributes), or they may have internal content, such as a text paragraph component whose internal content includes display text, as well as font, formatting, and layout information. The content can obviously be different for different instances of the same text paragraph component.

With such a system for building a website, a web designer can design a new product from scratch (starting from a blank page) or can use as a basis pre-configured application templates, created by himself, provided by the creator of the system or the community of web designers. The system for building a website can support templates that are solely collections of components, complete pages (or mini-pages), or even sets of pages, or complete websites.

Once the web designer has got the application template at his disposal, he can personalize it as he wishes by adding, removing or changing any of the template elements, as a result of which his own version of the template can be created. Personalization can be achieved by creating a modified version of the template (which is different from and independent of the original template). Alternatively, in a system for building a website, personalization can be implemented through a mechanism similar to inheritance, while maintaining a link to the original template and correspondingly indicating the changes made to it.

At the same time, systems for building websites can be extensible, for which third-party applications and built-in components are used. Such third-party applications may be included in the development environment of the system for building websites, or may be purchased (or otherwise obtained) separately, using various delivery mechanisms, for example, from an AppStore built into the system for building a website. , or from an independent web-based or offline application store (or application store) maintained by a website building system (WBS) vendor or other organization. Third party

- 1 036433 applications can also be obtained directly from a third-party application provider (via an application store or otherwise), which can provide an installation module directly, or only an activation or access code.

Third-party applications can include any combination of front-end (display, frontend) elements and auxiliary (back-office) elements (which are not part of the visual presentation of the website). Third-party applications can have no display elements at all (be completely back-office), or be completely front-end elements (that is, be active only in the context of using the website), or they can be some combination of the two listed options.

The back office elements of a third-party application may include features such as database connectivity, external update options, etc. For example, a third-party blogging (internet diary) application might include a back-office element that allows you to receive updates from non-human sources (for example, the RSS news feeds of major news services), as well as from human sources not affiliated with this website (for example, stand-alone smartphone apps that allow you to post to your blog).

The integration of the visual elements of a third-party application into its containing website can be done in many different ways. Third-party widget-type applications can be embedded as a component on a website page, while third-party applications, which are separate sections of a website, can be added to it as an additional page or multiple pages.

That being said, third-party apps (both widgets and sections) can be either single-page third-party apps or multi-page third-party apps (which can have internal mini-pages represented by an internal URL structure). The system can use any of four possible combinations (single or multi-page widgets and sections) or all possible combinations.

Multi-page third-party applications typically have a default landing (landing) mini-page, which can be a start page, a specific internal mini-page (for example, the newest blog post in the case of a third-party blogging app), a mini-page selection screen or some other mini-page.

The use of third-party applications on websites built with website building systems is implemented using instances of third-party applications. The system for building a website may support multiple uses of third-party applications at several different levels, for example, may only allow one instance of a third-party application to be present on an entire website; may allow multiple third-party applications to be instantiated within a website (but not more than one instance for each third-party application), or may allow multiple instances of many different third-party applications to be instantiated (but not more than one instance per page). It may also allow multiple instances of third-party applications that are components, but not third-party applications that are sections, to be created on a page, or creating multiple instances of different third-party applications may not be limited in terms of their number, multiplicity, or location.

The content of an instance of a third-party application may be different for each specific instance. For example, a third-party online store application may have a product database that is associated with a specific instance and is different from the product databases associated with other instances of that third-party online store application (on the same or other websites).

For ease of description, a page (or mini-page) of a website that includes a third-party application with its mini-pages or elements (i.e., a wrapper page) will hereinafter be referred to as the containing web page, and the entire website as a whole - the main website. The page as a whole, which is displayed to the user and which includes a main page with an embedded mini-page, or component, of a third-party application will hereinafter be referred to as a combination page. In the case of third-party applications that are sections of a website, the hosting web page will be the virtual page that hosts the third-party application.

Third-party applications are typically deployed to either the servers of the system provider for building the website, or to the servers of the third-party application provider, or external servers (fourth-party servers), or some combination of the above. Referring to FIG. 1, which shows that a third-party application may include elements that actually run on the end user's machine, such as statically installed browser extensions or dynamically executable JavaScript components that run as part of system code to build a client-side website.

The servers owned by the system vendor for building the website act as a contact point for end users and respond to requests (possibly in conjunction with the servers of the third-party application provider to obtain the necessary information). The system for building the website can form direct connections (if necessary) between the client computer

- 2 036433 and third-party application provider servers, for example, if video streaming is required.

Instances of third-party applications hosted on the website, as well as regular components of the website, may have their own internal content. Referring to FIG. 2, which shows that a third-party application can manage their content independently of the system for building the website and independently of the website built using such a system. Multiple instances of a third-party application (one third-party application or several different third-party applications) may share content, for example, two instances of an online store application on two independent pages of a website may be linked to the same product database.

The output of embedded third-party applications can be integrated into their containing web pages in many different ways, for example:

Server side data processing: In this case, as illustrated in FIG. 3, on the example of which this case is considered, the third-party application [a] (including design elements and display elements) and user-specific data [b] of the third-party application are combined using the server code [c] of the third-party application running on the server [d] third party application provider. They are passed over the medium [e] to the server code [f] of the system to build a website, which combines them with the information [g] of the hosting web page and then transmits them for display to the user's client station [h].

Client Side Processing: In this embodiment, as illustrated in FIG. 4, on the example of which this case is considered, the third-party application [a] (including design elements and displayed elements) and user-specific data [b] of the third-party application are combined using the server code [c] of the third-party application running on the server [d] third party application provider. They are transmitted over the data transmission medium [e] to the client-side processor component [h]. The server code [f] of the system for building the website passes the information of the hosting web page to the processing component [h] of the client side. The client-side processor component [h] combines these two sources of information and provides a unified application to the browser (or other client agent) [i].

Activation using iFrame technology: with this embodiment, according to the illustration in FIG. 5, on the example of which this case is considered, the third-party application [a] (including design elements and display elements) and user-specific data [b] of the third-party application are combined using the server code [c] of the third-party application running on the server [d] third party application provider. They are transferred through the medium [e] of data transmission to the application [h], based on the browser and executed inside the user agent (for example, a web browser) [i]. The server-side code [f] of the system for building the website passes the information of the hosting web page to that browser-based application [h]. The enclosing web page is implemented as a web page that contains one or more iFrame directives that include content received from a third-party application server [d]. Additional or alternative methods can also be used.

The essence of the invention

In accordance with one preferred embodiment of the present invention, there is provided a system implemented on a website using a client-server system having at least one processor for processing instructions defining the system. The system includes at least one hub for coordinating at least one activity message between a website and at least one third-party application, said at least one activity message having a standardized format. The system also includes an activity coordinator for listening to said at least one activity message and at least for adding data retrieved from said at least one message to a stream associated with an identified contact person and / or an anonymous contact person, where the identified the contact person and / or the anonymous contact person is the user of the website. The system also includes a contact coordinator for extracting and analyzing information related to a contact person from a stream and for enriching previously stored information on contacts, as well as at least one database for storing streams of activity data and information related to a contact person. for use by the website and contact persons.

Moreover, in accordance with one of the preferred embodiments of the present invention, said at least one hub includes at least one of the following: a router and a tracker for routing and tracking at least one activity message between the website and at least one third-party an application, a privacy policy enforcement device for enforcing privacy policies between a website and at least one third-party application, a translator and an adapter for applying at least one predetermined broadcast rule and adaptation of content between the website and at least one third-party application, proxy confidential data module for implementation

- 3 036433 representations regarding confidential data and / or replacement of confidential data and for imposing restrictions on user permission fields between the website and at least one third-party application, as well as a validation and signature device for validating and signing said at least one message about activity using the receiving key of at least one third-party application, for broadcasting the external identifier associated with the said at least one activity message to the internal identifier for the website and for signing the outgoing at least one activity message using the transmitting key at least one third-party application.

Moreover, in accordance with one of the preferred embodiments of the present invention, the activity coordinator includes at least one of the following: a flow generator for identifying contacts associated with the at least one activity message, and for generating a data flow, if the corresponding contacts does not exist, a stream merging device for merging data from said at least one activity message with an existing stream, as well as data from at least two activity data streams into a single stream, and a log generator for logging activity data from a data stream activity in at least one database.

Also in accordance with one preferred embodiment of the present invention, the contact coordinator includes at least one of the following: a data extractor for extracting information related to a contact from one or more of the following: an activity message, other contacts, and external sources; a data fusion device for merging at least two records of contact information, where said records are associated with the same identified contact, and for merging the extracted information related to a contact with the contact information of an existing contact according to predefined merge rules, a processor contacts to create a new identified contact and / or anonymous contact and to track the contact's activity during a website session, as well as a data and permission processor to manage privacy protection and permissions for retrieved information related to the contact.

Additionally, in accordance with one preferred embodiment of the present invention, the router and tracker support routing said at least one activity message using at least one listen request submitted by a third party application.

Moreover, in accordance with one of the preferred embodiments of the present invention, a stream merger includes an activity-stream merger for merging data with a stream that is associated with an identified contact, and a stream-stream merger for merging at least two separate streams into a single one. flow.

Also in accordance with one preferred embodiment of the present invention, a stream-to-stream fusion apparatus includes at least one of the following: a horizontal stream fusion device for fusing at least two different streams according to a common identified contact, and a vertical stream fusion device for stream fusion, generated for an anonymous contact, with a flow related to the registered contact after logging into an account or registering, allowing the two contacts to be merged.

Also, in accordance with one of the preferred embodiments of the present invention, the data fusion device includes at least one of the following: a contact identification device configured for at least one of the following: detection of identical values of the primary identifier field in at least two records contact information, detecting primary key field values in at least two contact information records that are identical after normalization, identifying a website user using cookies, identifying a website user using a registered user account login, and identifying a website user site through a social network account for website users whose accounts are related to social networks. The data fusion device also includes a combiner for combining contact information using at least one of the following: linguistic characteristics, syntax, text analysis and consultation with external data sources or services, a contradiction device for resolving contradictions between contact information records according to predefined rules , a list-value generator for generating list-value fields that uniquely determine the order of contact information records, a horizontal contact merge device to merge two unrelated contacts when a common primary identifier is found, and a vertical contact information merge device to merge an anonymous contact with a contact person who associated with the registered user, after logging into an account or registering, which allows the two contacts to be combined.

- 4 036433

Additionally, in accordance with one preferred embodiment of the present invention, the horizontal merge device includes a virtual merge device for maintaining at least two contact information records as independent and for concatenating them together, as a result of which they are marked as representing the same contact person ...

Additionally, in accordance with one preferred embodiment of the present invention, the vertical contact merger includes a virtual merger for maintaining the anonymous contact and the contact associated with the registered user as independent and for concatenating them together so that they are marked as representing the same contact person.

Also, in accordance with one preferred embodiment of the present invention, the user permission field is determined by the website and / or is determined by the owner of the website.

Also, in accordance with one of the preferred embodiments of the present invention, said standardized format is at least one of the following: a format defined by a predefined scheme, inheritance, a callback reference, a format encoded and defined by at least one third party application, or a format based on an external formal, industrial, or de facto generally accepted standard.

In accordance with one of the preferred embodiments of the present invention, there is provided a method implemented on a website using a client-server system having at least one processor for processing instructions defining the method. Moreover, in accordance with one of the preferred embodiments of the present invention, said negotiation includes at least one of the following: routing and tracking at least one activity message between the website and at least one third-party application, the enforcement of privacy policies between the website site and at least one third-party application, applying at least one predefined rule for broadcasting and adapting content between the website and at least one third-party application, implementing representation with respect to confidential data and / or replacing confidential data, and imposing constraints on custom fields permissions between the website and at least one third-party application, as well as validating the signature of said at least one activity message using the receiving key of at least one third-party application, broadcasting an external identifier associated with with said at least one activity message, an identifier internal to the website, and a signature of the outgoing at least one activity message using the transmitting key of at least one third-party application.

Moreover, in accordance with a preferred embodiment of the present invention, said listening and at least adding comprises at least one of the following: identifying contacts associated with said at least one activity message and generating a data stream if no corresponding contacts exist. , merging data from said at least one activity message with an existing stream, as well as data from at least two activity data streams into a single stream, and logging activity data from the activity data stream into at least one database ...

Also, in accordance with one of the preferred embodiments of the present invention, said acquisition and analysis includes at least one of the following: extracting information related to a contact from one or more of the following: an activity message, other contacts and external sources ; merging at least two records of contact information, wherein said records are associated with the same identified contact person; and merging the extracted contact information with the contact information of an existing contact according to predefined merge rules. The acquisition and analysis referred to also includes the creation of a new identified contact and / or anonymous contact and tracking the contact's activity during a website session, as well as managing privacy protection and access rights to the retrieved information related to the contact.

Additionally, also in accordance with one preferred embodiment of the present invention, said routing and snooping supports the routing of said at least one activity message using at least one listen request submitted by a third party application.

In addition, in accordance with one preferred embodiment of the present invention, said merging includes merging data with a stream that is associated with an identified contact and merging at least two separate streams into a single stream.

Also in accordance with one of the preferred embodiments of the present invention

- 5 036433 then said merging data with a stream associated with an identified contact and merging at least two separate streams into a single stream include at least one of the following: a horizontal merging of at least two separate streams according to a common identified contact and a vertical Merging the flow generated for the anonymous contact with the flow associated with the registered contact after logging in or registering to merge the two contacts.

Moreover, in accordance with one of the preferred embodiments of the present invention, said merging of at least two contact information records includes at least one of the following: detection of identical primary identifier field values in at least two contact information records, detection of primary key field values in at least two contact information records that are identical after normalization, identifying website users using cookies, identifying a website user using an account login for registered users, and identifying a website through a social network account for website users whose accounts are associated with a social network. Said merging of at least two contact information records also includes merging contact information using at least one of the following: linguistic characteristics, syntax, text analysis and consultation with external data sources or services; resolving contradictions between contact information records according to predefined rules, generating list value fields that uniquely determine the order of contact information records, horizontally merging two unrelated contacts when a common primary identifier is found, and vertically merging an anonymous contact with a contact that is associated with the registered user, after logging in or registering, which allows the two contacts to be merged.

Also in accordance with one preferred embodiment of the present invention, said horizontal merge includes a virtual merge for maintaining at least two contact records as separate and for linking them together, thereby marking them as representing the same contact person.

Also, in accordance with one preferred embodiment of the present invention, said vertical merge includes a virtual merge to maintain the anonymous contact and the contact associated with the registered user as independent and concatenate them together so that they are marked as representing the same same contact person.

Also, in accordance with one preferred embodiment of the present invention, the user permission field is determined by the website and / or is determined by the owner of the website.

Also in accordance with one preferred embodiment of the present invention, said standardized format is at least one of the following: a format defined by a predefined scheme, inheritance, a callback link, a format encoded and defined by at least one third party application, or a format based on an external formal, industrial, or de facto generally accepted standard.

Brief Description of Drawings

The present invention, which is the subject of this document, is described in detail and is uniquely defined in the claims set forth in the final part of the application. However, the invention, as regards its organization and mode of operation, together with its objects, elements and advantages, can be best understood by reading the detailed description below with reference to the accompanying drawings, where: FIG. 1 is a sketchy illustration of the deployment configurations of a website building system (WBS) and a third party application (TPA).

in fig. 2 sketches for managing the internal content of third-party applications;

in fig. 3 is a sketchy illustration of the inclusion of a third-party application on a hosting web page using data processing on the server side;

in fig. 4 is a sketchy illustration of the inclusion of a third-party application on a hosting web page using data processing on the client side;

in fig. 5 is a sketchy illustration of the inclusion of a third-party application on the containing web page using an iframe;

in fig. 6 is a sketchy illustration of the display of a third-party application when changing the page layout in accordance with the current state of the art, which is not optimal;

in fig. 7A and 7B schematically illustrate a system for integrating a system for building a website and one or more third-party applications, constructed and operated in accordance with the present invention;

- 6 036433 in Fig. 8 schematically illustrates a document object model in comparison with a component model;

in fig. 9 sketches an example of a composite third-party blogging application;

in fig. 10 is a sketchy illustration of an example of a modular third-party online store application;

in fig. 11A and 11B sketchily illustrate various embodiments of a communication hub constructed and operated in accordance with the present invention;

in fig. 11C schematically illustrates the elements of the communication hub of FIG. 11A and 11B constructed and operated in accordance with the present invention;

in fig. 12 schematically illustrates a communication broadcast scenario using the hub shown in FIG. 11A and 11B constructed and operated in accordance with the present invention;

in fig. 13 is a thumbnail illustration of an containing web page that controls a third party application having an associated template, the containing web page being constructed and operated in accordance with the present invention.

in fig. 14 is a thumbnail illustration of an enclosing web page that includes a third party application having an associated template within a mini page, the containing web page being constructed and operated in accordance with the present invention.

in fig. 15 is a sketchy illustration of a system for coordinating and collecting data from various messages transmitted between a system for building a website and one or more embedded third-party applications, the system being constructed and operating in accordance with the present invention;

in fig. 16A, 16B, 16C, and 16D schematically illustrate elements of the system shown in FIG. 15 built and operating in accordance with the present invention;

in fig. 17 is a thumbnail illustration of an example graphical user interface that displays an activity data stream related to a contact, the interface shown being constructed and operated in accordance with the present invention;

in fig. 18 schematically illustrates the exchange of messages about the activity of a third-party application between the client and server sides; and in FIG. Figure 19 is a sketchy illustration of how to manage login and logout during a website session.

It should be understood that in order to maintain simplicity and clarity of illustrations, elements in the drawings are not necessarily drawn to scale. For example, to make the drawings easier to understand, some of the elements may be oversized compared to other elements. In this case, if necessary, the numeric designations in different drawings may be repeated, which indicates the corresponding or similar elements.

Detailed description of the invention

In the following detailed description, many specific details are set forth in order to achieve an in-depth understanding of the present invention. However, those skilled in the art should understand that the present invention may be practiced without these specific details. Conversely, in order not to obscure the description of the present invention, well-known methods, procedures, components, blocks and / or circuits are not discussed in detail.

The authors of this application have found many shortcomings in existing methods of embedding third-party applications in systems for building websites and in the methods of interaction of third-party applications with systems for building websites.

One of these drawbacks is that the display of a third-party application is limited to a single rectangular area of the containing web page, the area within the iframe. Other disadvantages are the inability of third-party applications to control the size and position of their own window, as well as visual elements that are outside the actual display window of a third-party application (for example, special frames around the window of a third-party application).

A third-party application can have its own display styles (color schemes, fonts, character sizes, etc.). The use of these styles may be appropriate for some containing web pages, but may visually discord with other containing web pages.

Another drawback is the lack of flexibility in displaying third-party applications in terms of the hosting website. If the appearance of the website is changed (for example, when deploying to a platform with a different screen size or as a result of a dynamic layout event), the hosting web page may be forced to resize the window provided by a third-party application. In this case, the display of the third-party application may be clipped, i.e. to reach some subareas of the third party application, it may be necessary to scroll using the scrollbars. Referring to FIG. 6, which illustrates an example showing what can happen when the containing web page is resized [a]: the size of the area provided to the third-party application [b] of the online store has decreased, and the [c] Buy button is not visible under the contents of the shopping cart [d], therefore, several scrolling operations are required to make a purchase, and the likelihood of making a purchase is thus significantly reduced.

It should be understood that a third-party application cannot interact with other components of the hosting web page, and that such interaction is nevertheless necessary to implement more complex functions. Namely, in the above example, the third-party application is unable to perform different operations depending on the type of components on the containing page and the content of these components. An example of this is a website that broadcasts online cooking courses. It may be convenient for the user to select a small area on the screen to view the news feed as a background when viewing the relevant videos, and also to view weather reports in some other area of the screen (for example, a live broadcast from the CNN website). For the convenience of the user, when the weather report for the region of his residence starts, the user training session can be suspended.

There is no single, standardized method by which many third-party applications can interact with each other, especially if provided by different vendors. That is, there is no single method for a web designer to combine many third-party applications from different vendors. An example would be an online store website running a module from a third-party order processing system, as well as an independent module for a delivery system. It would be convenient to be able to replenish the warehouse in accordance with the delivery schedule, etc.

The authors of this application have found that such integration can be implemented using structured two-way communication channels between the system for building a website and the instances of third-party applications that are part of it, as well as between different instances of third-party applications that can be hosted on the same containing page. ... Such channels can also transmit information related to layout, styles, and auxiliary information.

It should be understood that the description below is based on the method of including third-party applications using the iframe, which is the preferred method insofar as it is built-in and integrated into modern browsers and does not require any special integration code. Iframe included provides browser-supported encapsulation and sandboxing, and built-in protection against attacks such as cross-site scripting used by malicious third-party applications.

Referring to FIG. 7A and 7B, illustrating a system 100 for integrating a system for building a website and one or more third-party applications, in accordance with one embodiment of the present invention. FIG. 7A, the system 100 is shown during the website design phase, and FIG. 7B, the system 100 is illustrated in operation. As illustrated in FIG. 7A, system 100 includes a client program 10, a website building system 30 installed on a website building system (WBS) server 20, and one or more third-party applications 40 installed on one or more third-party application servers 50. ... The system 30 for building a website includes a WBS coordinator 21, an application store 22, a WBS side of a third party application properties table 23, a third party application coordinator 24, and an application store 25 (which may include a search device 26). Client 10 includes a page builder 12 and a client-side third party application properties table view 23. In some embodiments of the present invention, the client 10 may also include a client-side view of the application store 25. The page builder 12 includes a linker 13, described in more detail below. The third-party application server 50 includes a third-party application 40, an external third-party application coordinator 51, and a third-party database 52 that stores components of the third-party application 40, templates, and other items for use. It should be noted that system 100 may include multiple third-party application servers belonging to multiple third-party application providers 40.

It should be understood that the table 23 properties of third-party applications can be called when assigning attributes to a given instance of the third-party application 40. You also need to understand that when called, the table 23 properties of third-party applications can be displayed on the client side as a view of the table 23 of properties of third-party applications in the client 10. When It should be understood, however, that offline implementations may also have their own property tables as part of the installed client software, that is, the third party application table 23 and / or the third party application store may not be present.

You need to understand that the web designer or end user 5 behind the client machine 10 can create their own website (or any other online application) using the page builder 12 and form the pages of the website along with the corresponding interactions (both within the page and and between pages). The web designer 5 can select components, templates and other elements that are part of the system 30 for building the website, which are stored in the repository 22

- 8 036433 applications, via the 21 WBS coordinator. The web designer 5 may also create a hosting web page 203 into which instances of third-party applications 40 from a plurality of third-party applications 40 that have been purchased in advance are embedded and templates, components, and other elements of which may be stored in the application store 22. In an alternative embodiment of the present invention, purchased templates, components, and other items may be stored in a third-party application database 52 and accessed by an external third-party application coordinator 51. In yet another embodiment of the present invention, templates, components, and other elements of the third-party application 40 may be purchased as needed through the application store 25. The property table 23 may be populated by the web designer 5 and contain, for example, information about the purchased third-party application 40 instances such as access rights, installation instructions, payments, or the like, as described in more detail below. The web designer 5 can also use the linker 23 to manually assign communication channels between the embedded third-party applications 40 if necessary. It should also be understood that the linker 23 can allow the web designer 5 to assign any specific link connections and communication rules between the hosting web page he creates and the instances. 40 third-party applications that are hosted on this web page, for example, as in the case of the above video and CNN news bulletin, displayed simultaneously. It should be understood that the links created with the linker 23 can be changed during the life of the website.

It should be understood that the web designer 5 may receive third-party applications 40 through other channels external to the application store 25, for example, through an external application store provided by the third-party application provider 40 or a third party. In such a case, the website building system 30 may register the third party application 40 and its configuration data when the third party application 40 is initially installed on the website created by the web designer 5 using the website building system 30.

For linker 23 to be able to configure potential communication channels, third-party applications 40 must be able to correctly recognize and identify components on the hosting web page 203 (with which they need to communicate), including also instances of other third-party applications 40. Identification of components that are based on associated templates (discussed in detail later in this document) is executed by the third-party application provider 40 in advance. Special reference identifiers can be assigned to the components in the associated template, and these identifiers can be used by the third party application 40 to communicate with said components.

You also need to understand that in the case of composite third-party applications 40 (which will be discussed in more detail below), for example, in the case of one third-party application 40 distributed over several iframes, several of its parts can automatically receive the information necessary to communicate with each other.

For host page components of a website that are not part of an associated template (this case will be discussed in more detail below), the third-party application 40 may have a list of host web page 203 components required (required or optional) for its operation. This list may be stored in a property table 23 and may include unique identifiers, descriptions, and details about the components (eg, requiring them to be text components that can be used as a blog comment mark). This list can be stored in an application store record 25 for the third-party application 40, and the web designer 5 can use the linker 23 to set the values of the components (fields) on the hosting web page 203 in accordance with the requirements of the third-party application 40. It should be understood that the system 30 for building a website can dynamically create the missing components of the hosting web page 203 when instantiating the third-party application 40 and can subsequently provide the web designer 5 with the ability to move them, resize them, and more fully describe them.

Alternatively, the system 30 for building a website may provide a complete or partial component model of the hosting web page 203 to a third-party application 40 included in the hosting web page 203. It should be understood that such a structure could be a component model rather than a document object model. the containing web page 203. The DOM model of the containing web page 203 can be significantly more complex and detailed than the component model, since the actual containing web page 203 may contain many HTML elements - both hidden and displayed - that are part of the infrastructure of the system 30 for building the website, or that are used to support the components of the hosting web page 203. The component model is thus much simpler.

Referring to FIG. 8, which illustrates one possible way to implement a text component [a] using a set of HTML constructs (such as outer div [b], inner div [c], mini widgets frame [d1]. .. [d5] etc.) The DOM [e] of the hosting page 203 9 036433 can contain separate DOM tree nodes for each of these sub-elements. Component Model [f | can be much simpler and contain only one [g] component node.

It should be understood that the system 100 can also support the selective provision of information about the components - the web designer 5 can designate, using the linker 23, information about which of the components should be provided to the third-party application 40, while only such components (possibly having a path location that points to them) can be included in a simplified component model that is visible to third-party application 40. Assignment can be accomplished by explicitly tagging the appropriate components according to their type or any other attribute of the system 30 for building the website. The third party application 40 can then parse the component model of the hosting web page 203 and find the required components.

It should also be understood that links (links) between the hosting web page 203 and instances of third-party applications 40 can also be generated automatically, for example, broadcast linking can be performed, in which the third-party application 40, during its operation, can transmit messages in order to record certain events. Such messages may be optional or required (i.e., in this case, the third-party application 40 cannot function or even be installed unless there is a corresponding third-party application 40 that has been linked to receive such messages. For example, the third-party application 40 may broadcast send packets with information about its own activity, and some installed third-party application 40 that implements data logging can receive these information packets.

Newly created web pages, all parameters of which have been assigned the appropriate values, can be saved in the application store 22 (using the WBS coordinator 221) and dynamically called during the operation of the website in accordance with the following more detailed description.

Referring again to FIG. 7B. In this embodiment of the present invention, the same elements are used as for FIG. 7A, with the exception of the elements of the client 10. In operation, the client 10 includes a viewer 201 for displaying containing web pages. It should be understood that the viewer 201 may include a plurality of display ports 202, each displaying a native instance of the third-party application 40 (instances derived from one or more third-party applications 40). The client 10 also includes a communication hub 205 to provide communication and to provide a backhaul between the hosting web page 203 and all third-party applications 40 based on it, as well as communication that occurs directly between the third-party applications 40, without connecting to the corresponding hosting web page 203 The functionality of hub 205 will be discussed in more detail below.

It should be understood that the hub 205 can be implemented as part of the client 10, since the hosting web page 203 and all third-party applications 40 included in it are simultaneously interactive subsystems of the website displayed to the users, and it is unacceptable that communication between them suffers due to delays. when sending data from client to server and vice versa. In an alternative embodiment of the present invention, the hub 205 can be implemented on the server 20 of the system for building the website, which is more preferable for cases in which the third-party application servers 40 need to exchange large amounts of data, and accordingly it is better not to route them through the client 10 ...

It should be understood that communication hub 205 may support various combinations of communications between the website building system 30 and one or more third-party applications 40, as well as between multiple third-party applications 40. For example, the hub 205 may provide the third-party application 40 with the ability to communicate to the system. 30 to build a switch request website on the main site. Communication hub 205 may also provide third-party application 40 with the ability to submit a request to resize its own window, which may affect the layout of the hosting web page. This can be done using dynamic layout control, which will be described in more detail below. Alternatively, the hosting web page 203 can, for example, transmit a request to switch to a different version of a third-party application if necessary to accommodate changes in display. It should be understood that such a two-way communication can also be established between the third-party application component 40 and the website building system component 30 related to the third-party application 40 that displays auxiliary information, as well as between elements of composite third-party applications 40 or modular third-party applications in in accordance with the following more detailed description.

It should also be understood that system 100 can also be implemented using both online and offline systems 30 to build a website, and that it can use

- 10 036433 any combination of options for hosting a third-party application, such as client-side elements, the servers of the system provider 30 for building the website, the servers of the third-party application provider 40, or other servers belonging to the fourth party. It should be understood that in the case of the offline embodiment of the present invention described above, a server may still be required to implement system 100.

System 100 may be hosted on a different set of servers (operated by a non-system vendor to build a website), such as a private site hosting system for large organizations.

System 100 may also support a full range of options for embedding instances of third-party applications 40, as previously described. However, system 100 may also support only a subset of such options, or may impose restrictions on the ability to embed instances of third-party applications 40.

System 100 may also be capable of implementing composite third-party applications 40. Composite third-party application 40 may include multiple display areas, each of which is managed using a separate iframe. These areas can also interact with each other (if necessary) using the communication hub 205 in accordance with the following more detailed description.

Referring to FIG. 9, which illustrates an example of a composite third-party application 40. As illustrated, the third-party blogging application [a] obtained from the application store [b] is placed on the hosting web page 203 [c]. The third-party blogging application [a] includes the following three areas: area [d] blog entries; area [e] tag cloud; area [f] of the news summary. It should be understood that in a composite third-party application, many of its areas can be applied in different ways, including both many simultaneously present parts of the same application in the case of the above example for a blog, and many optional parts of one application, when there is a set of always displayed areas and a set of optional areas displayed only when needed. The display of optional areas can be controlled by a third-party application 40 or a web designer 5 (who makes decisions about the configuration of the third-party application when it is included in the page). Display control can also be available for areas of auxiliary functionality, such as configuration areas or additional dialog areas; and as an alternative display for third-party applications that are available in multiple versions (for example, those with a small and larger version, or with a portrait-oriented and horizontal version).

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

You also need to understand that the implementation of composite third-party applications 40 requires that third-party applications 40 (inside their iframes) can control the display of various iframes (for example, their visibility, size and location). It should also be understood that the communication hub 205 may provide the ability to display them in accordance with the following more detailed description.

You also need to understand that even in the case where the composite third-party application 40 consists (visually) of several elements and areas, it is still considered a single third-party application 40 with respect to purchase (for example, in an app store 25), installation, configuration, etc. .P.

In existing systems, each of the third-party applications 40 can be viewed as an independent entity, and the interaction between the two third-party applications 40 (from the same vendor or from cooperating vendors) must be implemented on a case-by-case basis. It should be understood that system 100 may also support modular third-party applications 40, which are comprised of a plurality of interoperable sub-modules that are independently purchased and installed.

Referring to FIG. 10, which illustrates how a modular third-party application [a] for sales management can be broken down into submodules: module [b] CRM; module [c] lead management and module [d] online store. All required modules of this third party application can be provided by one third party application provider. Alternatively, the third-party application provider may provide a subset of the modules (or functionality) of the third-party application 40 and allow the web designer to purchase and / or install additional third-party application modules from the same or different third-party application provider. It should be understood that while a composite third-party application is purchased and installed as a single third-party application from a single vendor, which simply occupies several screen regions, a modular third-party application includes many modules that can be purchased and installed independently and may include modules from multiple vendors. third-party applications. To enable the integration of many third-party application modules from

- 11 036433 multiple vendors, each third-party application module must have a list of the interfaces and / or functions it needs and the interfaces and / or functions provided. This can be implemented, for example, using lists of interface names based on the dot-separated hierarchical naming tradition (e.g. My_CRM_TPA.NewClient.Getlnfo) and interface parameter specifications.

Interfaces required for the third-party application module 40 can be marked as required (i.e. without which the module will not function) or as optional (i.e. the module will function, but its functionality will be limited or changed). So the parameters provided for each of the interfaces can be: a unique name of the interface; interface description - displayed to the web designer 5, and providing him with information about the functionality provided by the missing interfaces; required / optional status; list of interface parameters and their types. You need to understand that each of the modules of the third-party application will still be in a separate iframe (or a set of iframe frames). The operation of the interfaces is based on the communication channels described in more detail below.

It should be understood that third party application modules 40 can be compiled during the website design phase. The system 30 for building the website may resolve the links to the interfaces as additional modules of the third-party application 40 are added, when the new modules 40 of the third-party application allow existing required interfaces, but also possibly adding new (unresolved) required interfaces.

It should also be understood that Web Designer 5 can edit a website and run it as a whole even when there are unresolved mandatory (and optional) interfaces. However, web designer 5 will not be able to publish the generated website until all required interfaces are enabled, and he will be given a corresponding notification when trying to call a function that can trigger activation by hub 205, a third-party application module that still has unresolved mandatory interfaces.

It will also be appreciated that the app store 25 may include a search engine 26 that may attempt to locate third-party application modules that enable interfaces that are required by existing third-party application modules. Searcher 26 may search based on unauthorized interfaces, for a particular module (s) of a third-party application, or for all modules of a third-party application. The searcher 26 can also search on currently unauthorized interfaces, or even on already allowed interfaces, as well as by the type of interfaces - mandatory, optional, or both. It should be understood that the search device 26 can be limited only by allowing specific third-party applications not allowed by the interface, as well as searching for specific providers of third-party applications. Finder 26 can perform either a first level search (e.g., searching for modules corresponding to currently unauthorized interfaces) or multilevel search (i.e., performing an iterative search, also finding modules corresponding to currently unresolved interfaces, taking into account third-party application modules. found in the previous search iteration).

In the system 100, the interface descriptions can be used to provide the web designer 5 with information about the significance of some of the missing interfaces. The hub 205 can translate interfaces between incompatible third-party applications that still require communication. The communication can be implemented using an adapter module provided by the vendor of the system 30 for building a website, or by an external party that converts a given desired interface to a different format.

System 100 may also be used in online application editing systems where the Internet (or any other network connection) and non-browser based client software are used to view generated online applications. Such systems do not require the use of special technologies (for example, communication over IP, HTTP, HTML, etc.), which are necessary for the infrastructure of a standard website.

It should be understood that standard cross-domain communication techniques known in the art can be used to provide inter-domain communication. These methods may include:

HTML5 PostMessage method. This is a standard HTML5 feature that can be used to provide secure cross-domain messaging. The Windows.Postmessage HTML5 method enables secure messaging between windows, iframes, and the main HTML document, even if they are hosted on different domains. The PostMessage method provides the iframe that needs to pass data with tools to specify the domain to which the message will be sent, and the iframe that receives the data with tools to verify the domain from which the message was sent.

Message URL fragment identifier: This method relies on using a URL fragment identifier to pass message data from one endpoint to another endpoint. The data is encoded as plain text and added (as a fragment identifier) to

- 12 036433

The URL used to invoke a service on the domain of the target endpoint or hidden iframe within the target endpoint iframe. The chunk identifier is then decoded with the appropriate code in the target service or target iframe.

Specialized communication web service. The website building system 30 provides a dedicated web service hosted on the website building system server 20. Various communication endpoints connect to this server, either to send messages or to check the messages available to them. This can be accomplished using methods known in the art, such as the pre-HTML5 Comet suite of technologies, HTML5-based WebSockets, or any other queuing, pull, server push, or similar technology. ...

Local HTML5 storage. The HTML5 standard provides local structured storage that can be used to store queued messages. However, local storage can only be accessed by web content in the same domain as the storing iframe. To date, solutions have been created (for example, the technology underlying the Meebo XAuth software product, which was purchased by Google), in which a relatively simple server provides support for creating the necessary intermediate iframe, which allows you to access local storage located in a certain domain , from iframes hosted on third party domains.

HTML5 Application Programming Interface (API) for accessing the local file system. Similar to using the local storage described above, the communication channel between iframes can be formed using local files in the local user agent storage, which are accessed using the HTML5 file APIs. It should be noted, however, that the sandbox-protected local file system created by the HTML5 file-access APIs is available exclusively to its creator, and therefore an iframe middleware or server component is required to overcome this limitation.

Dedicated browser plugin. A special browser plugin (or other user agent) can be created to manage the queue of messages passed between different iframes. Such a plugin must be installed by the users of System 30 to build the website (at all levels) and provide the appropriate services to all iframes as well as the main website pages of System 30 to build the website.

It will be appreciated that communication hub 205 can function as a coordinator for communication between iframes using any of the messaging methods described above. It should also be understood that the hub 205 may have complete information about the structure of the hosting web page 203 and all the detailed information about the third-party application 40 provided by the provider of the third-party application 40 and stored in a property table 23. The third-party application 40 may then have different parameters when included in other applications or in other specific cases of inclusion in the same application (in accordance with the previous description). Such parameters may include a unique instance name that can be used for smart addressing (as described in more detail below). It should also be understood that the hub 205 may have detailed information about the third-party application 40 that does not need to be stored in the property table 23.

It should also be understood that the hub 205 may provide smart addressing and identification, message source verification, communication policy enforcement, resolving compatibility issues with third-party applications 40, and redirecting data from third-party applications 40 to other components. The hub 205 may provide the ability to dynamically update the layout in third-party applications 40 based on changes made to the hosting web page 203 as described in more detail below.

Referring to FIG. 11A and 11B, which illustrate various embodiments of hub 205, as well as FIG. 11C, which illustrates the functionality of its various elements.

The hub 205 may include a smart identification and addressing device 310, a source verifier 320, a communication policy enforcement device 330, a protocol translator 340, a redirector 350, a dynamic layout updater 360, a configuration manager 370, a general updater 380, and a hosted API wrapper 390. Below the functionality of these elements will be discussed in more detail. It should be understood that all the listed functions are used to ensure the operation of all cross-domain communication channels, that is, the communication channel between the third-party application 40 and the system 30 for building a website and the communication channel between one third-party application 40 and another third-party application 40.

Referring to FIG. 11A, an exemplary embodiment of a hub 205 is illustrated using an intermediate frame [a] iframe that uses an internal communication API to interact with the system 30 to build a website. In this way,

- 13 036433 messages [c] transmitted (for example) from third-party application [d] to third-party application [e] (for which modules [f] and [g] of the communication API are used, respectively) can be analyzed, verified or changed when using methods that imply the availability of information about this particular application.

Referring to FIG. 11B, which illustrates an alternative embodiment of the present invention without using an intermediate iframe. Instead, cross-domain communication technology is applied in one or more of the modules [a] and [b] of the communication API (embedded in third-party applications [c] and [d], respectively). Modules [a] and [b] interact directly with the system 30 to build the website, obtain information about specific applications in use, and use it to process the communication message | f]. This embodiment is compared to the embodiment of the present invention shown in FIG. 11A has the disadvantage that much of the system level 30 information for building a website can be processed inside a module included in a third-party application, and this information can be accessed (or even modified) by a malicious third-party. application.

As described above, in all of the cross-domain communication methods discussed above, iframes are addressed based on the origin of the iframe (which includes the source domain, protocol, and port), i.e. is performed using direct addressing of third-party applications 40 both when transmitting messages (when specifying the receiving side) and receiving messages (in the form of the name of the transmitting side provided to the receiver). Also, in order to transmit the message, the transmitting side must specify the target window of the iframe (by calling the document.getElementByld (...). ContentWindow method in JavaScript or any other method). Thus, in existing systems, each of the third-party applications 40 must store complete and specific information about all other third-party applications with which it can communicate (including domain, protocol, port, and iframe id).

Obviously, this type of direct addressing can be inconvenient in the environment of system 100. Although the web designer 5 has the ability to integrate third-party applications 40 from multiple third-party application providers 40 that are not coordinated with each other, third-party application providers 40 may provide third-party applications 40s hosted on some domain and then move them to another domain or subdomain. Also, third party application providers 40 may change the protocols or ports used to communicate with some given third party application. The web designer 5 would then have to change the design of the hosting web page 203 that contains the third party application 40. All of the described events can occur in the third party applications 40 that are used on a live website that has many visitors. However, a single hosting web page 203 may include multiple instances of a third-party application serving for different purposes. For example, one of the pages on a website created to support a commercial product may contain two third-party chat applications 40: one for chat between users and for a forum, and one for communicating with a vendor's support staff when available.

It should be understood that the addressing and identifying device 310 may have complete information about the structure of the hosting web page 203, but a detailed description of the third-party application 40 (provided by the third-party application provider 40 to the system 30 for building the website). The addressing and identifying device 310 may address third-party applications 40, both sources and receivers of data, to communicate with each other using any of the following: the unique name of the third-party application 40 (under which it is registered in the application store 25); a descriptor identifier for an instance of a third-party application 40 assigned to each of the instances of the third-party application 40 on the hosting web page 203 so that multiple instances of the same third-party application 40 can be addressed; a base identifier for the type or class of the target third-party application (for example, it is necessary to pass the message <x> to all instances of the third-party application 40 for logging to the hosting web page 203). Such an identifier may also indicate specific services that are to be supported by the third-party application 40. The addressing and identification device 310 may also apply a version reference, for example, it is necessary to transfer transaction <x> to the accounting package instance <y> only if it has version < z>.

It should be understood that during their operation, third-party applications 40 interact only with the hub 205 and, therefore, they should only know the direct address of the hub 205, and not the addresses of all other third-party applications 40. This single direct address can be encapsulated using an API wrapper - a communication interface (eg, communication modules f and g shown in FIG. 11A, and modules a and b illustrated in FIG. 11B) provided by the system 30 for building a website to a third-party application provider 40. The third-party application 40, the caller can provide descriptive addresses of third-party applications 40, depending on the specific application (in accordance with the previous description), and the addressing and identification device 310 can translate them into direct addresses 40 of third-party applications and execute

- 14 036433 routing. Thus, third-party applications 40 do not need to maintain a table of absolute addresses of all third-party applications with which it can potentially communicate.

You need to understand that verification of the message source is critical, since otherwise, the receiving third-party application 40 could potentially receive a message from the malicious third-party application 40. Since all communication can take place through the hub 205, the source verifier 320 can authenticate all incoming messages from all third-party applications. The source verifier 320 can also provide additional information that can be added to the message and can be used for additional verification. It should be understood that since all third-party applications 40 in the app store 25 used on the system 100 are registered with the system 30 to build the website, the hub 205 can check with the system 30 to build the website whether the unique source identifier that can be included in the message, the expected source of the message (domain, port, etc.).

The third party application 40 may define a general communication policy, which may depend on external information, information about the hosting web page 203, or the like. The communication policy executor 330 can enforce the appropriate communication policy without having to process out-of-compliance communication. For example, on a website that handles sensitive information, third-party applications in their profiles may be flagged with a privacy level field. A third-party application 40 providing an internal database for event logging and certified as having a security level of X may appropriately determine the policy that it will not accept events for logging whose security level is greater than X. The communications policy enforcement device 330 may execute necessary pre-filtering and prevent messages with a higher security level from ever reaching applications with a lower security level.

You also need to understand that a web designer 5 may need to include two (or more) third-party applications in one website he creates that could interact with each other, but in fact this may not be feasible due to incompatibility of protocols. For example, as illustrated in FIG. 12, which will be discussed below, the third-party app [a] of the online store may be able to send messages about goods orders to the third-party application of order fulfillment and their delivery, for example, the third-party app [b] (provided by another supplier). However, the information provided by the third-party application [a] may be missing some of the fields required by the third-party application [b]. Such a problem, as a rule, requires the intervention of third-party application providers, but in some cases such a solution is unacceptable (for example, one of the two third-party applications is no longer updated for some reason at the moment). The protocol translator 340 can translate the appropriate messages from application [a] to application [b] (eg, adding the required missing fields). The broadcast may be performed by the protocol translator 340, or may, in some cases, involve interaction with the main website and the hosting web page 203 (eg, if additional information is required).

It should also be understood that the third party application 40 may have functionality requiring the sending or receiving of messages from another third party application 40 (eg, as in the case of the above pair of third party online store and order fulfillment applications).

However, in some cases, part of the solution may be missing, as in the example described above, it may turn out that a suitable application 40 for order fulfillment does not exist. In such a case, the redirector 350 may allow the web designer 5 to indicate that the required messages can be routed to or from some component of the hosting web page 203, and that the required functionality can be resolved by that component of the hosting web page 203 using functionality that can provide its components. This allows the entire website to be constructed without the need to create highly specialized third-party applications 40. Accordingly, transactions can be forwarded to a system component 30 to build a website that can log transactions to a database and that database can subsequently be used (by another application ) for order fulfillment and delivery offline.

Third-party applications 40 can have many different configurations and different capabilities, and still be based on the same underlying code, but with different activatable functionality. For example, the third-party application 40 may provide basic functionality in the free version and additional functionality in the paid premium version, a set of different paid versions, or additionally purchased features of the third-party application 40.

It will be appreciated that system 100 may include managing the state of purchased third-party applications 40 using system 30 to build a website for each individual user (or, in fact, each individual web designer). You also need to understand that all web designers can be registered users of the 30 system to build a website, and

- 15 036433 in this way, the system 30 for building the website can administer a database of purchased third-party applications 40 for each of the web designers 5. This information can be stored in a property table 23, by the third-party application coordinator 24 during the website design phase or by a manager 370 configurations during its operation. For example, the third-party application 40 may send a version request message to the client-side web site element 30. The client element of the system 30 for building the website can check with the store 22 or its locally cached copy and return a response message to the third-party application 40 with information about the functionality that it should have.

In an alternate embodiment of the present invention, the website building system 30 may provide the third party application 40 with the configuration information of the third party application 40 via alternative channels, such as an encrypted iframe parameter, without the need for the request message described above.

As previously described, third-party application 40 can communicate directly with specific components of the hosting web page 203. Third-party application 40 can identify components to communicate using several different methods: directly for components based on associated templates (in accordance with the following more detailed description); by using an access identifier explicitly provided by the web designer 5 directly for specific components of the hosting web page 203; by passing a (possibly selective) component model corresponding to the hosting web page 203 to the third party application 40.

It will be appreciated that in the operation of the system, the exchange of messages and responses between the components of the hosting web page 203 may be implemented using the updater 380. For example, the third-party application 40 may influence or request information about the visual and display attributes of the components of the hosting web page 203 (such as information about their position, size, color, transparency, etc.). The updater 380 may also provide the ability in the third-party application 40 to read or write the contents of the components of the hosting web page 203, and also allow it to control the components with multimedia functions, for example, send a given audio or video fragment to the multimedia playback component, or request it to pause playback for a given period of time.

The device 380 may also make it easier for the components of the system 30 to build a website to determine the type of access they grant to third-party applications 40, in a similar way to how modern operating systems use permission bits or access control lists to protect files. list, ACL). Such permissions may be specific to each and every component and apply to all third-party applications 40 from a particular vendor or specific third-party applications 40. For example, a third-party application 40 may be allowed to access a text field that is part of the hosting web page 203 from outside the third-party application 40. This text box can be used to edit a blog entry in the case of a third party blogging application 40 to provide more screen real estate than is available directly inside the area of the third party application 40. It should be understood that in the case of third party applications 40 embedded on specific mini -pages in a multi-page container, the system 30 for building the website can restrict the access of the third-party application 40 to only the components on that particular mini-page.

It should also be understood that the updater 380 may allow third-party application 40 to affect global site elements. This can include getting and setting attributes such as the website's current page, the current mini-page in a container that contains 40 third-party app, and page browsing history. Updater 380 may thereby filter or limit such requests.

The updater 380 may also allow the website building system 30 to influence the visual appearance and display of the third-party application 40. The updater 380 can make calls with which the website building system 30 can provide formatting and style guidance to third-party application 40. These may include the following properties: colors and color schemes; fonts; size of characters; transparency; animation and special effects (for example, blur). In particular, a color scheme can include a standard color scheme (for example, using the following x colors) or high-level colors (for example, using x for text and y for borders).

It should be understood that one of the preferred ways of presenting composite style information is through the use of Cascading Style Sheets (CSS), which allows you to represent a combination of a variety of style hints including fonts, sizes, colors, and the like. The device 380 may send similar CSS based messages to the third party application 40. The style sheets may be generic in nature, or may include specific names of types defined in the third party application 40, whereby the system 30 for building a website

- 16 036433 can provide more precise instructions to the third-party application 40 (for example, the style sheet may refer to specific elements 40 of the third-party application 40 and contain instructions specifically for them).

The third-party application 40 can then apply these guidelines to more efficiently adapt its own visual appearance to the hosting web page 203. This is especially important for third-party applications 40 that are included in or displayed on multiple hosting web pages 203 on a single website (the above-mentioned multiport inclusion). Such a plurality of enclosing pages may have different color schemes or general designs. The third party application 40 may use the information provided by such style messages and adapt its colors and styles to better suit each of the containing pages, thereby avoiding displaying inconsistent color schemes or interface designs.

It will be appreciated that the dynamic layout updater 360 may provide interoperability between the system for building the website and the third-party application 40, or between two third-party applications, while managing display changes as a result of a dynamic layout event. The website building system 30 can resize and position the components on the page to preserve the page design in the event of events that modify some of the page components. Such dynamic layout events can include, for example, viewing the website on different screen sizes; rotation of the display device and its transition from portrait to horizontal mode; resizing or positioning some of the components and changing the content of the specified components (if this requires resizing them). A dynamic layout event can also include updating a component as a result of server content updates, such as displaying information from an Internet feed, or as a result of content changes made by other users who are also currently using the website. You also need to understand that dynamic layout events can occur both in the design environment of a website, and in its working environment. Namely, some of the components and third-party applications 40 may be capable of changing content or resizing / positioning as it actually operates (i.e., end users), not just a web designer.

It should also be understood that a dynamic layout event may also be triggered by a third-party application 40. For example, a third-party online store application 40 may require resizing when a user navigates from displaying a product catalog to viewing a shopping cart (having a different size). As another example, third-party product catalog application 40 may include an option to highlight products, which may include displaying a larger catalog page with extended content for them. A third example is a multi-area third party application 40 that can enable and disable the display of additional areas.

In existing systems, such situations (if they are possible at all) are handled by trimming the display of third-party applications, adding scrollbars to it, or simply resizing it, and displaying it as a floating window that overlaps the rest of the page, as illustrated in FIG. 6, which will be discussed below. The dynamic layout updater 360 may implement a collaborative dynamic layout in which the website building system 30 and third-party applications 40 interact to perform dynamic layout while maintaining the overall design of the hosting web page 203. The dynamic layout functionality is described in more detail in the US patent application No. 13/771119, registered on February 20, 2013, also by the authors of this application. However, even in systems that support dynamic collaborative layout, the dynamic layout engine on the hosting web page 203 does not have complete control over the internal layout of the third-party application 40. However, the widgets of the system 30 for building the website can be designed to be resized arbitrarily. way (within a given range), however, third-party applications 40 may not support arbitrary resizing. The third party application 40 may provide, for example, any combination of the following: a set of display configurations having different sizes (eg, displaying more or less detail); the ability to resize its internal elements; and the ability to display some of its internal text elements using a variety of font sizes.

Third party application 40 may provide a limited set of display sizes, or may have the full range of possible sizes. Accordingly, a request to resize in the direction from the hosting web page 203 to the third party application 40 can be resolved by switching the third party application 40 to the closest available size, or by providing a list of possible sizes for the third party application 40 (allowing the system 30 to build the website to select the appropriate size for use) ...

The dynamic layout updater 360 may implement dynamic layout collaboratively from the hosting web page 203 to the third-party application 40 using the following sequence of operations:

- 17 036433

For example, it may be necessary to resize the third-party application 40 embedded in the containing web page 203 to a specified size (eg, X1 * Y1 pixels). The dynamic layout updater 360 can send to the third-party application 40 a message with a request to change, by the third-party application 40, its content to a predetermined size (X1 * Y1). The third party application 40 can adapt to this size through an alternate display configuration, internal resizing, internal dynamic layout control, or other means. It should also be understood that the hosting web page 203 can resize the outer iframe that contains the third-party application 40 to a new size (X1 * Y1).

It should also be understood that the third party application 40 may only be resizable with a limited set of possible sizes (eg, specific user interface configurations). Accordingly, the dynamic layout updater 360 may use an alternative algorithm described below that allows the third-party application 40 to provide a set of possible sizes.

If the hosting web page 203 is resized, the dynamic layout updater 360 sends to the third-party application 40 a message requesting that the third-party application 40 change its content to a predetermined size (X1 * Y1). The third-party application 40 then determines the closest available size (for example, X2 * Y2 pixels) and resizes itself accordingly by applying an alternate display configuration, internal resizing, internal dynamic layout control, or other means. The updater 380 may then transmit to the hosting web page 203 a response message confirming the resize and containing the actual new size (X2 * Y2). It should also be understood that the hosting web page 203 can resize the outer iframe that contains the third-party application 40 to the actual new size (X2 * Y2). The hosting web page 203 can then further control the internal layout based on the actual new size (X2 * Y2).

It should be understood that another embodiment of the present invention may also apply, namely if the hosting web page 203 hosts multiple third-party applications 40 (or a multi-domain third-party application 40). In this embodiment of the present invention, the hosting web page 203 can query hosted third-party applications 40 for a list of display sizes, so that they can subsequently attempt to optimize the appearance based on the many options available in the plurality of third-party applications 40. This embodiment of the present invention may also be applicable in the case where third-party applications 40 are displayed in many different areas.

The hosting web page 203 may perform dynamic layout control, detect that one or more third-party applications 40 (TPA [1] ... TPA [n]) are hosted on the hosting web page 203 and that their size should be resized using the following algorithm:

Loop on i from 1 to n:

For each TPA [i], determine the minimum size Xmin [i] * Ymin [i];

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

optimal size Xopt [i] * Yopt [i].

The dynamic layout updater 360 can send a message to the third party TPA [i] application with information on the minimum, maximum and optimal sizes described above, and request information about the possible sizes of the third party application 40.

The third-party application 40 may provide to the dynamic update device 380 an array of possible size variations, Xposs [i] [j] * Yposs [i] [j].

Based on the information obtained in the manner described above, Xposs [] [] / Yposs [] [] the hosting web page can compute a solution for calculating dynamic layout using (for example) a full analysis of all possible sizes of third-party applications, linear programming methods or any other methods used in dynamic layout algorithm.

Saving results in array Xfinal [i] / Yfinal [i] for all third-party applications.

Loop on i from 1 to n:

The hosting web page 203 can then send a resize message to TPA [i] that contains the final size Xfinal [i] / Yfinal [i];

The hosting web page 203 resizes the outer iframe that contains the third party TPA [i] to Xfinal [i] / Yfinal [i];

The hosting web page 203 further controls the internal layout based on the actual new dimensions.

It should be understood that managing dynamic layout can generally require changing the location of 40 third-party applications, not just resizing them. However, the third-party application 40 must be invariant to the specific location of its frame on the hosting web page 203.

- 18 036433

As previously described, the third party application may also need to resize its display window from time to time. Since the size of the window in which the iframe is displayed is controlled by the main page (i.e., the containing web page 203), the window resizing of the third-party application 40 must be performed by the hosting web page 203 with a request from the third-party application 40 (via the dynamic update device 360 ) to the hosting web page 203 to resize the window.

It should also be understood that the third-party application 40 may also request (via the dynamic layout update device 360) to change its location on the hosting web page 203. This may not affect the internal structure of the third-party application 40 (as opposed to resizing), but requires display changes on the hosting web page 203. The dynamic layout updater 360 can integrate this request with the dynamic layout. The hosting web page 203 may employ the dynamic layout updater 360 to resize the window of the third-party application 40 (and possibly its location) and to transmit the size and location confirmation back to the third-party application 40.

It should be understood that the hub 205 may also implement additional custom messages, depending on the class of the third-party application 40 or the particular third-party application 40, by which the actual system 30 for building the website, the particular hosting web page 203, or another third-party application 40 can influence the third-party application 40. For example, third-party blogging application 40 may determine an incoming message to publish a new blog post, or a new comment on a current blog post. Such a message can be used by the hosting web page 203 (for example, as a method of publishing blog posts from a larger text editing field outside the scope of a third-party application). They can also be used for higher-level communication between applications, for example, allow blog posts to be published to a third-party blogging application using a third-party helper application.

It should be understood that third-party applications 40 often require many different complex services, either internally in the third-party application 40, or for use downstream of the data chain by web designers who use the third-party application 40 on their websites. Such services may include user administration, billing, and delivery management. The provider of the website building system 30 is not always able to provide all such services as part of the website building system (for example, for technical or economic reasons). It may also not be possible to provide such services in the form of bundles of third party applications 40. In addition, the third party application provider 40 may need to be able to provide many such services to web designers using a third party application 40 (e.g., multiple third party charging APIs), selectable by a web designer 5 suitable for use. For example, the system 30 may provide a built-in Paypal ™ payment system API for building a website, which may be used directly by a third party application 40, or may be offered by a third party application 40 to a web designer for use. The third-party application 40 may also provide its own options to choose from (ie, use a specific billing type, such as one-time payments, recurring payments, or revenue sharing) and implement those options by calling the native Paypal API.

Thus, the web designer 5, using the system 30 to build the website, can generate specific proposals (for example, an online music store) that apply more complex billing. The web designer 5 can then avoid having to form a specific clearing or merchant service agreement with the charging API provider by using the built-in charging API, either directly or through a third party application 40 providing an additional layer of abstraction. In this sense, the system 30 for building a website can function as a service distributor for embedded API providers.

The embedded API wrapper 390 can provide similar communication between various parts of the system (eg, the system 30 for building a website, the embedded API code, and included third-party applications 40). It should be understood that the API wrapper layer and the actual implementation of the API can be hosted directly in the system 30 to build the website, or in another third-party application 40. The provider of the third-party application 40 (or web designer 5) can use the built-in API. an interface by wrapping the 390 built-in API without being aware of the method that the underlying API actually implements.

In one alternative additional embodiments of the present invention, the authors of the present application have found that intelligent integration between the system 30 for building a website and one or more third-party applications 40 can be achieved using an integration model in which additional templates and system components for building a website connected

- 19 036433 (associated) with third-party applications at the 25 application store level, which also applies to the corresponding instances of third-party applications. The third-party application 40 may also interact with these components (as well as non-associated components), exchanging informational and control messages with them. As previously described, the third party application regions 40 on the hosting web page are separate iframes, the content of which may be hosted in different domains (third party application provider or other domains) other than the host domain of the main website. Accordingly, communication between different iframes is limited by the browser's same origin policy, which means that the methods described above must be applied.

In existing systems, third-party applications 40 are implemented as monolithic inflexible objects that can be placed on the containing web page 203, but cannot otherwise affect the appearance of the containing web page 203 itself. Instances of third-party applications 40 are placed in the area ( usually rectangular), while the third-party application performs all its operations in this area.

The authors of the present application have found that this principle can be extended by the presence of an (optional) additional template in the system 30 for building a website that is associated with, or associated, with a third-party application 40 and is called an associated template in accordance with one embodiment of the present inventions. It should be understood that such linking can be performed during the development and publication of the third-party application 40, and can also be presented to the web designer 5 as part of the procedure for purchasing and / or selecting a third-party application 40 (from the app store 25) and the procedure for creating an instance of the third-party application 40 The third party application coordinator 24 may retrieve the template associated with the third party application 40 (as part of an app store maintained by the app store 25 or otherwise provided by the third party application provider 40), and may also store the template in the store 22 for later use in accordance with following a more detailed description.

It will be appreciated that system 100 can support the publication of third-party applications 40 having a plurality of associated templates, allowing the web designer 5 to select the most appropriate template.

It should be understood that when instantiating a third-party application 40 on any hosting web page 203, the components of the associated template can be combined with the components of the hosting web page 203 and can be displayed in conjunction with the rest of the components on the hosting web page 203.

Referring to FIG. 13, which illustrates an example of using an associated template in accordance with one embodiment of the present invention. As illustrated, the third-party app [a] resides in the app store [b] along with an associated template [c], which includes components [d] and [e]. It should be understood that when a third-party application [a] is placed on the hosting web page 203 [f], the third-party application [a] may appear in its dedicated area [g] on page [f], and instances [d '] and [ e '] components [d] and [e] can be displayed on page [f] along with the originally present components [h] and [i].

It should be understood that system 100 can support many different ways in which component instances from an associated template (eg, components [d '] b [e'] described above) are placed on the hosting web page 203 [f]. These methods may include: absolute placement (ie, using the size and position specified in the associated template [c] for applications [d] and [e]); placement relative to the target component (i.e. adjusting the size and location of new instances [d '] and [e'] according to the hosting web page 203 [f]) and placement relative to the third-party application 40 (i.e. adjusting the size and location of new instances [d '] and [e'] relative to the size and location specified for the third party application instance [g] on the hosting web page 203 [f]). The choice of a specific placement method can be based on the settings included in the associated template [c], while, optionally, the web designer 5 can override them.

You should also understand that the web designer 5 can modify the instances [d] and [e] inherited from the template [c] and placed on the page [f]. Changes can only relate to the use of instances [d] and [e] specifically on page [f] (and possibly also pages inherited from it in 30 systems for building websites that support cross-page inheritance) and not affect the original template [ с] associated with a third-party application [a] in the application store [b].

It should be understood that the above changes to instances [d] and [e] may include, but are not limited to, the assignment of specific content (text, visual, etc.) to the field instances, as well as normal attribute changes. It should also be understood that if the third-party application 40 is embedded in a mini-page, the associated template is applied to the specific mini-page on which the third-party application 40 is placed in accordance with the illustration of FIG. 14, which will be discussed below. As illustrated, the third-party application 40 is included on the mini-page [x], and the components [c] and [d] will be added to the mini-page [x], but not to additional mini-pages [y] and [z] of the same multi-page container [g].

You also need to understand that for mini-pages that are sections of a website, the associated templates (if any) are applied to the virtual (and blank) containing web page

203 file created to host the 40 third party app.

In an alternative embodiment of the present invention, a pre-created associated template may be applied to a newly generated page or mini-page that is parallel to the containing web page 203. This newly created page or mini-page can be initialized using a template that is subsequently can be changed according to requirements.

The system 30 for building a website can also be multiportable, in which one instance of a third-party application 40 is displayed or located on multiple pages of the main website. This is in contrast to the multiple inclusion of some third-party application 40 on the main website, in which multiple instances of the third-party application 40 are created. The content of the third-party application 40, which depends on a particular instance, is common to multiple views of one multi-port third-party application 40.

With this kind of multiport enablement, the associated template can be applied independently for each of the pages and minipages to which the third party application instance 40 is added.

In accordance with the foregoing description, system 100 may provide a two-way communication link between a third-party application 40 and components on the hosting web page 203. It should be understood that these components include components of the hosting web page 203 resulting from a merge with the associated template of the third-party application. as well as components that do not belong to any of the associated templates.

Therefore, it should be understood that a third party application provider 40 may typically create a set of templates associated with third party applications 40 provided by that provider. These patterns, in addition to the actual distribution patterns (that is, associated with current versions of third-party applications being distributed), may include test patterns, design patterns, and other patterns.

As previously described, the third-party application 40 may be distributed through the application store 25, or may also be distributed through alternative channels outside of or outside the control of the provider of the website building system 30. However, the associated templates distributed with the third-party application 40 can be tightly coupled and integrated with the application repository 22 as they are constructed using components, base templates, and other elements administered by the system 30 to build a website.

This may necessitate the modification or removal of independently redistributable elements of the system 30 to build a website, underlying the associated template, which may conflict with the associated template. To address this problem, in system 100, such associated templates may be implemented in a separate area (possibly for each vendor 40) of the application store 22. System 30 for building a website can administer these templates in a similar way to all other templates for system 30 for building a website.

It should also be understood that each third-party application provider 40 can be assigned a unique identifier (design identifier) assigned to each template that is created, and this identifier can be used in the design and testing process of the third-party application 40. When the third-party application 40 is ready for publication or distribution, the provider of the third-party application 40 will need to request and obtain an alternate unique identifier (publisher ID) that will identify the published third-party application 40. Once the publisher ID is issued, a separate locked version of the template is created. This copy is referenced by the third party application 40 and is used when instantiating the third party application 40. Thus, the provider of the third party application 40 cannot mistakenly change the template associated with the public third party application 40 (hosted by web designers) and the link integrity is guaranteed. Also, in this case, the system 100 can generate cross-references based on the relationship between the locked templates and their underlying components, as well as the base templates. These cross-references can be used, for example, to alert users of the system 30 for building a website if the components of the system 30 for building a website, or the underlying template included in such a blocked template, is changed (and such a change could in some way damage template or third party app 40).

Accordingly, system 100 can provide two-way communication channels between third-party applications 40, components on the hosting web page 203, and system 30 for building a website. The components of the hosting web page 203 may be based on a template (or templates) associated with third party applications, based on other templates in the system 30 for building a website, or not depend on any templates.

In accordance with the foregoing description, communication hub 205 can support this communication and can provide a back channel between the hosting web page and any of the third-party applications 40. The authors of this application have found that data traveling in both directions between the hosting web page and any of the third parties 40 applications, if collected, processed and integrated (merged), can have useful applications.

For example, a website owner may need to keep a record of the contingent of users or members of the website, which may differ from the registered user base of the corresponding system 30 for building the website. Website users can be registered or unregistered (anonymous), and the site can provide different levels of functionality for different levels of users. However, users often provide personal or contact information (even if they are anonymous), such as data in a contact form, when launching instant messaging software to call the owner of a website, or when logging into a social network that cooperates with the website. It should be understood that such information may be entered directly on a constructed website or may be provided in the course of interaction with third-party applications 40 embedded in this website.

You also need to understand that fragments of such information may not be organized, not related to each other, possibly contradictory, and in many cases they are not saved for future use. For example, some user may enter a personal email address into a contact form (running directly on the website) and a work email address into another form, a subscription form (operated by third-party application 40), during the same session.

Moreover, such wandering pieces of information can have different permissions that restrict their use. For example, users who enter their email address in the subscription form understand that they will be subscribed to that email address and are likely to receive the relevant newsletter. On the other hand, users who provide their email address as an identifier during registration do not want to receive any messages from it, other than emails related to account management, security alerts, etc.

Referring again to FIG. 15, which illustrates a system 200 for coordinating and collecting data from various messages exchanged between the system 30 for building a website and one or more embedded third-party applications 40. System 200 includes a client hub 210 installed on the client side 220 and a server hub 230 , contact coordinator 240, activity coordinator 250, contacts database 245, and activity database 255 installed on server 260. It should be understood that hubs 210 and 230 can provide communication between system 30 for building a website and a variety of third-party applications 40 installed on servers 270, as well as between various third-party applications 40 in accordance with the previous description with respect to hub 205. Contact database 245 and activity database 255 may contain contact information and / or activity information extracted from message streams in accordance with the following detailed description.

Referring again to FIG. 16A, the elements of the client hub 210 are illustrated, and to FIG. 16B, which illustrates the elements of the server hub 230, contact coordinator 240, and activity coordinator 250. The client hub 210 includes a router 211, a translator and adapter 212, and a privacy policy enforcer 213. The server hub 230 includes a router and tracker 231, a translator and adapter 232, a privacy policy enforcer 233, a confidential data proxy 234, and a validator and signature 235. Contact coordinator 240 includes a data extractor 241, a contact handler 242, a data merger 243, and a data and permission handler 244. Activity coordinator 250 includes a stream generator 251, a stream merger 252, and a log generator 253. The operation of these elements will be discussed in more detail below.

Referring again to FIG. 16C, where elements of the stream merger 252 are illustrated, and FIG. 16D, which illustrates the elements of the data merger 243. Data merger 252 includes an activity-stream merger 261 and a stream-stream merger 262. The stream-to-stream merger 262 includes a horizontal stream merger 263 and a vertical stream merger 264. The data merger 243 includes a contact identifier 272, a merger 273, a contradiction resolver 274, a list value generator 275, a vertical contact merger 276, and a horizontal contact 277. The horizontal contact merger 277 includes a horizontal virtual merger 278. The vertical contact merger 276 includes a virtual vertical merger 279. Below the operation of these elements will be discussed in more detail.

It should be appreciated that system 200 can provide the ability to transfer messages between system 200 and multiple third-party applications 40, as well as provide other functionality, including organizing activity messages into streams, storing the history of activity messages, multi-leveling activity messages, using side channels for activity messages, broadcasting and adapting activity messages, validating and signing activity messages, and dynamically routing activity messages using listen requests, as described in more detail below.

In doing so, system 200 can extract user information and merge it by combining information from different sources as well as information already present in system 200. This can be done using merge rules to reconcile different and possibly conflicting information. The combined information can be stored in a contact database 245. This information may also include permission-to-use fields, which control the permission to use the collected information, as described in more detail below.

In alternative embodiments of the present invention, both the client hub 210 and the server hub 230, separately, can be used to communicate with a plurality of third-party applications 40 installed on the servers 270. It should be understood that in the case where only the client hub 210 is used, the coordinator 240 contacts, activity coordinator 250 and databases 245 and 255 data can be installed locally on the side of the corresponding client.

It should also be understood that system 200 may include additional components that allow third-party applications 40 to administer user contact operations (eg, bulk newsletters) with user-defined restrictions. Such components can even isolate sensitive user data from third-party application 40 so that third-party applications 40 can perform their operations without actually accessing sensitive user data. Such functionality can be implemented, for example, using the proxy module 234 confidential data, discussed in more detail below.

It should also be understood that the contact database 245 may be website specific. However, the system 30 for building a website can define a meta-site, or design, level that includes a set of websites (owned by the same owner) and allows you to specify that contacts are to be stored, processed and combined at the meta-site level, and not at the level of a single website. Other elements of a website (such as 40 built-in third-party applications) can also be defined at the meta-site level, rather than at the single website level. In addition to supporting the meta-site level, system 200 generally does not share contact information (with the exceptions described below) and does not integrate contact information from different websites or different website owners (to avoid leaking data provided by end users of the same website, to other websites).

As previously described, system 200 can support multiple interactions between the system 30 for building a website and one or more third-party applications 40. Such interactions can represent predetermined operations, such as making a purchase, adding an item to a cart, entering contact information, etc. P. The third-party application 40 may indicate which operations it supports, and the remaining third-party applications 40 may listen for specific operations and act in response to the received operations and associated information. It will be appreciated that the activity listener list for a given third-party application 40 may be explicitly assigned and include one or more operations, or may be determined by an activity listener request as described in more detail below.

It should be understood that each operation can be considered a message, and each message can include an activity data structure. Activity data structures are predefined data types, but they can also be defined by inheritance between them and using 40 third party applications that can extend them with new fields. They can be system-specific, or based on standardized data structures, or include standardized data structures. They can be encoded in the same way as XML or JSON data, or they can be encoded using a binary object encoding scheme.

The activity data structure may also include a description field provided by the third party application 40. This is a description of the activity based on the third party application 40 (which may be more detailed than the information available on the website building system 30). For example, third-party IP telephony application 40 may provide the following activity description text: Call John Smith at 999-555-1234-01: 15.

- 23 036433

The activity data structure can also include a return link, such as additional information that leads back to the activity data structure. It can be used to provide additional important information, for example, for the structure of activity data in an online store application: complete information on order tracking, order history, etc.; for the activity data structure in the chat application: a complete recording of the chat conversations, and for the activity data structure in the telephony application: a call recording. Thus, the complete activity data structure can include the following fields: creation time stamp; type of activity; source of activity (identifier of a third-party application or component); activity data stream identifier; activity-specific information (different for each activity type); source website identifier; website member database ID; the identifier or URL of the website page on which this activity occurred; a description of the activity provided by a third-party application 40; link to more detailed information for use by third party application 40 and captured user information and the like.

Activity coordinator 250 can be viewed as a logging element that can receive data from skipped messages from hub 230. Stream generator 251 can create an original stream, which can be considered a log-like or list-like structure, and stream merger 252 can add any additional input information to it. activity, with each stream being unique to an individual contact. It should be understood that the thread builder 251 cannot create a new thread for all the individual operations that are reported in the various activity messages. You also need to understand that the information about the activity in the stream may be in the wrong sequence (for example, third-party application 40 may report activity with a delay). The stream merger 252 may functionally merge streams if they are owned by the same single contact, and the log generator 253 may save a log file to the activity stream database 255 of all previously generated activity streams.

As previously described with respect to FIG. 16C, the stream merger 252 includes an activity-stream merger 261 and a stream-stream merger 262. Activity-to-stream merger 261 may associate activity data with a stream that relates to an identified contact, and stream-to-stream merger 262 may convert two separate streams into one stream. Horizontal merger 263 can merge two unrelated streams based on identical primary identifiers found, and vertical merger 264 can merge a stream created for an anonymous contact with a stream associated with a registered user after logging into an account or registering. allows you to combine these two contacts. It will be appreciated that the stream merger 252 can optionally access previously created streams in the database 255.

For example, an anonymous user might fill out a contact form on a website. The stream builder 251 can create a new activity data stream (with anonymous identifier 1), and the contact processor 242 can create a new contact person (with anonymous identifier 1, according to the following more detailed description). The same user can then use chat to communicate with the owner of the website. The stream merger 252 can merge this activity with the anonymous 1 activity data stream, and the anonymous 1 contact can be updated (in accordance with the following more detailed description). The same user can then fill out the planning form using a different browser. Since there is no correlation with the original user, the originator 251 can create a new activity stream with anonymous identifier 2, and the contact handler 242 can create a new contact with anonymous identifier 2.

The same user can then make a purchase from the website. The stream merger 252 merges the new activity with the activity data stream Anonymous 2, and the contact person Anonymous 2 can also be updated (for example, a buyer tag can be added).

The user can register on this website using another browser. Upon registration, all users receive a user ID x from the registered user manager on this website. At this point in time, the stream generator 251 can create a new activity data stream (with the id user x), and the contact handler 252 can create a new contact person (with the same id user x).

The user then returns to the previous browser and continues to chat with the owner of the website. Since there is no cookie on the website, the flow builder 251 can create another new flow with the ID anonymous 3, and the contact processor 242 can create a new contact anonymous 3.

The user can then log in to the website account. At this moment, there will be contact persons with identifiers anonymous 3 and user x. Merge device 243

- 24 036433 data can merge contacts anonym 3 and user x, as a result of which the account login operation in the user x stream and the account login operation for the contact person user x will simultaneously point to the user x and anonymous 3 streams. 252, merge streams can merge any additional activity done in the current session by the user into a stream of activity data for user x. The log generator 253 can log all activity data from threads and save a copy of the log to the activity database 255.

It is to be understood that the website owner can access the history of the activity data streams for designated contacts via the appropriate user interface provided by the system 30 for building the website as illustrated in FIG. 17, which will be discussed below. For one of the contact persons, Dani Bronstein, the history of his work with the website can be easily obtained. It should be understood, however, that the website building system 30 or the third-party application 40 may also provide an API for accessing the logged information. You need to understand that the activity log can be used for optimization, improving the user interface, targeting ads, etc.

You also need to understand that in parallel with this, the contact coordinator 240 can select information from the data provided in the streams (or messages) about activity and form a contact profile for each specific user. The data extractor 241 can extract data from activity messages and activity data streams, the data fusion device 243 can combine the corresponding data with a specific contact, information about which can be stored in the database 245, or can be obtained from it. Contact handler 242 can create new contacts, handle website user IDs, anonymous users, or other users, and data and permission processor 244 can manage privacy protection and access rights to the associated data. As previously described, data merger 243 may include a horizontal contact merger 277 and a vertical contact merger 276. Horizontal merge device 277 can merge two unrelated contacts based on identical primary identifiers found, and vertical merge device 276 can merge an anonymous contact with a contact that is associated with a registered user after logging into an account or registering to merge these two contact persons. The contact merger 277 may also include a virtual horizontal contact merger 278 for maintaining two contacts as separate, but concatenating them together, in which they are marked as representing the same contact, with or without merging the actual contact information. him. The vertical contact merger 275 may then include a virtual vertical contact merger 279 for maintaining the anonymous contact and the contact associated with the registered user as separate, but concatenating them together, in which they are marked as representing the same same contact person, with or without merger of actual contact information. The data merger 243 may also merge contact information (typically retrieved by the data extractor 241) with an existing contact. It should be understood that the contact identification device 272 can track user IDs using cookies and can recognize merge contacts as described in more detail below.

Referring again to FIG. 15, 16A and 16B. Messaging can be performed on the client 220 side, on the server 260 side, or on both sides. It should be understood that third-party applications 40 may generally have a client-side element as well as a server-side element, or at least a server-side connection, such as a connection to the server 270 of the provider of the third-party application 40. The hub 210 can handle all messages between the client 220 and third party applications 40, and hub 230 between server 260 and third party applications 40. It should be understood that data received by hub 210 can be processed and redirected to hub 230 for further processing as described in more detail below.

Referring to FIG. 18, which illustrates one possible scenario for the transfer of messages between different platforms. The user's client machine X can be connected (t) to the system 30 for building a website on the server Y. The system 30 for building a website can be implemented using the client component A 'of the website building system 30 and the server component A of the system 30 for building a website. When displaying a constructed website, it may include client-side elements (data and / or code) B 'and a server-side B element. The website being constructed may also include three third party applications 40 - TPA1, TPA2 and ETPA3.

A third party TPA1 application can be implemented using the D 'component on the client side and the D component on the server side, which has a connection to the third party provider H

- 25 036433 appendix TPA1. The third party TPA2 application can be implemented using the E 'component on the client side and the E component on the server side, which has a connection to the provider I of the third party TPA1 application. The third-party application ETPA3, however, may be a third-party application 40 hosted exclusively on the server side and implemented using a server-side component G that has a connection to the internal interface F for supporting third-party applications 40 in the system 30 to build a website. Both said component and the system can communicate with the server J of the third-party application provider 40.

It should be understood that third-party applications TPA1 and TPA2 can exchange messages on the client side (between components D 'and E'), on the server (between components D and E), or on both sides at the same time. However, communication with a third-party ETPA3 application is only possible on the server side. You also need to understand that each of these methods has its own advantages and disadvantages. Sending activity messages on the client side can provide more interactivity and faster user response.

Server-side activity messages can be more efficient, reliable (for example, the user will not be able to close the browser window during the procedure), ensure that messages are received correctly, and provide the ability to transmit activity messages to 40 backend third-party applications installed on the server or in application control panels. It should be understood that 40 such backend third-party applications are not presented at all on the client side.

An example of the use of many third-party applications 40 would be a scenario in which a user adds an item to the cart in a third-party application A (such activity is of the type change cart). Third party application A may then transmit an activity message with information about the added product to the system 30 to build the website. The website building system 30 can then send activity information to all third-party applications 40 registered to listen for bucket changes. Since third party application B is registered, it accepts this activity information. Third-party application B may then display a message to the user, for example, if you add item X to your cart, you will get a discount, or Share this site with your friends and get a discount.

Another example is when a user selects an option I like (for example, via the social network Facebook) for some item in third-party application A. Third-party application A can then send an activity message to system 30 to build a website whose type of activity I like for Facebook. The system 30 for building a website can then send activity information to all third party applications 40 registered to listen for operations of the type I like. Since third party application B is registered, it accepts this activity information. Third-party application B might display a re-invite widget to the user and display a message accordingly, for example, if you like this website, maybe you want to contact the owner? or would you like to get a discount coupon ?.

In accordance with the foregoing description, all communication can occur through the hubs 210 and 230.

Router 211 may provide client-side message routing between the website and all third-party applications 40. Router 211 may also route messages between hub 210 and hub 230 for further processing as described in more detail below.

The router and tracker 231 can route messages between the website and any of the third party applications 40, and can also track messages. It should be understood that third party applications 40 can also listen for messages on both the client side and the server side. You also need to understand that the third party application 40 explicitly specify one or more types of activity to listen, for example, listen for all operations such as adding an item to the shopping cart. The third party application 40 can also explicitly specify the activity classes to listen to, such as listening for all Facebook related activity. Also, the third party application can include a wildcard expression (applied to the name of the activity) that can be used to determine whether or not the activity information should be passed to the third party application.

You also need to understand that a request to listen for an activity may be applied in a third-party application 40. Such a request may refer to additional system information, including information that is usually not available to the actual third-party application, for example: user attributes (for example, only registered users, only users from Europe, etc.), attributes or information about the structure of the website (for example , listening to a given activity only on pages inherited from a given page template), history of user operations (for example, listening to payment transactions associated with a shopping cart only if the user has previously made purchases for a total amount exceeding X), etc. Such a request may be generated by a third party application 40, but may also be editable by a web designer.

Thus, the router and tracker 231 can also track messages that are being listened to by the third-party application 40. It should be understood that such an architecture for listening to activity requests can be most efficiently implemented at the level of routing activity messages (instead of using an API call within the 40), because then the web designer will be able to customize and personalize without the third party applications 40 providing a high degree of programmability and personalization. Router and tracker 231 can also help maintain the privacy of user data, since the web designer is not required to provide additional information (needed to make routing decisions) to the involved third-party applications 40. This also avoids unnecessary calls to third-party applications 40 that are often hosted on different servers.

It should be understood that a user (website visitor) is a person who visits a website, registers on it and transmits information to it. The user may not be aware that the website that he or she is accessing is built using a combination of the system 30 for building the website, components generated by the websites and 40 third party applications. Thus, the responsibility for privacy of user data ultimately rests on the shoulders of the website owner (who is also responsible for the actions of the 40 third party applications included in his or her website).

It should also be understood that access to user profile information by third-party applications 40 (or other components of the system 30 for building a website) may be based on the privacy rules defined by the system 30 for building a website, through the API provided by system 30 for building a web. -site. At the same time, the hosting website, as well as the third-party applications 40 placed on it, can use the received contact information to communicate with the user (by e-mail or otherwise).

It should be understood that there are three possible major data privacy threats. The first is the interaction of the website and the system 30 for building the website with the third-party application provider 40. The website and the system 30 for building the website cannot fully trust the third-party application 40 to process user data, for example, it cannot be guaranteed that the third-party application 40 will not send bulk mail (using the email addresses provided by the website), send unsolicited messages (spam) to users who have requested deletion from the mailing list, or transfer users' personal information to third parties. However, such problems can be solved by the methods described below.

The provider of the system 30 for building a website may require the providers of the 40 third party applications to sign a Terms of Use (Toll) agreement before they are given access to the application market for the system 30 to build the website. Such an agreement may state that the third party application 40 (and the provider of the third party application 40) will not misuse or distribute user information. The provider of the website building system 30 may then impose penalties on the third party application provider for misuse of information (e.g., block the third party application 40, remove the third party application 40 from the application market of the website building system 30, etc.) ) Appliances 213 and 233 of the enforcement of privacy policies, as well as the proxy module 234 confidential data can enforce the privacy policies of third-party applications 40 in accordance with the following more detailed description.

A second privacy threat is the interaction of the website and the system 30 for building the website with the user (site visitor). The website must provide the user with a clear understanding of how his or her personal data may be used, obtain the user's consent and, for its part, comply with the relevant agreement. System 30 for building a website requires all public websites to provide the user with a Terms of Use Agreement (Toll) document that defines the permissible operations with sensitive user information, and the user is required to electronically sign this document. The website must then comply with the terms of the agreement and use the data accordingly. System 30 for building a website may further include a sample Toll Agreement page in each website template provided to it. The privacy policy enforcers 213 and 233 may enforce the terms listed in the Toll document. Privacy policy enforcement devices 213 and 233 can also ensure, by deleting or reconfiguring relevant data, that only authorized information is passed to third-party applications.

The third privacy threat is support for unsubscribe requests. The website should provide the user with the option to unsubscribe from the promotional mailing list.

- 27 036433

This can be provided by the data and permission processor 244 as described in more detail below.

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

The sensitive data proxy module 234 may provide for the website building system 30 (and websites built with it) to store all or part of the sensitive data in a secure storage that is administered by the website building system 30, and may provide third-party applications with alternative unique identifiers (for use instead of confidential data) with which hidden confidential data can be retrieved by the system 30 to build a website). For example, the email address can be replaced with an alternate email address identifier that is passed to the third party application 40 so that the third party application 40 does not have access to the real email address.

The sensitive data proxy module 234 may still provide a set of interfaces for various communication methods (e.g., email, social media messages, etc.) that can be used by third-party applications 40 to communicate, or send messages, to a user without actually having third-party access. attachments 40 to sensitive data associated with that user. Such sensitive data may include any identification information that allows you to contact the user, including, for example, name, address, email, telephone (including SMS / MMS), uniform communication identifier (Skype, etc.) or social network ID.

The sensitive data proxy 234 can thus enforce the restrictions set in the user permission field, enforce user unsubscribe requests, and regulate the transmission of messages to users, such as no more than 100 email messages per day for a given third party application 40 running. on a given website. The proxy module 234 sensitive data can determine the parameters of representation with respect to sensitive data, as well as which sensitive data can be exposed to a third-party application, and which are hidden, for each of the third-party applications 40 or for each individual data field.

For third-party applications 40 hosted on the servers of the website building system 30, the confidential data proxy 234 may issue an alternative unique identifier similar in form to the original confidential data (e.g., provide an alternative bogus email address instead of the original personal email address) and then intercept calls requiring this information and forward the email message (in this example) to the correct address. The same method can be applied to detect violations by 40 third-party applications of the rights granted to them.

It should be understood that the website owner may need to provide limited or modified information to any of the specific third party applications 40. This may be due to general security considerations, specific privacy obligations regarding any user data element, or regulatory requirements related to specific industry or specific application. Privacy policy enforcement devices 213 and 233 may implement similar changes made by the owner of the website, as well as override the current settings.

One example would be a health information website that may need to block some personal information in contact information when transferring it to a third-party application 40 that performs a general analysis of the geographic distribution of users. In another example, third-party application 40 may not work correctly with some types of contact information. A site owner who wants to continue to use such a third-party application 40 (despite a known bug) may need to filter the contacts that are causing the known error, or change this data to avoid this error.

Translators and adapters 212 and 232 may apply predefined rules for broadcasting messages and adapting content. Each such rule can include conditions, for example, the third-party application (or applications) 40 to which it applies, filter criteria for selecting messages to which it applies, a transformation rule (for example, discarding a given message if it relates to a given third-party application 40) or applying a transformation to the specified field (or fields) in the activity data structure.

Thus, hubs 210 and 230 can provide different versions of activity data structures to different third-party applications 40 (or not at all) as directed by the owner of the website.

An appropriate system 30 for building a website may also support validation and

- 28 036433 Signing messages to protect the system from errors and hacking attempts (for example, from man-in-the-middle attacks aimed at spoofing the payload data of third-party application 40 messages). To this end, each third-party application 40 registered with the website building system 30 may have two sets of public / private keys: one used to decode messages sent from the third-party application 40 to the website building system 30 (receive key), and another, used to encode messages sent from the website building system 30 to the third party application 40 (transmitting key).

For example, third party application A can send a message to system 30 to build a website. This message can be transmitted using the third party application identifier used on the website, i.e. an external third-party application identifier (from the third-party application identifier range), and can be signed by a third-party application. System 30 for building a website can receive this message. The validator and signature device 235 may validate the signature using the third party application A receive key. If the validation fails, the validator and signature device 235 may report that the received message is invalid and the message will not be forwarded.

The validator and signature device 235 may translate the external identifier associated with the message to the internal website identifier. The validator and signature device 235 ensures that each message is received only by the desired third-party application (or applications) 40.

For example, for each of the third-party applications B1 ... Bp, the validator and signature device 235 can find the external identifier of the third-party application B. Then, the validator and signature device 235 can generate a message for the third-party application B and transmit an instruction to translators and adapters 212/232. the need to apply all applicable filtering and transformation rules in accordance with the previous description. The validator and signature device 235 may then sign the message using the transmission key for third-party application B and transmit this message to third-party application B via router and tracker 231 (or router 211). Third party application B can then receive this message and validate the signature. If the current validation is unsuccessful, a report is generated that this message is not correct, and it is no longer processed. It should be understood that the validator and signature device 235 can only process data on the server side, and not on the client side, in order to prevent the transmission of the secret validation data to an untrusted client.

In accordance with the foregoing description, the system 200 may employ a variety of types of communication between the website building system 30 and third party applications 40. The communication may include, for example, control communication, such as issuing, by the website building system 30, a command to disconnect the third party. applications 40, functional communication, for example, transfer from third-party shopping cart application 40 of the total amount of purchases through system 30 for building a website to billing third-party application 40 for making a payment, or transferring activity information, an example of which is discussed in this application ... It should be understood that all these different types of communication have different profiles and requirements, for example, in terms of the volume of transmitted messages, priority, reliability, response time requirements, etc.

Namely, system 200 may include activity reports that are reported very frequently (for example, if graphical user interface (GUI) events of the third party application 40 are considered as activity of the third party application 40 that needs to be reported). Multiple activity reports like these can overwhelm the parts of the system that handle more critical messages. Accordingly, multiple communication channels can be implemented in system 200 (eg, using different ports, multiple concurrent sessions, and the like) such that each class of messages can be transmitted on a separate channel. Thus, a side channel can be used for activity reporting, i.e. a parallel channel that does not affect the functioning of the control and functional communication.

In accordance with the foregoing description, system 200 can collect activity information for the purpose of generating and enriching contact information using the contact coordinator 240 and the activity coordinator 250, and also aggregate activity events associated with specific contacts. For each activity message routed through hubs 210 and 230, contact coordinator 240 and activity coordinator 250 may process this information. The stream generator 251 can generate a data stream for each specific contact from the activity messages, and the contact coordinator elements 240 can retrieve the data and process it before being stored in the contact database 245.

Accordingly, each activity data stream can have an associated formed contact, whose contact information can be gradually enriched with data extracted from the information about the activity passing through the given stream. It should be understood that the contact coordinator 240 can also detect the presence of related contacts, i.e. multiple contact information records describing the same person. Identification device 272

- 29 036433 contacts can recognize such records by matching a primary identifier field, such as email address, phone number, social security number, Facebook ID, etc. It should be understood that some of the primary identifier fields may be ambiguous (for example, a person may have more than one email address that identifies them), while others may be strictly unambiguous fields (for example, a social security number).

Accordingly, the data fusion device 243 can merge the contact information fields extracted from the new activity information with the currently generated contact, and can also merge the contact created for the anonymous user while using the website with a predefined stored contact. after that anonymous user has logged in to the account and turned into an authenticated user (this can be called a vertical merge). The horizontal contact merger 277 can thereby horizontally merge two different contacts (created or stored) when it detects that they are related and refer to the same user. As previously described, such a merge can be real (where two separate contacts are converted to one contact) or the merging of two contacts to each other can be done using a virtual merge (i.e. the two contacts remain separate, but they are then linked to each other by marking that they represent the same user - with or without merging actual contact information and activity streams). You also need to understand that in a virtual merge, additional information may be added to the set of related virtually merged contacts.

Thus, the data extractor 241 can extract contact type information from the corresponding activity data structure, and the data fusion device 243 can combine this information with the contact information associated with the activity data streams (anonymous or identified). If the contact type information I contains a primary identifier field, then the merger 243 can check for related contacts based on the value of that primary identifier field, and if found, merge those contacts. The data fusion device 243 may also check if the activity is consistent with the establishment of the user's identity on the website (for example, whether it is a login to a website account), and if so, merge the anonymous contact with the existing contact information record. stored for this user, and in the future to work with him as an identified contact person.

It should be understood that the contact ID device 272 may employ many different methods to identify users of a website, for example, using cookies to track the session of an individual anonymous user (not logged into the website account), using the account login. a website record for registered users, by logging into a social network account for website users whose account is associated with a social network, or by mapping primary identifier fields (such as email almost or phone number) to determine whether that two user profiles describe the same user.

You also need to understand that website users who are stored in the contact database 245 may be classified as anonymous users, not registered on the website, registered users and potential users, while the records of potential users are not yet officially registered. registered on the website can be imported from external sources.

Since the respective website may set persistent cookies that persist from session to session, multiple anonymous sessions may exist on the same computer and in the same browser, remaining sources of new information for the same contact record. Accordingly, even an anonymous user can have a significant amount of contextual and contact information.

Registered users must provide an identifier that is unique to that particular website. Many types of identifiers, such as an email address, telephone number, or social security number, or an external identifier provided by another system, such as a social network ID can be used as a separate identifier (such as a username) depending on a particular website. , Google ID, OpenID, etc.

A user registering through a social network account may authorize this site to use personal information available on the social network to complete his user profile on this website. The data extractor 241 may revisit the social network profile to detect changes in personal information and optionally update the user profile on the website.

- 30 036433

A registered user generally needs to log in to a website account to identify himself, but the system may also provide the option to keep the login. The login procedure can be explicit, i.e. the user can be presented with an implicit login dialog, i.e. the user may be prompted for identifying information, for example when adding a comment to a blog, or may be based on an external account, i.e. the system can invoke a procedure to log into an account associated with another system, such as logging into an account on a social network or OpenID. The account login procedure can also be performed using a physical device (for example, a security token connected to the system directly or via a wireless interface) or using biometric information (including both biometric parameters of the user, for example, scanning of fingerprints or iris of the eye, as well as and recognizing user behavior, such as recognizing the typing style on the keyboard), or using a combination of the above methods.

You also need to understand that the procedure for logging into a social network account can interact with the procedure for regular logging into an account in both directions. For example, a website subscriber ID might have a social network ID associated with it, that is, logging into a social network account would imply a website account login, or a website subscriber ID might be associated with social network IDs, that is logging into a website account can also identify a user on one or more social networks.

When the user explicitly logs out of the account, the contact handler 242 can generate a new anonymous user's cookie and accordingly generate a new anonymous session (or series of sessions) whose activity information will be stored in this new anonymous contact. A new anonymous contact could potentially be merged with an identified contact if subsequently logged into the account.

Referring to FIG. 19, which illustrates the login and logout procedures for an anonymous user. The user can start using the system being anonymous. Contact handler 242 can generate a new contact, and flow builder 251 can automatically generate anonymous 1 activity data stream when the user performs the first operation, operation 1, in a third-party application. The stream merger 252 may merge information from step 1 and further steps 2 and 3 into anonymous contact 1.

After the same user logs into the account as user X, the data fusion device 243 can merge the contact person anonymous 1 (and all other relevant contact information obtained from the activity data stream), combining it with the contact information of user X It should be understood that the stream merger 252 can also merge information extracted from additional operations, operation 4 and operation 5, into a single stream, and the data extractor 241 can then create a new cookie to highlight the subsequent activity of user X. Thus if a new operation is performed, operation 6, the contact handler 242 can create a new anonymous contact anonymous 2, and the data extractor 241 can store the extracted contact information (and activity information) in the newly created anonymous contact anonymous 2.

If (as in scenario A) user anonymous 2 logs into the account a second time as user Y, the data fusion device 243 can merge contact anonymous 2 (updated after step 6 and step 7) by adding his information to the contact information of identified user Y , where information about all subsequent activity will also be added.

If (as in scenario B) user anonymous 2 re-logs into the account as user X, the data merge device 243 can merge the contact information for user anonymous 2 (updated after step 6 and step 7) by adding it to the contact information for user X (already updated and reflecting operations 1-6), where information about all subsequent activities will also be added.

It should be understood that the activity data structure associated with the operations performed may also include contact information. A data extractor 241 can extract this information and forward it to a data merger 243, which can combine it with existing contact information in the contacts database 245, possibly enriching this information. It should also be understood that data extractor 241 can extract data from specific activity messages, from streams in general, from other contacts, or from external sources, such as IP-to-geographic services, as described in more detail below. In accordance with the foregoing description, the contact information in the contact database 245 may also include contact information explicitly provided by the user during the registration or subscription process on the website, information retrieved from the social network account used by the user when registering on the website ( if the login or registration function was used - 31 036433 tions via social network), or provided by the user when updating his own user profile. The data extractor 241 can also extract information from external sources (for example, the user can only enter the US postal code, which can be used by a website to obtain complete address information from an external web service that decodes postal codes).

As previously described, the contact identifier 272 can detect that two contacts are related, or related, based on a primary identifier field such as a username, email address, or phone number. After detecting that contacts A (new) and B (existing) are related, the data fusion device 243 can merge contacts A and B (contact person B will be the main one, where the data of contact person A will be added). The merge is performed using the following merge rules:

B1 = B or A (i.e. B || A); return B, and if B is null or empty, return A;

B1 = math-func (A, B) (matching function); there are important special cases:

B1 = A + B; for example, the number of visits, the total amount of purchases;

B1 = min (A, B); for example, the date of registration on the website;

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

E1 = list-umte (B, A) (function of combining lists); adding A to the end of B deleting elements of A that duplicate elements in B (i.e. B1 = B & (AB)). The data merger 243 can detect duplicate items in lists according to the following rules:

for a list consisting of regular values (for example, scalar values), a comparison of regular values is used;

for a list of structures, a specific structure sub-field is used as the comparison key. For example, the type of address (home, work, shipping address, ...) in the system 30 for building a website that supports multiple addresses; comparison of normalized values. An example of such a comparison is the handling of phone numbers, described below:

adding structure A to structure B if structure A is a more detailed version of structure B (in accordance with the following more detailed description), and a higher confidence score - values may have confidence indicators attached to them (for example, information obtained directly from the user, and the inference information about the user may have different confidence values). The data merger 243 may select a value with a higher confidence factor.

You need to understand that some types of fields have a normalized format. For example, phone numbers can be normalized to the standard US phone number format (for example, (999) 555-1234) or international format (for example, + 1-999-555-1234). The data fusion device 243 can convert the field value to a normalized format for comparison, for example, when comparing primary contact identifiers (such as phone numbers) or when checking merged lists for duplicates.

The data merger 243 may compare two structured values having the same basic structure, such as an address value made up of several sub-fields (country, region, postal code, street, house number, etc.). A structure Y is considered a detailed version of a structure X if each of the non-empty fields in X has a value equal to the same field in Y, i.e. Y all includes all the value of non-empty X fields, as well as possibly the values of some additional fields. Accordingly, the data merger 243 may merge A and B into A to B, if A is a detailed version of B and A is not identical to B.

It should be understood that the data extractor 241 can obtain a contact address based on the IP address using which the corresponding activity is performed. This is done only if the activity data came from a browser session and the user's address is unknown. Accordingly, the data extractor 241 can extract information about a region, or a country, according to the geographic information corresponding to the IP address. In this case, the address is tagged as the intended geographic IP address. This is necessary in order not to interfere with future address merging due to the presence of an address field containing an existing (and possibly inaccurate) address, which is based on the analysis of the IP address, which may prevent the later obtained more complete (but essentially different ) addresses in the database of 245 contacts.

The data merger 243 may also handle tag inconsistencies for merged lists. It should be understood that in the case of merging lists, it is possible that there are two different objects: one from contact person A, and the other from contact person B, which are different, but have the same tag. In such a case, the data merger 243 can merge the lists by placing both objects with the same tag in the resulting list.

So, the concatenation [{tag: home, email: a@b.center}] + [{tag: home, email: c@d.com}] can give [{tag: home, email: a @ b .com}, {tag: home, e-mail 32 036433 ta: c@d.com}]. This procedure can be used if the fields to be combined are marked as allowing non-unique list tags.

The 243 may also use linguistic, syntactic, or other text analysis techniques, as well as consult with external data sources or services when attempting to combine contact information. For example, a user can write their street name in two different ways in two activity records, but use the same house number, city, and zip code. The combiner 273 can apply text analysis (eg, soundtex algorithms) when comparing the two records, and can also compare the two street names with an external source of street names for a given city and zip code. In such a case, the combiner 273 may select a common street name if both addresses are similar (but possibly not identical) to that common name and the remaining address data fields have corresponding values.

The data merger 243 can also merge the contact information according to the account or session information. The user can use the website without logging into an account or registering, start a session, perform some operations as part of that session and subsequently register or log into an account, whereby the current session can be associated with a newly created or existing profile of the registered user (which contains contact information).

After the user starts a session with the website (as an anonymous user), the contact ID device 272 can track the user's activity during that session (using cookies, session ID, etc.), and the contact handler 242 can create for of this specific anonymous user, a formed contact person based on the user's activity during the anonymous session. Router and tracker 231 may also continue to track the activity of the anonymous user in many different sessions on the same computer. This can be done with a persistent cookie (as opposed to a session cookie).

After the user is registered, the data fusion device 243 can use the generated contact information to pre-populate the user profile. If the user logs in to the account, the data fusion device 243 can merge the originally generated contact information with the existing user profile. It should be understood that the generated contact information is merged according to the user ID on this website, since the data fusion device 243 may not have any other primary identifiers (email, etc.) to use in the generated merge contact information ... You also need to understand that such a merger can reveal inconsistencies in the collected information. When merging contact information created for an anonymous user with existing profile data, conflicts can inevitably arise. For example, an anonymous user can fill out a data entry form (displayed by some third-party application 40) as John Smith, and then can log into an account as John Doe (using the same browser session or different sessions). It is possible (for example) that the later login to the account was actually done by a second person using the same computer, or that the user entered an alias in the contact form to maintain their privacy. The same is possible when the data fusion device 243 merges multiple anonymous contact information structures.

Conflict resolver 264 can generally resolve inconsistencies automatically because most fields (including primary key fields such as email or phone number) are list fields capable of containing multiple values. This can only apply to multiple uses of the same underlying website. Any such inconsistencies that cannot be resolved (for example, by merging multiple values into a list value) can be flagged so that they can be handled manually by the website owner, the end user (who can specify which value to use), or other technologies.

Thus, it is possible that the constructed contact information may reflect not one person, but a combined set of users accessing the same website from one computer.

As previously described, data fusion device 243 generally combines contacts according to primary identifier fields (eg, email and phone number) whenever they are created or modified.

The input to this procedure is a contact information record (input contact C) with one or more primary identifier fields that have one or more values (eg, a contact information record with two email addresses and three phone numbers). Multiple primary identifier fields may be required since the user can have (for example) home / work / cell phone numbers and home and work e-mail addresses, and the user can use them interchangeably in the contact form.

The data fusion device 243 may normalize the primary key values to generate a contact record request containing any of the normalized primary key values, such as (phone = P1 or phone = P2) or (email = E1 or email = E2). The data fusion device 243 may thereby restrict the request to the contacts database 245 for a particular website. The data fusion device 243 may also query the contact database 245 and obtain a list of L matching contacts (which includes the input contact C).

If the input contact matches a registered website member (for a specific website), the data fusion device 243 can remove contact C from list L and merge all other contacts in list L into contact C. The data fusion device 243 can then save the updated contact C back to the contact database 245; and delete all other contacts present in the L list from the contact database 245. As previously described, the data merger 234 may alternatively perform a virtual merge, merge all contact information (i.e., update all contact information records to contain all available information), and mark the matched contact information records as belonging to the same person ( instead of removing duplicate contact information records). This may be necessary, for example, if third-party applications 40 store or use internal identifiers related to contact records, and deleting contact records could lead to errors in third-party applications 40. Similar processing (i.e. marking contacts as linked instead of their removal) can be applied in other cases in accordance with the following more detailed description.

If the input contact is NOT a registered subscriber to the website, the data fusion device 243 can verify how many contacts that are members of the website are in the L list. If there are 0 website members, the device can remove the contact. C from list L and merge all other contacts from list L into contact person C. Data fusion device 243 may then save the updated contact C back to database 245 and delete all contacts remaining in list L of contact database 245.

If there is one member of the website (contact D), the data fusion device 243 can remove contact D from the list L and combine all contacts remaining in the list L (including contact C) into contact C. The device 243 can then save the updated contact D back to database 245, and delete all contacts remaining in list L of contact database 245.

If there are two or more contact persons (D, D1, D2, ...) of the participants of the website, the data fusion device 243 can select the contact person D from the found contacts (D, D1, D2, ...) of the participants of the web site and remove contact D from list L. The device can then generate a sublist LL that is based on list L and contains all contacts from list L that are not members of the website. The data merger 243 can then merge all contacts remaining in the LL into contact D. The data merger 243 can then store the updated contact D back into the database 245 and delete all contacts remaining in the LL of the contact database 245.

Consistent with the preceding description for post-login data fusion, data inconsistencies may arise. However, since the list value generator 275 can generate list (ie, multiple) value fields and can determine an unambiguous contact order, in most cases this problem does not arise.

For example, when the contact merge device 243 merges the following contacts:

Contact 1 = [Phone 1, Email1];

Contact2 = [Phone2, Email2];

Contact3 = [Telephone3, Email3].

It can generate combined contact information

Combined Contact = [Telephone = [Telephone1, Telephone2],

E-Mail = [E-Mail1, E-Mail2].

It should be understood that the contact database 245 may include contact information from a variety of sources, having varying levels of access rights for its use. What is described below concerns e-mail, however, the discussed technology is applicable to any of the types mentioned above (telephone, fax, Skype ID, IM ID, social network ID, etc.) used to contact the user.

For example, the way in which an email address was provided on a website may indicate acceptable uses for it. Possible sources of the email address could

- 34 036433 be: identifier used during registration; contact form, newsletter subscription and unsubscribe request. Email addresses may further vary according to the terms of an acceptable use agreement that the user electronically signs.

It will be appreciated that the system 30 for building a website generally has information about acceptable uses for each given email address. However, the website owner may have different, independent or additional information. For example, it may be due to the nature of the various forms of registration on the website, or due to the presence of contact information in the system that was imported by the website from another source that includes additional information on permissions to use.

The data and permission processor 244 can enforce the correct usage policy for third-party applications 40 applied on the website, helping the website owner to administer this information.

Accordingly, the contact information record for the corresponding contact person can include two information fields. The first field is a website permissions field that contains derivatives or inferred resolutions calculated by the website based on user activity. The contact form implies only functional emails, while the subscription form may imply periodic mailings. The second field is the website owner's permissions based on the website's permission field. The website owner can change the website's recommendations and act according to his or her own judgment, but he or she is responsible for any use outside the permissions set in the website's permission field.

It should be understood that the value in the website permissions field may represent the most complete information about the user's intent that the website owns. The website owner permission value is assigned by the website and used by 40 third party applications as well as other parts of the system (for example, 40 third party newsletter application).

Data and permission processor 244 can use these permission fields to determine actual permissions in several different ways. For example, data and permission handler 244 may implement any of the following codes, as well as combinations and variations thereof (for both email addresses and other contact identifiers):

Unknown - The email address was obtained from an unknown source and cannot be used to send any emails.

Identifier email address is the email address provided for registration purposes. It cannot be used to send any emails, except for questions related to registration, such as confirmation, forgotten password or warning of potential security threats.

A functional email address is provided for a specific purpose and is a one-time email. For example, a purchase confirmation email or an email sent for a specific contact form.

Recurrent email address - allows the sending of periodic mailings and promotional emails from a specific website. In this case, an explicit subscription and / or permission is required.

The shared email address allows for the transmission of multiple and recurring mailings and promotional emails by this website as well as its partners (40 third party applications or a fourth party). This requires an explicit subscription and / or permission and may include details of the permitted sharing.

Unsubscribe - The user has explicitly unsubscribed. No emails are allowed to be sent to the user (with the possible exception of a cancellation notice).

Be aware that the data and permission handler 244 can use alternative methods, such as a bitmap of permissions (similar to those used on UNIX or Linux systems) or ACLs. Data and permission handler 244 may also implement separate permission fields for individual pieces of contact information (e.g., email address, instant messaging address, social network ID, etc.)

In one typical use case, database 245 contains a first set of email addresses collected from contact forms and a second set of email addresses derived from subscription requests. The website can call the third-party newsletter application 40, knowing that the third-party application 40 will only send letters to users in the second set (who submitted a subscription request).

The advantages of such a system include a higher level of protection (both technical and legal), for both the website owner and the website, from inadvertent spam or misuse of confidential information, as well as the ability to effectively enforce privacy policies when using systems in conjunction with the proxy module 234 confidential data 35 036433 described above. It also allows for stricter enforcement of unsubscribe requests.

Accordingly, the user can generate activity streams between the respective website building system 30 and any appropriate third-party applications 40. These streams may be referred to as activity streams. Each activity data stream can be used as a source of information about an individual contact. Activity data structures from separate streams can be combined to form a single contact information if it is determined that the different activity data streams come from the same source. For example, one user can work anonymously using two devices, such as a mobile device and a personal computer. Such a user can form two anonymous streams, messages from which can be saved. Once it is established that both of these streams are associated with the same user, they can be merged.

The procedures and information displayed in this document are not inherently specific to any particular computing device or other type of device. Many different general-purpose systems can be used having programs that are consistent with the spirit of the present invention, or it may be more convenient to construct a more specialized device to execute the corresponding method. The structure that must be present in these various systems will be presented in the description below. However, the embodiments of the present invention are not described using any particular programming language as an example. It should be understood that many different programming languages may be used to implement the concept of the present invention described herein.

Unless otherwise indicated, as follows from the foregoing discussion, it is assumed that in the present description such terms as, for example, processing, calculation, calculation, definition, or similar terms that may refer to an operation and / or procedure of a computer, computer a system or other electronic computing device that manipulates data and / or converts data presented in the form of physical (for example, electrical) quantities in registers and / or memory of a computer system into other data, also represented as physical quantities in the memory of a computer system, its registers or on another similar medium for storing information or in transmission or display devices.

Embodiments of the present invention may include an apparatus for performing the operations described herein. Such a device may be specially designed for a specific purpose, or may include a general purpose computer selectively actuated or reconfigurable by a computer program stored in the computer. Such a computer program may be stored on a computer-readable medium, such as but not limited to, any type of disc, including floppy disks, optical disks, magneto-optical disks, read-only memory (ROM), read-only memory on compact discs (CDROM ), random access memory (RAM), electrically programmable read-only memory (EPROM), electrically programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, or any other type of media, suitable for storing electronic instructions and allowing connection to the bus of a computer system.

Specific features of the present invention are illustrated and described herein, however, those skilled in the art will find many modifications, replacements, alterations, and equivalent elements. Accordingly, it is to be understood that the appended claims are intended to cover all such modifications, substitutions, alterations and equivalent elements as consistent with the spirit of the present invention and falling within the scope of its legal protection.

Claims (25)

CLAIM 1. A system for collecting data on the activity of users of third-party applications for the website, including memory; CPU; at least one hub configured to receive activity messages from at least one third-party application embedded in the website, wherein the activity message includes a descriptive address of the target third-party application embedded as an instance in the website, information related to the interaction of the website user with an instance of said third-party application, and identification information of the website user; redirecting said activity messages to a target third-party application by converting the descriptive address into a direct address of the target third-party application and / or to the web site, wherein the hub maintains a table of absolute addresses of all third-party applications embedded in the website; and transmitting activity messages to the activity coordinator and contact coordinator; an activity coordinator including a contact identification device configured to identify a contact associated with the activity message based on identification information from the activity message, said identified contact being a user of said website; a sequence generator configured to generate the start of a sequence of activity messages associated with the identified contact by storing the activity message in the database as the first message of said sequence if the contact is identified for the first time; and a sequence merger, configured to add an activity message to an existing sequence of stored activity messages associated with the identified contact if the contact has been previously identified; a contact coordinator including a data extractor configured to extract user information from the activity message and store it in a database as a contact information record associated with the identified contact; and a data merger device configured to merge at least two records of contact information if said records are associated with the same identified contact person; wherein said activity coordinator, said contact coordinator and said at least one hub are implemented with said memory and said processor. 2. The system of claim 1, wherein said at least one concentrator comprises at least one of the following: a router and tracker for routing and tracking said activity messages between said website and said third party applications; a privacy policy enforcement device to enforce the terms of a confidentiality agreement between said website and said third party applications; a translator and an adapter for applying at least one predetermined rule for transforming and adapting content between said website and said third-party applications; a proxy module of confidential data for realizing representation with respect to confidential data and / or replacing confidential data and for enforcing restrictions on user permission fields between said website and said third party applications; and a validation and signing device for validating and signing said at least one activity message using a reception key of said at least one third-party application, for converting an external identifier associated with said at least one activity message into an internal identifier of said web -site and for signing the outgoing at least one activity message using the transmitting key of the at least one third-party application. 3. The system of claim 1, wherein said activity coordinator also includes a log generator for logging activity data from said sequence of activity messages to said database. 4. The system of claim 1, wherein said contact coordinator also includes a contact handler for creating a new identified contact and / or anonymous contact and for tracking the activity of the contact during a session with said website; and a data and permission processor for managing privacy protection and permissions for the retrieved information related to the contact. 5. The system of claim 2, wherein said router and tracker support routing said activity messages using discovery requests for said at least one third party application. 6. The system of claim 1, wherein said sequence fusion device comprises an activity-sequence fusion device configured to combine said activity messages into a sequence associated with said identified contact, and a sequence-sequence fusion device for fusing at least two separate sequences into a single sequence. 7. The system of claim 6, wherein said sequence-to-sequence merger comprises a horizontal sequence merger for merging - 37 036433 of said at least two separate sequences according to the common identified contact and a vertical sequence merger for merging the sequence generated for the anonymous contact with the sequence associated with the registered contact after logging in or registering, allowing these two contact persons. 8. The system of claim 1, wherein said contact identification device is also configured to perform at least one of the following: detecting identical primary identifier field values in at least two of said contact information records, detecting primary key field values at least in the two mentioned contact information records, which are identical after normalization, identification of the website user using cookies, identification of the website user using account login for registered users, and identification of the website user through a social network account for users a website whose social media accounts are; said data fusion device includes a merger for merging contact information using at least one of the following: linguistic characteristics, syntax, text analysis and consultation with external data sources or services; a conflict resolution device for resolving conflicts between contact information records according to predetermined rules; a list value generator for generating fields with list values defining an unambiguous sequence of said contact information records; a horizontal contact merge device for merging two unrelated contacts upon detection of a common primary identifier; and a vertical contact merger for merging an anonymous contact with a contact that is associated with a registered user after logging in or registering, thereby merging the two contacts. 9. The system of claim 8, wherein said horizontal contact merge device includes a virtual merge device for maintaining at least two contact information records as separate records and for concatenating them together so that they are marked as representing the same contact face. 10. The system of claim 8, wherein said vertical contact merger includes a virtual merge device for maintaining the anonymous contact and the contact associated with the registered user as separate entities and for linking them together so that they are marked as representing the same contact person. 11. The system of claim 2, wherein said user permission field is defined by said website and / or defined by said owner of the website. 12. The system of claim 1, wherein the activity messages have a standardized format that is at least one of the following: a format defined by a predefined scheme, inheritance, a callback link, a format encoded and defined by said at least at least one third-party application, or a format based on an external formal, industrial, or de facto generally accepted standard. 13. The system according to claim 1, characterized in that said system is implemented on a server, client or in the form of a client-server system. 14. A method for collecting data on the activity of users of third-party applications for a website by means of the system according to any one of claims 1-13, comprising receiving by the hub of activity messages from at least one third-party application embedded in the website, while the message about activity includes the descriptive address of the target third-party application embedded as an instance in the website, information related to the interaction of the website user with the instance of the said third-party application, and identification information of the website user; redirecting said activity messages to a target third-party application by converting a descriptive address into a direct address of the target third-party application and / or to a website, while the hub maintains a table of absolute addresses of all third-party applications embedded in the website; transmission of activity messages to the activity coordinator and contact coordinator; identification by the contact identification device of the contact person associated with the activity message based on identification information from the activity message, said identified contact being a user of said website; generating the start of a sequence of activity messages associated with an identified contact by storing an activity message in the database as the first message in said sequence if the contact is first identified, or - 38 036433 adding an activity message to an existing sequence of stored activity messages associated with an identified contact if the contact was previously identified; extracting by the data extractor information about the user from the activity message and storing the extracted information in a database as a record of contact information associated with the identified contact; merging at least two records of contact information if said records are associated with the same identified contact. 15. The method according to claim 14, wherein the method also includes routing and tracking said activity messages between said website and said third-party applications; compliance with the terms of the confidentiality agreement between the said website and the said third party applications; applying at least one predetermined rule for transforming and adapting content between said website and said third-party applications; implementation of representation in respect of confidential data and / or replacement of confidential data and enforcement of restrictions on user permission fields between said website and said third party applications; and validating the signature of said at least one activity message using a receiving key of said at least one third-party application, converting the external identifier associated with said at least one activity message into an internal identifier of said website and signing the outgoing said at least one activity message using the transmission key of the at least one third-party application. 16. The method of claim 14, wherein the method further comprises logging activity data from said sequence of activity messages to said database. 17. The method of claim 14, wherein the method also includes generating a new identified contact and / or anonymous contact and monitoring the contact's activity during a session with said website, and managing privacy protection and permissions for the retrieved information, related to the contact person. 18. The method of claim 15, wherein said routing and snooping supports routing said activity messages using discovery requests for said at least one third party application. 19. The method of claim 14, wherein said merging comprises merging said activity messages into said sequence associated with said identified contact and merging at least two separate sequences into a single sequence. 20. The method of claim 19, wherein said combining said activity messages into said sequence associated with said identified contact and merging at least two independent sequences into a single sequence comprises horizontally merging said at least two independent sequences according to a common identified contact and / or vertically merging the sequence generated for the anonymous contact with the sequence associated with the registered contact after logging into an account or registering to merge the two contacts. 21. The method of claim 14, wherein said merging at least two contact information records comprises at least one of the following: detecting identical primary identifier field values in at least two said contact information records, detecting primary key field values in at least two said contact information records that are identical after normalization, website user identification using cookies, web user identification - the site using the login to the account for registered users and identification of the user of the website through the social network account for the users of the website, whose accounts are related to social networks; combining contact information using at least one of the following: linguistic characteristics, syntax, text analysis and consultation with external data sources or services; resolving conflicts between contact information records according to predefined rules; the formation of fields with list values that determine the unambiguous order of the mentioned records of contact information; - 39 036433 horizontal merge of two unrelated contacts upon detection of a common primary identifier; and vertically merging the anonymous contact with the contact that is associated with the registered user after logging in or registering to merge the two contacts. 22. The method of claim 21, wherein said horizontal merge includes a virtual merge for maintaining at least two contact information records as separate records and concatenating them together so that they are marked as representing the same contact. 23. The method of claim 21, wherein said vertical merge comprises virtual merging to maintain the anonymous contact and the contact associated with the registered user as separate entities and to link them together so that they are marked as representing one and the same same contact person. 24. The method of claim 15, wherein said user permission field is defined by said website and / or defined by said owner of the website. 25. The method of claim 14, wherein said activity messages have a standardized format that is at least one of the following: a format defined by a predetermined scheme, inheritance, a callback link, a format encoded and defined by said at least one third party application, or a format based on an external formal, industry, or de facto generally accepted standard.