JP6746746B2 - Systems and methods for websites - Google Patents

Description

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

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

These website building systems are provided in various forms, for example hosted on one or more servers connected to the Internet and using Internet communication protocols such as HTTP (Hypertext Transfer Protocol). Such as a fully online website building system that is accessed. Creation, editing, and deployment of these website building systems are all performed by direct online operations by the server.

The website building system can be partially online or completely online. For partially online systems, website editing is performed locally on the user's machine and later uploaded to a central server or servers for deployment. Once websites are uploaded, these website building systems function in the same way as fully online website building systems.

A website construction system has an internal data architecture for the purpose of organizing the data and elements within the system. This architecture may differ from the appearance of the target site as seen by the user, and may also differ from the way standard HTML (Hypertext Markup Language) pages are sent to the browser. For example, the internal data architecture may include additional properties for each element on the page, such as author, creation date, permissions, links to templates, etc., and these additional properties may be used by the website building system. Indispensable for editing and maintaining the site internally, but invisible to external end users (and in some cases editing some users). The general architecture of a site based on a website building system can consist of pages containing components such as shape components, photo components, text components, as well as single-page and multi-page containers containing minipages. it can.

A component can be contentless, such as a star with no internal content (but with color, size, position, and other attributes), or it can have internal content, such as a text paragraph component, The internal content of such components includes the text to be displayed as well as font, format, and layout information. Of course, this content can vary for each text paragraph component.

Designers using such website building systems can either design a new site from scratch (starting with a blank screen) or pre-defined by the designer himself, the system creator or a community of designers. You can use the created application template. A website building system can support templates that are simply collections of components, templates that are complete pages (or minipages) or series of pages, and templates that are complete websites.

When a template for an application is provided, the designer is free to customize it and add, remove, or modify all the elements of the template to create his own version of the template. Such customization can be performed by creating a modified version of the template (a separate version different from the template). Alternatively, the website construction system can apply the customization through an inheritance-type mechanism, which keeps the link to the original template, and hence the template later. The changes are reflected.

Further, the website building system can be extended with third party applications and components embedded therein. Such third party applications may be included in the design environment of the website building system, or through various distribution mechanisms, such as from an application store (AppStore) that is embedded in the website building system, or It can be purchased (or otherwise obtained) separately from a web-based or independent application repository (or AppStore) operated by a website building system (WBS) vendor or another organization. Further, the third-party application may also be obtained directly (through or without AppStore) from the third-party application vendor, in which case the vendor provides the actual installation module, or the activation or access code. Provide only.

Third party applications may include any combination of front end (display) elements and back office elements, which are not displayed on the website. The third-party application may be wholly back-office (i.e. without display elements) or wholly front-end (i.e. launched only when used on a website), or a combination of the two. is there.

The back office elements of the third party application may include features such as database communication options and external update options. For example, blog third-party applications may include sources other than people (eg, RSS news distribution from a major news service) and sources not related to the website (eg, standalone blog entries that can be posted. Back office elements that can receive updates (from smartphone applications).

The process of incorporating the visual elements of a third party application into the website in which they are included can be done in a variety of ways. Widget-type third-party applications can be embedded as components inside the pages of a website, while section-type third-party applications can be added to a website as one or more additional pages. ..

Furthermore, the third-party application (both widget type and section type) can be a single-page third-party application or a multi-page third-party application (with internal mini-pages represented as an internal URL structure). .. The system can implement one or more, or all, of four possible combinations (widgets or sections, single page or multipage).

Multi-page third-party applications usually provide a default "landing" mini-page, which can be an opening page, a specific internal mini-page (eg the latest blog entry in a blog's third-party application), a mini-page. A page selection screen or other mini page.

Use of third party applications in websites based on the website building system is through instances of the third party applications. The website building system can support multiple usages of third party applications at multiple levels, eg, multiple third parties inside the website, allowing one instance of the third party application throughout the website. Allow creating instances of party applications (but only one instance per third party application), Allow creating multiple instances of multiple third party applications (but only one instance per page) ) Is mentioned. In addition, you can allow multiple instances per page for component-type third-party applications (not section-type third-party applications), and also, without restrictions on the number, multiplicity, or location of instances of third-party applications. You can also allow multiple instances of multiple third-party applications to be created.

Instances of third-party applications can have content that is unique to the instance. For example, an online shop (e-Shop) third-party application may have a product database associated with a particular instance, which product database may be a third party of the same online shop (in the same site or another site). Different from the product database that is associated with another instance of the application.

For purposes of explanation, a website page (or minipage) that includes a third-party application and its minipages or elements (ie, a "wrapper page") shall be referred to as a containing webpage, and shall be referred to as the entire website. It is assumed to be known as the main site. The integrated page presented to the user (including the main page and embedded TPA minipages/components) is referred to as the composite page. For section-type third-party applications, the "virtual page" containing the third-party application acts as the containing web page.

The third party application is typically deployed on the vendor's server of the website building system, on the vendor's server of the third party application, on an external (force party) server, or on any combination of these servers. A third-party application may be an element that actually executes on the end user's machine (eg, a statically installed browser extension, or dynamically inside the client-side code of a website building system as shown in Figure 1). Javascript (registered trademark) component that is executed in the above). In the following, reference is made to FIG.

The website building system vendor's server acts as a contact point for the end user and responds to the request (possibly connecting to the third party application vendor's server to receive the required information). The website building system can form a direct connection (if desired) between the client computer and the third party application vendor's server, for example when video streaming is required.

Instances of contained third-party applications can have their own internal content, just as regular components do. Referring to FIG. 2, as shown in this figure, a third-party application may manage this content independently of the website building system and the websites created using the website building system. it can. Multiple instances of one or more third-party applications can have shared content, eg, two online shop instances on two separate website pages can reference the same product database.

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

Server-side processing: (See FIG. 3 below.) In this method shown in FIG. 3, the third-party application [a] (including the design element and the display element) and the user-specific third-party application The data [b] is merged by the server code [c] of the third-party application running on the server [d] of the third-party application vendor. These are sent to the server code [f] of the website construction system via the communication medium [e], and the server code [f] merges these with the information [g] of the containing web page, and then merges them with the user's information. Send so that it can be displayed on the client station [h].

Client-side processing: (See FIG. 4 below.) In this method shown in FIG. 4, the third-party application [a] (including design elements and display elements) and the user-specific third-party application The data [b] is merged by the server code [c] of the third-party application running on the server [d] of the third-party application vendor. These are sent to the processing component [h] on the client side via the communication medium [e]. The server code [f] of the website construction system sends the information [g] of the contained web page to the processing component [h] on the client side. The client-side processing component [h] performs a merge of the two sources and presents the integrated application to the browser (or other client agent) [i].

iFrame Inclusion: (See FIG. 5 below.) In the method shown in FIG. 5, a third party application [a] (including design and display elements) and a third party application specific to the user are included. Data [b] of the third party application is merged by the server code [c] of the third party application running on the server [d] of the vendor of the third party application. These are sent via a communication medium [e] to a browser-based application [h] running inside a user agent (eg a web browser) [i]. The server code [f] of the website construction system sends the information [g] of the contained web page to this browser-based application [h]. The containing web page is created as a web page that includes one or more iframe directives that include content from the server [d] of the third party application. Additional and alternative methods are also applicable.

U.S. Patent Application Publication No. 2013/0219263

According to a preferred embodiment of the present invention, a system implementable on a website via a client/server system, the client/server system comprising at least one processor for processing the instructions defining the system. System. The system is at least one hub for coordinating at least one activity message between a website and at least one third-party application, the at least one activity message having a standardized format. Including a hub. Further, the system listens for at least one activity message and adds at least data extracted from the at least one message to a stream associated with at least one of the identified contact and the anonymous contact, an activity coordinator. At least one of the identified contact and the anonymous contact includes an activity coordinator, who is a user of the website. In addition, the system retrieves and analyzes contact-related information from the stream to enhance the quality of previously held information for the contact, as well as the activity coordinator and the contact stream for use by websites and contacts. At least one database for storing information.

Furthermore, according to a preferred embodiment of the invention, the at least one hub is a router/tracker for routing and tracking at least one activity message between the website and the at least one third party application. , A privacy policy enforcer that enforces a privacy policy between the website and the at least one third-party application, and at least one pre-specified message conversion/content adaptation between the website and the at least one third-party application. User field between the website and at least one third-party application that implements at least one of a private data proxy and a private data replacement, and a translator/adapter that applies the emulation rules. A private data proxy that enforces the restrictions of at least one activity message, validates the signature of the at least one activity message using an input key of at least one third party application, and is associated with at least one activity message external At least one of a verifier/signer that transforms the ID using the internal website ID and signs at least one activity message sent using the output key of at least one third party application. Including one.

Further in accordance with a preferred embodiment of the present invention, the activity coordinator identifies a contact associated with at least one activity message and creates a stream of data if there is no associated contact and a stream creator and at least one Merge data from one activity message into an existing stream, merge data from at least two of the activity streams into one stream, record stream merger and activity data from the activity stream into at least one database And at least one of:

Further in accordance with 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, another contact, external source, and at least 2. A data merger that merges two contact information records and merges the extracted contact related information with the related information of existing contacts according to predefined merge rules, where the records are the same as the identified contact. A contact handler and extracted contact-related information that creates data mergers and/or new and/or anonymous identifiable contacts that track contact activity during a website session And/or at least one of: a data/authorization handler that handles privacy protection and authorization of the.

Further, according to a preferred embodiment of the present invention, the router/tracker supports routing at least one activity message using a listening query specified by at least one third party application.

Further in accordance with a preferred embodiment of the present invention, the stream merger merges data into a stream associated with the identified contact, an activity-to-stream merger, and at least two separate streams. Stream-to-stream merger, which merges into one stream.

Furthermore, according to a preferred embodiment of the present invention, the stream-stream merger merges at least two separate streams according to the identified common contact, a horizontal stream merger, an anonymous contact and a registration. A vertical stream merger that merges streams created for anonymous contacts with streams associated with registered contacts when they are tied together at login or registration. And at least one of

Further, according to a preferred embodiment of the present invention, the data merger is normalized in at least two of the contact information records identifying the same primary ID field value in at least two of the contact information records. Identify the primary ID field value that is the same when you use, use cookies to identify site users, and if you are a registered user use site login to identify site users, to social networks A contact identifier that performs at least one of identifying a site user through social login in the case of a site user who has an associated account. In addition, the data merger uses at least one of linguistic analysis, syntactic analysis, and text analysis and reference/use of external data sources and external services to combine contact information between a combiner and a contact record. A common primary ID was found, with a conflict resolver that resolves conflicts according to predefined rules, and a list value creator that creates list value fields and defines a clear priority among contact records. This allows a horizontal contact merger that merges two unrelated contacts, an anonymous contact, and a contact associated with a registered user when they are linked at login or registration. , A vertical contact merger that merges anonymous contacts into contacts associated with registered users.

Further, in accordance with a preferred embodiment of the present invention, the horizontal contact merger maintains at least two contact records as separate records, two contact records being shown to represent the same contact. Includes a virtual merger, which links records together.

Further, according to a preferred embodiment of the present invention, the vertical contact merger maintains anonymous contacts and contacts associated with registered users as separate contacts and associates them with anonymous contacts and registered users. Virtual mergers, which are linked to each other so that the contacts that are represented represent the same contact.

Further, according to a preferred embodiment of the present invention, the user permission field is determined by the website and/or the website owner.

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

According to a preferred embodiment of the invention, a method implementable on a website via a client/server system, wherein the client/server system comprises at least one processor for processing the instructions defining the method. Method. The method comprises coordinating at least one activity message between a website and at least one third party application, the at least one activity message having a standardized format, and at least one Listening for activity messages and at least adding data extracted from these at least one message to a stream associated with at least one of the identified contact and the anonymous contact, the identified contact and the anonymous contact At least one of the contacts is a user of the website. In addition, the method obtains and analyzes contact-related information from the stream to enhance the previously held information of the contact and the activity stream and contact-related information for use by the website and contact. Storing, and.

Furthermore, according to a preferred embodiment of the present invention, the step of coordinating comprises the steps of routing and tracking at least one activity message between the website and the at least one third party application, and the website and at least one third party. Enforcing a privacy policy with the application, applying at least one pre-specified message conversion/content adaptation rule between the website and the at least one third party application, and a private data proxy. And/or private data substitution to enforce user permission field restrictions between the website and at least one third party application, and at least one activity message signature to at least one Verify using an input key of a third party application, convert an external ID associated with at least one activity message using an internal website ID, and send at least one activity message with at least one third party And/or signing with the output key of the application.

Further, in accordance with a preferred embodiment of the present invention, listening and at least adding comprises identifying a contact associated with at least one activity message and creating a stream of data if the contact does not exist. Merging data from one activity message into an existing stream, merging data from at least two of the activity streams into one stream, and recording the activity data from the activity stream in at least one database. And at least one of:

Further in accordance with a preferred embodiment of the present invention the steps of obtaining and analyzing include extracting contact related information from at least one of at least one activity message, stream, another contact, external source, and at least Merging two contact information records and merging the extracted contact related information with the related information of an existing contact according to a predefined merge rule, wherein the records are associated with the same identified contact. At least one of the steps having relevance. In addition, the steps of retrieving and analyzing create at least one identifiable new contact and/or anonymous contact, tracking the activity of the contact during the website session and privacy protection of the extracted contact-related information. And processing the authorization.

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

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

Furthermore, in accordance with a preferred embodiment of the present invention, the steps of merging data into streams associated with identified contacts and merging at least two separate streams into one stream combine at least two separate streams. , A horizontally merging step according to the identified common contacts, an anonymous contact and a registered contact are created for anonymous contacts when they are tied at login or registration. Vertically merging the stream to a stream associated with the registered contact.

Further in accordance with a preferred embodiment of the present invention, the step of merging at least two contact information records comprises identifying the same primary ID field value in at least two of the contact information records, Identifying the primary ID field value that is the same when normalized, of at least two, using cookies to identify site users, and using registered site users for site login Identifying the site user through a social login if the site user has an account associated with a social network. Further, the step of merging at least two contact information records combines the contact information using at least one of linguistic parsing, parsing, and text parsing and referencing/using external data sources and services. To resolve inconsistencies between contact records according to pre-defined rules, create list value fields to define clear priorities between contact records, and detect common primary IDs By doing so, the step of horizontally merging two unrelated contacts, the anonymous contact, and the contact associated with the registered user are linked to each other at the time of login or registration. Vertically merging contacts with contacts associated with registered users.

