KR20160092021A - Third party application activity data collection - Google Patents

Abstract

The system comprises at least one hub for coordinating at least one activity message having a standardized format between the website and at least one third party application and at least one hub for listening to at least one activity message and for extracting data extracted from the at least one message At least one of the identified contact and the anonymous contact is a user of the web site. ≪ RTI ID = 0.0 > [0002] < / RTI > The system also includes a contact coordinator and web site for retrieving and analyzing contact related information from the stream and for enhancing previously held information about the contact and for storing at least one of the activity streams and contact related information for use by the contact .

Description

Third party application activity data collection {THIRD PARTY APPLICATION ACTIVITY DATA COLLECTION}

The present invention relates to the use of online applications by online applications, and in particular by third party applications included.

Cross-reference to related application

The present application was filed on Dec. 4, 2013, and claims the benefit of US Provisional Patent Application No. 61 / 911,485, which is incorporated by reference herein in its entirety.

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

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

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

Web site building systems have an internal data architecture to organize data and elements within the system. This architecture may differ from the external view of the site as viewed by the user and may also differ from the manner in which typical hypertext markup language (HTML) pages are sent to the browser. For example, an internal data architecture is an essential addition to editing and maintaining sites within a website building system by each element on the page (creator, creation time, access permissions, links to templates, etc.) Attributes, but the end user (or even some editing users) can not see it from the outside. Web Site Construction A typical architecture for a system-based site includes components (e.g., single and multi-page containers, including shape components, image components, text components, minipages, etc.) As shown in FIG.

The components may have no content, such as a star shape (although it may have color, size, location, and some other properties) that does not have any internal content, or may have internal content, such as a text paragraph component And this internal content includes font, formatting, and layout information as well as the text to be displayed. This content, of course, can vary from one text element to another.

Designers using such a website building system can design new creations from scratch (starting with a blank screen), or they can design a new creation by the designer himself, by a system generator, or by a designer community And may rely on defined application templates. The website building system can support templates, which are simple component collections, complete pages (or mini-pages) or even sets of pages and complete websites.

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

Web site building systems can also be extended using third party applications and components embedded within them. Such third party applications may be included in a web site build system design environment or may be provided through a number of deployment mechanisms, for example, from an application store (AppStore) integrated within the website build system, Web-based or standalone application repositories (or AppStores) that are run by a vendor or other entity in a web site building system (WBS) Or otherwise obtained). Third party applications may also be obtained directly from a third party application vendor (either through or through the App Store) - this will either provide the actual install module or just provide an activation code or access code.

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

The back office element of the third party application may include functions such as database communication, external update options, and the like. For example, a blog third-party application may allow updates to be sent to non-human sources (e.g., RSS news feeds from major news services) as well as human sources (E.g., a standalone smartphone application capable of submitting blog entries), which may be provided to the user.

Integration into a web site containing visual elements of a third party application can be done in a number of ways. Widget-type third-party applications can be embedded as elements within a website page, whereas section-type third-party applications can be added as additional pages or pages to a website.

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

Multi-page third-party applications typically have a default page that can be a start page, a specific internal mini-page (e.g., the most recent blog entry in a blog third party application), a mini-page selection screen, ) Provides a "landing" mini-page.

Building Websites Using third-party applications in system-based Web sites is done through third-party application instances. The website building system enables a single third party application instance across the entire web site; Enables instances of a number of third party applications to be created within a website (but no more than one instance of any given third party application) and multiple instances of multiple third party applications But can support multiple uses for third party applications at multiple levels, such as enabling it to be created but no more than one instance per given page is created. This may also enable multiple instances per page of component third party applications, but not per page of section third party applications, and multiple instances of a plurality of third party applications may also be able to support multiple instances of third party application instances , Multipleity, or position without any limitations on it.

The third-party application instance may have instance-specific content. For example, an e-Shop third-party application can have a product database associated with a particular instance, which is the same e-Shop third-party application (on the same site or on other sites ≪ / RTI > of the product database).

For the sake of discussion, a website page (or mini page) that includes a third party application and its mini-pages or elements (i.e., a "wrapper page") is referred to as a containing web page, Will be announced as the main site on the entire web site. The integrated page shown to the user - including the main page and the embedded third party application (TPA) mini page / component - will be referred to as the combined page. In the case of section type third party applications, a "virtual page" containing a third party application will serve as an embedded web page.

Third party applications are typically deployed in web site building system vendor servers, third party application vendor servers, external (fourth party) servers, or any combination thereof. The third party application may also include elements that are actually running on the end user machine, such as a static install browser extension, or may include JavaScript elements that run within the website build system client-side code, (JavaScript) component can be activated dynamically.

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

The included third party application instances may have their own internal content similar to how regular components include internal content. The third party application can manage the content regardless of the website generated using the website building system and the website building system as shown in FIG. 2, which is now referred to. A plurality of third party application instances (of a single or multiple third party applications) may have shared content, e.g., two e-Shop instances on two distinct website pages are the same You can refer to the product database.

The output from the included third party applications may be incorporated into the included web page in a number of ways:

Server-side Processing : In this alternative, as illustrated in FIG. 3, now referred to, the third party application [a] (including design and display elements) and the user specific third party application data [ Is merged by the third party application server code [c] running on the vendors' server [d]. These are sent to the website building system server code [f] via the communication medium [e], which merges them with the embedded web page information [g] and then sends them to the user client station [h] for display.

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

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

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

In accordance with a preferred embodiment of the present invention, a system is provided that can be implemented on a website via a client / server system having at least one processor, and the processor processes instructions that define 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, wherein at least one activity message has a standardized format . The system also includes an activity coordinator for listening to at least one activity message and at least adding 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 at least one of the identified contact and the anonymous contact is a user of the website. The system also includes a contact coordinator and web site for retrieving and analyzing contact-related information from the stream and enriching previously held information about the contact and for providing information about activity streams and contact related information And at least one database for storing the database.

Moreover, according to a preferred embodiment of the present invention, the at least one hub comprises: a router and a tracker for routing and tracking at least one activity message between a website and at least one third party application, And at least one message transformation and content adaptation rule pre-specified between the web site and at least one third party application that implements a privacy policy between at least one third party application and at least one third party application, A personal data proxy that implements at least one of an adapter, an adapter, a personal data proxy and a personal data replacement to enforce user permission field restrictions between the website and the at least one third party application, The incoming key of one third-party application y) to transform an external ID associated with at least one activity message having an internal website ID, and to convert the external ID associated with the at least one third party application's outgoing key And at least one of a verifier and a signer for signing the at least one activity message that is fetched using the signature.

Moreover, according to a preferred embodiment of the present invention, the activity coordinator comprises: a stream generator for identifying a contact associated with at least one activity message and for generating a stream of data if an associated contact is not present; A stream merger that merges data from at least two of the activity streams into a single stream, and a log creator that logs activity data from the activity stream into at least one database. .

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

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

In addition, according to a preferred embodiment of the present invention, a stream merger includes an activity-to-stream merger that merges data into a stream associated with the identified contact and a stream-to-stream merger that merges the at least two separate streams into a single stream. Stream merger.

Moreover, according to a preferred embodiment of the present invention, the stream-to-stream merger includes a horizontal stream merger that merges at least two distinct streams according to the identified common contact, and a stream generated for the anonymous contact A vertical stream merger that merges a stream associated with a contact user and a stream associated with an anonymous contact at login that merges a stream associated with the contact user.

Furthermore, according to a preferred embodiment of the present invention, the data merge: finds the location of the same primary ID field values in at least two of the contact information records, and at least two of the same contact information records To identify site users using cookies, to identify site users using site logins for registered users, and to identify social users for site users who have accounts associated with the social network And a contact identifier that performs at least one of identifying a site user through a login. The data mergeer may also include an integrator that integrates contact information using at least one of language, syntax, text analysis, and consultation with external data sources and services, disagreements between contact records with predefined rules A contradiction resolver that solves the problem according to the following equation; A list value generator for generating list value fields for defining a clear priority between contact records, a horizontal contact merge for merging two unrelated contacts due to the detected common primary ID, And a vertical contact merge that merges an anonymous contact with a contact associated with the registered user at the time of registration or login that can connect the contact associated with the user.

In addition, according to a preferred embodiment according to the present invention, the horizontal contact merge maintains at least two contact records separately and links at least two contact records to each other such that at least two contact records are represented as representing the same contact And a virtual merge unit.

In addition, according to a preferred embodiment of the present invention, the vertical contact merge maintains separate contacts that are associated with anonymous contacts and registered users, and that the contacts associated with anonymous contacts and registered users are represented as representing the same contact An anonymous contact and a virtual merge that links the contacts associated with the registered user to each other.

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

Furthermore, according to a preferred embodiment of the present invention, the standardized format is defined by a predefined schema, inheritance, call back link, and by at least one third party application, Is defined and encoded on the basis of external normal industry or virtual standards.

According to a preferred embodiment of the present invention there is provided a method implementable on a website via a client / server system having at least one processor, wherein the processor processes instructions defining the method. The method comprising the steps of coordinating at least one activity message between the website and at least one third party application, the at least one activity message having a standardized format, listening to at least one activity message Adding at least one of the identified contact and the anonymous contact to a stream associated with at least one of the identified contact and the anonymous contact, the data being extracted from the at least one message, . The method may also include retrieving and analyzing the contact-related information from the stream and enhancing the previously held information about the contact and storing the activity streams and contact-related information for use by the website and by the contact .

In addition, according to a preferred embodiment of the present invention, the coordinating step comprises: routing and tracking at least one activity message between the website and at least one third party application, the website and at least one third party application Applying at least one message transformation and content adaptation rules pre-specified between the web site and the at least one third party application, applying at least one of the personal data proxy and the personal data replacement And enforcing user permission field restrictions between the web site and the at least one third party application and verifying the signature of the at least one activity message using the incoming key of the at least one third party application, At least one < RTI ID = 0.0 > Converting the external ID is associated with the same message and includes at least one step to sign the at least one active message drawn by using the take-off key of the at least one third-party applications.

In addition, according to a preferred embodiment of the present invention, listening and at least adding comprises: identifying a contact associated with at least one activity message and generating a stream of data if an associated contact is not present; Merging data from the message into an existing stream and data from at least two of the activity streams into a single stream and logging activity data from the activity stream into at least one database.

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

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

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

Furthermore, according to a preferred embodiment of the present invention, merging the data into the stream associated with the identified contact and merging the at least two separate streams into a single stream may comprise at least two distinct Merging the streams horizontally, and associating a stream created for the anonymous contact with a stream associated with the registered contact user or a stream created for the anonymous contact at the time of login associated with the stream associated with the registered contact user ≪ / RTI > and vertically merging the stream with the stream.

In addition, according to a preferred embodiment of the present invention, merging the at least two contact information records comprises: locating the same primary ID field values in at least two of the contact information records, Identifies site users using cookies, identifies site users using site login for registered users, and identifies the account associated with the social network. ≪ RTI ID = 0.0 >Quot; includes at least one of identifying a site user via a social login to site users. The merging of the at least two contact information records may also include incorporating the contact information using at least one of language, syntax, text analysis and reference to external data sources and services, Resolving according to prescribed rules, generating list value fields for defining a clear priority between contact records, horizontally merging two unrelated contacts due to the detected common primary ID And vertically merging an anonymous contact with a contact associated with the registered user at registration or login that can connect an anonymous contact and a contact associated with the registered user.

Moreover, according to a preferred embodiment of the present invention, the step of merging horizontally merges at least two contact records so that at least two contact records are represented as representing the same contact, To each other.

Moreover, according to a preferred embodiment of the present invention, the step of merging vertically merges the contacts associated with the anonymous contact and the registered user in order to keep the contacts associated with the anonymous contact and the registered user separate, And linking the contacts associated with the anonymous contact and the registered user to be marked as representing the same contact.

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

Further, according to a preferred embodiment of the present invention, the standardized format is defined by a predefined schema, inheritance, callback link, and is defined by at least one third-party application or on the basis of an external formal industrial or de facto standard And encoded.