Further, according to a preferred embodiment of the present invention, the step of horizontally merging maintains at least two contact records as separate records, as shown by the two contact records representing the same contact. Linking two contact records together and virtual merging.

Further, according to a preferred embodiment of the present invention, the vertically merging step maintains the anonymous contact and the contact associated with the registered user as separate contacts, and the anonymous contact and the registered user Linking and virtually merging the contacts associated with each other such that they represent the same contact.

Further, according to a preferred embodiment of the present invention, the user permission field is determined by the website and/or the website owner.

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

The subject matter regarded as the invention is particularly pointed out and distinctly stated in the concluding portion of the specification. However, a deep understanding of the present invention, both with respect to its organization and method of operation, as well as the objects, features, and advantages of the present invention, will be obtained by reading the following detailed description with reference to the accompanying drawings. You can

Schematic diagram of deployment configuration between website building system and third party applications Schematic of internal content management for third-party applications Schematic diagram of including third party application in contained web page by server side processing Schematic diagram of including third-party application in contained web page by client side processing Schematic diagram of including a third-party application in the containing web page by including iframe Schematic view of existing non-optimal third-party applications when changing page layout Schematic diagram of a system that integrates a website building system with one or more third-party applications, constructed and operative in accordance with the present invention. Schematic diagram of a system that integrates a website building system with one or more third-party applications, constructed and operative in accordance with the present invention. Schematic representation of the document object model compared to the component model Schematic diagram of an example of a multipart third-party application for a blog Schematic diagram of an example modular third-party application for sale Schematic diagram of different implementations of a communication hub constructed and operative in accordance with the invention. Schematic diagram of different implementations of a communication hub constructed and operative in accordance with the invention. Schematic representation of elements of the communication hubs of FIGS. 11A and 11B constructed and operative in accordance with the present invention. Schematic diagram of a communication conversion process performed by the communication hubs of FIGS. 11A and 11B constructed and operative in accordance with the present invention. Schematic diagram of a contained web page handling a third party application with associated templates constructed and operative in accordance with the present invention. Schematic diagram of a contained web page that includes a third-party application inside an minipage with an associated template constructed and operative in accordance with the invention. Schematic diagram of a system constructed and operative in accordance with the present invention for coordinating and collecting data from various messages exchanged between a website construction system and one or more embedded third party applications. 15 is a schematic diagram of elements of the system of FIG. 15 constructed and operative in accordance with the present invention. 15 is a schematic diagram of elements of the system of FIG. 15 constructed and operative in accordance with the present invention. 15 is a schematic diagram of elements of the system of FIG. 15 constructed and operative in accordance with the present invention. 15 is a schematic diagram of elements of the system of FIG. 15 constructed and operative in accordance with the present invention. Schematic diagram of an example of a graphical user interface displaying activity streams associated with contacts, constructed and operative in accordance with the present invention. Schematic diagram of message-passing activity messages for client-side and server-side third-party applications Schematic diagram of login/logout processing during a user's website session

It should be understood that the elements shown in the figures are not necessarily drawn to scale for the sake of brevity and clarity. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Furthermore, where considered appropriate, corresponding or similar elements have been designated by the same reference numeral in the several figures.

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, one of ordinary skill in the art will appreciate that the invention may be practiced without these specific details. Furthermore, well-known methods, procedures, and components have not been described in detail so as not to obscure the present invention.

Applicants have found that there are many limitations to the current way in which third party applications are generally integrated into website building systems and the way in which integrated third party applications interact with website building systems. Recognized.

Such restrictions include limiting the display of the third-party application to one rectangular area inside the containing web page, which area is included in the iframe. As a further limitation, the size and position of the window of the third-party application and visual elements that are outside the actual display window of the third-party application (for example, a dedicated display frame around the window of the third-party application) may be The ability to control.

The third party application may have its own display style (color scheme, font, font size, etc.). These styles are compatible with some contained web pages, but may be visually problematic or inconsistent with other contained web pages.

Another limitation is the inflexibility of displaying third party applications from the perspective of the containing site. If you need to visually modify your site (for example, to deploy on platforms with different screen sizes, or due to a dynamic layout event), change the size of the window assigned to the third-party application. May be required for contained web pages. In such a case, the display of the third party application is cut off in the middle and scrolling via the scroll bar is required to reach the various sub-areas in the third party application. Referring to FIG. 6, this figure shows an example of a situation that can occur when resizing the containing web page [a]. The space allocated to the online shop's third-party application [b] is reduced and the "Buy" button [c] cannot be displayed with the contents of the shopping cart [d], so to complete the purchase Several scrolling operations are required, greatly reducing the chances of the actual purchase being completed.

It should be appreciated that a third party application may not be able to interact with another component within the containing web page, and such interaction may be required to achieve complex functionality. In particular, third-party applications cannot perform different actions depending on the type and content of components within the containing web page. One example of this is a website streaming an online cooking class. The user wants to display a small screen area dedicated to delivering the latest news and weather information (for example, a live stream from CNN) in another area of the screen in the background of watching a video. There is. A user may wish to have a learning session automatically paused when the weather forecast for his area begins.

Furthermore, there is no clear and standard way for these third-party applications to cooperate with each other, especially if the third-party applications are provided by different vendors. Therefore, designers have no clear way to combine multiple third-party applications from different vendors. One example of this is in the case of an e-commerce website that implements modules of a third party ordering system and different modules of a shipping system. It may be desirable to order merchandise according to a shipping schedule or the like.

Applicant has structured both the website construction system and the third party application instances contained therein and between different third party application instances that may be implemented within the same containing page. We have recognized that this integration can be achieved by using a directional communication channel. These channels can also transfer information regarding layout, style, and additional information.

The following discussion focuses on the iframe inclusion method, which is the preferred method because it is built into or integrated into modern browsers and does not require you to write your own integration code. I want you to understand. In addition, the iframe inclusion method provides the encapsulation and sandboxing features supported by the browser, as well as inherent protection against hacking techniques such as cross-site scripting attacks that can be adopted by malicious third-party applications. It

7A and 7B, which show a system 100 that integrates a website building system with one or more third party applications, according to embodiments of the invention. FIG. 7A shows the system 100 at the design stage, and FIG. 7B shows the system 100 at run time. As can be seen in FIG. 7A, system 100 is installed on a client 10, a website building system 30 installed on a website building system (WBS) server 20, and one or more third party application servers 50. And one or more third party applications 40 that are installed. The website construction system 30 includes a WBS coordinator 21, an application repository 22, a WBS side TPA property sheet 23, a third party application (TPA) coordinator 24, and an AppStore 25 (which may include a searcher 26). There is. The client 10 includes a page composer 12 and a client-side display of the TPA property sheet 23. In some embodiments, the client 10 may further comprise an AppStore 25 client-side display. The page composer 12 includes a linker 13, which will be described in more detail later. The third party server 50 includes a third party application 40, an external TPA coordinator 51, and a TPA database 52, and the TPA database 52 stores components and templates of the third party application 40 so that they can be used. .. It should be noted that the system 100 may include multiple third party servers 50 belonging to multiple vendors of the third party application 40.

It should be appreciated that the TPA property sheet 23 can be invoked when the attributes of an instance of the third party application 40 are specified. Further, it should be appreciated that when called, the TPA property sheet 23 is displayed on the client 10 as a client-side display of the TPA property sheet 23. Further, it should be appreciated that the offline embodiment may have its own property sheet as part of the client software installed, and thus there is no application TPA property sheet 23 or repository.

A designer or end user 5 sitting in front of the client 10 creates website pages and interactions (inter-page and intra-page interactions) using the page composer 12 to create his own website (inter-page and intra-page interactions). Or other online applications) can be created. The designer 5 can select, via the WBS coordinator 21, components, templates, etc., which are stored in the application repository 22 and are a part of the website construction system 30. Further, the designer 5 can create a contained web page 203 that embeds a third party application 40 instance from the third party application 40, which can be pre-purchased, such as its templates and components. It can be stored in the repository 22. In an alternative embodiment, purchased templates, components, etc. may be stored in the TPA database 52 and accessed via the external TPA coordinator 51. In yet another embodiment, templates, components, etc. of the third party application 40 can be purchased via AppStore 25 as needed. The property sheet 23 can be specified by the designer 5 and can hold information about the purchased instance of the third party application 40 (permissions, installation guides, payments, etc.), as described in more detail below. Furthermore, the designer 5 can use the linker 23 to manually specify the communication channel (if necessary) between the included third party applications 40. Further, it should be appreciated that the designer 5 can use the linker 23 to specify unique communication connections and rules between the containing web page that it is building and the instance of the third party application 40 that it contains. (Videos and CNN news reports are displayed simultaneously as described above). It is to be understood that the links created by the linker 23 can be modified as long as the website is alive.

It should be appreciated that the designer 5 may obtain the third party application 40 through a channel external to the AppStore 25, such as an external AppStore operated by a vendor of the third party application 40 or an external vendor. In such a case, when the website building system 30 first installs the third party application 40 on the website created by the designer 5 through the website building system 30, the third party application 40 and its configuration data (configuration). data) can be registered.

In order to allow the linker 23 to establish a communication channel when needed, the third party application 40 may have a component (including an instance of another third party application 40) within the containing web page 203 (that it is trying to communicate with). It is to be understood that (including) must be correctly recognized and identified. In the case of associated template-based components (discussed in more detail below), this identification is pre-performed by the vendor of the third party application 40. The components in the associated template can be given unique reference IDs and the third party application 40 can use these IDs when communicating with these components.

Furthermore, in the case of a multi-part third-party application 40 (which will be described in more detail below) (ie, one third-party application 40 distributed across multiple iframes), multiple parts will automatically know how to communicate with each other. Please understand that

For components of the containing website page (discussed in more detail below) that are not included in the associated template, the third party application 40 is required (required or required) to be present for it to function. A) of the containing web page 203 components. This list can be stored in the property sheet 23 and contains a unique ID, description, and component details (eg, used as a blog talkback label, which must be a text component). Can be included. This list can be listed in the entry of the third party application 40 to the AppStore 25, and the designer 5 uses the linker 23 to identify the components (fields) in the containing web page 203 that meet the requirements of the third party application 40. Can be specified. The website construction system 30 can dynamically create the missing components of the containing web page 203 when an instance of the third party application 40 is created, and the designer 5 will later create these components. It should be appreciated that it can be moved, resized, and fully specified.

Alternatively, the website construction system 30 can expose the whole or a part of the component model of the contained web page 203 to the third party application 40 included in the contained web page 203. It should be appreciated that the component model in this case is the component model of the containing web page 203, not the Document Object Model (DOM). The Document Object Model (DOM) of the containing web page 203 may be a much more complex and detailed model than the component model because the actual containing web page 203 is part of the infrastructure of the website building system 30. Or a huge number of HTML elements (both hidden and visible elements) that support the components of the containing web page 203 may be included. Therefore, the component model is much simpler.

Next, referring to FIG. 8, FIG. 8 shows a plurality of HTML constructs (div tag [b] surrounding a part, internal div tag [c], frame “mini-widget” [d1]... [d5], etc.). Shows how to implement a text component [a] using. The DOM model [e] of the containing web page 203 can include a separate DOM tree node for each of these sub-elements. The component model [f] can be much simpler and contains only one component node [g].

The system 100 may also support selective component publishing, allowing the designer 5 to specify via the linker 23 which components should be exposed to the third party application 40, and these components (in case It should be appreciated that some may only include the "containment path" leading to these components) in the simplified component model visible to the third party application 40. This designation can be performed by explicitly marking the included components according to their type and other attributes of the website building system 30. This allows the third party application 40 to follow the component model of the containing web page 203 to identify the required component.

In addition, a link (eg, a broadcast link) between the containing web page 203 and an instance of the third-party application 40 may be automatically created, where the third-party application 40 may communicate at run time to identify a particular link. It should be understood that the event of can be recorded. This communication may be optional or mandatory (ie the third party application 40 will not work or install unless there is a corresponding third party application 40 linked to receive such messages). ). For example, the third party application 40 can broadcast information packets regarding the operations/functions that the third party application 40 executes, and the installed logging third party application 40 can receive these information packets.

The newly created page, which has been set up in this way, is stored in the application repository 22 (via the WBS coordinator 21) so that it can be called at runtime, as will be explained in more detail later. be able to.

Next, refer to FIG. 7B. In this embodiment, the elements are the same as those in FIG. 7A, except for the client 10 elements. At runtime, the client 10 comprises a viewer 201 for displaying the contained web page 203. It should be appreciated that the viewer 201 may comprise multiple viewports 202, each for displaying a different instance of the third party application 40 (instances derived from one or more third party applications 40). In addition, the client 10 includes a communication hub 205 that facilitates communication and provides a back-up between the contained web page 203 and a third party application 40 hosted by the contained web page 203. It provides the channels and required communications between hosted third party applications 40 without connecting to the associated contained web page 203. The function of the hub 205 will be described in more detail later.

The hub 205 can be implemented on the client 10, because both the containing web page 203 and the inclusion of the third party application 40 are visible interactive parts of the website, and these communications are between the client and server. It should be understood that it should not be delayed by a round trip. In an alternative embodiment, the hub 205 is implemented on the server 20 of the website building system when the third party application server 50 needs to exchange large amounts of data and it is preferable not to route these data through the client 10. be able to.

It is understood that the communication hub 205 can support various combinations of communication between the website building system 30 and one or more third party applications 40, as well as communication between the plurality of third party applications 40. I want to. For example, the hub 205 allows the third party application 40 to request the website building system 30 to switch to another page within the main site. In addition, the communication hub 205 allows the third party application 40 to request that its window be resized (possibly affecting the layout of the containing pages). This resizing can be performed through a dynamic layout process which will be described later in more detail. Alternatively, if the third party application 40 is required to switch to another version to accommodate (for example) a display change, the containing web page 203 can request this switching. This two-way communication is between the components of the third-party application 40 and the components (displaying additional information) of the website building system 30 associated with the third-party application 40, and as described above, the multi-part third-party application. It should be appreciated that there may also be established between 40 elements and modular third party applications.

Further, the system 100 may be implemented using both online and offline website building systems 30, and the system 100 may also be implemented using hosting methods (eg, client-side components, website building system 30 vendors'). It should be appreciated that any combination of servers, third party application 40 vendor servers, other fourth party servers, etc.) may be used. It should be appreciated that the server may still be required to implement system 100, even for the offline embodiments described above.

Further, the system 100 can also be hosted on another set of servers (not operated by the website construction system vendor), such as a private site hosting system in a large organization.

In addition, the system 100 can support all of the above instance inclusion options from the third party application 40. However, the system 100 may only support a subset of these options, or may impose restrictions on inclusion options for an instance of the third party application 40.

Further, the system 100 may also implement a multi-part third party application 40. The multi-part third party application 40 can include multiple display areas, each processed using a separate iframe. These areas may also cooperate (if desired) through communication hub 205, as described in more detail below.

Referring now to FIG. 9, this figure shows an example of a multipart third party application 40. As illustrated, the blog's third party application [a] acquired from AppStore[b] is placed on the containing web page 203[c]. The blog third party application [a] includes three areas, namely a blog entry area [d], a tag cloud area [e], and a news update area [f]. A multipart third-party application can use multiple areas of its own in a variety of ways, for example, as multiple co-existing parts of an application (as in the blog example above), or It should be understood that it can be used as multiple parts that exist as options in one application, including areas that are always displayed and areas of options that are only displayed when requested. The display of the optional areas can be controlled by the third party application 40 or by the designer 5 (which determines how to configure it when it is included). Further, the display can be controlled as a support function area such as a configuration area or an additional dialog area. Alternatively, the same is true for the display of multi-versioned third-party applications (eg, having small and large versions of third-party applications, or having portrait and landscape versions of third-party applications).

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

Furthermore, implementing a multi-part third-party application 40 requires that the third-party application 40 (inside each iframe) be able to control the display of various iframes (eg, iframe visibility, size, position). To be done. Further, it should be appreciated that the communication hub 205 may enable this display, as described in more detail below.

Moreover, even when the multi-part third-party application 40 consists of (visually) multiple elements and regions, in terms of purchasing, installation, configuration (eg in AppStore 25), this application 40 is still a single third-party application. It should be understood that it is considered 40.

In existing systems, each third-party application 40 is considered as a separate entity, and the collaboration between two third-party applications 40 (from the same vendor or from an affiliated vendor) is case-by-case. You have to develop it for each system. It should be appreciated that the system 100 may also support a modular third party application 40 consisting of cooperating sub-modules that may be individually purchased and installed.

Next, referring to FIG. 10, a sales management modular third-party application [a] has sub-modules such as a customer management (CRM) module [b], a lead management module [c], and an electronic module. It shows how the commerce module [d] can be included. This one third-party application vendor can provide all the required third-party application modules. Alternatively, the third party application vendor may provide a subset of the modules (and functionality) of the third party application 40 and the designer may provide supplemental third party application modules to the same or another third party. It can be purchased and installed from an application vendor. Multipart third-party applications are acquired and installed as one third-party application from one vendor (multipart third-party applications only occupy multiple screen areas), while modular third-party It should be appreciated that an application includes multiple modules that can be individually obtained and installed, and in some cases, modules from multiple third-party application vendors. To be able to integrate multiple third-party application modules from multiple vendors, each third-party application module provides a list of the interfaces/features it needs and the interfaces/features it provides. There must be. Providing the list can be done, for example, by using a list of interface names based on a dot-separated hierarchical name notation (eg, My_CRM_TPA.NewClient.GetInfo) and interface parameter specifications.

A module of the third-party application 40 may have a required interface (ie, an interface without which the module would not work) or an optional required interface (ie, the module would work without it but provided functionality). Interfaces that are restricted or change) can be specified. Therefore, the parameters provided for each interface are: a unique interface name, a description of the interface (shown to designer 5 so that designer 5 can (eg) recognize the functionality handled by the missing interface), required/optional. Status, list of interface parameters and types. It should be appreciated that each third party application module still belongs to a separate iframe (or set of iframes). The operation of the interface is based on the communication channel, which will be described in more detail later.

It should be appreciated that the modules of the third party application 40 can be assembled at the design stage of the website. The website building system 30 can resolve interface references because an additional module of the third-party application 40 is added, in which case the new module of the third-party application 40 can replace the existing required interface. Resolve, but in some cases add new (unresolved) required interfaces.

Further, it should be appreciated that the designer 5 can edit and run the completed website while the required (and optional) interfaces are still unresolved. However, the designer 5 cannot publish the created website until all the required interfaces are resolved, and the hub 205 starts the third-party application module that still has the required interfaces that have not been resolved. If you try to request a function, a message will be displayed.

Further, it should be appreciated that the AppStore 25 may include a searcher 26 that attempts to identify a third party application module that resolves the interface of the required third party application module. The searcher 26 may search for a particular third party application module or all third party application modules based on the unresolved interface. In addition, the searcher 26 can search based on interfaces that are not currently resolved, or interfaces that have already been resolved, and even based on required interfaces, optional interfaces, or both types of interfaces. be able to. Further, it should be appreciated that the searcher 26 can be limited to resolving unresolved interfaces of a particular third party application and searching for a particular third party application vendor. The searcher 26 performs a first level search (ie, a module that fills an interface that is not currently resolved) or a multi-level search (ie, an iterative search and considers third-party application modules found by previous searches). Sometimes I also look for modules that satisfy unresolved interfaces).

The system 100 can use the interface description to provide the designer 5 with information regarding the importance of providing some missing interfaces. The hub 205 can provide interface translation between incompatible third party applications that still need to communicate. This conversion can be done by an adapter module added by the vendor of the website construction system 30 or an external vendor, which adapts the required specified interface to another format.

Further, the system 100 may be applied to an online application editing system that is created using the Internet (or any other network connection) and client side software that is not a browser. Is displayed. In such a system, it is not necessary to use the particular technology used by normal web infrastructure (eg, IP communication, HTTP, HTML, etc.).

It should be appreciated that standard cross domain communication methods known in the art can be used to facilitate cross domain communication. The following are examples of cross-domain communication methods.

HTML5 PostMessage: This is a standard function of HTML5, and it is possible to provide secure cross-domain messaging by using this function. HTML5 Windows. Postmessage allows you to securely send messages between windows, iframes, and main HTML documents, even if they belong to different domains. PostMessage provides a tool for the sender iframe to specify the domain of the message destination, and a tool for the receiver iframe to confirm the domain of the sender of the message.

Message URL Fragment Identifier: This method uses a URL fragment identifier to send message data from one endpoint to another. The data is encoded in plain text and added (as a fragment identifier) to the service used in the target endpoint domain or the URL used to call the hidden iframe inside the target endpoint iframe. Decode the fragment identifier by the code in the target service or iframe.

Dedicated Communication Web Service: The website building system 30 provides a dedicated web hosted on the server 20 of the website building system. Various communication endpoints connect to this server to send messages or check for waiting messages. This can be done by methods known in the art such as the pre-HTML5 Comet set of technologies, HTML5-based WebSockets, or any other queuing, polling, server push, or similar technique.

HTML5 Local Storage: HTML5 provides a structured local storage function that can be used to store queued messages. However, the local storage can be accessed only by the web content belonging to the same domain as the stored iframe. Solutions developed in this area of technology include the underlying technology used by the Meebo XAuth product (now owned by Google Inc.), in which a small server provides the required intermediate iframe. Provides support for creating, which allows domain-specific local storage to be accessed from iframes that belong to foreign domains.

HTML5 Local File Access API (Application Programming Interface): Similar to the method of using local storage described above, on the local storage of the user agent accessed through the HTML5 file access API (File API, FileWriter API, FileReader API) Local files can be used to build a cross-iframe communication channel. However, the sandboxed local file system created by the file system access API of HTML5 is still only accessible from within the origin (origin-private), and thus the intermediate iframe is used to overcome the limitation of the same origin. /Server component required.

Dedicated browser plugins: Dedicated browser (or other user agent) plugins can be created to manage the cross iframe message queue. Such plugins, which must be installed by the user of the website building system 30 (at all levels), provide all the iframes and the main page of the website building system 30 with the necessary services. ..

It should be appreciated that the communication hub 205 can act as a broker in all inter-iframe communication using any of the transfer methods described above. Further, it is understood that the hub 205 can fully understand the structure of the contained web page 203 and the detailed information of the third party application 40 provided by the vendor of the third party application 40 and stored in the property sheet 23. I want to be done. Further, the third party application 40 can have different parameters when included in different applications and in different instances included in the same application (as described above). Such parameters include unique instance names that can be used for smart addressing (discussed in more detail below). Further, it should be appreciated that the hub 205 may also recognize additional details of the third party application 40 that are not stored in the property sheet 23.

In addition, the hub 205 facilitates smart addressing and smart identification, verifies the source of communication, enforces communication policies, resolves incompatibility issues with the third party application 40, and is a component from the third party application 40. Please understand that you can be redirected to. In addition, the hub 205 may enable dynamic layout updates in the third party application 40 based on changes made to the containing web page 203, as described in more detail below.

Next, please refer to FIG. 11A, FIG. 11B, and FIG. 11C. 11A and 11B show different embodiments of the hub 205, and FIG. 11C shows the function of various elements of the hub 205.

Hub 205 is hosted by smart identifier/addresser 310, origin verifier 320, communication policy enforcer 330, protocol converter 340, redirector 350, dynamic layout updater 360, configuration manager 370, general updater 380, and hosted. An API (application programming interface) wrapper 390 may be provided. The function of these elements will be described in detail later. All features can be applied to all cross-domain communication channels (eg, channel from third party application 40 to website building system 30, third party application 40 to another third party application 40). I want you to understand.

Referring now to FIG. 11A, which shows a general embodiment of the hub 205 through an intermediate iframe[a], which uses the internal communication API (application programming interface) to access the web. Communicate with the site construction system 30. By doing this, a message sent from (for example) TPA (third party application) [d] (using communication API module [f]) to TPA [e] (using communication API module [g]). [C] can be analyzed, verified, or modified in a way that applies information specific to the application.

Referring now to FIG. 11B, which shows an alternative embodiment, in which the communication API module [embedded in the third party application [c]] is used without the use of an intermediate iframe. a] and one or both of the communication API module [b] (embedded in the third party application [d]). Modules [a] and [b] interact directly with the website construction system 30 to receive application specific information and use this information when handling the communication message [f]. As a drawback of this embodiment (compared to the embodiment shown in FIG. 11A), a considerable amount of information at the level of the website building system 30 is processed inside a module contained in a third party application. This information may be accessed (and possibly modified) by malicious third-party applications.

As mentioned above, in all the cross-communication methods described above, the addressing of the iframe is based on the origin of the iframe (source domain, source protocol, source port, etc.), ie (to specify the receiver). Use the direct addressing of the third party application 40 when sending the message and when receiving the message (as the sender's name is provided to the receiver). In addition, in order to send the message, the sender requires that the target iframe window be specified (using the Javascript document.getElementById("...").contentWindow call or any other method). To be done. Thus, in existing systems, each third-party application 40 contains all the specific details (including domain, protocol, port, iframe ID) of another third-party application 40 with which it communicates. There must be.

It should be appreciated that this type of direct addressing can be awkward in the environment of system 100. Even though the designer 5 integrates multiple third-party applications 40 from multiple non-affiliated third-party application 40 vendors, the third-party application 40 supplied by the third-party application 40 vendor is initially a specific domain. Hosted in, but may later be moved to another domain or subdomain. Third party application 40 vendors may change the protocol or port used to communicate with a particular third party application. The designer 5 may be required to modify the design of the contained web page 203, including the third party application 40. All of these can occur in third party applications 40 that are in use and used on websites that are accessed by thousands of users. Further, one contained web page 203 may include multiple instances of one third party application 40 that may perform different functions. For example, two pages of a third-party application 40 for chat (one for user-to-user chat and forums, the other for contacting one page in the product support website) Sometimes used to consult vendor support personnel).

The addresser/identifier 310 may be fully aware of the structure of the containing web page 203 and the detailed information of the third party application 40 (provided by the vendor of the third party application 40 to the website building system 30). I want you to understand. The addresser/identifier 310 addresses the addressing of the source third party application 40 or the destination third party application 40, the unique name of the third party application 40 (registered in AppStore 25) and the third party application in the containing web page 203. A descriptive ID of the instance of the third party application 40 that is added to each instance of the 40 and thus allows addressing of multiple instances of the same third party application 40 and the type/class of the third party application required. Of each of the generic identifiers (e.g., "I want to send a message <x> to an instance of the event logging third party application 40 in the containing web page 203") of each other. You can Such an identifier may also describe the particular service to be supported by the third party application 40. In addition, the addresser/identifier 310 can use version indication information (eg, "Transaction <x> for instance of accounting package <y> only if accounting package <y> is version <z>". want to send").

At runtime, the third-party application 40 only communicates with the hub 205, and thus need only know the direct address of the hub 205, not the addresses of other third-party applications 40. Please understand that. This single direct address can be encapsulated by the communication API wrapper provided by the website construction system 30 to the provider of the third party application 40 (communication modules f and g shown in FIG. 11A, shown in FIG. 11B). Communication modules a and b etc.). The calling third party application 40 can provide its own (as described above) descriptive addresses known to the application and the addresser/identifier 310 translates these addresses into the direct addresses of the third party application 40. Then, the routing can be performed. In this way, the third party application 40 does not have to maintain a table of absolute addresses of all the third party applications 40 with which it can communicate.

It should be appreciated that confirmation of the originator of the message is important and without confirmation the receiving third party application 40 may receive the message from the hostile third party application 40. Since all communication is via the hub 205, the origin verifier 320 can check the authenticity of all incoming messages from third party applications. Further, the origin verifier 320 can provide additional information that can be added to the message, and this additional information can be used to provide additional confirmation. Each and every third party application 40 included in the AppStore 25 and used by the system 100 is registered with the website building system 30 so that the hub 205 knows that the unique ID of the originator contained in the message. It should be appreciated that the match with the originator of the message (domain, port, etc.) can be verified by the website construction system 30.

The third party application 40 can define a general communication policy that can depend on external information, information on the contained web page 203, and the like. The communication policy enforcer 330 can ensure that applicable communication policies are applied so that communication that does not comply with the specifications need not be handled. For example, in a website that handles sensitive information, third-party applications can be given the confidentiality level field in their profile. A third-party application 40 that provides a backend event logging database that is allowed to handle sensitivity level X can define a policy that it will not accept and log events with a sensitivity level higher than X. In such a situation, the communication policy enforcer 330 can perform the necessary pre-filtering to prevent even highly sensitive messages from reaching applications that can only handle low confidentiality levels.