The subject matter of the patent, which is regarded as the present invention, is specifically mentioned and specifically claimed in the concluding portion of the specification. The invention may, however, be best understood when read in conjunction with the accompanying drawings, both as to organization and method of operation, as well as to the objects, features and advantages of the present invention, by reference to the following detailed description:
BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a schematic diagram of deployment configurations between a website building system and a third party application;
Figure 2 is a schematic diagram of third party application internal content management;
3 is a schematic diagram of third party application containment within an embedded web page via server-side processing;
4 is a schematic diagram of third party application containment within an embedded web page via client-side processing;
5 is a schematic diagram of third party application containment within an embedded web page via an eye frame nest;
Figure 6 is a schematic drawing of existing and non-optimal third party application displays during page layout change;
Figures 7A and 7B are schematic illustrations of a system incorporating one or more third party applications and a website building system configured and operative in accordance with the present invention;
Figure 8 is a schematic diagram of a document object model compared to a component model;
Figure 9 is a schematic drawing of a sample multi-part blog third party application;
10 is a schematic diagram of a sample modular sales third party application;
11A and 11B are schematic illustrations of different implementations of a communication hub constructed and operative in accordance with the present invention;
FIG. 11C is a schematic diagram of the elements of the communication hub of FIGS. 11A and 11B constructed and operative in accordance with the present invention; FIG.
Figure 12 is a schematic drawing of a communication translation scenario performed by the communication hub of Figures 11A and 11B constructed and operative in accordance with the present invention;
13 is a schematic diagram of an embedded web page for processing a third party application having an association template constructed and operative in accordance with the present invention; And
Figure 14 is a schematic diagram of an embedded web page comprising a third party application having an association template in a mini page configured and operative in accordance with the present invention.
15 is a schematic diagram of a system for coordinating and collecting data from different messages exchanged between one or more embedded third party applications and a website building system, constructed and operative in accordance with the present invention;
Figures 16A, 16B, 16C and 16D are schematic illustrations of elements of the system of Figure 15 constructed and operative in accordance with the present invention;
17 is a schematic diagram of a sample graphical user interface for displaying an activity stream associated with a contact constructed and operative in accordance with the present invention;
18 is a schematic diagram for client-side and server-side third party application activity message delivery; And
19 is a schematic diagram of handling login / logout during a user website session;
It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures are not necessarily drawn to scale. For example, the dimensions of some of the elements may be exaggerated for other elements for clarity. Moreover, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or similar elements.

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

Applicants have recognized that there are many limitations to current methods in the manner in which third party applications are typically incorporated into website building systems and in the way in which integrated third party applications and website building systems interact Respectively.

These restrictions are limited to a single rectangular area within the web page that the third-party application display includes, and this area includes what is included in the eye frame. These limitations also apply to third-party applications that do not have their own window size and location, as well as visual elements (e.g., specialized display frames around third-party application windows) outside the actual third- And the ability to control.

Third party applications may have their own display styles (color schemes, fonts, character sizes, etc.). These styles may be good for some included web pages, but they can be visually problematic or incompatible for other included web pages.

Another limitation is the rigidity of the third party application display from the perspective of the containing site. If the site needs to be visually modified (for example, due to placement on a platform with a different screen size or due to dynamic layout events), the embedded web page needs to change the size of the window allocated to the third party application Can be. In such a case, the third-party application display may be clipped and would need to scroll through the scroll bars to reach different sub-areas within the third-party application. Now the inclusion web page [a] is resized, the area allocated to the e-shop third party application [b] is reduced and the "buy" button [c] can not be viewed with the contents of the shopping cart [d] When making a purchase - it requires a lot of scrolling actions to complete the purchase, making the possibility of the purchase actually being made very small - reference is made to FIG. 6 which shows an example of what could happen.

It will be appreciated that a third party application can not interact with other components within an embedded web page, and that such interactions are sometimes necessary to achieve complex functionality. In particular, there is no way for a third party application to be performed differently depending on the type and content of the components within the included web page. One example of this could be a website that streams online cooking courses. In the background of watching his movie, a user may wish to have a small area of his screen dedicated to the news feed and update the weather in another area of his screen (such as a live stream from CNN). The user may wish to automatically pause their learning section when the weather report for their residence area begins.

In particular, where a large number of third party applications are provided by different vendors, there is no clear standard way in which they cooperate with one another. Therefore, designers do not have a clear way to combine multiple third party applications from different vendors. One example of this is when an e-commerce website runs a module from a third-party ordering system and operates a different module for the shipping system. It may be desirable to order supplies in accordance with shipping schedules and the like.

Applicants may use structured two-way communication between the web site building system and the third party application instances included therein and between different third party application instances that may be implemented within the same include page, It has been recognized that this integration can be achieved by using channels. These channels can also send information about the layout, style and additional information.

It will be appreciated that the discussion below focuses on how to embed an i-frame and that this is the preferred method since the i-frame is built and integrated into modern browsers and does not require the creation of special integrated code. The iFrame nesting also provides intrinsic protection for hacking technologies such as browser support encapsulation and sandboxing as well as cross-site scripting attacks that can be used by malicious third-party applications Can be provided.

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