In addition, Designer 5 has two (or more) third-party applications on the same website that can work together, but do not actually work because of protocol compatibility issues. It should be appreciated that you may wish to include it. Referring now to FIG. 12, for example, as shown in this figure, a third-party application [a] in an online shop is a third party for procurement and shipment of a third-party application [b] (provided by a different vendor). The party application may have the ability to send a purchase order message. However, the information provided by the third party application [a] may not include some fields required by the third party application [b]. Such situations should generally be resolved by the vendor of the third party application involved, but in some cases such a resolution cannot be made (eg one of the two third party applications may Has not been updated at this time). The protocol converter 340 can convert the relevant message from [a] to [b] (eg, by providing the required additional fields). Such conversion may be performed by the protocol converter 340 or may involve interaction with the website in which the application is embedded and the containing web page 203 (eg, if additional information is needed). ..

Furthermore, it should be appreciated that the third party application 40 may have the functionality required to send messages to or receive messages from another third party application 40. (For example, the online shop/procurement third party application 40 pair described above). However, in some cases some of the solution may not be present, and in the above example, there may not be a corresponding or appropriate procured third party application 40. In such a case, by using the redirector 350, the designer 5 routes a particular message to a component of the containing web page 203 or a particular message from a component of the containing web page 203. Comparable functionality can be specified to be resolved by the components of the containing web page 203 and the functionality that the component can provide. This allows a complete website to be built without having to build a dedicated third party application 40. Thus, the transaction can be sent to a component of the website construction system 30 that can log the transaction to a database, which can be used later (by another program) to perform offline procurement and shipping. can do.

Third party application 40 may provide multiple configurations that use the same code base but have different capabilities enabled. For example, the third-party application 40 may provide basic functionality through a free version and may provide additional functionality through a premium version to purchase, multiple paid versions, or additional functionality to purchase of the third-party application 40. ..

It should be appreciated that the system 100 may include functionality based on the website building system 30 that manages the purchase status of the third party application 40 by user (actually by designer). Further, all the designers can be registered users of the website building system 30, and thus the website building system 30 can manage the database of the purchase status of the third party application 40 of each designer 5. I want you to understand. This information can be stored in the property sheet 23 by the TPA coordinator 24 at the design stage and by the configuration manager 370 at run time. For example, the third party application 40 can send a version query message to the client-side element of the website building system 30. The client-side element of the website building system 30 queries the repository 22 or a locally cached copy of the repository and sends a response message to the third-party application 40 containing information about the capabilities the third-party application 40 should provide. return.

In an alternative implementation, the website building system 30 provides the necessary configuration information for the third party application 40 (such as encrypted iframe parameters) to the third party via the alternative channel without the need for a prior inquiry message. It can be provided to the party application 40.

As mentioned above, the third party application 40 can communicate directly with certain components of the containing web page 203. The third party application 40 can identify the component with which it communicates in a variety of ways: directly identifying the component based on an associated template (as described in more detail below), or by the designer. 5 through an access ID explicitly specified for a particular component of the containing web page 203 by, or following (optionally optional) component model provided by the containing web page 203 to the third party application 40. Identify by.

It should be appreciated that at run time, the updater 380 may implement messages and responses between the components of the containing web page 203 and the third party application 40. For example, the third-party application 40 can change or modify the visual/display attributes (component position, size, color, transparency, etc.) of the component of the contained web page 203, or inquire. In addition, the updater 380 enables the third party application 40 to read or write the content of the components of the containing web page 203, further allowing the third party application 40 to perform media functions (eg, a specified audio segment or It is possible to pass the video segment to the media player component or instruct the component to perform a request to the media player component to pause playback for a specified period of time.

In addition, the updater 380 facilitates the components of the website building system 30 to specify the type of access to allow to the third party application 40, in which case access to protect files in modern operating systems. By a method similar to how permission bits and access control lists (ACL) work. Such permissions may be defined for each component to apply to all third party applications 40, third party applications 40 from a particular vendor, or a particular third party application 40. For example, the third party application 40 may be allowed to access text fields within the containing web page 203 outside the third party application 40. For a blog third party application 40, this text field can be used to edit a blog entry, providing more screen area than can be provided inside the area of the blog third party application 40 itself. Provided. For a third-party application 40 embedded in a particular minipage inside a multi-page container, the website construction system 30 limits access from the third-party application 40 to only the components within that particular minipage. Please understand that you can.

Further, it should be appreciated that the updater 380 allows the third party application 40 to influence site-wide elements. For example, there is a process of acquiring and setting attributes such as the current page in the site, the current minipage in the container including the third party application 40, and the page history. Further, updater 380 can filter or limit such requests.

In addition, updater 380 allows website building system 30 to change and modify the style and presentation of third party applications 40. Updater 380 may implement the calls that website construction system 30 uses when providing formatting and style guidelines to third party applications 40. Guidelines can include properties such as color and color scheme, font, font size, transparency, animation and special effects (eg blur). Color schemes include, in particular, general color schemes (eg, use the x color below) and high-level color schemes (eg, use color x for text and color y for frames).

One preferred way to represent complex style information is to use Cascading Style Sheets (CSS), which represents a combination of multiple style directives such as font, size, and color. Please understand that Updater 380 can send such CSS-based messages to third party application 40. The style sheet may be generic in nature or may include unique style names defined by the third party application 40, so the website building system 30 provides the third party application 40 with better guidelines. (For example, the stylesheet can reference elements of a particular third party application 40 to provide these guidelines).

This allows the third-party application 40 to use these guidelines to create its own look and feel that fits well into the containing web page 203. This is particularly important for third party applications 40 that are contained in or visible from multiple contained web pages 203 within the same site (multiport inclusion as described above). Multiple contained web pages can adopt different color schemes and basic designs. The third-party application 40 uses the information provided through these style messages to adapt its display colors and styles to each of the included pages to suit them well and to create a color scheme that is inconsistent compared to the included web pages. It is possible to avoid the display of and the appearance/operation feeling.

The dynamic layout updater 360 may be used by the website building system 30 and the third-party application 40, or the third-party application 40 and ancillary third-party applications to process the display changes resulting from the dynamic layout event. It should be understood that it enables us to work together. The website building system 30 can change the size and position of components within a page for the purpose of maintaining the page design when an event occurs that changes some of the components within the page. These dynamic layout events include, for example, browsing a website on screens with different sizes, rotating the display between portrait mode and landscape mode, changing the size or position of some components. , Changing the content of a particular component (resulting in a requirement to resize the component). In addition, dynamic layout events include component-based updates of server-based content (eg, in a component that displays information from a data feed), or content changes by another concurrent user of the same website. Updates are included. Further, it should be appreciated that dynamic layout events can occur in the runtime environment as well as the design environment. In particular, depending on the component and third party application 40, the content and size/position of the component can be changed at runtime (ie by the end user) as well as by the designer.

Further, it should be appreciated that the dynamic layout event may also be raised by the third party application 40. For example, an online shop's third party application 40 may require resizing when a user navigates from a product catalog view to a shopping cart view (having a different size). As another example, a product catalog third party application 40 may include an option to highlight a product, which results in the third party application 40 having a larger catalog with more content. Display the page. A further example is a multi-region third party application 40 that can start or stop the display of additional regions.

Referring now to FIG. 6 above. In existing systems, even if this situation is dealt with, it is common to cut off the display of the third-party application and add a scroll bar to the display, or to other pages such as shown in FIG. Handle by simply resizing the display as a popup window that hides the component. The dynamic layout updater 360 may implement a collaborative dynamic layout, in which case the website building system 30 and the third party application 40 cooperate to perform the dynamic layout and to include the contained web pages 203. Keep the basic design of. The functionality of the dynamic layout is further described in US Pat. No. 6,037,086 (filed on Feb. 20, 2013, assigned to the common assignee of the present invention). However, even in systems that support collaborative dynamic layout, the dynamic layout mechanism in the containing web page 203 does not fully control the internal layout of the third party application 40. Furthermore, the widgets of the website construction system 30 may be designed to be resized to any size (within a certain range), but the third party application 40 may not support any resizing. The third party application 40 may, for example, have multiple display settings with different sizes (eg, show more or less detailed information), the ability to resize some of the internal elements of the third party application 40, a third party Any combination of the ability to display some of the text elements of application 40 using multiple font sizes may be provided.

Further, the third party application 40 may have a limited number of possible display sizes offered and may have an entire range of possible sizes. Therefore, a resizing request from the containing web page 203 to the third party application 40 provides a list of the possible sizes of the third party application 40 by switching to the closest possible size of the third party application 40 (which allows the web The site building system 30 can choose the appropriate size to use) to solve the problem.

The dynamic layout updater 360 may implement a collaborative dynamic layout [from the containing web page 203 to the third party application 40] using the following sequence.

For example, it may be necessary to resize the third party application 40 embedded in the containing web page 203 to a particular desired size (eg, X1*Y1 pixels). The dynamic layout updater 360 may send a message to the third party application 40 requesting that the third party application 40 resize its content to a particular desired size (eg, X1*Y1 pixels). The third-party application 40 can be sized to a specified size by using alternative display settings, internal resizing, internal dynamic layout, or any other means. Furthermore, it should be appreciated that the containing web page 203 can resize the external iframe window containing the third party application 40 to a new size (X1*Y1).

Further, it should be appreciated that the third party application 40 may only be able to resize to a limited set of possible sizes (eg, particular user interface configurations). Therefore, the dynamic layout updater 360 can use the following alternative algorithm that can provide a set of sizes that the third party application 40 can.

The containing web page 203 is resized and the dynamic layout updater 360 sends a message to the third party application 40 requesting that the third party application 40 resize its content to a particular desired size (X1*Y1). send. The third-party application 40 finds the closest possible size (eg, X2*Y2 pixels) and uses alternative display settings, internal resizing, internal dynamic layout, or any other means. By resizing to that size. The updater 380 can then send a response message confirming the resizing process to the containing web page 203 and provide the actual new size (X2*Y2). The containing web page 203 can resize the external iframe window containing the third party application 40 to the actual new size (X2*Y2). The containing web page 203 can continue the dynamic layout process based on the actual new size (X2*Y2).

It should be appreciated that other embodiments are also applicable, particularly where there are multiple third party applications 40 (or multi-domain third party applications 40) within the containing web page 203. In this embodiment, the containing web page 203 allows the embedded third-party application 40 to attempt to optimize the look/feel by considering the options of the third-party applications 40. First, the embedded third-party application 40 can be queried to obtain a list of display sizes. This embodiment is also relevant when the third party application 40 is displayed across multiple areas.

The contained web page 203 executes the dynamic layout process and one or more third party applications 40 (TPA[1] to TPA[n]) are embedded in the contained web page 203 and use the following algorithm. Then recognize that it should be resized.

Loop from 1 to n for i.

For each TPA[i], we find:

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] listing the above min/max/optimal sizes to request information about the possible sizes of the third party application 40.

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

The containing web page 203 is based on the Xposs[][]/Yposs[][] information gathered as described above, a complete evaluation of all possible size combinations (for example) of third party applications, linear programming, Alternatively, the solution of the dynamic layout calculation can be calculated by using any other technique used by the dynamic layout algorithm.

Store the results for all TPAs in Xfinal[i]/Yfinal[i].

Loop from 1 to n for i.

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

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

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

It should be appreciated that the dynamic layout process may generally require moving the third party application 40 rather than just resizing the third party application 40. However, the third party application 40 should be invariant to the exact location of its frame inside the containing web page 203.

As mentioned above, the third party application 40 may occasionally need to resize its display window. Since the size of the window displaying the iframe is managed by the hosting page (ie the containing web page 203), changing the window size of the third party application 40 must be performed by the containing web page 203, in which case the third The party application 40 requests (via the dynamic layout updater 360) the containing web page 203 to change the window size.

Further, it should be appreciated that the third party application 40 may also request (via the dynamic layout updater 360) to change its position inside the containing web page 203. In this case, the third party application 40 is not affected internally (as when resizing), but a change in the display within the containing web page 203 is required. The dynamic layout updater 360 can integrate this requirement with the dynamic layout. The containing web page 203 invokes the dynamic layout updater 360 to change the window size (and possibly the window position) of the third party application 40 and ask the third party application 40 to confirm the size and position change. Can be sent.

The hub 205 may provide additional messages specific to the class of the third party application 40, or additional messages specific to the third party application 40 as the website building system 30 itself, or a particular contained web page 203, or an auxiliary third party. It should be appreciated that the party application 40 may also implement additional messages, which may affect the third party application 40. For example, the blog third party application 40 may define an input message that may post a new blog entry or a new response to the current blog entry. Such a message can be used by the containing web page 203 (eg, as a way to post a blog entry from a large edit field outside the area of a third party application). Further, such messages can also be used for links between higher level applications, which allows, for example, a supporting third party application to post a blog entry to the blog's third party application.

Third party applications 40 often require a wide range of complex services for use within or downstream of third party applications 40 by designers using the third party applications 40 within their site. I want you to understand. Such services include user management and billing/shipping management. The vendor of the website building system 30 may not be able to provide such services as part of the website building system (eg, due to technical issues or business reasons). Moreover, these services may not be suitable to be “packaged” as a third party application 40 alone. In addition, the vendor of the third party application 40 may provide a number of such services (eg, third party billing APIs) to the designer using the third party application 40 so that the designer 5 selects the appropriate service. May need options to make it available for use.

For example, in the website construction system 30, an API hosted by Paypal ^™ can be provided, and this API can be directly used by the third party application 40 or provided by the third party application 40 to the designer 5 who uses this API. can do. In addition, the third-party application 40 provides its own set of options (ie, uses a particular billing type, such as one-time billing, automatic recurring billing, revenue sharing), and is hosted by Paypal. You can also implement these options by calling the API.

Therefore, the designer 5 using the website construction system 30 can develop a unique service (such as an online shop that sells music) that uses advanced billing. The designer 5 uses the hosted billing API either directly, or through a third party application 40 that provides an additional level of abstraction (or abstraction layer) to identify a particular billing API provider. It avoids the need to negotiate clearing agreements and merchant agreements. In this sense, the website construction system 30 can be an agent of a vendor of a hosted API.

The hosted API wrapper 390 facilitates this communication between different parts of the system (eg, website building system 30, hosted API code, included third party applications 40). be able to. It should be appreciated that the API wrapper layer and the actual API implementation may belong to the website building system 30 itself or another third party application 40. The vendor (or designer 5) of the third-party application 40 can use the hosted API through the hosted API wrapper 390 without knowing how to actually implement the underlying API.

In a complementary alternative embodiment of the present invention, Applicant is confident that additional templates and components of the website building system are associated with third party applications at the AppStore 25 level and associated instances of the third party applications. It was further recognized that by using the model, smart integration between the website building system 30 and one or more third party applications 40 can be achieved. Third party applications 40 may also communicate with these components (and unassociated components) to exchange data and control messages. As mentioned above, the third-party application area 40 within the containing web page 203 is a separate host where the content is hosted in a separate domain (third party application vendor domain or otherwise) different from the domain where the main site is hosted. Iframe. Therefore, the "same origin policy" of the browser is applied to the communication between a plurality of different iframes, and it is required to use the above-described method.

In existing systems, the third-party application 40 is implemented as an integral, less flexible object that is included in the contained web page 203 but otherwise does not affect the appearance/feel of the contained web page 203 itself. .. The instance of the third-party application 40 is located in a (generally rectangular) area and performs all of its operations/functions in this area.

In addition, Applicants have taken this concept by having an (optional) additional template (referred to as an associated template, according to embodiments of the invention) of the website building system 30 that is associated with the third party application 40. Recognized that it can be expanded. This association can be performed at the time of development or publication of the third party application 40, and as part of the selection/purchase process of the third party application 40 (from AppStore 25) and instantiation of the third party application 40, the designer 5 Please understand that can be presented to. The third party application (TPA) coordinator 24 retrieves the templates associated with the third party application 40 (as part of the application repository managed by the AppStore 25 or provided by the vendor of the third party application 40), As mentioned above, the template can be stored in the repository 22 for later use.

It should be appreciated that the system 100 can support the publishing of a third party application 40 having multiple associated templates, which allows the designer 5 to select the optimal template as needed.

When creating an instance of the third party application 40 in the containing web page 203, the components in the associated template can be merged with the containing web page 203, along with other components in the containing web page 203. It should be appreciated that it can be displayed.

Referring now to FIG. 13, this figure illustrates an example of the use of associated templates, according to an embodiment of the invention. As shown, the third party application [a] is located in AppStore[b] with an associated template [c] that includes components [d] and [e]. When the third party application [a] is included in the containing web page 203[f], the third party application [a] can be displayed in a designated area [g] inside the page [f], It should be appreciated that instances [d'] and [e'] of components [d] and [e] may be displayed on page [f] along with pre-existing components [h] and [i].

It is to be appreciated that the system 100 can support multiple ways of placing the associated template component instances (eg, [d′] and [e′] above) into the containing web page 203[f]. .. The placement methods include absolute placement (that is, using the sizes and positions of the original components [d] and [e] specified in the associated template [c]), and placement based on the target ( That is, the size and position of the new instances [d′] and [e′] are adjusted according to the containing web page 203[f], and the arrangement based on the third party application 40 (ie, of the containing web page 203[f]). Adjusting the size and position of the new instances [d'] and [e'] based on the size and position specified for the inner third-party application instance [g]). The placement method employed can be determined based on the settings included with the associated template [c], and the designer 5 can use another placement method if desired.

Further, it should be appreciated that designer 5 can modify the instances of components [d] and [e] in [f] that are inherited from template [c]. The modification is to the use of [d] and [e] in [f] (and in some cases, pages inherited from within a website building system 30 that supports inter-page inheritance). Only applied and does not affect the "original" template [c] associated with the third party application [a] in AppStore [b].

Understand that changes to the above instances of [d] and [e] include, among other things, assigning specific content (text, images, etc.) to the instance of the field, or changing normal attributes. I want to be done. Further, referring to FIG. 14, if the third party application 40 is included inside the minipage, the associated template is applied to the particular minipage containing the third party application 40, as shown in FIG. Please understand what is done. As shown, the third party application 40 is contained in the mini page [x], thus components [d] and [e] are added to [x], but a further mini of the same multi-page container [g]. It is not added to pages [y] and [z].

Further, for section type mini pages, it should be appreciated that the associated template (when present) applies to the virtual (and empty) containing web page 203 created to include the third party application 40. ..

In an alternative embodiment, pre-created associated templates can be applied to newly created pages or mini-pages that are "parallel" to the containing web page 203. This newly created page or minipage can be initialized with a template and modified as needed.

In addition, the website building system 30 also allows for multi-port inclusion, where the same instance of the third party application 40 is visible to and "belongs" to) multiple pages on the main site. Multi-port inclusion is different from multiple inclusions (creating multiple instances of third party application 40) of a particular third party application 40 within the main site. Thus, the content of the third party application 40 (which is instance specific) is shared among multiple representations of the same multi-port third party application 40.

In such multi-port inclusion, the associated template can be applied individually to each of the page and minipage to which the instance of the third party application 40 is added.

As mentioned above, the system 100 can provide a two-way communication link between the third party application 40 and the components within the containing web page 203. It is to be understood that such components include components of the containing web page 203 as a result of merging associated templates from third party applications and components not associated with such associated templates.

Therefore, it should be appreciated that the vendor of the third party application 40 may generally create multiple templates associated with the third party application 40 provided by the vendor. These templates include test templates, development templates, and other templates, in addition to the templates that are actually distributed (ie, associated with the currently distributed third party application version).

As mentioned above, the third-party application 40 can be distributed through the AppStore 25, and even through alternative paths that are not related to or controlled by the vendor of the website building system 30. However, the associated template distributed with the third party application 40 may be strongly associated with the application repository 22, because the associated template is a component managed by the website building system 30, the base template. , And other elements are used to build it.

Furthermore, the elements of the website building system 30 that underlie such individually distributed associated templates may have to be modified or deleted (which in some cases causes the associated template to "break"). "). To solve this problem, the system 100 can implement these associated templates in separate areas inside the application repository 22 (possibly by the vendor of the third party application 40). The website construction system 30 can manage these templates like any other template of the website construction system 30.

Further, the vendor of the third-party application 40 can be provided with a unique ID (development ID) for each template created, and the vendor of the third-party application 40 can use this ID during the development and testing process of the third-party application 40. It should be appreciated that can be used. At the time the third-party application 40 is published/distributed, the vendor of the third-party application 40 may be required to apply and receive an alternate unique ID (public ID), which will be published. The ID can be referred to in the third party application 40. When the public ID is provided, a separate locked copy of the template is created. This copy is the copy referenced by the third party application 40 and used when creating an instance of the third party application 40. This ensures that the vendor of the third party application 40 cannot inadvertently modify the template associated with the "raw" third party application 40 (included by the designer), maintaining referential integrity. To be done. Moreover, the system 100 can cross-reference the relationship between such locked templates and the underlying components and base templates. The use of this cross-reference attempts to modify, for example, the components of the website building system 30 or the base template contained in such locked template (and such modification may result in modification of the template or third-party template). The staff of the website building system 30 can be alerted if the party application 40 may break in some way).

Thus, the system 100 can provide a two-way communication channel between the third party application 40, the components in the containing web page 203, and the website building system 30. The components of the containing web page 203 are based on the template(s) associated with the third party application, or based on another template of the website building system 30, or are independent of the template. You can

As mentioned above, the communication hub 205 can facilitate communication and can provide a back channel between the containing web page and the third party application 40. Applicants have further recognized that the data sent bi-directionally between the containing web page and the third party application 40 is useful once they have been collected, processed and integrated.

For example, a website owner needs to manage the number of users and membership per site, which is different from the value based on the registered users of the associated website building system 30. Users of the website can either register or not register (anonymous), and the website can provide different levels of functionality to different levels of users. In addition, users (even anonymous users) may not be able to personalize when launching instant messenger software to contact the site owner or when connecting to social networks as part of their activity on the site. Often provide information and contact information (eg data in contact forms). It should be appreciated that this information may be entered directly into the created site or made available as part of interaction with a third party application embedded within the site.

Further, it is to be understood that these pieces of information are unorganized, unrelated to each other, possibly inconsistent, and often not preserved. For example, one user enters his private email address into a contact form (managed directly by the site) and, in the same session, a work email address (from a third-party application). 40) (subject to management by 40).

Furthermore, these “fluid” information may include different permits for the use of that information. For example, a user who enters their email address in the subscription form expects to receive the email-based subscriptions they have subscribed to and possibly the associated email newsletter. On the other hand, users who have disclosed their e-mail address as their registration ID may not want to receive e-mail addressed to their registered address, except for e-mails regarding the handling of their accounts and security warnings. is there.

Referring now to FIG. 15, which illustrates a system 200 for coordinating and collecting data from various messages exchanged between a website building system 30 and one or more embedded third party applications 40. Is shown. The system 200 comprises a client hub 210 installed on a client 220, a server hub 230 installed on a server 260, a contact coordinator 240, an activity coordinator 250, a contact database 245, and an activity stream database 255. Hub 210 and hub 230 communicate between website building system 30 and a plurality of third party applications installed on server 270, as described above in connection with hub 205, and a plurality of different third party applications. It should be appreciated that communication between 40 can be facilitated. The contact database 245 and the activity stream database 255 can hold contact information and activity information and information extracted from the message stream, as described in more detail below.

16A and 16B, FIG. 16A shows elements of the client hub 210, and FIG. 16B shows elements of the server hub 230, elements of the contact coordinator 240, and elements of the activity coordinator 250. ing. The client hub 210 includes a router 211, a converter/adapter 212, and a privacy policy enforcer 213. The server hub 230 includes a router/tracker 231, a converter/adapter 232, a privacy policy enforcer 233, a private data proxy 234, and a verifier/signer 235. The contact coordinator 240 includes a data extractor 241, a contact handler 242, a data merger 243, and a data/permission handler 244. The activity coordinator 250 includes a stream creator 251, a stream merger 252, and a log creator 253. The function of these elements will be described in more detail later.

16C and 16D, FIG. 16C shows the elements of the stream merger 252 and FIG. 16D shows the elements of the data merger 243. The stream merger 252 includes an activity-stream merger 261 and a stream-stream merger 262. The stream-stream merger 262 further includes a horizontal stream merger 263 and a vertical stream merger 264. The data merger 243 includes a contact identifier 272, a combiner 273, a conflict resolver 274, a list value creator 275, a vertical contact merger 276, and a horizontal contact merger 277. The horizontal contact merger 277 further includes a virtual horizontal merger 278. Vertical contact merger 276 further comprises a virtual vertical merger 279. The function of these elements will be described in more detail later.

The system 200 enables message passing between the system 200 and multiple third-party applications, while providing various capabilities: organizing activity messages by stream, storing a history of activity messages, multi-level. Message passing of activity messages in, using side channels for activity messages, transforming activity messages and adapting content, validating activity messages and signing activity messages, listener query It should be appreciated that it provides functionality such as using to dynamically route activity messages. These functions will be described later in detail.

In addition, system 200 can extract user-related information and merge them (combining information from multiple sources and information already present in system 200). Merging can be done through merge rules that coordinate different types of information, possibly conflicting with each other. The combined information can be stored in the contact database 245. This information may further include permission fields that control the allowed use of the gathered information, as described in more detail below.

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

In addition, system 200 allows, as a further component, third-party application 40 to manage the activity of contacting the user (eg, mass sending of newsletters) while enforcing usage restrictions set by the user himself. It should be appreciated that the components that enable may be provided. Such a component may also insulate the user's private data from the third party application 40 (thus the third party application 40 may perform each operation without actually accessing the user's private data). it can). Such functionality may be implemented, for example, using private data proxy 234, as described in more detail below.

Further, it should be appreciated that the contact database 245 can be unique to each site. However, the website building system 30 may define a metasite/metaproject level that includes a collection of websites (owned by the same site owner), where contacts are stored at the metasite level rather than the single site level, It can be specified to be processed and merged. Other elements of the site (such as included third party applications 40) can also be defined at the metasite level rather than at the site level. Other than supporting metasites, the system 200 generally does not share contacts between different sites or different site owners (except in situations described below), and does not consolidate contact information (except as described below). Therefore, data provided by one end user to one site does not leak to another site).

As mentioned above, system 200 can support multiple interactions between website building system 30 and one or more third party applications 40. Such interactions can be predefined activities such as shopping, adding items to a shopping cart, entering contact information, and so on. One third-party application 40 can specify the activities it supports, and other third-party applications 40 "listen" for a particular activity and act on the received activity and the information associated with it. be able to. It is understood that the list of activities listened to in a particular third party application 40 can be explicitly set to one or more activities, or determined by an activity listening query, as described in further detail below. I want to.

It should be appreciated that each activity can be thought of as a message and each message can include an activity data structure. Activity data structures are predefined data types, but defined through inheritance between each other or through a third party application 40 (with the option to extend the activity data structure by adding fields). It can also be defined. The activity data structure may be system specific, based on, or include standardized data structures. The activity data structure can also be encoded in some way (such as using XML, JSON data, or binary object encoding).

In addition, the activity data structure may include a “description” field provided by the third party application 40. This is a description of the activity as defined by the third party application 40 (which may be more detailed than the description known to the website building system 30). For example, the third party application 40 of the VOIP communication displays the activity description text "Call to John Smith at 999-555-1234-01:15 (01:15)". Can be provided.

Further, the activity data structure may include a callback link, eg, "more information" (return to activity data structure). Callback links can be used to provide additional important information, for example, in the case of e-commerce activity data structures, complete order tracking information, order history, etc. In the case of the activity data structure, it is the complete chat log, and in the case of the telephone activity data structure, it is the call log. Thus, the complete activity data structure as an example is specific to the following fields: creation time, activity type, activity origin (third party application 40/component ID), activity stream ID, activity type. Information (depending on the type of activity), created site ID, site member database ID, site page ID/URL where the activity was performed, description of the activity provided by the third party application 40, used by the third party application 40. Additional information links provided and details of the retrieved user, etc. may be included.

The activity coordinator 250, which can be considered a logging element, receives data from the messages passed from the hub 230. The stream creator 251 can create an initial stream (which can be thought of as a log or chain-like structure), and the stream merger 252 can add activity to this initial stream as it comes in. , Each stream is then unique to the contact. It should be appreciated that the stream creator 251 does not have to create a new stream for each individual activity contained in a different message. Furthermore, it should be appreciated that the activities included in the stream may not be in the correct order (eg, some third party application 40 may be delayed in reporting the activity). In operation, the stream merger 252 can merge multiple streams if they belong to the same single contact, and the log maker 253 can stream all previously created activity streams. Log files may be stored in the activity stream database 255.

As described above with reference to FIG. 16C, the stream merger 252 comprises an activity-stream merger 261 and a stream-stream merger 262. The activity-stream merger 261 can associate the activity with the stream associated with the identified contact, and the stream-stream merger 262 can convert two separate streams into one stream. The horizontal stream merger 263 can merge two streams that are not related to each other due to the detection of the common primary ID, and the vertical stream merger 264 can merge the streams created for anonymous contacts with These two streams can be merged when the stream associated with the registered user is tied at login or registration. It should be appreciated that the stream merger 252 can access previously created streams in the activity stream database 255 when needed.