It will be appreciated that the TPA property sheet 23 can be invoked when attributes are specified for a given third party application 40 instance. It will be further appreciated that when invoked, the TPA property sheet 23 can appear as a client-side view of the TPA property sheet 23 on the client 10. [ It will further be appreciated that the offline embodiment may have its own property sheet as part of the installed client software, so that there may be no TPA property sheet 23 or its repository.

The designer or end-user 5 at the client 10 side has a page configurator 12 to generate website pages and interactions (intra-page as well as inter-page) ) May be used to create your own web page (or any other online application). The designer 5 may select components, templates, etc. that are part of the website building system 30 stored in the application repository 22 via the WBS coordinator 21. Designer 5 may also embed instances of third party applications 40 from third party applications 40 that may have been pre-purchased and their templates, components, etc., may be stored in application repository 22. [ To generate an embedded web page (203). In alternate embodiments, the templates, components, etc. purchased may be stored in the TPA database 52 and accessed via the external TPA coordinator 51. In yet another embodiment, third party applications 40 templates, components, etc. may be purchased through the App Store 25 as needed. The property sheet 23 can be specified by the designer 5 and includes information about the purchased third party applications 40 instances, such as permissions, installation orders, payment, etc., Lt; / RTI > The designer 5 may also use the linker 23 (if necessary) to manually specify any communication channels between the included third party applications 40. [ The linker 23 may also include any specific web page between the embedded web page on which the designer 5 is built and the included third party applications 40 instances, such as movies and CNN news reports, It will also be appreciated that it is possible to specify communication connections and rules. It will be appreciated that the link generated by the linker 23 may be modified through the duration of the website.

It is recognized that the designer 5 can acquire the third party application 40 through channels external to the app store 25, such as an external app store operated by a third party application 40 vendor or an external party. Will be. In such a case, the website building system 30 first registers the third party application 40 and its configuration data and the third party application 40 registers the designer data 5 through the website building system 30, Lt; / RTI >

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

In the case of a multi-part third-party application 40 (described in more detail herein below), i.e., a single third-party application 40 that spans a plurality of child frames, Will be recognized more automatically.

In the case of an embedded website page component that is not included in the associated template (as will be described in more detail below), the third party application 40 is required to have the necessary May include a list of components of the embedded web page 203 (e.g. This list can be stored within the property sheet 23 and include unique IDs, description and component details (e.g., whether it should be a text component or used as a blog talkback label) have. The list may be refined to indicate that the third party application 40 has entered the App Store 25 and the designer 5 may place the component web page 203 in an embedded web page 203 that meets the third party application 40 requirements. The linker 23 can be used to specify fields (fields). The website building system 30 can dynamically generate the missing web page 203 components that were missing when the third party application instance 40 was created and the designer 5 would then move them and the size It may be possible to make adjustments and full manifestations.

Alternatively, the website building system 30 may expose the entire or partial component model of the included web page 203 to the third party application 40 included in the included web page 203. [ It will be appreciated that this may be a component model and not a Document Object Model (DOM) of the embedded web page 203. The embedded web page 203 may be much more complex and fragmented than the component model because the actual embedded web page 203 is part of the web site building system 30 infrastructure or is comprised of an embedded web page 203 You can include a number of HTML elements that support elements - both hidden and visible. The component model will therefore be much simpler.

Now the text component [a] has a number of HTML constructs (enclosing div tag [b], inner div tag [c], frame "mini widgets" [d1] .. [d5] ≪ RTI ID = 0.0 > 8 < / RTI > The DOM model [e] for the embedded web page 203 may include separate DOM tree nodes for each element of these sub-elements. The component model [f] is much simpler, and can only contain a single component node [g].

System 100 may also support selective component exposures-designers 5 can specify, via linker 23, which components should be exposed to third party application 40, May be included in a simplified component model that may be visible to the third party application 40 (including possibly the "containment path " This may be done by explicitly marking the components included, depending on their type or any other website building system 30 attribute. The third party application 40 may then examine the included web page 203 component model and locate the required components.

The links between the embedded web page 203 and the third party application 40 instances may also include broadcast linking that allows the third party application 40 to send communications during runtime to record a particular event, It will also be appreciated that it can be automatically generated as follows. This communication may be optional or mandatory (i.e., the third party application 40 may not function or may be installed unless there is a matching third party application 40 that is linked to receive such messages) none). For example, the third party application 40 may broadcast information packets for activities it performs, and any installed logging third party applications 40 may receive the information packets can do.

Newly created pages that are now fully populated with settings may be stored (via the WBS handler 21) in the application repository 22 to be called at runtime, as described in more detail below.

7b is now referenced again. In this embodiment, the elements are the same as the elements in Fig. 7A except for the elements of the client 10. During runtime, the client 10 includes a viewer 201 for displaying embedded web pages 203. The viewer 201 includes a plurality of view ports 202 for displaying different instances of the third party application 40 (instances derived from the one or more third party applications 40) It will be acknowledged. The client 10 may also include a communication hub 205 to facilitate communication and include any necessary communications between the hosted third party applications 40 without any connection to the associated embedded web page 203 And provides a back channel between the web page 203 and any third party applications 40 it hosts. The function of the hub 205 will be described in more detail below.

Hub 205 is an interactive portion of a website that both the inclusive web page 203 and any third party applications 40 nests can see and their communication should not be delayed by a client- It will be appreciated that the invention may be implemented in a computer 10. In an alternate embodiment, the hub 205 may be used by the third party application servers 40 in the case where it is more desirable for third party application servers 40 to exchange large amounts of data and not route them through the client 10. [ May be implemented in the building system server 20.

It is recognized that the communication hub 205 may support different combinations of communication between the website building system 30 and one or more third party applications 40 as well as between a plurality of third party applications 40 Will be. For example, the hub 205 may enable the third party application 40 to request the website building system 30 to switch to another page in the primary site. The communication hub 205 may also enable the third party application 40 to request to adjust the size of its own window, possibly affecting the layout of the included page. This can be done through the dynamic layout process described in more detail below. Alternatively, the inclusive web page 203 may request that the third party application 40 switch to a different version if a switch to a different version is needed to accommodate the change (e.g.) on the display. This two-way communication also includes communication between a third party application 40 that displays third party application 40 components and additional information and web site building system 30 components associated therewith, as described herein above. It will further be appreciated that communication between the components of the multi-part third party applications 40 and the modular third party applications may be initiated.

The system 100 may also be implemented using both the online and offline website building system 30, which may include client-side elements, a website building system 30 vendor servers, a third-party application 40 vendor server It will be further appreciated that any combination of hosting methods may be used, such as other third-party servers and other fourth-party servers. It will be appreciated that in the case of offline embodiments, the server may still need to implement system 100 as described herein.

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

The system 100 may also support the full gamut of the inclusion of the third party application 40 instance option from the third party application 40 as described herein. However, the system 100 may also only support a subset of these options or may place restrictions on the possibilities of third party application 40 instance inclusion.

The system 100 may also implement the multi-part third party applications 40. The multi-part third-party application 40 may include a plurality of display areas, each of which is processed using a separate eye frame. These areas may also cooperate (as needed) through communication hub 205 as described in more detail herein below.

Reference is now made to Fig. 9, which illustrates one example of a multi-part third party application 40 now. As shown, the blog third party application [a] obtained from the app store [b] is placed in the embedded web page 203 [c]. The blog third party application [a] includes three areas as follows: a blog entry area [d]; Tag cloud area [e]; News update area [f]. A multi-part third-party application may have its own plurality of regions, such as multiple simultaneous resident portions of a single application, as in the above blog example, or as multiple optional resident portions of a single application, And having multiple areas that are selectively and simply displayed as needed, as will be appreciated by those skilled in the art. The display of the selection areas can be controlled by the third party application 40 or by the designer 5 (which determines how to construct this third party application when it includes a third party application). The display also includes support function areas such as configuration or additional dialog areas; (For example, having a small version and a large version of a third party application or having a portrait and landscape version of a third party application) as a display of an alternative to the multi-version third party application .

It will be appreciated that the above described functionality may be implemented by using eye frames for the third party application 40 element display to achieve encapsulation and security advantages of the eye frame based architecture.

The implementation of the multi-part third party applications 40 requires that the third party applications 40 (within their own eye frames) control the display of the various eye frames (e.g., their visibility) , Size, and location). It will be further appreciated that the communication hub 205 may enable this display as will be described in more detail below.

Even when the multi-part third-party application 40 is configured (visually) with a number of elements and regions, it is still in the purchase (e.g., in the App Store 25) It will also be appreciated that a single third party application 40 is considered.

In existing systems, each third-party application 40 may be considered a separate entity and may be used between two third-party applications 40 (from vendors that cooperate with the same vendor or otherwise) Any collaboration should be developed on the fly based on individual cases. It will be appreciated that the system 100 may also support modular third party applications 40 comprising a plurality of cooperative sub-modules that may be purchased and installed separately.

Now the modular sales management third party application [a] has the following sub-modules: CRM module [b]; See FIG. 10, which illustrates how lead management module [c] and electronic commerce module [d] can be included; A single third-party application vendor can provide all the necessary third-party application modules. Alternatively, the third-party application vendor may provide a subset (and function) of third-party application 40 modules and may allow the designer to purchase / install complementary third-party application modules from the same or additional third- . ≪ / RTI > While a multi-part third-party application may be acquired and installed as a single third-party application from a single vendor, this only occurs to occupy multiple screen areas, whereas a modular third-party application may be acquired and installed separately It will be appreciated that it may be possible to include multiple modules and to include modules from multiple third party application vendors. In order to provide the ability to integrate multiple third party application modules from multiple vendors, each third party application module has a list of interfaces / functions it needs and interfaces / functions Must be provided. This can be done, for example, by using lists of interface names based on the hierarchical point-separated name convention (e.g., My_CRM_TPA.NewClient.GetInfo) and interface parameter specifications.

The third party application 40 module may be configured to require the required interface to be mandatory (i.e., the module will not work without them) or as optional (i.e., the module will work but may provide reduced or modified functionality) Can be specified. Therefore, the parameters provided for each interface are: interface unique name; Interface description - By being seen by the designer (5), this designer will be aware of the functions being handled by (for example) missing interfaces; Forced / selected state; Interface parameter list and type. It will be appreciated that each third party application module still resides in a separate eye frame (or a set of eye frames). The operation of the interface is based on the communication channels described in more detail below.

It will be appreciated that third party application 40 modules may be assembled during the website design phase. The website building system 30 may resolve interface reference variables when additional third party application 40 modules are added where new third party application 40 modules And add new (possibly unresolved) required interfaces if possible.

It will also be appreciated that the designer 5 can edit and operate the finished website while the mandatory (and optional) interfaces are still not resolved. However, the designer 5 may not issue a website that is created until all mandatory interfaces have been resolved, and the designer has determined that the hub 205 has a third party application module with mandatory interfaces that have not yet been resolved Attempting a function that may be needed to activate will prompt the designer.

It will further be appreciated that the App Store 25 may include a searcher 26 that can locate the third party application modules that are resolving the required third party application module interfaces. The explorer 26 may search for specific third party application module (s) or all third party application modules based on the interfaces that have not been resolved. The navigator 26 can also search for interfaces that are not currently resolved, or even for interfaces that have already been resolved, as well as compulsory, optional, or both types of interfaces. It will be appreciated that the explorer 26 may also be limited to resolving interfaces that have not been resolved by a particular third-party application, and limited to searching for specific third-party application vendors. The searcher 26 may perform a first level search (i. E., The modules satisfy the currently unresolved interfaces) or a multi-level search (i. E. Looking for modules that satisfy the non-resolved interfaces added when considering third-party application modules).

The system 100 may use the interface techniques to provide information to the designer 5 about the importance of proceeding with missing interfaces. Hub 205 may provide interface conversions between incompatible third-party applications that still need to communicate. This may be done by an adapter module added by the website builder system 30 provider or by an external party adapting some desired interface in a different format.

The system 100 may also be applied to online application editing systems that use the Internet (or any other network connection) to view the generated online applications and that use non-browser client-side software. Such systems do not require the use of specific technologies (e.g., IP communications, HTTP, HTML, etc.) when used by a regular web-based architecture.

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

HTML5 PostMessage : This is a standard HTML5 feature that can be used to provide secure cross-domain messages. Using HTML5 Windows.Postmessage, messages can be transmitted securely between windows, child frames, and main HTML documents, even when they belong to different domains. PostMessage provides a tool for the sending eye frame to specify the domain to which the message will be sent, and a tool for the receiving eye frame to verify the domain to which the message was sent.

URL fragment identifier for messages : This method relies on the use of a URL part identifier to send message data from one endpoint to another endpoint. The data is encoded in plain text and appended to the URL (as a region identifier) used to invoke the hidden i-frame within the target end-point eye frame or the service on the target end-point domain. The site identifier is then decoded by the code in the target service or eye frame.

SPECIFIC COMMUNICATION WEB SERVICES : The website building system 30 provides a specialized web hosted on the website building system server 20. Various communication endpoints are connected to this server to check for messages that are sending or waiting. Such as a pre-HTML5 Comet set of technologies, HTML5-based Web Sockets, or any other queuing, polling, server push or similar technology. Can be done through known methods.

HTML5 local storage : HTML5 provides a structured local storage facility that can be used to store queued messages. However, local storage can only be accessed by web content that belongs to the same domain as the storage eye frame. Meebo XAuth products in which a small server provides support to create the necessary intermediate eye frames that enable domain-specific local storage to be accessed from child frames based on foreign domains - currently owned by Google Inc. Solutions have been developed, such as the underlying techniques used by the HAM.

HTML5 Local File System Access Application Programming Interfaces (APIs) : Similar to the use of local storage described above, the cross-iFrame communication channel is accessed via HTML5 file access APIs (File API, FileWriter API, and FileReader API) Can be configured using local files on the local storage of the user agent being accessed. It is noted, however, that the sandboxed local file system generated by the HTML5 file system access APIs is still origin-private, so that the intermediate eye frame / server component will be needed for the source to fill the same limit.

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

It will be appreciated that the communication hub 205 acts as a broker for all child frame communication using any of the transmission methods discussed hereinabove. Hub 205 may be fully aware of the third party application 40 details and the embedded web page 203 structure as provided by the vendor of the third party application 40 and stored in the property sheet 23 More will be appreciated. The third party application 40 may also have different parameters (as described herein above) when included in different applications and for instances of different inclusions in the same application. Such parameters may include unique instance names that may be used for smart addressing (described in more detail below). It will also be appreciated that the hub 205 may also be aware of additional third party application 40 details that may not be stored in the property sheet 23.

The hub 205 also facilitates smart addressing and identification, verifies communication sources, enforces communication policies, solves third-party application 40 incompatibility issues, It will also be recognized that it can be redesigned into elements. The hub 205 may also enable dynamic updates of the layout in the third party application 40 based on changes made to the inclusive web page 203, as described in more detail below.

Reference is now made to Figs. 11A and 11B which illustrate different embodiments of the hub 205 and Fig. 11C, which illustrates the function of the different elements of the hub.

The hub 205 includes a smart identifer and addresser 310, a sender verifier 320, a communication policy enforcer 330, a protocol converter 340, a rewriter 350, a dynamic layout updater A configuration manager 360, a configuration manager 370, a general updater 380, and a hosted application programming interface (API) wrapper 390. The function of these elements will be described in detail below. All functions are recognized as being applicable to all cross-domain communication channels, such as the third party application 40 versus the website building system 30 channel and third party application 40 versus other third party applications 40 will be.

Referring now to FIG. 11A, there is shown an exemplary embodiment for hub 205 via intermediate eye frame [a] using an internal communication application programming interface (API) to contact website building system 30. In this way messages [c] (using communication API modules [f] and [g], respectively) sent from TPA [d] to TPA [e] Can be analyzed, verified, or modified.

An alternative embodiment, as now referenced in FIG. 11B, does not use intermediate iFrames, but rather encapsulates the communication API modules [a] and [b] (embedded within third party applications [c] and [ Lt; RTI ID = 0.0 > and / or < / RTI > The modules [a] and [b] directly interact with the website building system 30 to receive application specific information and use this information when processing the communication message [f]. This embodiment allows a significant amount of website building system 30 level information to be processed within a module contained within a third party application and this information can be accessed (or even modified) by a malicious third party application (Compared with the embodiment shown in Fig. 11A).

As described herein above, in all of the cross-communication methods described herein, the i-frame addressing is used only when transmitting an i-frame source (including source domain, protocol and port, But uses direct third party application 40 addressing when receiving a message (as the name of the sender provided to the recipient). In addition, sending a message requires the sender to specify a target eye frame window (using JavaScript's document.getElementById ("..."). ContentWindow call or some other method). Thus, in existing systems, each third party application 40 may have complete and specific details (domain, protocol, port and child frame IDs) of any other third party applications 40 with which it can communicate ). ≪ / RTI >

It will be appreciated that this type of direct addressing may be inconvenient to handle in the context of system 100. Although the designer 5 integrates the third party applications 40 from a number of unregulated third party application 40 vendors, the third party application 40 vendors are hosted in a given domain, And may provide third party applications 40 that are moved to different domains or sub-domains. The third party application 40 vendor may change the protocol or port used to contact any given third party application. The designer 5 may be required to modify the design of the embedded web page 203 including the third party application 40. [ All of which may occur in third party applications 40 that are in operation and used in a web site that is accessed by a large number of users. In addition, a single embedded web page 203 may include multiple instances of one third party application 40 that may be useful for different functions. For example, a single page within a product support web site may include two chat third party applications (40) instances-one for user versus user chat and forum, one for vendor support personnel And what is used to communicate.

The addressee and identifier 310 may be used to determine the structure of the inclusive web page 203 and the details of the third party application 40 (such as the URL provided to the website building system 30 by the vendor of the third party application 40) The same) can be fully recognized. Addresser and identifier 310 may provide the addressing of the source or target third party applications 40 to each other using any one of the following: a unique name for the third party application 40 ))); (40) instance descriptive ID (descriptive) that enables addressing of multiple instances of the same third party application (40) by being added to each third party application (40) ID); (For example, "I want to send a message <x> to an instance of any event logging third party application 40 in an embedded web page 203") for the required third party application type / . Such an identifier may also describe the specific services that should be supported by the third party application 40. The address and identifier 310 also indicates a version indication, for example: "I want to send a transaction <x> to an instance of an accounting package <y>, but only if it belongs to version <z> Can be used.

During runtime, since the third party applications 40 communicate only with the hub 205, they need only know the direct address of the hub 205 and may not know the direct address of some other third party application 40 It will be recognized that there is no need to know. This one direct address may be a communication API wrapper provided by the website building system 30 to the third party application 40 provider (communication modules f and g as shown in FIG. Lt; / RTI &gt; may be encapsulated by the communication modules (a and b) as shown. The calling third party application 40 may provide the descriptive addresses of the application or third party application 40 and the addressee and identifier 310 may provide them directly to the third party To application 40 addresses and perform routing. In this manner, the third party application 40 need not maintain a table of absolute addresses of all possible third party applications 40 with which it communicates.

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

The third party application 40 may define general communication policies that may be dependent on external information, embedded web page 203 information, and the like. The communication enabler 330 can ensure that the communication policy is enforced without having to process the non-compliant communication. For example, in a categorized information processing web site, third party applications may be tagged with a classification level field in their profile. A third party application 40 providing a back-end event logging database authenticated with a classification level X may define a policy and accordingly the third party application 40 may be able to define a classification level Lt; RTI ID = 0.0 &gt; events. &Lt; / RTI &gt; The communication enabler 330 can perform the necessary preliminary filtering in such a situation and prevent the messages classified as higher from reaching even the lower classification application.

It may be further appreciated that the designer 5 may wish to include two (or more) third party applications on the same generated web site that can cooperate if possible, but which do not actually do so due to some protocol compatibility issues . For example, as shown in FIG. 12, which is now referenced, the e-shop third party application [a] sends purchase order messages to third party applications [b] (such as those provided by different vendors) And may have the ability to post to a third party application. However, the information provided by the third-party application [a] may not include some of the fields required by the third-party application [b]. Such a situation can typically be solved by third party application vendors of the accompanying third party applications, but in some cases such resolution is not possible (e.g., two third party applications Is currently not updated for some reason). The protocol translator 340 may convert the relevant messages from [a] to [b] (e.g., by providing additional required fields). Such a conversion may be performed by the protocol translator 340 or, if possible, involve some interaction with the embedded web site and the embedded web page 203 (e.g., when additional information is needed ).

Having certain capabilities that require the third party application 40 to send messages or receive messages from other third party applications 40 (a pair of e-shop / billing third party applications 40 described above) It will be recognized more. However, in some cases where a portion of this solution may be missing, it may happen that in this example, there is no matching or appropriate order processing third party application 40. In such a case, the reanimator 350 may allow the designer 5 to route certain messages to or from the included web page 203 component, It may be possible to specify that the page 203 component and components may be relieved by a function that they can provide. This will make it possible to configure the entire website without requiring the configuration of the special purpose third party application 40. [ Thus, transactions can be posted to a website building system 30 component capable of performing transaction logging to a database, which can then be used to perform off-line billing and shipment (separate By the program of.

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

It will be appreciated that the system 100 may include a web site build system 30 based management of the third party application 40 purchase status per user (or indeed designer). It is further appreciated that designers may all be users of the registered website building system 30 and that the website building system 30 can therefore manage a database of third party applications 40 purchases by each designer 5 will be. This information may be stored in the property sheet 23 by the TPA governor 24 during the design phase and by the configuration manager 370 during runtime. For example, the third party application 40 may send a version query message to the client side component 30 of the website build system 30. The Web site building system 30 client side component refers to the repository 22 or its locally stashed copy and returns a response message containing information about the capabilities that the third party application 40 should provide by itself can do.

In an alternative implementation, the web site building system 30 does not require a previous query message, but rather, via an alternative channel, such as an encrypted i-frame parameter, to the third party application 40 ) Configuration information.

As described herein, the third party application 40 may communicate directly with particular embedded web page 203 components. The third party application 40 may communicate the components to communicate in a number of ways: directly to the components (described in more detail below) based on the associated templates; Via the access ID explicitly provided to the specific embedded web page 203 components by the designer 5; Can be identified by examining (if at all possible) the component model provided to the third party application 40 by the embedded web page 203.

It is to be appreciated that, during runtime, the updater 380 may implement messages and responses between the components of the embedded web page 203 and the third party application 40. For example, the third party application 40 may affect or query the visual and display properties (including their location, size, color, transparency, etc.) of the components of the containing web page 203 . Updater 380 may also enable third party application 40 to read or write the contents of web page 203 components that it includes and may be configured to allow third party applications 40 to perform media functions For example, to instruct a certain audio or video segment to be posted to the media player component, or to require the media player component to pause playing for a predetermined period of time.

The updater 380 may also facilitate these components to specify the types of access that the website building system 30 components may perform-access control bits or access control lists (ACLs) ) Are similar to the way they function to protect files in modern operating systems. Such permissions may be defined for each third party application 40 to apply to specific third party applications 40 or from specific vendors. For example, the third party application 40 may be allowed to access a text field that is part of the embedded web page 203 outside the third party application 40. [ This text field can be used to edit the blog entry against the blog third party application 40 to provide more screen real estate than can be provided within the blog third party application 40 area itself. In the case of third party applications 40 that are embedded with specific mini-pages within a multi-page container, the website building system 30 may access the third party application 40 with components that are only in a particular mini-page It will be recognized that it can be restricted.

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

The updater 380 may also enable the website building system 30 to influence the style and display of the third party application 40. The updater 380 may implement calls that allow the website building system 30 to provide formatting and style guidelines to the third party application 40. [ These include color and color schemes; Fonts, character sizes; transparency; Animation, and special effects (e.g., blurring). The color scheme may especially include a generic color scheme (e.g., use of the following x colors) or a high-level color (e.g., using color x for text and color y for frames).

One preferred way of representing complex style information is to use Cascading Style Sheets (CSS) that can represent a combination of multiple style indications, including fonts, sizes, colors, Will be. Updater 380 may send such CSS-based messages to third party application 40. [ The stylesheets can be in fact comprehensive or the web site building system 30 can be configured to provide better guidelines to the third party application 40 (e.g., May include specific style names defined by the third party application 40 (e.g., to be able to refer to elements and provide guidelines for them).

The third party application 40 then uses these guidelines to make it better suited to the web page 203 including its own look and feel. This is particularly important for third party applications 40 that are viewed or included from multiple embedded web pages 203 within the same site (multi-port inclusion as mentioned above). The multiple included pages use a different color scheme or generic design. The third party application 40 uses the information provided to it via these style messages, adapts its own display colors and style to better fit each containing page, and creates a color It is possible to prevent displaying the schemes or the look and feel.

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

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

Existing systems can now be used by clipping a third party application display, adding scroll bars to the display, or just scaling the display as a pop-up window hiding other page components, as shown in Figure 6, (Even a little). The dynamic layout updater 360 can implement a collaborative dynamic layout in which the website building system 30 and the third party applications 40 cooperate in performing dynamic layout and maintain the basic design of the embedded web page 203 have. The functionality of the dynamic layout is further described in US patent application Ser. No. 13 / 771,119, filed February 20, 2013, which is assigned to common assignee of the present invention. However, even in a collaborative dynamic layout support system, the dynamic layout mechanism in the embedded web page 203 does not control the entire internal layout of the third party application 40. Furthermore, the web site building system 30 widgets may be designed such that they can be resized to any arbitrary size (within a predetermined range), but the third party application 40 may support any sizing I can not. Third party application 40 may provide, for example, any combination of: a plurality of display configurations (e.g., displaying more or less details) having different sizes; The ability to scale some of its internal elements using multiple font sizes and the ability to display some of its own internal text elements.

The third party application 40 may still provide a limited number of possible display sizes and may have a full range of possible sizes. Thus, the resizing request [inclusive web page 203 → third party application 40] may be requested by the third party application 40 by switching to the closest possible size or by retrieving a list of possible third party applications 40 sizes (And by enabling the website building system 30 to select a size that is suitable for use).

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

For example, the third party application 40 embedded in the embedded web page 203 may need to be scaled to a desired desired size (e.g., X1 * Y1 pixels). The dynamic layout updater 360 may send a message to the third party application 40 requesting that the third party application 40 resize its content to a predetermined desired size X1 * Y1. Third party application 40 can be scaled to this size - by using alternative display configurations, internal scaling, internal dynamic layout processing, or any other means. It will further be appreciated that the containing web page 203 may resize the outer eye frame window including the third party application 40 to a new size X1 * Y1.

It will also be appreciated that the third party application 40 may be enabled only with a limited set of resizable sizes (e.g., specific user interface configurations). Thus, the dynamic layout updater 360 may use the following alternative algorithm that allows the third party application 40 to provide a set of possible sizes.

The embedded web page 203 is resized and the dynamic layout updater 360 causes the third party application 40 to resize its content to a predetermined desired size X1 * Y1 And transmits a message requesting that it be a message. The third party application 40 then determines the closest possible size (e.g., X2 * Y2 pixels) and then uses an alternative display configuration, internal sizing, internal dynamic layout processing, or any other means . The updater 380 may then send a response message confirming the resizing to the included web page 203 and provide the actual new size (X2 * Y2). The embedded web page 203 may resize the outer eye frame window including the third party application 40 to the actual new size X2 * Y2. The embedded web page 203 can continue dynamic layout processing based on the actual new size (X2 * Y2).

It will be appreciated that other embodiments are also applicable, particularly if there are multiple third party applications 40 (or multi-region third party applications 40) within the embedded web page 203. In this embodiment, the inclusion web page 203 allows the embedded third party applications 40 to make an attempt to optimize the look and feel, taking into account a number of options for multiple third party applications 40 To query the embedded third party applications 40 to obtain a list of display sizes to allow for the display size. This embodiment may also be appropriate if the third party applications 40 are displayed across multiple areas.

The inclusion web page 203 performs dynamic layout processing so that one or more third party applications 40 (TPA [n] in TPA [1]) are embedded in the embedded web page 203 and using the following algorithm It can be found that it needs to be resized:

Loops 1 through n for i:

Determined for each TPA [i]

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

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

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

The dynamic layout updater 360 may send a message to TPA [i], which details the request information for the above minimum / maximum / optimal sizes and possible third party application 40 sizes.

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

Based on the Xposs [] [] / Yposs [] [] information collected above, the inclusive web page 203 can be used to perform a full evaluation of all possible third party application size combinations (e.g., The solution to the dynamic layout calculation can be calculated by using any other technique used by the algorithm.

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

Loops from 1 to n for i:

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

The embedded web page 203 scales the outer eye frame window including TPA [i] to Xfinal [i] / Yfinal [i].

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

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

As described herein, the third party application 40 may also need to occasionally change its display window size. Since the size of the window displaying the eye frame is managed by the hosting page (i.e., the embedded web page 203), the window size change of the third party application 40 should be performed by the embedded web page 203 - here The third party application 40 requests (via dynamic layout updater 360) to change the window size from the embedded web page 203.

It will also be appreciated (via the dynamic layout updater 360) that the third party application 40 can also request to change its location within the embedded web page 203. This may not affect the third party application 40 internally (as the size change affects), but it requires display changes within the embedded web page 203. Dynamic layout updater 360 can integrate this request with dynamic layout. The inclusion web page 203 is used by the dynamic layout updater 360 to change the size (and possibly its location) of the third party application 40 window and to reverse identify the size and location change to the third party application 40 Can be activated.

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

It will be appreciated that third party applications 40 will often require a wide variety of complex services-third party applications 40 may be used for internal use or for designers using third party applications 40 at their sites For use in downstream applications. Such services may include user management, billing and shipment management. Web site builder system 30 vendors may not be able to provide such services as part of a website build system (e.g., due to technical or business considerations). Moreover, these services may not be suitable for "packaging" as third party applications 40 on their own. In addition, the third party application 40 vendor may provide a number of such services (e.g., multiple third party billing APIs) to designers using the third party application 40 - and It may require an option that allows the designer 5 to select what is suitable for his use.

For example, an API hosted by Paypal ^TM may be provided within the website building system 30 and may be used directly by the third party application 40, or may be used by the third party application 40, (5). The third party application 40 may also implement these options by providing a set of its own options (i.e., using a specific charging type such as lump sum, recurring or revenue grant) and calling the hosted Paypal API .

Therefore, the designer 5 using the website construction system 30 can develop a specific offering (such as a song-sale e-store) that uses the evolved bill. The developer 5 may avoid having to negotiate a particular approval or merchant agreement with the billing API provider by using the hosted billing API - either directly or by providing an additional abstraction level (or layer) Through the third party application 40. In this sense, the website building system 30 may be a distributor for hosted API vendors.

The hosted API wrapper 390 facilitates this communication between different parts of the system (e.g., the website building system 30, the hosted API code, and the included third party applications 40) . It will be appreciated that the API wrapper layer and actual API implementation may reside within the website building system 30 itself or other third party applications 40. The third party application 40 vendor (or designer 5) can use the hosted API through the hosted API wrapper 390 without knowing how the actual underlying API is implemented.

In an alternative and complementary embodiment of the present invention, applicants are also aware that smart integration between the website building system 30 and the one or more third party applications 40 may also be used by additional website building system &lt; RTI ID = 0.0 &gt; Can be accomplished by using an integrated model that is associated with third party applications at the level of the App Store 25 as well as with related third party application instances. Third party application 40 may also communicate with these components (as well as non-associated components) to exchange data and control messages. As described herein, the third party application areas 40 within the embedded web page 203 may have their own content stored in separate domains (third party application vendors or otherwise) - the domain in which the primary site is hosted Are separate child frames hosted on different -. Therefore, communication between different eye frames is subject to the browser's "same original policy &quot; and requires the use of techniques such as those described herein.

Existing systems may be monolithic (e.g., rigid objects that are included in the web page 203 including the third party applications 40 or otherwise do not affect the look and feel of the included web page 203 itself) monolithic). The instance of the third party 40 is placed in an (typically rectangular) area and performs all of its activities within this area.

Applicants may extend this by having an additional website construction system 30 template (optional) associated with the third party application 40, which concept is referred to as an association template according to one embodiment of the present invention. . This association can be performed during the development and publishing of the third party application 40 and allows the designer 5 to access the third party application 40 selection / purchase processor (from the app store 25) &Lt; / RTI &gt; 40) instance creation. The TPA coordinator 24 can retrieve a template associated with the third party application 40 (which may be part of an application repository managed by the app store 25 or otherwise provided by the third party application 40 vendor) The template may be stored in the repository 22 for later use as described herein.

The system 100 can support the issuance of third party applications 40 having a number of associated templates-allowing the designer 5 to select the template that best fits his needs .

When creating an instance of the third party application 40 in any embedded web page 203, the components in the association template may be merged with the embedded web page 203 and any other within the embedded web page 203 May be displayed together with the components.

Reference is now made to Fig. 13 which illustrates one example of the use of an association template in accordance with one embodiment of the present invention. As shown, third party application [a] is placed in app store [b] with association template [c] containing components [d] and [e]. When the third party application [a] is included in the embedded web page 203 [f], the third party application [a] is displayed in its own designated area [g] it is to be appreciated that the instances [d '] and [e'] of the elements [d] and [e] can be displayed on the page [f] along with the elements [h] and [i]

It is to be appreciated that the system 100 may support a variety of methods where the associated template component instances (e.g., [d '] and [e'] above) are located in the containing web page 203 [f] will be. These include: absolute placement (ie, using the size and location specified in association template [c] for original [d] and [e]); To adjust the size and location of new instances [d '] and [e'] according to the target-related layout (i.e., including web page 203 [f]); And the third party application 40 (i.e., the size and location of the new instances [d '] and [e'] in the third party application instance [g] in the containing web page 203 Adjusted with respect to the size and position specified for the &lt; / RTI &gt; The determination of the specific layout method can be done based on the settings enclosed with the associated template [c], allowing the designer 5 to override it if possible.

It will further be appreciated that the designer 5 can modify instances of [f] of the components [d] and [e] that are inherited from the template [c] The changes can only be applied to the use of [d] and [e] in [f] (and, if possible, pages inherited from the website building system 30 that support inheritance between pages), but in the App Store [b] It may not affect the "circle" template [c] associated with the third party application [a].

Changes to the above [d] and [e] instances may be considered to include: assigning specific content (text, images, etc.) to field instances, as well as regular attribute changes will be. If the third-party application 40 is included within the mini-page, it will be further appreciated that the association template is applied to the particular mini-page included, as shown in FIG. 14, where the third-party application 40 is now referenced. As shown, since the third party application 40 is contained within the mini page [x], the components [c] and [d] are added to [x] [y] and [z].

In the case of sectioned mini-pages, it will be further appreciated that the association template (if any) is applied to the virtual (and empty) embedded web page 203 that is created to include the third party application 40.

In alternative implementations, pre-generated association templates may be applied to newly created pages or mini-pages that are "in parallel" to the containing web page 203 they contain. This newly created page or mini-page can be initialized as a template, which can then be modified as desired.

Web site building system 30 may also enable multi-port inclusion - where the same instance of third party application 40 may be seen from multiple pages of the primary site and "reside " ". This may be different from creating multiple instances of a given third party application 40 at the primary site - multiple instances of the third party application 40. Third party application 40 content-instance-specific-is therefore shared between multiple views of the same multi-port third party application 40.

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

As described herein, the system 100 may provide a two-way communication link between the components within the included web page 203 and the third party application 40. [ It will be appreciated that this includes components not related to any such associated template, as well as embedded web page 203 components resulting from merging an associated template from a third party application.

It will therefore be appreciated that a third party application 40 vendor may generate a plurality of templates associated with third party applications 40 that are typically produced by a vendor. These templates may include test, development, and other templates in addition to those that are actually deployed (i.e., associated with currently deployed third party application versions).

As described herein, the third party application 40 may be distributed via the app store 25 and may also be provided through alternative channels that are not associated with or managed by the website building system 30 vendor Can be distributed. However, associated templates that are distributed to the third party application 40 may be highly related to or may be combined with the application repository 22 because they are components managed by the website building system 30, Base templates and other elements.

Moreover, the elements of the website building system 30 that form the basis of the association template so distributed separately may have to be modified or deleted - if possible, "break" the association template. To solve this problem, the system 100 may implement these association templates in a separate area within the application repository 22 (possibly per third-party application 40 vendor). The website building system 30 can manage these templates in the same manner as other website building system 30 templates.

A vendor of the third party application 40 may be provided with a unique ID (development ID) for each template to be generated and this third party application 40 may use this ID during the development and testing process of the third party application 40 Will also be recognized. Once the third-party application 40 can be published / distributed, the third-party application 40 vendor needs to apply and receive an alternative unique ID (publication ID) Can be referenced in. Once a publication ID is provided, a locked copy of a separate locked template is created. This is a copy that is referenced by the third party application 40 and used when creating instances of the third party application 40. [ In this manner, the third party application 40 vendor can not inadvertently modify the template associated with the "live" third party application 40 (included by the designers) integrity is preserved. Moreover, the system 100 may cross-refer to such locked templates and the relationship between the base components and base templates. This cross-reference can be used, for example, if the base template or website building system 30 component included in the immersed template is to be modified (and if such modifications are made in some way to a template or third party application (E. G., If the web site builder system 40 can break the web site 40).

Thus, the system 100 may provide bi-directional communication channels between the third party applications 40, the components within the embedded web page 203, and the website building system 30. [ Included web page 203 components may be based on template (s) associated with a third party application, based on other website building system 30 templates, or not associated with any template.

As discussed herein, the communication hub 205 can enhance communication and provide a back channel between an embedded web page and any third party applications 40. [ Applicants have further recognized that data flowing backwards and forwards between an embedded web page and any third party applications 40 may be useful once they have been collected, processed and integrated.

For example, website owners need to manage a user population or members per site that can be distinguished from the registered user base of the relevant website building system 30. [ Web site users may or may not be registered (anonymous) and Web sites may provide different levels of capabilities to different levels of users. Moreover, users often use personal or contact information such as data when they activate the instant messenger software to contact the site owner, or when they connect to the social network as part of collaborating with the site (even with anonymous users ) Can be provided as a contact form. It will be appreciated that this information may be entered directly into the generated site or made available as part of the interaction with the third party applications 40 embedded within the site.

It will be further appreciated that these pieces of information may be unorganized, uncorrelated, potentially inconsistent and may not be stored many times at all. For example, a single, predetermined user may enter his or her personal email in a contact form (which is operated directly by the site) and send his or her business email to a separate subscription form within the same session Operated by the three-party application 40).

Moreover, the "floating" parts of the information may include different authorizations for its own use. For example, users who fill their email address with a subscription form are entirely eager to receive email-based subscriptions they have subscribed to and, if possible, relevant email newsletters. On the other hand, a user supplying an e-mail address as a registration ID may not wish to receive any e-mails at his registered address, except e-mails related to his account processing, security alerts and the like.

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

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

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

The system 200 includes an activity message organization by streams, storage of activity message histories, multi-level activity message delivery, use of side channels for activity messages, activity message conversions and content adaptation as described in detail below herein It may be possible to deliver a message between the system 200 and a plurality of third party applications 40 while providing various capabilities, including dynamic message routing, dynamic message routing using dynamic message authentication and signature and listener queries, It will be recognized.

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

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

System 200 may be configured to allow third party applications 40 to manage activities that the user contacts (e.g., mass mailing of newsletters) while enforcing usage restrictions set by users themselves It will further be appreciated that the present invention may include additional components to enable the &quot; Such components may even isolate user personal data from third party applications 40 - allowing third party applications 40 to perform their actions without actually accessing the personal user data. . Such capabilities may be implemented using personal data proxy 234, for example, as described in more detail below herein.

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

As described herein, the system 200 may support multiple interactions between the website building system 30 and one or more third party applications 40. Such interactions may be predefined activities such as making purchases, adding items to shopping carts, populating contact information, and the like. Third party applications 40 may specify what activities they support and other third party applications 40 may "listen" certain activities and may be based on information received and activities associated therewith You can act by doing. It should be appreciated that the list of activities that are listened to for a given third party application 40 may be set explicitly in one or more activities as described in more detail herein below or may be determined by an activity listening query will be.

It will be appreciated that each activity can be regarded as a message and each message can include an activity data structure. The activity data structures are predefined data types, but can be defined through third-party applications 40, which may have options to extend them through inheritance and by adding fields therebetween. These may be system-specific, or may be based on or include standardized data structures. They can also be encoded in some manner, such as XML, JSON data, or using a binary object encoding scheme.

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

The activity data structure may further include a callback link back to the activity data structure, e.g., "more information. &Quot; This is: for e-commerce activity structures: full order tracking information, history of orders, etc; For chat activity data structures: For whole chat transcripts and phone activity data structures: can be used to provide additional substantive information such as a record of the call. Therefore, the sample completion activity data structure may contain the following fields: creation timestamp; Activity type; Source of activity (third party application 40 / component ID); Activity stream ID; Activity type specific information (depending on activity type); Creation site ID; Site member database ID; ID / URL of the site page where the activity occurred; An activity description provided by the third party application 40; More information links used by the third party application 40, and user details captured.

The activity coordinator 250 may be regarded as a logging element and may receive data from a delivery message from the hub 230. Stream generator 251 may generate an initial stream that may be considered a log or chain structure and stream merger 252 may add any additional ingest activity to this stream, Lt; / RTI &gt; It will be appreciated that the stream generator 251 may not generate a new stream for each individual activity included in the different messages. (For example, the third party application 40 may be delayed in reporting activity) that the activities contained in the stream may be out of sequence. Stream merger 252 may merge these streams in operation if the streams belong to the same single contact and log generator 253 may store log files in the activity stream database 255 of all previously generated activity streams have.

Stream combiner 252 includes an activity-to-stream merger 261 and a stream-to-stream merger 262, as described herein with respect to FIG. 16C. The activity-to-stream merger 261 may associate activity into the stream associated with the identified contact and the stream-to-stream merger 262 may convert the two separate streams into a single stream. The horizontal stream merger 263 may merge two unrelated streams due to the detected common primary ID and the vertical stream merger 264 may combine the streams generated for the anonymous contacts and the stream associated with the registered user You can merge the two at the time of registration or login that can link streams. It will be appreciated that stream merger 252 may access previously created streams from activity stream database 255 when needed.

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

The user then purchases something from the site. Stream merger 252 may merge the new activity into the "anon 2" activity stream and the contact "anon 2" may be updated (eg, with the "customer" tag).

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

Later, the user returns to another browser and chat with the site owner. Since the website does not have a cookie, the stream generator 251 may generate another new stream ID "anon 3" and the contact processor 242 may generate a new contact "anon 3 ".

Now, the user logs in to the website. At this time, there are contacts by "anon 3" ID and "user x" ID. The data merge 243 may send the contacts "anon 3" and "anon 3" to both the login activity in the "user x" stream and the login activity for the contact "user x" "To" user x ". Stream merger 252 may merge any additional actions performed by the user in this session into the "user x" activity stream. The log generator 253 may log all activity data from the streams and store a copy of the log in the activity database 255.

It will be appreciated that the site owner can access the history of the activity stream for a given contact via the associated user interface provided by the website building system 30 as shown in FIG. 17, now referenced. In the case of a single contact "Dani Bronstein", this person's website usage history can be easily accessed. It will also be appreciated that the website building system 30 or the third party application 40 may also provide an API to access the log information. It will be appreciated that activity logs can be used for optimization, user interface improvement, ad targeting, and the like.

At the same time, it will be further appreciated that the contact coordinator 240 may collect information from the data provided by the activity streams (messages) to augment the contact profile of the user. The data extractor 241 may extract data from the activity messages and streams and the data mergeor 243 may associate the relevant data with a specific contact whose details are stored and accessible from the contact database 245 Can be merged. The contact processor 242 can create new contacts, process site user identities, anonymous users, and the like, and the data and permission handler 244 can handle privacy protection and permissions of related data. The data merge 243 may include a horizontal contact merge 277 and a vertical contact merge 276, as described herein. Horizontal contact merge 277 may merge two unrelated contacts due to the detected common primary ID and vertical contact merge 276 may associate an anonymous contact and a contact associated with the registered user You can merge them both at registration or at login. Horizontal contact merge 277 may also include a virtual horizontal merge 278 that keeps the two contacts separate but links them together so that they are represented as representing the same contact - Or without merging. Vertical contact merge 276 also includes a vertical virtual merge 279 to keep the contacts associated with anonymous contacts and registered users separate but to link them together so that they are represented as representing the same contact You can include - without merging or merging the actual contact information. The data merge 243 may also merge the contact information (typically extracted by the data extractor 241) into an existing contact. It will be appreciated that contact identifier 272 may use cookies to track user identities and recognize contacts to be merged as discussed in more detail below.

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

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

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

It will be appreciated that TPA1 and TPA2 may exchange messages at the client (between components D 'and E'), at the server (between components D and E), or both . However, any communication with ETPA3 must be performed only on the server. Whichever method you use, you will appreciate the advantages and disadvantages. Client-side activity message transmission can be more mutual and provides a faster user response. Server-side activity message transmission may be stronger, more reliable (e.g., the user can not close the browser window during processing), may ensure better ordering of correct message reception, and that activity messages are sent backend or application dash To the backend third party applications 40 installed on the dashboard. It will be appreciated that these backend third party applications 40 are not displayed on the client side.

One example of using multiple third party applications 40 is an example where a user adds a product to a shopping cart at a third party application A (activity type is "cart change"). The third party application A may then send an activity message with the added product to the website building system 30. [ The website building system 30 may then send this activity to all third party applications 40 registered in the cart changes. Since the third party application B is registered, it receives the activity. The third party application (B) can then display to the user a message such as "You will also receive a discount if you also add product X" or "Share this site to receive a discount."

Another example is a user "like" (e.g. via Facebook) in a third party application (A). The third party application A may then send an activity message with the activity type "Facebook Like" to the website building system 30. Website building system 30 may then send the activity to all third party applications 40 that are registered with the "like" activities. Since the third party application B is registered, it receives the activity. The third party application (B) shows the re-engagement widget to the user and says, "If you like this site, why do not you contact the site owner?" Or a message such as "Do you want a discount coupon? &Quot;.

As described herein above, all communications may occur through hubs 210 and 230. [

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

The router and the tracker 231 can route messages between the website and any third party applications 40 and also track messages. It will be appreciated that the third party applications 40 may also listen to messages at both the client and the server. It will further be appreciated that the third party application 40 may explicitly specify one or more activities in which it listens, e.g., listens to all "add shopping cart-items" activities. Third party application 40 may also specify activity classes for which it listens, e.g., listens to all Facebook related activities. Furthermore, the third-party application may include a wild-card representation (applied to the activity names) used to determine whether the activity should be sent to the third-party application.

It will also be appreciated that the third party application 40 may use the activity listener query. Such queries may be based on user attributes (e.g., only registered users, only European users, etc.), website attributes or structure (e.g., only on certain pages derived from a given page template) (E.g., only listening to the activity of the third party application itself), user history (e.g., listening to the cart checkout activity when the user has just purchased in excess of the total amount X in the past) Additional system information may be mentioned. Such a query may be specified by the third party application 40, but may also be editable by the designer.

Thus, the router and tracker 231 can also track messages that are being listened to by the third party application 40. Such an activity listener query architecture may enable the website designer to perform customization and customization without requiring third party applications 40 to be highly programmed and customized, It may be best implemented at the routing level (instead of being performed by an API call within third party application 40). The router and tracker 231 may also help preserve user private information because the website designer does not need to provide additional information (required for routing decisions) to the accompanying third party applications 40 Because. This can also save unnecessary invocations to communicate with third party applications 40, which are often also hosted on individual servers.

Visiting, registering and submitting information to websites will be recognized as users (website visitors). The user can not recognize that the website to which he / she is actually accessing is constructed using a combination of the website building system 30, the components, the configured web sites, and the third party applications 40. [ Therefore, the responsibility for user privacy ultimately lies with the website owner (and is responsible for the activities undertaken by the third party applications 40 included in his web site).

The user profile information is based on privacy rules defined by the web site build system 30 and is used by the third party applications 40 (and other web site build system 30) via the API provided by the website build system 30. [ Lt; / RTI &gt; (30) components). Moreover, as well as the containing sites, the third party applications 40 included therein may use the contact information (via email or other methods) to communicate with the user.

It will be recognized that there can be three major privacy-related issues. The first is interaction with the third party application 40 provider of the website and website building system 30. The web site (and website building system 30) may not fully trust that the third party application 40 uses its user data, for example, if the third party application 40 is a large- (Using site-served user emails), or may not fully trust that they will not send spam or send their personal information to a fourth party to users who have requested not to send mail. However, this can be resolved in the following ways:

Website builder system 30 vendors require providers to sign a Terms of Use (TOU) agreement when adding third party applications 40 providers to the website build system 30 application market . Such an agreement specifies that the third party application 40 (and the third party application 40 vendor) will not misuse or further initiate the user's information. The web site builder system 30 vendor may then penalize the third party application provider if the third party application misuses the information (e.g., disabling the third party application 40, Withdrawing application 40 from web site building system 30 application market, etc.). The personal policy enforcers 213 and 233 and the personal data proxy 234 may enforce privacy policies in the third party applications 40 as described in more detail below.

The second privacy-related problem is interaction with the user of the website and the website building system 30 (the site visitor). Websites should provide users with a clear understanding of how their personal data is used, receive consensus from users, and comply with terms of use agreed upon by the user. The website construction system 30 requires all issued sites to provide the user with a ToU document that defines the allowed use of the personal information belonging to the user and the user is asked to digitally sign the document. The site must then adhere to these terms of use and permitted use. The website building system 30 may also include a sample ToU page in each website template that it provides. Personal policy enforcers 213 and 233 can ensure that the conditions of use of the ToU document are followed. The personal policy enforcers 213 and 233 can also ensure that only the permitted information is provided to the TPA by deleting or rearranging the relevant data.

The third privacy concern is the support of unsubscribe requests. The site must provide the user with an option to unsubscribe from any marketing emails. Which may be handled by the data and permission processor 244 described in more detail below.

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

The personal data proxy 234 is used by the web site building system 30 (and the web sites built in the web site building system 30) to store all or some personal data in a secure repository (Instead of personal data) that can be used by the website building system 30 to retrieve hidden personal data to third party applications. For example, the email address is replaced with an alternative "email address ID" provided to the third party application 40 such that the third party application 40 can not access the actual email address.

The personal data proxy 234 may also be a variety of data proxy 234 that may be used by the third party application 40 to contact and / or send messages to the user without accessing the personal data that the third party application 40 is actually associated with. And may provide a set of interfaces for communication methods (e. G., Email, social network messaging, etc.). Such personal data may include any identification (such as name, address, email, phone (including SMS / MMS), unified communications ID (such as Skype) Details may be included.

The personal data proxy 234 is therefore responsible for enforcing user permission field restrictions, for enforcing user subscription cancellation requests, for throttling user message transmissions, for example, for a given third party Only about 100 e-mails per day for the application 40 may be allowed. The personal data proxy 234 can define proxy parameters, define which personal data can be exposed to third party applications and which can be hidden-by third party applications 40, Can be set based on one.

In the case of third party applications 40 hosted on the website building system 30 servers, the personal data proxy 234 provides an alternative unique ID that is similar in form to the original personal data (e.g., (E. G., An alternative dummy e-mail instead of a personal user e-mail) and then use this information and "capture" the call (in this example) to send the e-mail to the correct address. It may also be used to detect any third party applications 40 that exceed their authorized privileges.

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

One example would be a web site that processes medical information, which is interested in blocking some personal details from the contact information when passing the medical information to the general geographic user distribution analysis third party application 40 Can be. In another example, the third party application 40 may have trouble processing certain types of contact information. Web site owners who wish to continue using the third party application 40 (despite the known bugs) may want to modify the data to filter out or cause no problems causing known problems.

The transcoder and adapters 212 and 232 may apply pre-specified message translation and content adaptation rules. Each such rule may include conditions such as how this rule is applied to which third party application (s) 40, filtering criteria for selecting which messages this rule should be applied to, (As far as the associated third party application 40), such as discarding the content, or a transformation to be applied to certain fields or fields in the activity data structure.

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

The associated website construction system 30 may also support the verification and signing of messages to prevent malfunctions and intrusion attempts (such as man-in-the-middle attacks aimed at modifying the third party application 40 message payload data) -middle attack). &lt; / RTI &gt; Each third party application 40 registered with the website building system 30 can thus have two sets of personal / public keys: one from the third party application 40 to the website building system &lt; RTI ID = 0.0 &gt; 30, and one is a key (retrieval key) used to encode messages sent from the website building system 30 to the third party application 40. The key (retrieval key) to be.

For example, the third party application A may send a message to the website building system 30. The message may be sent with a third party application ID to the site - a third party application external ID (with a third party application scope) - which may be signed by a third party application. The website construction system 30 can receive the message. The verifier and signer 235 can verify the signature using the incoming key of the third party application A. [ If the verification fails, the verifier and signer 235 may report the incoming message as invalid and no further message is sent.

The verifier and signer 235 may transform the external ID associated with the message having the internal site ID. The verifier and signer 235 can determine which third party application (s) 40 should acquire the message.

For example, for each third-party application B 1 .. Bn, the verifier and signer 235 may look up the external ID of the third party application B. The verifier and signer 235 then generates a message to the third party application B and applies any applicable filtering and transformation rules as described herein to the converter and adapters 212/232 . The verifier and signer 235 then signs the message with the retrieval key for the third party application B and sends this message to the third party application (e. G., Via the router &lt; B). The third party application B can then receive the message and verify the signature. If the current verification fails, the message is reported as invalid and is not further processed. It will be appreciated that the verifier and signer 235 may only perform server-side processing and not client-side processing to ensure that the secret verification data is not sent to untrusted clients.

As described herein, the system 200 may use multiple types of communication between the website building system 30 and the third party applications 40. [ These types include, for example, control communications, for example, that the website building system 30 commands the third party application 40 to shut down, functional communication, e.g., And sending the total purchase amount to the billing third party application 40 via the website building system 30 so that the billing application 40 affects the billing or activity communication that is the example discussed in the present application. It will be appreciated that these different types of communication have different profiles and requirements regarding, for example, the amount, priority, robustness, response time requirements, etc. of the messages to be transmitted.

In particular, the system 200 may be configured to perform actions (e.g., when the third party application 40 is modified with third party application 40 activities for which graphical user interface (GUI) events are reported) Reports may be included. Many such activity reports can overwhelm parts of the system that process more critical messages. Thus, the system 200 may implement multiple communication channels (e.g., using different ports, multiple concurrent sessions, etc.) such that each class of messages is transmitted on a separate channel. In this manner, activity reporting uses side channels and is parallel to command and function communication, but does not interfere with this command and function communication.

As discussed herein, the system 200 can collect activity information to generate and enforce contact information through the contact coordinator 240 and the activity coordinator 250, as well as to analyze activity events associated with a particular contact have. For each activity message routed through hubs 210 and 230, contact coordinator 240 and activity coordinator 250 may process information. The stream generator 251 may generate contact specific data streams from the activity messages and the elements of the contact coordinator 240 may process it before extracting the data and storing it on the contact database 245. [

Thus, each activity stream may have a configuration contact associated with it and that can be enhanced by data extracted from activities performed under the data stream. It will be appreciated that contact coordinator 240 may also recognize the presence of related contacts-multiple contact records found to describe the same person. The contact identifier 272 may recognize such records by matching primary ID fields such as e-mail, phone numbers, social security numbers, Facebook IDs, and so on. Some primary ID fields are multi-valued fields (e.g., one person may have multiple identity e-mails), while some are entirely single value fields (e.g., social security numbers) will be.

Therefore, the data merge unit 243 can merge the contact fields extracted from the new activity into the current configuration contact, and once the anonymous user has performed the login operation and becomes the identified user, the use of this anonymous (Which may be known as "vertical" merging) to a predefined stored contact. Horizontal contact merge 277 may also perform a "horizontal" merge of two different contacts (either constituent or stored contacts) if it detects that there are related contacts that refer to the same user. As discussed herein, such merging may be accomplished by merging (i.e., switching two separate contacts into a single contact), merging one contact into another, or through a virtual merge (i.e., Links to each other so that they are represented as representing the same user - without merging or merging the actual contact information and activity streams). It will also be appreciated that further information, even in a virtual merge, can be added to multiple linked virtual merge contacts.

Thus, the data extractor 241 may extract contact type information from the associated data activity structure and the data merge 243 may incorporate (anonymous or identified) the contact type information into the contacts associated with the activity streams . If the contact type information I includes a primary ID field, the data merge 243 can check for related contacts based on the primary ID field value, and if found, have. The data merge 243 can also check if the activity sets the identity of the user at the site (e.g., site login activity) and if so, merge the anonymous contact with the existing contact record stored for the user , Which can now be made into the identified contact.

The contact identifier 272 may include, for example, a cookie to track a session by a single anonymous user (not logged into the site), a site login to registered users, (E. G., Email / phone) to identify two user profiles that identify the same user or via a social login for site users associated with the network. &Lt; RTI ID = It will be appreciated that methods can be implemented.

Anonymous users whose details are not registered on the site by site users stored in the contact database 245; It will further be appreciated that registered users and potential users - as well as records of potential users who have not yet officially registered on the site (imported from external sources).

Related Web sites can install persistent cookies that persist into a session in a session, so that multiple anonymous sessions that can be executed in the same browser on the same computer can continue to contribute information to the same contact record. Therefore, even anonymous users can have significant context and contact information.

Registered users must provide a unique ID for a particular site. Such as an external identifier, such as a separate site-specific ID (e.g., a user name), an external identifier such as an email, phone number or social security number, or an external identifier provided by a different system such as a social network ID, Google ID, OpenID identification, May be used.

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

Registered users should log in to the system in order to establish their identity, even though the system provides an option to "stay connected to this system". Such a login procedure may be explicit, or it may be implicit that the user invokes a login dialog, or the user needs to provide some identification details, for example, when adding a talkback to a blog, or It can be an external login base - the system invokes a login procedure that is associated with a different system, such as a social network login or an OpenID login. The login procedure may also be performed via a physical device (e.g., a security token connected to the system directly or via a wireless interface) or through the use of biometric information (e.g., a user's biometric parameters, Or iris scans as well as detection of the user's behavior, such as detection of typing patterns), or any combination of the above-described methods.

It will also be appreciated that the social login procedure can interact with regular logins in both directions. For example, the social ID may be associated with a site member ID so that the social login may implicate site login, or the site member ID may be associated with one or more social network IDs such that the site login also identifies the user to one or more social networks Lt; / RTI &gt;

When the user performs an explicit logout, the contact handler 242 generates a new anonymous user cookie and therefore opens a new anonymous session (or series of sessions) whose activities will be stored under this new anonymous contact . This new anonymous contact may be merged with a contact that is subsequently identified at the time of further login, if possible.

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

Once the same user has performed a login as user X, data merge 243 may merge the anon1 contact (and any other relevant contact data retrieved from the activity stream) into user X's contact information. It will be appreciated that the stream merge 252 can also merge the information extracted from the additional actions act4 and act5 into a single stream and the data extractor 241 can then extract the contact information of user X . When user X performs a logout, contact processor 242 may generate a new cookie and separate additional activities from user X. [ Thus, when a new activity act6 is performed, the contact processor 242 may generate a new anonymous contact anon2 and the data extractor 241 may extract its extracted contact details (and activities) Can be stored under contact anon2 of.

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

It will be appreciated that an activity data structure associated with activities may also include contact details. The data extractor 241 may extract this information and send it to the data mergeor 243 and the data mergeer 243 may integrate this information with the existing contact information in the contact database 245, have. The data extractor 241 extracts details from an external source, such as IP, from all the streams, from other contacts, or from geographical address translation services, from specific activity messages, as described in more detail below It will be appreciated more. As discussed herein, the contacts in the contact database 245 may also be explicitly provided to the website by the user as part of the registration or subscription process, or may be provided by the user when subscribing to the website (via the social login / registration feature) May include contact details that are provided by the user when extracted from a social networking account used by the user or when updating their user profile. The data extractor 241 may also retrieve contact information from an external source (e.g., when the user specifies only the US home code (zip code) When used by the site to retrieve information).

As discussed hereinabove, the contact identifier 272 may recognize two contacts as being related based on a primary ID field such as a user name, e-mail or telephone number. Once the contacts (A (new) and B (existing)) are found to be involved, data merge 243 can merge A into B (B is master). This is done using field merge rules as follows:

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

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

B1 = A + B; For example, visits, total purchases;

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

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

B1 = list-unite (B, A); Connect list A to the end of B, and remove elements within A that can overlap for the elements in B (ie, B1 = B & (A-B)). The data merge 243 may determine replicas between catalog members in accordance with the following rules:

Use regular value comparisons for lists consisting of regular values (ie scalar);

For lists consisting of structures, use specific subfields of the structure as comparison keys. For example, the address type (home, business, delivery, ...) in the website building system 30 supporting a number of addresses;

Comparison of normalized values. See (for example) the processing of telephone numbers below:

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

An upper certainty score - a value can have a certainty score assigned to it (e.g., having different positive scores for the information inferred against the user versus the information directly provided by the user). The data merge unit 243 can select a value having an upper certainty score.

It will be appreciated that some field types have a normalized format. For example, phone numbers may be normalized to a normalized US format (e.g., (999) 555-1234) or an international format (e.g., + 1-999-555-1234). The data merge 243 may convert the field values to a normalized format for comparison, such as when comparing primary contact keys (such as telephone numbers) and checking for replicas in merged lists.

The data merge unit 243 may compare two structured values having the same underlying structure-for example, an address value consisting of a number of subfields (country, state, home code, distance, number, etc.) . If each of the non-empty fields in X has the same value as each of the same fields in Y, i. E. Y contains all non-empty field values of X and possibly some additional field values, It is a detailed version of Structure X. Therefore, the data merge unit 243 can integrate A into B if A is a detailed version of B and A is not equal to B.

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

The data merge 243 may also handle tag conflicts for merged listings. It will be appreciated that when merging lists, it is possible to have a situation where there are two entities, i.e., an entity from contact A, a second entity from contact B with one and the same tag. In this scenario, the data merge 243 may merge the list by loading both entities with the same tag into the list.

Therefore, [{tag: "Assumptions", email: "a@b.com"}] + [{Tags: "Assumptions", Email: "c@d.com" Email: "a@b.com"}, {tag: "home", email: "c@d.com"}. This will be used if the merged fields are marked as "allowed unique list tags ".

Data merge 243 may also use references to external data sources or services as well as language, syntax, or other text analysis methods when attempting to integrate contact information. For example, a user may have listed his home address street name in two different ways in two activity records - but with the same home phone number, city and home code. The integrator 273 may apply a text analysis (e.g., a soundex algorithm) when comparing the two entries, and may also apply the two versions of the street names to a street name Can be compared with an external source of the. In such a case, the integrator 273 can select this authentic street name if both addresses are similar (but probably not identical) to the authentic street name and all other address data fields have appropriate values.

The data merge 243 may also merge the contact information according to login / session information. The user may use the site without performing a login or registration, start a session, perform some activities as part of and subsequent to this session, or as a login - thus creating a session with a newly created or existing registered user profile (Which may include the &lt; / RTI &gt;

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

When the user registers, the data merge 243 may use the configuration contact information to initially populate the user profile. Once the users are logged in, the data merge 243 may initially integrate the configured contact information with the existing user profile. The configuration contact information may be merged according to the user's site ID since the data merge 243 may not have any other primary IDs (such as emails) for use in the configuration contact for merging. It will also be appreciated that any such merging may expose inconsistencies in the collected information. When merging an anonymous configuration contact with existing profile data, inconsistencies can occur and become inevitable. For example, an anonymous user fills in a data form (displayed by some third party application (40)) under the name John Smith and then logs into the account under the name Jane Doe (see the same or different browser sessions using). It is possible (for example) that subsequent logins were actually done by a second person using the same computer, or that the user could use a pseudonym in the contact form to protect his / her privacy. The same can be applied when the data merge unit 243 merges a plurality of anonymous configuration contacts.

The discrepancy resolver 264 can typically process discrepancies automatically, since most fields are list fields that can contain multiple values (including primary key fields such as e-mail and telephone). This can only be applied to multiple uses of the same underlying site. Any such inconsistencies that can not be resolved (for example by merging multiple values into the list value) can be mitigated by the site owner, by the end user (which can decide which value to use) And may be flagged for possible manual processing.

Thus, it is possible that the configuration contact information reflects not only a single person but also a combination set of users accessing the same site via the same computer.

As discussed herein, data merge 243 typically merges contacts according to primary ID fields (such as e-mails and telephone numbers) whenever contacts are created or modified.

The input is a contact record (input contact C) (e.g., a contact record with two emails and three phone numbers) having one or more primary ID field (s) with one or more values. A number of primary ID fields are used when the user can have (for example) a home / work / cellular phone number and home / work emails - and the user can use any of these interchangeably in a contact form When you need it - you may need it.

The data merge 243 normalizes the primary key values and returns any value of the normalized primary key values, e.g., "(telephone = P1 or telephone = P2) or (email = E1 or email = E2) To generate a query for the containing contact record. The data merge 243 may additionally limit the query to the contact database 245 for a particular site. The data merge 243 may query the contact database 245 and retrieve the matching contact list L (including the input contact C).

If the input contact is a registered site member (of a particular site), the data merge 243 removes the contact C from the list L and merges all the remaining contacts in the list L into the contact C have. The data merge 243 may then store the updated contact C back into the contact database 245 and remove any remaining contacts in the list L from the contact database 245. [ As described herein, the data merge 234 may alternatively virtual merge, integrate all of the contact information (i.e., update all contact records to include all available information), and associate the matching contact records with the same (Instead of deleting the "duplicate " contact records). This may be necessary, for example, if third party applications 40 store or use specific internal IDs in contact records, and therefore deleting contact records will cause this third party application 40 to fail . The same process (i.e., marking contacts as being relevant rather than deleting contacts) can be applied to other cases discussed in more detail below.

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

If there is one site member (contact D), data merger 243 removes contact D from list L and sends all remaining contacts in L to contact D (including contact C) ). &Lt; / RTI &gt; The data merge 243 may then store the updated contact D back into the contact database 245 and remove all remaining contacts in the list L from the contact database 245. [

If there are more than one site member contacts D, D 1, D 2, ..., the data mergeer 243 retrieves the contacts D from the discovered site member contacts D, D 1, D 2, And remove the contact (D) from the list (L). The data merge 243 may then create a sub-list LL from the list L, which includes contacts in the list L that are not site members. The data merge 243 may then merge all the remaining contacts on the list LL into the contact D. The data merge 243 may then store the updated contact D back into the contact database 245 and remove all remaining contacts in the list LL from the contact database 245. [

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

For example, data merge 243 merges the following contacts:

Contact 1 = [Phone 1, Email 1];

Contact 2 = [Phone 1, Email 2];

Contact 3 = [Phone 2, Email 2];

This can generate a combined contact:

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

It will be appreciated that the contact database 245 may include contact information from multiple sources and with different levels of permissions for its use. The following discussion refers to emails; However, these discussions and techniques apply to any type of information used to contact the user (phone, fax, Skype ID, instant messaging ID, social network ID, etc.) as mentioned above.

For example, the manner in which an email address was provided to a site may indicate different permissions for its own use. Some possible sources for email addresses are registration ID; Contact forms, newsletter subscriptions and subscription cancellation requests. Email addresses may be different in terms of an "allowed user agreement" electronically signed by the user.

It will be appreciated that the website building system 30 typically has information about allowed uses for a given e-mail. However, the website owner may be different, for example because of the nature of the different subscription forms within the site, or because the contacts in the system are imported from different sources including additional usage information by the website, Information.

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

Thus, a contact record for an associated contact may contain two fields of information. The first field is a website permission field that includes derivations or suggested permissions calculated from user activity by the website. A contact form only implies a functional email, while a subscriber form can imply recurring emails. The second field is a site owner permission field based on the website permission field value. The site owner can change the website recommendations and do whatever they like, but he is responsible for any use beyond the permissions specified by the website permission field.

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

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

Unknown - E-mail has been extracted from unknown sources and can not be used for any e-mail transmission.

Email ID - Email provided for registration purposes. This can not be used for any e-mail transmissions, except registration problems, such as registration confirmations, unrecognized passwords, and suspected security breach notices.

Features Email - Provides for specific functions and allows one-time emails. For example, a purchase confirmation email or an email provided for a particular contact form.

Repeat email - Allows multiple and periodic subscriptions and ads to be sent by a particular website. This requires explicit subscription / approval.

Shareable email - Allows multiple and periodic subscriptions and ads to be sent by their partners (third party applications 40, fourth parties) as well as the website. This may require explicit subscription / authorization and may include detailed information about the allowed shares.

Opt out - The user explicitly unsubscribed. No e-mails can be sent to the user (except for possible escape notices).

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

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

The advantages of such a system include not only the non-essential spamming of users, but also better protection (both technical and legal) from misuse of personal information - both for the website and the website owner - And the ability to actually enforce the privacy policy when used with the personal data proxy 234 as described above. This can also ensure that subscription cancellation requests are enforced more stringently.

Thus, the user can generate a stream of activities between the relevant website building system 30 and any of the associated third party applications 40. These streams may be known as activity streams. Each activity stream can be used as an informatin source for a single contact. The activity data structure of the individual streams may also be merged to form a contact if it can be determined that the different activity streams are from the same source. For example, a single user can work anonymously through two devices, such as a mobile device and a personal computer. Such a user may create two anonymous streams from which messages may be stored. Once the streams have been identified as being associated with the same user, they may be merged.

The processes and displays presented herein are not implicitly associated with any particular computer or other device. A variety of general purpose systems can be used with programs in accordance with the teachings herein or it may prove convenient to construct more specialized devices to perform the desired method. From the above description, the desired structure for a variety of these systems will emerge. In addition, embodiments of the present invention are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.

As is apparent from the foregoing discussions, discussions utilizing terms such as " processing, "" computing," " calculating, " As well as to manipulate and / or manipulate data represented in physical quantities within registers and / or memories of a computing system or to store such data in memory, registers or other such information storage, transmission or display devices Quot; refers to the acts and / or processes of a computer, computing system, or similar electronic computing device that transforms data into other data similarly represented as physical quantities within the computing system.

Embodiments of the invention may include apparatus for performing operations herein. The apparatus may be specially configured for desired purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored on the computer. Such a computer program may be stored in a computer readable storage medium, such as, for example, floppy disks, optical disks, any type of disk including magnetic optical disks, read-only memory (ROM) (CDROM), random access memory (RAM), electrically programmable ROM (EPROM), electrically erasable and programmable read only memory But are not limited to, electrically erasable and programmable ROM (EPROM), magnetic or optical cards, flash memory or any other type of medium suitable for storing electronic instructions and capable of being coupled to a computer system bus Do not.

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

Claims (24)

A system that can be implemented on a web site via a client / server system having at least one processor, the processor processing instructions defining the system, the system comprising:
At least one activity message for coordinating at least one activity message between the website and at least one third party application, the at least one activity message having a standardized format, ;
An activity coordinator that listens to the at least one activity message and at least adds data extracted from the at least one message to a stream associated with at least one of an identified contact and an anonymous contact, activity coordinator, wherein the at least one of the identified contact and the anonymous contact is a user of the website;
A contact coordinator for retrieving and analyzing contact related information from the stream and enriching previously held information for the contact; And
And at least one database for storing the activity streams and the contact related information for use by the website and by the contact. The method according to claim 1,
Wherein the at least one hub comprises:
A router and a tracker for routing and tracking the at least one activity message between the website and the at least one third party application;
A private policy enforcer that enforces a privacy policy between the web site and the at least one third party application;
A translator and an adapter for applying at least one message conversion and content adaptation rules pre-specified between the website and the at least one third party application;
A personal data proxy that implements at least one of a personal data proxy and personal data replacement and enforces user permission field restrictions between the web site and the at least one third party application; And
Verifying the signature of the at least one activity message using an incoming key of the at least one third party application and translating an external ID associated with the at least one activity message having an internal website ID A verifier for signing the at least one activity message fetched using an outgoing key of the at least one third party application,
&Lt; / RTI &gt; The method according to claim 1,
The activity coordinator comprising:
A stream generator for identifying said contact associated with said at least one activity message and for generating a stream of said data if an associated contact is not present;
A stream merger that merges data from the at least one activity message into an existing stream and data from at least two of the activity streams into a single stream; And
A log creator for logging activity data from the activity stream to the at least one database,
&Lt; / RTI &gt; The method according to claim 1,
The contact regulator comprising:
A data extractor for extracting contact related information from at least one of the at least one activity message, the stream, other contacts and external sources;
Merging at least two contact information records, wherein the records have associations with the same identified contacts, and a data merge module that merges the extracted contact related information with information about an existing contact according to predefined merge rules ;
A contact processor for generating at least one of an identifiable new contact and an anonymous contact and tracking contact activity during the session of the website; And
Data and permission handlers for handling privacy protection and permissions of the extracted contact-related information
&Lt; / RTI &gt; 3. The method of claim 2,
Wherein the router and the tracker support routing of the at least one activity message using auditory queries specified by the at least one third party application. The method of claim 3,
The stream merger includes an activity-to-stream merger that merges the data into the stream associated with the identified contact, and a stream-to-stream merger that merges the at least two separate streams into a single stream. . The method according to claim 6,
The stream-to-stream merger includes: a horizontal stream merger that merges the at least two distinct streams according to the identified common contact, and a stream associated with the stream generated for the anonymous contact and a stream associated with the registered contact user And a vertical stream merger that merges a stream created for the anonymous contact upon login or upon login with a stream associated with the registered contact user. 5. The method of claim 4,
The data mergeer comprises:
Finding the location of the same primary ID field values in at least two of the contact information records, finding the location of the primary key field values in at least two of the same contact information records when normalized, Identifying a site user using a site login to registered users, and identifying a site user via a social login to site users having an account associated with a social network A contact identifier;
An integrator for integrating contact information using at least one of language, syntax, text analysis, and consultation with external data sources and services;
A contradiction resolver that resolves discrepancies between contact records according to predefined rules;
A list value generator for generating list value fields for defining a clear priority between the contact records;
A horizontal contact merge that merges two unrelated contacts due to the detected common primary ID; And
At the time of registration or at the time of login to connect an anonymous contact and a contact associated with a registered user, a vertical contact merge that merges the anonymous contact with the contact associated with the registered user
&Lt; / RTI &gt; 9. The method of claim 8,
Wherein the horizontal contact merge comprises a virtual merge that maintains at least two contact records separately and links the at least two contact records with each other such that the at least two contact records are represented as representing the same contact. 9. The method of claim 8,
Wherein the anchor contact and the contact associated with the registered user are maintained separately and the anonymous contact and the contact associated with the registered user are marked as representing the same contact, And a virtual merge that links the contacts associated with the registered user to each other. 3. The method of claim 2,
Wherein the user permission field is at least one of the determined website and the determined website owner. The method according to claim 1,
The standardized format may be defined by a predefined schema, inheritance, a call back link, by the at least one third party application, or by an external formal industry or de facto standard And is encoded and defined on a per-channel basis. A method implementable on a website via a client / server system having at least one processor, the processor processing instructions defining the method, the method comprising:
Adjusting at least one activity message between the web site and at least one third party application, the at least one activity message having a standardized format;
Listening to the at least one activity message and at least adding data extracted from the at least one message to a stream associated with at least one of an identified contact and an anonymous contact, wherein at least one of the identified contact and the anonymous contact One is the user of the website, the listening and adding step;
Retrieving and analyzing contact related information from the stream, and enhancing previously held information for the contact; And
Storing the activity streams and the contact-related information for use by the website and by the contact. 14. The method of claim 13,
Wherein the adjusting comprises:
Routing and tracking said at least one activity message between said website and said at least one third party application;
Enforcing a privacy policy between the web site and the at least one third party application;
Applying at least one message transformation and content adaptation rules pre-specified between the website and the at least one third party application;
Implementing at least one of a personal data proxy and personal data replacement and enforcing user permission field restrictions between the web site and the at least one third party application; And
Verifying the signature of the at least one activity message using a pull key of the at least one third party application, transforming an external ID associated with the at least one activity message having an internal website ID, Signing the at least one activity message to be retrieved using a retrieval key of one third party application
&Lt; / RTI &gt; 14. The method of claim 13,
The listening and adding step comprises:
Identifying the contact associated with the at least one activity message and generating a stream of the data if an associated contact is not present;
Merging data from the at least one activity message into an existing stream and data from at least two of the activity streams into a single stream; And
Logging activity data from the activity stream to the at least one database
&Lt; / RTI &gt; 14. The method of claim 13,
The searching and analyzing is:
Extracting contact-related information from at least one of the at least one activity message, the stream, other contacts, and external sources;
Merging at least two contact information records, the records having an association with the same identified contact, and merging the extracted contact related information with information about an existing contact according to predefined merge rules;
Generating at least one of an identifiable new contact and an anonymous contact and tracking contact activity during the session of the website; And
Processing the privacy protection and permissions of the extracted contact-related information
&Lt; / RTI &gt; 15. The method of claim 14,
Wherein the routing and tracking step supports routing of the at least one activity message using auditory queries specified by the at least one third party application. 16. The method of claim 15,
Wherein merging comprises merging the data into the stream associated with the identified contact and merging the at least two separate streams into a single stream. 19. The method of claim 18,
Merging the data into the stream associated with the identified contact and merging the at least two separate streams into a single stream comprises merging the at least two distinct streams horizontally according to the identified common contact And a stream that is created for an anonymous contact and a stream that is associated with a stream associated with a registered contact user, or a stream that is created for the anonymous contact upon login to a stream associated with the registered contact user &Lt; / RTI &gt; 17. The method of claim 16,
Wherein merging the at least two contact information records comprises:
Searching for the location of the same primary ID field values in at least two of the contact information records, finding the location of the primary key field values in at least two of the same same contact information records when normalized, Identifying a site user using a site login for registered users, and identifying a site user via a social login for site users having an account associated with the social network;
Integrating the contact information using at least one of language, syntax, text analysis and reference to external data sources and services;
Resolving inconsistencies between contact records according to predefined rules;
Generating list value fields for defining a clear priority between the contact records;
Merging two unrelated contacts horizontally due to the detected common primary ID; And
Merging the anonymous contact vertically with a contact associated with the registered user upon registration or login capable of associating an anonymous contact and a contact associated with the registered user
&Lt; / RTI &gt; 21. The method of claim 20,
The horizontally merging includes virtual merging to maintain at least two contact records separately and linking the at least two contact records to each other such that the at least two contact records are represented as representing the same contact How to. 21. The method of claim 20,
Wherein the vertically merging includes merging virtual contacts to maintain an anonymous contact and a contact associated with the registered user separately, and wherein the anonymous contact and the contact associated with the registered user are marked as representing the same contact And linking the anonymous contact and the contact associated with the registered user. 15. The method of claim 14,
Wherein the user permission field is at least one of the determined website and the determined website owner. 14. The method of claim 13,
The standardized format is at least one of being defined by a predefined schema, an inheritance, a callback link, and being defined and encoded by the at least one third party application or based on an external formal industry or de facto standard How, one.

Images