For example, anonymous users fill out contact forms on the site. The stream creator 251 creates a new activity stream (with ID "anon1") and the contact handler 242 creates a new contact (with ID "anon1" as described in more detail below). This same user then chats with the site owner. Stream merger 252 merges this activity into the "anon1" activity stream and the contact "anon1" is updated (as described in more detail below). The user then fills in the schedule form using another browser. The stream creator 251 creates a new activity stream with the ID "anon2" and the contact handler 242 creates a new contact with the ID "anon2" because there is no interaction with the first user.

The user then shop from this site. The stream merger 252 merges this new activity into the “anon2” activity stream and updates the contact “anon2” (eg, using the “customer” tag).

This user uses yet another browser to register on this site. Once registered, all users receive the ID "user x" from the site's membership handler. At this point, stream creator 251 creates a new activity stream (with ID "user x") and contact handler 242 creates a new contact (with the same ID "user x").

The user then visits the site again from another browser and chats with the site owner. Since no cookies are used on this website, the stream creator 251 creates yet another new stream ID "anon3" and the contact handler 242 creates a new contact "anon3".

The user then logs in to the website. At this point, there is a contact with ID “anon3” and ID “user x”. The data merger 243 can merge the contact “anon3” into “user x”, so both the login activity in the stream of “user x” and the login activity of the contact “user x” are activities. It refers to the streams "user x" and "anon3". Stream merger 252 may merge additional actions performed by the user in this session into the activity stream of "user x". The log maker 253 can log all activity data from these streams and store a copy of the log in the activity database 255.

Referring now to FIG. 17, it is to be understood that the site owner can access the activity stream history for a particular contact through the associated user interface provided by the website construction system 30 shown in FIG. For one contact "Dani Bronstein", the usage history of the website can be easily accessed. Further, it should be appreciated that website building system 30 or third party application 40 may also provide APIs for accessing log information. It should be appreciated that activity logs can be used for purposes such as optimization, user interface improvements, ad targeting, and so on.

Further, in parallel, it should be appreciated that the contact coordinator 240 can gather information from the data provided by the activity stream (message) to build a contact profile for the target user. The data extractor 241 can extract data from activity messages and activity streams, the data merger 243 can merge related data into a particular contact, and detailed information of this contact can be found in the contact database 245. It can be stored and can be accessed from the contact database 245. The contact handler 242 can create new contacts and can process the site user's identity information (such as anonymous users), and the data/permission handler 244 provides privacy protection and authorization of relevant data. Can be processed. The data merger 243 includes the horizontal contact merger 277 and the vertical contact merger 276 as described above. The horizontal contact merger 277 can merge two unrelated contacts due to the detection of a common primary ID, and the vertical contact merger 276 is associated with anonymous contacts and registered users. The anonymous contact can be merged with the contact associated with a registered user when the contact is tied at login or registration. The horizontal contact merger 277 can further include a virtual horizontal merger 278 that maintains the two contacts as separate contacts, but the two contacts represent the same contact. Link them with each other (with or without merging the actual contact information) as shown. The vertical contact merger 276 may further comprise a virtual vertical merger 279, which maintains anonymous contacts and contacts associated with registered users as separate contacts. Link them together (merge or not merge actual contact information) so that it is shown that two contacts represent the same contact. Further, the data merger 243 can merge contact information (typically extracted from the data extractor 241) into existing contacts. It should be appreciated that the contact identifier 272 can track the identity of the user using cookies and can recognize the contacts to be merged as will be described in more detail later.

Referring again to FIGS. 15, 16A, and 16B, message passing can be performed at client 220 or server 260, or both. It should be appreciated that the third party application 40 generally has client and server side elements, or at least has a server side connection with the server 270 of the provider of the third party application 40. The hub 210 can handle messages between the client 220 and the third party application 40, and the hub 230 can handle messages between the server 260 and the third party application 40. It should be appreciated that the data received by the hub 210 can be processed and then forwarded to the hub 230 for further processing, which will be described further below.

Referring now to FIG. 18, this figure illustrates a scenario of message passing between different platforms. The user's client machine X can be connected to the website building system 30 on the server Y. The website building system 30 can be implemented using the client component A′ of the website building system 30 and the server component A of the website building system 30. When the created site is displayed, the site can include a client-side element (data/code) B'and a server-side element B. The created site can further include three third party applications 40 (TPA1, TPA2, and ETPA3).

The TPA1 can be implemented by the client-side component D'and the server-side component D connected to the server H of the vendor of the TPA1. The TPA2 can be implemented by the client-side component E'and the server-side component E connected to the server I of the vendor of the TPA2. However, the ETPA 3 can be a server-side only third-party application 40 implemented by the server-side component G, which is connected to the third-party application 40 support backend F of the website building system 30. ing. These two components can communicate with the server J of the vendor of the third party application 40.

TPA1 and TPA2 are capable of exchanging messages on the client (between components D'and E'), on the server (between components D and E), or on both the client and server. I want you to understand. However, communication with ETPA3 must only be done on the server. Furthermore, it should be understood that there are advantages and disadvantages to using either method. Sending activity messages on the client side can be more interactive, resulting in faster user response. Sending activity messages on the server side can be more robust and reliable (eg, users cannot close their browser windows in the middle of the process) and ensure that messages are received in the correct order. Additionally, activity messages can be sent to backend third party applications 40 or application dashboards installed on the backend. It should be appreciated that these backend third party applications 40 are not displayed on the client side.

As a case of using a plurality of third party applications 40, for example, a user adds a product to a shopping cart in the third party application A (the activity type is “change cart”). Then, the third party application A sends an activity message regarding the addition of the product to the website building system 30. The website building system 30 forwards this activity to all third party applications 40 registered in the "Change Cart". The third party application B receives this activity because it is registered. The third-party application B can display a message to the user, such as "The discount will be applied if you also purchase the product X" or "The discount will be applied if you share this site".

As another example, a user “presses a like button” for something in third party application A (eg, via Facebook). The third party application A then sends an activity message to the website building system 30 regarding the activity type “Like Facebook”. The website construction system 30 forwards this activity to all third party applications 40 that are registered with the "Like Button" activity. The third party application B receives this activity because it is registered. The third-party application B presents a re-engagement widget to the user and asks, "If you like this site, why don't you contact the owner of the site?" or "Want a discount coupon?" A message such as "can be displayed.

As mentioned above, all communications can occur via hub 210 and hub 230.

The router 211 can route client-side messages between the website and any third party application 40. In addition, router 211 can route messages between hub 210 and hub 230 for further processing, as described in more detail below.

The router/tracker 231 can route messages between the website and any third party application 40 and can further track the messages. Further, it should be appreciated that the third party application 40 may listen for messages on both the client and server. Furthermore, it is understood that the third party application 40 can explicitly specify one or more activities that it listens to (eg, listens to all "shopping cart: add item" activities). I want to. In addition, the third party application 40 can specify the class of activity it listens to (eg, listens to all activities related to Facebook). Furthermore, third party applications can use wildcard expressions (applied to activity names) that are used to determine whether an activity should be sent to that third party application.

Further, it should be appreciated that the third party application 40 may use activity listener queries. Such queries refer to additional system information, including information not normally available from the third-party application itself, such as user attributes (eg registered users only, European users only), websites. Attributes or structure (eg listen to only certain activities on pages created from certain page templates), user history (eg only cart clearing if user has made more than X purchases in the past) Listen to activities) and so on. Such queries can be specified by the third party application 40, but can also be editable by the designer.

Therefore, the router/tracker 231 may also track messages being listened to by the third party application 40. Such an activity listener query architecture is best implemented at the routing level of the activity (rather than being executed by an API call inside the third party application 40) because it allows the website designer to It should be appreciated that the third party application 40 can perform adjustments and customizations without having to be highly programmable and customizable. In addition, the router/tracker 231 also helps protect the privacy of the user because the website designer needs to provide additional information (necessary for routing decisions) to the involved third party applications 40. This is because there is no In addition, the router/tracker 231 can prevent unwanted communication (often hosted by another server) with the third party application 40.

It is to be understood that it is the users (website visitors) who visit, register with, or provide information to the website. The user is actually aware that the website he is accessing is built using a combination of the website building system 30, components, the created website, and a third party application 40. Not always. Therefore, the responsibility for the privacy of the user ultimately lies with the owner of the website (and the owner is also responsible for the activities performed by the third party applications 40 included on his website).

Furthermore, the third-party application 40 (and other components of the website building system 30) may be able to interact with the user profile through the API provided by the website building system 30 based on the privacy rules defined by the website building system 30. Understand that you can access the information. Further, the containing site and the third party applications 40 contained therein can use the contact information to communicate with the user (via email or other means).

It should be appreciated that there can be three major privacy-related issues. The first issue is the interrelationship between the website and website building system 30 and the provider of the third party application 40. The website (and website building system 30) may not completely trust the third party application 40 with respect to the use of the user data, for example, the third party application 40 may (such as the user's email provided by the site). Do not send large numbers of emails (using your address), do not send spam emails to users who request you to remove them from your mailing list, or transfer your personal information to other third parties. Regarding that. However, this problem can be solved by the following method.

The vendor of the website building system 30 signs the terms of service (ToU) agreement with the provider of the third party application 40 when adding the provider of the third party application 40 to the application market of the website building system 30. Can be asked to. Such consent form may state that the third party application 40 (and the provider of the third party application 40) must not illegally use the user information or disclose it to a third party. it can. This allows the vendor of the website building system 30 to apply penalties to a third party application 40 provider if the provider of the third party application 40 misuses the information (eg, disables the third party application 40, The third party application 40 is deleted from the application market of the website construction system 30). Privacy policy enforcers 213, 233 and private data proxy 234 can enforce privacy policies for third party applications 40, as described in further detail below.

A second privacy related issue is the interrelationship between the website and website building system 30 and the user (site visitor). Websites must provide users with a clear understanding of how their personal data will be used, obtain their consent, and comply with the terms they have agreed to. The website construction system 30 requests all the published sites to present the user with the terms of use document that defines the permitted use of the personal information belonging to the user. In this case, the user You are required to digitally sign the document. The site must comply with these terms and permitted uses. Further, the website building system 30 can include a sample Terms of Use page in each website template it provides. The privacy policy enforcers 213 and 233 can ensure that the terms of use of the terms of use document are observed. Further, the privacy policy enforcers 213, 233 can delete or reorganize relevant data so that only authorized information is provided to third party applications.

A third privacy-related issue is supporting unsubscribe requests. The Site must provide you with the option to unsubscribe any marketing emails. This can be handled by the data/authorization handler 244, which is described in more detail below.

The data/authorization handler 244 can also handle different user permissions set by different users, as described in more detail below.

In the website building system 30 (and the websites built therein), the private data proxy 234 keeps all or some of the private data in a secure repository managed by the website building system 30. The private data proxy 234 can provide the third party application with an alternate unique ID (instead of private data), which the third party application can use to hide the hidden private Data can be acquired. For example, the email address may be provided to the third party application 40 by replacing it with an alternate "email address ID" so the third party application 40 cannot access the actual email address.

In addition, the private data proxy 234 can provide a set of interfaces for various communication methods (eg, email, social network messaging) that the third party application 40 can use to interface with the user. Can be contacted or a message sent to third party application 40 without actually accessing the private data associated with the user. Such private data may be any detailed identification information (eg name, address, e-mail address, telephone number (including SMS/MMS)) that can be used to contact the user, unified communication. ID (Skype etc.) and social network ID) are mentioned.

Therefore, the private data proxy 234 enforces user permission field restrictions, enforces user unsubscribe requests, and suppresses sending messages to users (e.g., certain operating sites at certain sites). It is possible to allow up to 100 e-mails per day for the third party application 40). The private data proxy 234 can define proxy parameters and private data (for each third party application 40) that is exposed to the third party application and private data that is not disclosed to the third party application, and these settings can be performed on a field-by-field basis.

The private data proxy 234 provides the third party application 40 hosted on the server of the website building system 30 with an alternative unique ID that is similar in shape to the original private data (eg, the user's original ID). An alternate dummy email address can be provided instead of the private email address) and the call that uses that information is "captured" and the email is (in this example) forwarded to the correct address. This feature can also be used to detect third-party applications 40 that have exceeded their authorized privileges.

It should be appreciated that website owners may wish to limit or modify the information provided to a particular third party application 40. Reasons for this include, for example, general security concerns, specific privacy commitments regarding any element of your data, and regulatory requirements specific to a particular industry or application. The privacy policy enforcers 213, 233 can implement such changes made by the website owner and overwrite the current settings.

As an example, a website that handles medical information may not access some of the detailed personal information of the contact information when passing the contact information to a third party application 40 that analyzes the general geographical distribution of users. You may want to As another example, certain third party applications 40 may have problems handling certain types of contact information. Website owners who want to use the third party application 40 as is (although the bug is known) want to exclude contacts that cause known problems or modify the data so that the problems do not occur. There is.

The translators/adaptors 212, 232 can apply pre-specified rules for translating messages and adapting content. For each such rule, a third-party application 40 to which the rule applies, filtering criteria that select messages to which the rule applies, conversion rules (eg, discard specific messages (related to a particular third-party application 40). Conditions), such as transformations that apply to a particular field or fields in the activity data structure.

In this way, the hub 210, 230 can provide different versions of the activity data structure (or not provide it at all) to different third party applications 40 according to the specifications created by the site owner.

In addition, the associated website building system 30 provides message protection in order to harden the system against failures and intrusion attempts (such as man-in-the-middle attacks aimed at tampering with the payload data of the messages of the third party application 40). Can support validation and signing of. Therefore, each third party application 40 registered in the website building system 30 can have two sets of private/public keys, one set being sent from the third party application 40 to the website building system 30. Used to decrypt the message (input key) and one set is used to encode the message sent from the website construction system 30 to the third party application 40 (output key).

For example, the third party application A sends a message to the website building system 30. This message is sent using the third party application ID at the site (external ID of the third party application (has third party application scope)) and the message is signed by the third party application. The website construction system 30 receives this message. The verifier/signer 235 verifies the signature using the input key of the third party application A. If this verification does not pass, the verifier/signer 235 reports the input message as invalid and the message is no longer sent.

The verifier/signer 235 can translate the external ID associated with the message using the internal site ID. The verifier/signer 235 can identify which third party application 40 should receive the message.

For example, the verifier/signer 235 can recognize the external ID of the third-party application B for each of the third-party applications B1 to Bn. The verifier/signer 235 then instructs the converters/adaptors 212, 232 to compose a message to the third party application B and apply the applicable filtering and conversion rules described above. The verifier/signer 235 then signs the message using the output key of the third party application B and sends the message to the third party application B via the router/tracker 231 (or router 211). Third party application B receives the message and verifies the signature. If the verification fails, the message is reported as invalid and cannot be processed further. It should be appreciated that the verifier/signer 235 performs only server-side processing, not client-side processing, so that secret verification data is not sent to untrusted clients.

As mentioned above, system 200 can employ multiple types of communication between website building system 30 and third party applications 40. Such communication includes, for example, control communication (eg, the website construction system 30 instructs the third party application 40 to shut down), and functional communication (eg, shopping cart third party application 40). Sends the total purchase amount to the billing third party application 40 through the website building system 30 (thus modifying the payment or activity communication in the example described in this application). Should be understood to have different profiles and requirements (eg, with respect to the amount of messages sent, priority, robustness, response time).

In particular, system 200 may have very frequent activity reports (eg, when a graphical user interface (GUI) event of third party application 40 is reported as an activity of third party application 40). Such huge activity reports can overwhelm parts of the system that handle more important messages. Thus, system 200 can implement multiple communication channels (eg, using different ports and multiple simultaneous sessions) such that each class of message is sent over a separate channel. In this way, the side channel is used for activity reporting and is done in parallel with the communication of instructions and the communication of functions, without interfering with the latter communication.

As mentioned above, the system 200 collects activity information for the purpose of creating and enhancing contact information via the contact coordinator 240 and the activity coordinator 250 and for matching activity events associated with a particular contact. You can Contact coordinator 240 and activity coordinator 250 can process information for each activity message routed through hub 210 and hub 230. The stream creator 251 may create a contact-specific data stream from the activity message, and multiple elements of the contact coordinator 240 may extract and process the data before storing it in the contact database 245. You can

Therefore, for each activity stream, it is possible to build a contact that is associated with each, and the built contacts are progressively quality graded using the data extracted from the activities performed under each data stream. Can be increased. It should be appreciated that the contact coordinator 240 may also be aware of the existence of related contacts (a plurality of contact records found to describe the same person). The contact identifier 272 can recognize such a record by matching the primary ID field (e-mail address, telephone number, social security number, Facebook ID, etc.). Some primary ID fields are multi-valued fields (eg, a person can have multiple email addresses identifying that person), while some primary ID fields are strictly It should be appreciated that it is a single valued field (eg social security number).

Therefore, the data merger 243 can merge the fields of the contacts extracted from the new activity into the contacts that are currently being constructed, giving the anonymous user the ability to use it while using the website. Contacts built against it can be merged into contacts that are already defined and stored once the anonymous user has performed the login action to become the identified user (this is called "vertical merge"). May be referred to as "). In addition, the horizontal contact merger 277 detects when two different contacts (built contacts or stored contacts) are related contacts that represent the same user. A "horizontal" merge of can be performed. As mentioned above, such a merge may be an actual merge (ie converting two individual contacts into one contact), or one contact into another contact, or through a virtual merge. Execute (ie keep the two contacts as separate contacts but link them together as shown to represent the same user, then merge the actual contact information and activity stream, or It can be done by not merging). Further, it should be appreciated that even in the case of virtual merging, additional additional information can be added to multiple contacts that are virtually merged and linked.

Accordingly, the data extractor 241 can extract contact type information from the associated activity data structure and the data merger 243 associates this contact type information with the activity stream (anonymous or identified). Can be integrated into contacts. If the contact type information I includes a primary ID field, the data merger 243 checks for contacts that are related to each other based on the value of the primary ID field, and if found, merges these contacts. .. In addition, the data merger 243 can check if the activity establishes the identity of the user within the site (eg, site login activity), and if so, an anonymous contact to the user. Merges with the existing contact record stored for it, making that contact a subsequently identified contact.

It should be appreciated that the contact identifier 272 can implement multiple methods for identifying site users. For example, use a cookie to track sessions by one anonymous user (not logged into the site), use site login for registered users, sites whose accounts are associated with social networks By using social login for users, by matching primary ID fields (such as email addresses and phone numbers) to identify that two user profiles describe the same user.

Furthermore, site users whose detailed information is stored in the contact database 245 include anonymous users who have not registered with the site, registered users, and potential users (not officially registered with the site yet. Not have, but have records imported from external sources).

Information related to the same contact record from multiple anonymous sessions running on the same computer using the same browser, as the relevant websites can install persistent cookies that persist across session changes. Can continue to get. Therefore, even anonymous users can have a significant amount of contextual and contact information.

Registered users must provide an ID that is unique at that particular site. Multiple types of IDs can be used, for example by unique IDs for individual sites (eg user name), external identifiers (email address, phone number, social security number, etc.) or by another system. The provided external identifier (social network ID, Google ID, OpenID ID, etc.).

User registration through login to a social network allows the site to populate the same user's site profile using personal information available on the social network. Further, the data extractor 241 can re-access the profile of the social network, detect any change in the personal information, and update the profile of the site user.

Registered users typically have to log in to the system to establish their identity, but the system can provide an option to "Keep Connected to This System." Such a login procedure may be explicit (the user invokes a login dialog) or implicit (for example, requiring the user to provide some identifying information when adding a post to the blog). ), or based on an external login (the system invokes a login procedure associated with another system, such as a social network login or an OpenID login). In addition, through physical devices (eg security tokens connected directly to the system or via a wireless interface) or using biometric information (user biometric parameters (eg fingerprint, iris scan) and user behavior detection). The login procedure may also be modified through (including both typing pattern detection, etc.) or through any combination of the methods detailed above.

Further, it should be appreciated that information can be exchanged in both directions between the social login procedure and normal login. For example, a social ID is associated with a site member ID, and thus social login is implicitly logging in to the site, or the site member ID can be associated with one or more social network IDs, thus Logging in to the site identifies the user on one or more social networks.

When a user performs an explicit logout, the contact handler 242 may create a new anonymous user cookie and thus open a new anonymous session (or series of sessions) whose activity is the new one. Saved under anonymous contact. At further login, this new anonymous contact can be merged with the contact identified at that login.

Referring now to FIG. 19, this figure illustrates the anonymous user login/logout process. The user can start using the system anonymously. When the user executes the first activity act1 in the third party application, the contact handler 242 creates a contact and the stream creator 251 automatically creates the activity stream anon1. The stream merger 252 merges the information from act1 and the information from the next activities act2 and act3 into the user anon1.

When the same user logs in as user X, the data merger 243 merges the contact of anon1 (and other relevant contact data obtained from the activity stream) with the contact information of user X. Further, it should be understood that the stream merger 252 merges the information extracted from the further activities act4 and act5 into one stream, and then the data extractor 241 extracts the contact information of the user X. When user X performs a logout, contact handler 242 creates a new cookie and disconnects subsequent activity from user X. Therefore, when the new activity act6 is executed, the contact handler 242 creates a new anonymous contact anon2, and the data extractor 241 newly creates the extracted contact detail information (and activity) of the contact. Save under anonymous contact anon2.

If user anon2 performs the second login as user Y (as in scenario A), data merger 243 will include contact information for user anon2 (updated by act6 and act7) along with further activities. To the contact detail information of the identified user Y.

If user anon2 performs a second login as user X (as in scenario B), data merger 243 will include contact information for user anon2 (updated by act6 and act7) along with further activities. Then, it is merged with the contact detail information of the user X (which has already been updated and reflects act1 to act5).

It should be appreciated that the activity data structure associated with the activity may also include contact details information. The data extractor 241 can extract this information and forward it to the data merger 243, which integrates this information with the existing contact information in the contact database 245 to create the existing contact information. You can improve the quality. Furthermore, the data extractor 241 can extract detailed information from a particular activity message, an entire stream, another contact, or an external source (such as an IP-to-geographic address translation service, which will be discussed in more detail below). I want you to understand. As mentioned above, contacts in the contact database 245 can be contact details provided by the user explicitly as part of the registration or sign-up process, or a website (via the social login/registration feature). It may also include contact details extracted from the social networking account used by the user when uploading or provided when the user updates their user profile. In addition, the data extractor 241 can also obtain contact information from an external source (eg, when a user specifies only a US zip code, the site uses this information to zip code decoding). Get full address information from an external web service).

As described above, the contact identifier 272 can recognize the two contacts as being related to each other based on the primary ID field (user name, email address, telephone number, etc.). When it is determined that contact A (new) and contact B (existing) are related to each other, data merger 243 can merge A into B (B is master). This process is performed using the following field merge rule, for example.

B1=B or A (eg “B||A”): Take B, and if B is null or empty, take A.

B1=Mathematical function (A, B): The important cases of private data are:

B1=A+B: For example, number of visits, total purchase amount B1=min(A,B): For example, registration date on the site B1=max(A,B): For example, date of the last activity

B1=list-unite(B,A): The list A is concatenated at the end of the list B, and the element that overlaps the element of B among the elements of A is deleted (that is, B1=B&(AB)). The data merger 243 can determine the duplication between the elements of the list according to the following rules.

For a list of regular values (ie scalars), use regular value comparison.

For a list of structs, use a particular subfield of the struct as the comparison key. For example, the type of address (home, company, shipping address, etc.) in the website construction system 30 that supports multiple addresses.

Normalized number comparison. See (for example) the processing of telephone numbers below.

If structure A is a more detailed version of structure B, then join A to B (discussed in more detail below).

Higher certainty score: A certainty score can be added to the value (for example, information provided directly by the user and information guessed about the user will have different certainty scores). To). The data merger 243 can select the value with the higher certainty score.

It should be appreciated that some field types have a normalized format. For example, a telephone number can be normalized to a normalized US format (eg (999)555-1234) or an international format (+1-999-555-1234). The data merger 243 may convert the field values to a normalized format for comparison when comparing, for example, the primary key of a contact (such as a phone number) or checking for duplicates in the merged list. it can.

The data merger 243 can compare two structured values having the same basic structure (eg, an address value consisting of multiple subfields (country, state, zip code, street, street address, etc.)). The value of each non-empty field in structure X is equal to the value of the same field in structure Y (ie, Y is the value of all non-empty fields of X, and possibly some Structure Y is a detailed version of structure X). Therefore, the data merger 243 can join A to B if A is a detailed version of B and A is not the same as B.

It should be appreciated that the data extractor 241 can infer the contact's address from the IP address from which the activity originated. This feature is used only if the activity originated in a browser session and the user's address has not been obtained. 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 marked as "estimated geographic IP address". Such marking is necessary because it conflicts with later address merging processes because the address field based on IP mapping (possibly incorrect) is already included in the address field. This is to prevent the detailed (though basically different) address from the above from being stored in the contact database 245.

The data merger 243 can also handle tag collisions in the merged list. It should be appreciated that when merging lists, there may be situations where there are two entities (one from contact A, the other from contact B) and these entities are different but have the same tag. In this scenario, the data merger 243 will include both entities with the same tag in the list.

Therefore, when the combination of [{tag: "home", e-mail: "a@b.com"}]+[{tag: "home", e-mail: "c@d.com"}] is performed, [[ {Tag: "home", e-mail: "a@b.com"}, {tag: "home", e-mail: "c@d.com"}] are created. Use this method if the fields to be merged are marked as "Allow non-unique list tags".

Further, the data merger 243 can use linguistic parsing, parsing, or other text parsing techniques, and referencing/using external data sources or services when attempting to combine contact information. For example, a user may enter a street name of a home address in two different formats in two activity records, with the same street number, city, and zip code. The combiner 273 can apply text parsing (eg, the soundex algorithm) when comparing the two entries, and additionally, two versions of the street name can be used to generate streets from an external source for a given city and zip code. Can be compared with the name. In such a case, the combiner 273 will use the standard if both addresses resemble a standard street name (but in some cases they are not), and all other address data fields have the correct values. You can select a typical street name.

Further, the data merger 243 can merge contact information according to login/session information. A user may use the site to initiate a session without performing a login or registration, perform some activity as part of that session, and later register or login, so the session is , Is associated with a newly created user profile or an existing profile (including contact information) of a registered user.

When a user initiates a session (as anonymous), the contact identifier 272 can track the user (using cookies, session ID, etc.) during the session, and the contact handler 242 can Based on the activities performed by the user during, a contact can be created that is built for that particular anonymous user. In addition, the router/tracker 231 can keep track of its anonymous users over multiple sessions from the same computer. This tracking can be done by using persistent cookies (rather than session cookies).

Once registered by the user, the data merger 243 can use the contact information constructed to make an initial entry in the user profile. When the user logs in, the data merger 243 can first combine the information of the constructed contacts with the existing user profile. The information of the constructed contact is merged according to the user's site ID, because the data merger 243 also has a primary ID (such as an email address) to use for merging in addition to the site ID of the constructed contact. It should be understood that this is because it is not retained in the information. Furthermore, it should be understood that such merges can cause inconsistencies in the information gathered. When merging anonymous structured contacts with existing profile data, there may be inevitable inconsistencies. For example, an anonymous user fills in a data form (displayed by some third-party application 40) with the name John Smith and then (using the same or another browser session) the name Jane Doe. Suppose you log in to your account with. In this case, the later login (for example) is a login that was actually made by another person using the same computer, or the first user used a pseudonym in the contact form to protect his privacy. It may have been done. The same applies when the data merger 243 merges multiple anonymous constructed contacts.

Conflict resolver 274 can generally handle conflicts automatically because most fields (including primary ID fields such as email addresses and phone numbers) are list fields that can contain multiple values. This is because. This can only be applied if the same underlying site is used multiple times. For inconsistencies that cannot be resolved (for example, by merging multiple values into a list value), the site owner or the end user can manually deal with it (you can decide which value to use), or It can be flagged so that it can be addressed using another approach.

Thus, the constructed contact information may reflect a set of users accessing the same site through the same computer, rather than a single person.

As mentioned above, the data merger 243 generally merges contacts according to the primary ID field (such as email address or phone number) when multiple contacts are created or modified.

The information entered is a contact record (contact C entered) having one or more primary ID fields with one or more values (eg, having two email addresses and three phone numbers). Contact record). Users may have (for example) home/work/mobile phone numbers and home/work e-mail addresses, and users may replace any of these in the contact form. Therefore, multiple primary ID fields may be required.

The data merger 243 normalizes the primary ID value and searches for a contact record that includes any of the normalized primary ID values (eg, “(telephone=P1 OR telephone=P2)” or “(email= E1 OR E-mail=E2)”) can be created. Further, the data merger 243 can limit the query to the contact database 245 of the particular site. Further, the data merger 243 can query the contact database 245 to obtain a list L of matching contacts (including the input contact C).

If the contact entered is a registered site member (of a particular site), the data merger 243 deletes contact C from list L and merges all remaining contacts in list L with contact C. You can The data merger 243 can then save the updated contact C back to the contact database 245 and delete all remaining contacts in the list L from the contact database 245. Alternatively, the data merger 243 can perform a virtual merge as described above, ie combine all contact information (ie all contact records to include all available information). , And mark the matching contact records (instead of removing the “duplicate” contact records) as belonging to the same person. Such processing is necessary because, for example, the internal ID unique to the contact record is stored or used by the third party application 40, and therefore, when the contact record is deleted, the third party application 40 does not operate properly. This is the case. The same process (i.e. marking contacts as related to each other rather than deleting them) can be applied in other cases as will be explained in more detail later.

If the entered contact is “not” a registered site member, the data merger 243 can check the number of site member contacts included in the list L. If the site member is 0, data merger 243 can remove contact C from list L and merge all remaining contacts in list L into contact C. The data merger 243 can then save the updated contact C back to the contact database 245 and delete all remaining contacts in the list L from the contact database 245.

If there is one site member (contact D), data merger 243 deletes contact D from list L and merges all remaining contacts in list L (including contact C) into contact D. You can The data merger 243 can then save the updated contact D back to the contact database 245 and delete all remaining contacts in the list L from the contact database 245.

If more than one site member contact (D, D1, D2,...) Is present, the data merger 243 selects contact D from the found site member contacts (D, D1, D2,...). , The contact D can be deleted from the list L. The data merger 243 can then create a sublist LL from the list L that includes contacts in the list L that are not site members. Data merger 243 can then merge all remaining contacts in list LL into contact D. The data merger 243 can then save the updated contact D again in the contact database 245 and delete all remaining contacts in the list LL from the contact database 245.

As mentioned above regarding merging at login, data inconsistency may occur. However, in most cases this problem occurs because the list value creator 275 can create list value fields (having multiple values) and can also define explicit priorities between contacts. do not do.

For example, the data merger 243 merges the following contacts.

Contact 1 = [Telephone 1, Email 1];
Contact 2 = [Telephone 1, Email 2];
Contact 3 = [phone 2, email 2];

The data merger 243 can generate the combined contacts as follows.

Combined contacts = [phone = [phone 1, phone 2], email = [email 1, email 2]].

It should be appreciated that the contact database 245 may include contact information from multiple sources with different levels of permission for use. Although the following discussion takes e-mail as an example, the discussion and techniques below describe any of the types of information (phone numbers, fax numbers, Skype IDs, instant messaging IDs, etc.) described above used to contact users. Social network IDs).

For example, the route that an email address is provided to a site may have different permissions regarding the use of that email address. Some possible ways to get an email address are registration ID, contact form, newsletter signup, unsubscribe request. Further, email addresses may differ in terms of "permitted use agreement" that is electronically signed by the user.

It should be appreciated that in general, the website construction system 30 has information regarding the permitted uses of a given email. However, the website owner may have different, personalized or additional information. For example, contacts from different sources due to the nature of the different sign-up forms within the site, or from different sources containing additional usage authorization information, are imported into the system by the website.

The data/authorization handler 244 can enforce the correct usage policies for the third party applications 40 used within the site in order to assist the website owner in managing this information.

Therefore, the contact record of the associated contact can include two information fields. The first field is the website permissions field that contains the permissions calculated or derived by the website from the user's activity or the proposed permissions. The contact form only implicitly specifies functional e-mail, while the subscription form implicitly specifies repetitive e-mail. The second field is a site owner permission field based on the value of the website permission field. The site owner can change the recommended permissions for the website and set them as he wishes, but is responsible for use beyond the permissions defined by the website permissions field.

It should be appreciated that the value of the website permission field represents the website's best perception of the user's intent. The value of the site owner permission field is the value assigned by the website and used by the third party application 40 and other parts of the system (eg, by the third party application 40 providing newsletter delivery).

The data/authorization handler 244 can use these authorization fields to define the authorization in multiple ways. For example, the data/authorization handler 244 may implement any of the following codes (for email addresses and other contact IDs), or combinations thereof, and variations thereof.

Unknown: The email address is extracted from an unknown source and cannot be used to send email.

Email ID: The email address provided for registration purposes. It cannot be used for the purpose of sending e-mail except for the contents related to registration (confirmation of registration, notification of suspected security violation if password is forgotten, etc.)

Functional emails: Allowed one-time emails provided for certain features. For example, a purchase confirmation email or an email provided for a particular contact form.

Repetitive Email: Allows certain websites to send multiple recurring subscriptions and advertisements. In this case, explicit subscription/approval is required.

Shareable e-mail: Allow that the web site and its partners (third-party application 40, other third parties (4 ^th parties)) sends a plurality of times regular subscriptions and advertising. In this case an explicit subscription/approval is required and can include detailed information about the shares allowed.

Opt-out: The user explicitly stopped the delivery. You will not be able to send email to that user (except in some cases except for opt-out notices).

The data/authorization handler 244 may use alternative methods, such as an authorization bitmask (similar to those used in UNIX and Linux systems) and ACL (access control list) mechanisms. I want you to understand. In addition, the data/authorization handler 244 may implement individual authorization fields that are targeted to individual portions of contact information (eg, email addresses, instant messenger addresses, social network IDs, etc.).

As a typical usage scenario, contact database 245 includes a first set of email addresses gathered from contact forms and a second set of email addresses from subscription requests. The website can call the newsletter-delivered third-party application 40. At this time, the third-party application 40 is “only” to the users (users who sent the subscription request) belonging to the second user set. I am aware of sending emails.

The advantage of such a system is that both websites and website owners (both technical and legal (In) and the ability to actually enforce a privacy policy when the system is used in combination with private data proxy 234 as described above. Further, the delivery stop request can be more strictly enforced.

Thus, a stream of activity between the associated website building system 30 and any associated third party application 40 can be generated for the user. These streams are sometimes referred to as activity streams. Each activity stream can be used as a source of information about one contact. Further, if it is determined that the origins of different activity streams are the same, the activity data structures of the individual streams can be merged to form a contact. For example, one user may perform an activity anonymously through two devices (a mobile device and a personal computer, etc.). Two anonymous streams are generated by such a user and messages are stored under these anonymous streams. Once they are recognized as being associated with the same user, they can be merged.

The processes and displays described herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used in combination with the programs according to the teachings herein, or it may be convenient to construct a dedicated device to carry out the desired method. The desired structure for a variety of these systems will be apparent from the description above. Moreover, the embodiments of the present invention are not described with reference to a particular programming language. It should be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.

As will be apparent from the foregoing description, unless otherwise specified, the description using terms such as “processing”, “calculating”, and “determining” is used throughout the specification. Computer system or similar electronic computing device (data represented as a physical quantity, such as an electronic quantity in a register or memory of the computing system, a memory, register, or other such information storage device of the computing system, It is to be understood that it means an operation or a process of a transmitting device, a device for operating or converting into another data which is similarly expressed as a physical quantity in a display device.

Embodiments of the invention may include devices that perform the operations or operations described herein. This device may be specially constructed for the desired purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. it can. Such a computer program may be a computer-readable storage medium, such as, but not limited to, a disc of any type (floppy (registered trademark) disc, optical disc, magneto-optical disc, etc.), read-only memory (ROM), compact disc. Read Only Memory (CD-ROM), Random Access Memory (RAM), Electrically Programmable Read Only Memory (EPROM), Electrically Erasable Programmable Read Only Memory (EEPROM), Magnetic or Optical Card, Flash Memory, or Electronic It may be stored on any other type of medium suitable for storing instructions and capable of being coupled to a computer system bus.

While we have shown and described specific features of the present invention, numerous modifications, substitutions, alterations and equivalents will be apparent to those of ordinary skill in the art. Therefore, it is to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true concept of the invention.

[Related application]
This application claims priority to US Provisional Patent Application No. 61/911,485 (filing date: December 4, 2013), which is incorporated herein by reference in its entirety. ..

Claims (24)

A system for a website,
A database that stores current contact information for at least the users of the website;
An activity coordinator for receiving at least one activity message exchanged between the website and at least one third party application embedded in the website;
A contact coordinator that collects contact-related information from the at least one activity message for at least one of the user of the website , a new contact, and an anonymous contact, and constructs a contact profile accordingly. ,
Equipped with
The contact coordinator from the contact profile, wherein updating the database with the current contact related information updated for one person, to create a new contact information for the new contact and the anonymous contact from the contact profile ,system. The activity coordinator is
A stream generator that identifies the contact associated with the at least one activity message and generates an activity stream of data if the contact does not exist.
A stream merger that merges data from the at least one activity message into an existing stream and merges data from at least two activity streams into a stream;
The system of claim 1, comprising at least one of: The contact coordinator is
A data extractor for extracting the contact related information from at least one of the at least one activity message, the activity stream, the current contact information for the contact, and an external source;
A data merger for merging at least two contact information records having an association with the same identified contact, and for merging existing contact information with the extracted contact related information according to a predefined merge rule; ,
A contact handler for generating at least one of identifiable new contacts and anonymous contacts to track contact activity during the website session;
A data/authorization handler that handles privacy protection and authorization of the extracted contact-related information,
The system of claim 2, comprising: The system of claim 1, which can be implemented on a client. The system of claim 1, wherein the at least one third party application is at least one of a social network, an interface to a social network, and interfaces to social network messaging software and instant messaging systems. The system of claim 3 , wherein the data extractor stores the extracted contact detail information under a newly created anonymous contact. The data merger is
Identifying the same primary ID field value in at least two of the contact information records and identifying a primary key field value in at least two of the contact information records that are the same when normalized. Use cookies to identify users of the site, use site logins for registered users to identify users of the site, and of sites that have accounts associated with social networks. Identifying a user of the site via a social login for the user, and a contact identifier for performing at least one of:
A combiner for combining contact information using at least one of linguistic parsing, parsing, and text parsing and referencing and consuming external data sources and services.
A conflict resolving device for resolving conflicts between contact records according to a predefined rule,
A list value builder that creates a list value field and defines a clear priority among the contact records,
A horizontal contact merger that merges two unrelated contacts due to a common primary ID being detected;
A vertical contact merger that merges contacts associated with registered users with anonymous contacts, merges with anonymous contacts at login or registration,
The system of claim 3, comprising at least one of: The stream merger is
An activity-stream merger that merges the data into the stream associated with the identified contact, and a stream-stream merger that merges at least two separate streams into one stream;
The system of claim 2, further comprising: The stream-stream merger is
A horizontal stream merger for merging at least two separate streams according to an identified common contact;
A vertical stream merger that merges the stream created for the anonymous contact with the stream associated with the registered contact upon login or registration that links the registered contact with an anonymous contact.
9. The system of claim 8, comprising at least one of: The horizontal contact merger comprises a virtual merger that maintains at least two contact records separately and links two contacts so that the two contacts are shown to represent the same contact. System. The vertical contact merger maintains an anonymous contact and a contact associated with a registered user separately, wherein the anonymous contact and the contact associated with the registered user represent the same contact. 8. The system of claim 7, comprising a virtual merger that links two contacts as shown to be present. A Subscriber authorization field is at least one of which is determined by the owner of the determined is and the website by the website,
The system according to claim 2. A method for a website,
Storing current contact information for at least the users of the website;
Receiving at least one activity message exchanged between the website and at least one third party application embedded in the website;
Collecting contact-related information from the at least one activity message for at least one of the user of the website , a new contact, and an anonymous contact, and constructing a contact profile accordingly ;
Equipped with
Constructing the contact profiles, the from contact profiles, the updates the database with current contact related information updated for one person, the new contact information for the new contact and the anonymous contact from the contact profile A method comprising: creating a . Receiving the at least one activity message comprises:
Identifying the contact associated with the at least one activity message, and generating an activity stream of data if the contact does not exist.
Merging data from the at least one activity message into an existing stream and merging data from the at least two activity streams into a stream;
14. The method of claim 13, comprising at least one of: Gathering the contact-related information and building a contact profile includes:
Extracting the contact-related information from at least one of the at least one activity message, the activity stream, the current contact information for the contact, and an external source;
Merging at least two contact information records having an association with the same identified contact, merging existing contact information with the extracted contact related information according to a predefined merge rule,
Generating at least one of identifiable new contacts and anonymous contacts to track contact activity during the session of the website;
Processing the privacy protection and authorization of the extracted contact-related information;
15. The method of claim 14, comprising: 14. The method of claim 13, which can be implemented on a client. 14. The method of claim 13, wherein the at least one third party application is at least one of a social network, an interface to a social network, and interfaces to social network messaging software and instant messaging systems. 15. The method of claim 14, wherein extracting the contact related information comprises storing extracted contact detail information under a newly created anonymous contact. Merging the at least two contact information records and merging the extracted contact related information comprises:
Identifying the same primary ID field value in at least two of the contact information records and identifying a primary key field value in at least two of the contact information records that are the same when normalized. Use cookies to identify users of the site, use site logins for registered users to identify users of the site, and of sites that have accounts associated with social networks. Performing at least one of identifying a user of the site via a social login for the user;
Combining contact information using at least one of linguistic parsing, parsing, and text parsing and referencing and consuming external data sources and services.
Resolving conflicts between contact records according to predefined rules,
Creating a list-valued field and defining a clear priority between the contact records;
Merging two contacts that are not related to each other due to the common primary ID being detected,
Merging a contact associated with a registered user with an anonymous contact, upon login or registration, merging the anonymous contact with the contact associated with the registered user;
16. The method of claim 15, comprising at least one of: Merging data from the at least one activity message into an existing stream and merging data from the at least two activity streams into a stream is
Merging the data into the stream associated with the identified contact;
Merging at least two separate streams into one stream;
15. The method of claim 14, further comprising: Merging the at least two separate streams into one stream is
Merging at least two separate streams according to the identified common contacts;
Merging a stream created for the anonymous contact with a stream associated with the registered contact at login or at registration, which associates the registered contact with an anonymous contact, and
21. The method of claim 20, comprising at least one of: Merging two unrelated contacts is
Maintaining at least two contact records separately, and
Linking the two contacts so that the two contacts represent the same contact, and
20. The method of claim 19, comprising: Merging the anonymous contacts
Maintaining separate anonymous contacts and contacts associated with registered users;
Linking the two contacts such that the anonymous contact and the contact associated with the registered user represent the same contact;
20. The method of claim 19, comprising: A Subscriber authorization field is at least one of the determined by the owner of and the website is determined by the web site The method of claim 14.

Images