JP2024023313A - System and method for website - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a system for a website hosted by a website construction system.

SOLUTION: A server of a website construction system 200 is provided with an activity coordinator including: a stream generator for generating a contact coordinator including a contact handler for generating anonymous user ID for an anonymous user and an activity stream for an activity message to be associated with the anonymous user ID, and storing the activity message in an activity database as a first message of a sequence related to the activity stream in the case that contact is identified as the anonymous user ID first; and a stream merger having a function for adding further activity messages of the anonymous user to the activity stream to be associated with the anonymous user ID and a function for combining a plurality of activity streams with the anonymous user ID.

SELECTED DRAWING: Figure 15

COPYRIGHT: (C)2024,JPO&INPIT

Description

FIELD OF THE INVENTION The present invention relates to online applications and, in particular, to methods of use in combination with third party applications included therein.

Many website building systems and other interactive application building tools are commercially available 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 come in a variety of 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 an accessed completely online website building system. The creation, editing, and deployment of these website building systems are all performed by direct online operations by the server.

Website building systems can also be partially online or completely online. For partially online systems, website edits are performed locally on the user's machine and later uploaded and deployed to one or more central servers. Once a website is uploaded, these website building systems function like fully online website building systems.

A website building system has an internal data architecture for the purpose of organizing 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 manner in which typical HTML (hypertext markup language) pages are delivered to the browser. For example, the internal data architecture may include additional properties for each element on the page (author, creation date/time, permissions, link to template, etc.), and these additional properties are used by the website building system It is essential for editing and maintaining the site internally, but is invisible to external end users (and in some cases, some of the users who make the edits). The general architecture of a site based on a website building system can consist of pages that contain components (e.g., shape components, photo components, text components, as well as single-page containers and multi-page containers with mini-pages, etc.). can.

A component can be contentless, such as a star that has no internal content (but has color, size, position, and other attributes), or it can have internal content, such as a text paragraph component, and The internal content of such components includes font, formatting, and layout information in addition to the displayed text. Of course, this content may vary from text paragraph component to text paragraph component.

Designers using such website building systems can either design a new site from scratch (starting with a blank screen) or use predefined sites created by themselves, system creators, 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 mini-pages) 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, adding, removing, or modifying any element of the template to create his or her own version of the template. Such customization can be performed by creating a modified version of the template (a separate version that is different from the template). Alternatively, the website building system can apply the customizations through an inheritance-type mechanism, which maintains a link to the original template and thus allows subsequent changes to be made to the template. The changes will be reflected.

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

Third-party applications may include any combination of front-end (display) and back-office elements that are not visible on the website. Third-party applications can be entirely back-office (i.e., do not contain display elements), or entirely front-end (i.e., launched only when used by the website), or a combination of the two. be.

Back-office elements of third-party applications may include functionality such as database communication options and external update options. For example, third-party applications for blogs can come from non-human sources (e.g., RSS news feeds from major news services) and from human sources unrelated to the website (e.g., stand-alone applications that allow you to post blog entries). It may include back-office elements that can receive updates from (smartphone applications).

Incorporating visual elements from third-party applications into the websites in which they are included can be accomplished in a variety of ways. A widget-type third-party application can be embedded as a component inside a website page, whereas a section-type third-party application can be added as one or more additional pages to a website. .

Additionally, third-party applications (both widget types and section types) can be single-page third-party applications, or multi-page third-party applications (with internal mini-pages represented as internal URL structures). . The system may implement one or more or all of the four possible combinations (widgets or sections, single page or multipage).

Multi-page third-party applications typically provide a default "landing" mini-page that includes an opening page, a specific internal mini-page (e.g. the latest blog entry in a blogging third-party application), a mini-page A page selection screen or other mini-page.

The use of third party applications in websites based on the website building system is done through instances of third party applications. A website building system can support multiple uses of third-party applications at multiple levels, for example, allowing one instance of a third-party application throughout the website, multiple third-party applications inside the website, etc. Allow to create instances of a third-party application (but only one instance per third-party application), Allow to create multiple instances of multiple third-party applications (but only one instance per page) ). Additionally, multiple instances of component-type third-party applications (not section-type third-party applications) may be allowed per page, and further, without any restrictions on the number, multiplicity, or location of third-party application instances. You can also allow multiple instances of multiple third-party applications to be created.

Instances of third-party applications may have instance-specific content. For example, a third-party application of an online shop (e-Shop) may have a product database associated with a particular instance, and this product database (within the same site or another site) can be used by a third-party application of the same online shop Different from the product database, which is associated with another instance of the application.

For purposes of explanation, the website page (or minipage) that contains the Third Party Application and its minipages or elements (i.e., "wrapper page") shall be referred to as the containing web page, and It shall be known as the main site. The integrated page (including the main page and embedded TPA mini-pages/components) that is presented to the user is referred to as a composite page. For section-type third-party applications, the "virtual page" containing the third-party application serves as the containing web page.

Third party applications are typically deployed on the website building system vendor's servers, on the third party application vendor's servers, on external (fourth party) servers, or on any combination of these servers. A third-party application is an element that actually runs on an end user's machine (for example, a statically installed browser extension or a dynamically installed component inside the client-side code of a website building system, as shown in Figure 1). (e.g., a JavaScript® component that is executed on the computer). Reference will be made to FIG. 1 below.

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

Instances of included third-party applications can have their own internal content, just as regular components have internal content. Referring to Figure 2, as shown in this figure, third-party applications can manage this content independently of the website building system and the websites generated using the website building system. can. Multiple instances of one or more third party applications may have shared content; for example, two online shop instances on two separate website pages may reference the same product database.

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

Server-side processing: (See Figure 3 below.) In this method, illustrated in Figure 3, a third-party application [a] (including design and display elements) and a user-specific third-party application Data [b] is merged by the third party application's server code [c] running on the third party application vendor's server [d]. These are sent via the communication medium [e] to the server code [f] of the website building system, which, after merging them with the information [g] of the containing web page, transfers them to the user's Send it so that it can be displayed on the client station [h].

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

iFrame inclusion: (See Figure 5 below.) In the method shown in Figure 5, a third-party application [a] (including design and display elements) and a user-specific third-party application data [b] are merged by the third party application's server code [c] running on the third party application vendor's server [d]. 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 building system sends the containing web page information [g] to this browser-based application [h]. A containing web page is created as a web page that includes one or more iframe directives that include content from the third party application's server [d]. Additional and alternative methods are also applicable.

US Patent Application Publication No. 2013/0219263

According to a preferred embodiment of the invention, a system implementable on a website via a client/server system, the client/server system comprising at least one processor for processing instructions defining the system. system. The system includes at least one hub for coordinating at least one activity message between a website and at least one third party application, the at least one activity message having a standardized format. hub, including. Additionally, the system includes an activity coordinator that listens for at least one activity message and at least adds data extracted from the at least one message to a stream associated with at least one of the identified contact and the anonymous contact. and an activity coordinator, wherein at least one of the identified contact and the anonymous contact is a user of the website. In addition, the system provides contact coordinators and contact coordinators who retrieve and analyze contact-related information from streams to improve the quality of previously maintained information for contacts, and activity streams and contact-related information for use by websites and contacts. at least one database storing information.

Further, according to a preferred embodiment of the invention, the at least one hub includes a router and tracker that routes and tracks 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 prespecified message transformation/content conformance between the website and the at least one third party application. a user authorization field between the website and at least one third-party application; a private data proxy that validates the signature of at least one activity message using an input key of at least one third-party application and that enforces restrictions on an external application that is associated with the at least one activity message; a verifier/signer that converts the ID using an internal website ID and signs the outgoing at least one activity message using an output key of the at least one third party application; including one.

Further, according to a preferred embodiment of the invention, the activity coordinator includes at least one stream creator for identifying a contact associated with at least one activity message and creating a stream of data if there is no associated contact. a stream merger that merges data from two activity messages into an existing stream, merges data from at least two of the activity streams into one stream, and records activity data from the activity streams into at least one database; at least one of: a log generator for generating a log;

Further, according to a preferred embodiment of the invention, the contact coordinator includes a data extractor for extracting contact-related information from at least one of at least one activity message, a stream, another contact, an external source; A data merger that merges two contact information records and merges the extracted contact-related information with the related information of an existing contact according to predefined merging rules, the data merger comprising: a data merger, a contact handler, and a contact handler, which creates new identifiable contacts and/or anonymous contacts, and tracks the contact's activities during the website session; a data/permission handler for handling privacy protection and permissions for the data/permission handler.

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

Further, according to a preferred embodiment of the invention, the stream merger merges at least two separate streams with an activity-to-stream merger that merges data into a stream associated with the identified contact. a stream-to-stream merger to merge into one stream.

Further, according to a preferred embodiment of the present invention, the stream-stream merger includes a horizontal stream merger that merges at least two separate streams according to an identified common contact, an anonymous contact, and a registration. A vertical stream merger that merges the stream created for an anonymous contact with the stream associated with a registered contact when the contact is associated at login or registration. , at least one of the following.

Further, according to a preferred embodiment of the present invention, the data merger is configured to identify normalized primary ID field values in at least two of the contact information records that identify the same primary ID field value in at least two of the contact information records. Identifying primary ID field values that are the same when users use cookies to identify site users; identify site users using site logins if they are registered users; a contact identifier that performs at least one of: identifying a site user through a social login if the site user has an associated account; Furthermore, the data merger includes a combiner that combines contact information using at least one of linguistic parsing, syntax parsing, and text parsing, and referencing/utilizing external data sources and external services; A conflict resolver that resolves conflicts according to predefined rules; a list value generator that creates list value fields and defines clear priorities between contact records; and a common primary ID is detected. horizontal contact merger, which merges two unrelated contacts, when an anonymous contact and a contact associated with a registered user are combined at login or registration. , a vertical contact merger that merges anonymous contacts with contacts associated with registered users.

Further, according to a preferred embodiment of the present invention, the horizontal contact merger maintains at least two contact records as separate records, and the horizontal contact merger maintains at least two contact records as separate records, such that the two contact records are 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 maintains anonymous contacts and contacts associated with registered users as separate contacts. and a virtual merger that links together such that contacts shown represent the same contact.

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

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

According to a preferred embodiment of the invention, a method implementable on a website via a client/server system, the client/server system comprising at least one processor for processing instructions defining the method. provide a method. The method includes the steps of 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; listening to activity messages and at least adding data extracted from the at least one message to a stream associated with at least one of the identified contact and the anonymous contact; at least one of the contacts is a user of the website. Additionally, the method includes the steps of: retrieving and analyzing contact-related information from the stream to improve the quality of previously maintained information for the contact; and storing.

Further, according to a preferred embodiment of the invention, the step of coordinating includes the steps of: routing and tracking at least one activity message between the website and the at least one third party application; enforcing a privacy policy between the application and the at least one pre-specified message transformation/content adaptation rule between the website and the at least one third party application; and a private data proxy. implementing at least one of the following: and private data replacement; and implementing user permission field restrictions between the website and the at least one third party application; verifying the external ID associated with the at least one activity message using the third-party application's input key and converting the external ID associated with the at least one activity message using the internal website ID; signing using the application's output key.

Further, according to a preferred embodiment of the invention, the step of listening to and adding at least includes the step of identifying a contact associated with the at least one activity message and creating a stream of data if there is no associated contact; 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 activity data from the activity stream into at least one database. and at least one of the following steps.

Further, according to a preferred embodiment of the invention, the obtaining and analyzing step includes extracting contact-related information from at least one of at least one activity message, a stream, another contact, an external source; merging two contact information records and merging the extracted contact related information with the related information of an existing contact according to predefined merging rules, the step of merging two contact information records with the same identified contact; and at least one of the following steps. Further, the retrieving and analyzing step includes creating new and/or anonymous contacts, tracking the contact's activities during the website session, and protecting the privacy of the extracted contact-related information. and processing authorization.

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

Further, according to a preferred embodiment of the invention, the step of merging includes merging data into a stream associated with the identified contact, and merging at least two separate streams into one stream. .

Further, according to a preferred embodiment of the invention, merging the data into a stream associated with the identified contact and merging at least two separate streams into one stream comprises: , a horizontally merging step according to a common contact identified, and an anonymous contact created for an anonymous contact when the anonymous contact and a registered contact are combined at login or registration. vertically merging the stream associated with the registered contact with the stream associated with the registered contact.

Further, according to a preferred embodiment of the invention, the step of merging at least two contact information records includes the step of identifying the same primary ID field value in at least two of the contact information records; identifying the primary ID field values of the at least two that are the same when normalized; using a cookie to identify the site user; using a site login in the case of a registered user; and, in the case of a site user with an account associated with a social network, identifying the site user through a social login. Further, the step of merging the at least two contact information records includes combining the contact information using at least one of linguistic parsing, syntactic parsing, and text parsing, and referencing/utilizing external data sources and external services. resolving conflicts between contact records according to predefined rules; creating list-valued fields to define clear priorities among contact records; and detecting common primary IDs. The step of merging two unrelated contacts horizontally and the step of horizontally merging two contacts that are unrelated to each other, and when an anonymous contact and a contact associated with a registered user are combined at login or registration, vertically merging the contacts with contacts associated with the registered user.

Further, according to a preferred embodiment of the present invention, the step of horizontally merging maintains the at least two contact records as separate records, such that the two contact records represent the same contact. virtual merging by linking the two contact records together.

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

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

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

The subject matter considered to be the invention is particularly pointed out and distinctly described in the concluding portion of the specification. However, a better understanding of the invention, both as to its organization and method of operation, as well as objects, features, and advantages of the invention, may be gained by reading the following detailed description when taken in conjunction with the accompanying drawings. Can be done.

Schematic diagram of a deployment configuration between a website building system and a third-party application Schematic diagram of internal content management for third-party applications Schematic diagram of including third-party applications in a containing web page through server-side processing Schematic diagram of including third-party applications in a containing web page through client-side processing Schematic diagram of including a third-party application in a containing web page by iframe inclusion Schematic diagram of display of existing non-optimal third-party applications when changing page layout Schematic diagram of a system for integrating a website building system and one or more third party applications constructed and operative in accordance with the present invention Schematic diagram of a system for integrating a website building system and one or more third party applications constructed and operative in accordance with the present invention Schematic diagram of the document object model compared to the component model Schematic diagram of a blog multipart third-party application example Schematic diagram of an example modular third-party application for sale Schematic diagrams of different implementations of communication hubs constructed and operative according to the invention Schematic diagrams of different implementations of communication hubs constructed and operative according to the invention Schematic illustration of elements of the communications hub of FIGS. 11A and 11B constructed and operative in accordance with the present invention A schematic diagram of a communications conversion process performed by the communications hub of FIGS. 11A and 11B constructed and operative in accordance with the present invention. Schematic illustration of a containing web page featuring a third party application with an associated template constructed and operative in accordance with the present invention Schematic illustration of a web page containing a third party application with an associated template inside a minipage, constructed and operative in accordance with the present invention Schematic illustration of a system constructed and operative in accordance with the present invention that coordinates and collects data from various messages exchanged between a website building system and one or more embedded third party applications Schematic diagram of elements of the system of FIG. 15 constructed and operative in accordance with the present invention. Schematic diagram of elements of the system of FIG. 15 constructed and operative in accordance with the present invention. Schematic diagram of elements of the system of FIG. 15 constructed and operative in accordance with the present invention. Schematic diagram of elements of the system of FIG. 15 constructed and operative in accordance with the present invention. 1 is a schematic illustration of an example graphical user interface constructed and operative in accordance with the present invention for displaying an activity stream associated with a contact; Schematic diagram of message passing for client-side and server-side third-party application activity messages Schematic diagram of the login/logout process during a user's website session

It is to be understood that, for clarity and clarity of illustration, the elements illustrated in the drawings have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Furthermore, where considered appropriate, corresponding or similar elements may be represented by the same reference numerals in the several figures.

In the detailed description that follows, extensive specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be understood by those skilled in the art that the 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.

Applicant acknowledges that there are a number of limitations in the current manner in which third party applications are generally integrated into website building systems and in the current manner in which integrated third party applications interact with website building systems. I recognized it.

Such limitations include limiting the display of the third party application to one rectangular area inside the containing web page (this area is contained in an iframe). Further limitations include the size and position of the third-party application's windows and the use of visual elements that are outside of the third-party application's actual display window (e.g., dedicated display frames around the third-party application's window). One example is the ability to control.

Third party applications may have their own display styles (color schemes, fonts, font sizes, etc.). These styles may work well on some containing web pages, but may be visually problematic or inconsistent on other containing web pages.

Another limitation is the lack of flexibility in viewing third party applications in terms of containing sites. If your site must be visually modified (for example, due to deployment to platforms with different screen sizes, or due to dynamic layout events), you may want to resize windows assigned to third-party applications. may be required to contain web pages. In such cases, the display of the third party application is truncated and scrolling via a scroll bar is required to reach various sub-areas in the third party application. Referring to FIG. 6, this figure shows an example of a situation that may occur when the containing web page [a] is resized. Due to the reduced space allocated to the online shop's third-party application [b], the "Purchase" button [c] cannot be displayed together with the contents of the shopping cart [d] in order to complete the purchase. Multiple scrolling operations are required, greatly reducing the likelihood that the purchase will actually be completed.

It should be appreciated that third party applications cannot interact with other components within the containing web page, and such interaction may be required to accomplish 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 that streams online cooking classes. Users want to have a small screen area dedicated to delivering the latest news and weather information (such as a live stream from CNN) in a separate area of the screen in the background while they are watching a video. There is. Users may want their learning session to be automatically paused when the weather forecast for their area begins.

Moreover, there is no clear and standard way for third-party applications to cooperate with each other, especially when these 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 the case of an e-commerce website that runs a module of a third party ordering system and a different module of a shipping system. It may be desirable to order products according to a shipping schedule or the like.

Applicants provide structured bidirectional communication between a website building system and third party application instances contained therein, and between multiple different third party application instances that may be implemented within the same containing page. It has been recognized that this integration can be achieved by using directional communication channels. 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-in or integrated into modern browsers and does not require writing dedicated integration code. I want you to understand. Additionally, the iframe inclusion method provides browser-supported encapsulation and sandboxing capabilities, as well as inherent protection against hacking techniques such as cross-site scripting attacks that can be employed by malicious third-party applications. Ru.

Reference is now made to FIGS. 7A and 7B, which illustrate a system 100 for integrating a website building system and one or more third party applications, according to embodiments of the present invention. FIG. 7A shows the system 100 at the design stage, and FIG. 7B shows the system 100 at runtime. As can be seen in FIG. 7A, the system 100 includes a client 10, a website building system 30 installed on a website building system (WBS) server 20, and one or more third party application servers 50. one or more third party applications 40. 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 can include a searcher 26). There is. The client 10 includes a page composer 12 and a client-side display of a TPA property sheet 23. In some embodiments, client 10 may further include a client-side representation of AppStore 25. The page composer 12 includes a linker 13, which will be explained 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, templates, etc. of the third party application 40 so that they can be used. . Note that the system 100 may include multiple third party servers 50 belonging to multiple vendors of third party applications 40.

It should be appreciated that TPA property sheet 23 may be invoked when attributes of an instance of third party application 40 are specified. Furthermore, it should be understood that when invoked, TPA property sheet 23 is displayed as a client-side representation of TPA property sheet 23 at client 10. Furthermore, it should be appreciated that offline embodiments may have their own property sheets as part of the installed client software, and thus there is no application TPA property sheet 23 or repository.

A designer or end user 5 sitting in front of a client 10 uses a page composer 12 to create website pages and interactions (inter-page interactions and intra-page interactions). or other online applications). The designer 5 can select components, templates, etc. that are part of the website construction system 30 and are stored in the application repository 22 via the WBS coordinator 21. Furthermore, the designer 5 can create a containing web page 203 that embeds an instance of the third party application 40 from the third party application 40, which can be purchased in advance and whose templates, components, etc. 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, third party application 40 templates, components, etc. may be purchased via AppStore 25 as needed. Property sheet 23 can be specified by designer 5 and can hold information about the purchased instance of third party application 40 (permissions, installation guides, payments, etc.), as will be explained in more detail below. Furthermore, the designer 5 can use the linker 23 to manually specify communication channels (if necessary) between the included third party applications 40. Additionally, it should be appreciated that the designer 5 can use the linker 23 to specify specific communication connections and rules between the containing web page it is building and the instance of the third party application 40 contained therein. (Videos and CNN news reports are displayed simultaneously as described above, etc.). It should be understood that links created by linker 23 may be modified during the life of the website.

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 the vendor of the third party application 40 or an external vendor. In such a case, the website building system 30 stores the third party application 40 and its configuration data when the third party application 40 is first installed on a website created by the designer 5 through the website building system 30. data) can be registered.

To enable linker 23 to establish a communication channel if necessary, third-party application 40 must connect a component (an instance of another third-party application 40) within containing web page 203 (with which it wishes to communicate). It should be understood that it is necessary to be able to correctly recognize and identify In the case of associated template-based components (described in more detail below), this identification is previously performed by the vendor of the third party application 40. Components within associated templates can be given unique reference IDs, and third party applications 40 can use these IDs when communicating with these components.

Additionally, in the case of a multi-part third-party application 40 (i.e., one third-party application 40 distributed across multiple iframes) (described in more detail below), the multiple parts may automatically know how to communicate with each other. I want you to understand that I can do it.

For any included website page components (described in more detail below) that are not included in the associated template, the third-party application 40 may require (required or optional) that be present in order for the third-party application 40 to function. ) may include a list of components of the containing web page 203. This list can be stored in the property sheet 23 and includes a unique ID, a description, and details of the component (e.g. it must be a text component, to be used as a blog talkback label). can include. This list can be enumerated in the entry of the third party application 40 to the AppStore 25, and the designer 5 uses the linker 23 to create components (fields) in the containing web page 203 that meet the requirements of the third party application 40. can be specified. Website building system 30 can dynamically create missing components of containing web page 203 when an instance of third party application 40 is created, and designer 5 can later create these components. It should be understood that it can be moved, resized, and fully specified.

Alternatively, website building system 30 may expose all or part of the component model of containing web page 203 to third party application 40 included in containing web page 203. It should be understood that the component model in this case is the component model of the containing web page 203 and 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 includes some of the infrastructure of the website building system 30. This is because a large number of HTML elements (both hidden and visible) may be included that support the components of the containing web page 203. Therefore, the component model is much simpler.

Next, referring to FIG. 8, FIG. 8 shows multiple HTML constructs (a partially enclosing div tag [b], an internal div tag [c], a frame "mini widget" [d1]... [d5], etc.) It shows how to implement text component [a] using . The DOM model [e] of the containing web page 203 may include separate DOM tree nodes for each of these sub-elements. The component model [f] can be much simpler and includes only one component node [g].

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

Additionally, links (e.g., broadcast links) between containing web pages 203 and instances of third-party applications 40 may be automatically created, where third-party applications 40 send communications at runtime to identify It is understood that events may be recorded. This communication may be optional or required (i.e. the third party application 40 will not function or install unless there is a corresponding third party application 40 linked to receive such messages). ). For example, the third party application 40 may broadcast information packets regarding the operations/functions it performs, and the installed logging third party application 40 may receive these information packets.

The newly created page with the settings completed 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 in FIG. 7A, except for the client 10 elements. At runtime, the client 10 is equipped with a viewer 201 for displaying the containing web page 203. It should be appreciated that viewer 201 may include multiple viewports 202, each for displaying a different instance of third party application 40 (instances derived from one or more third party applications 40). Additionally, the client 10 includes a communications hub 205 that facilitates communications and backing between the containing web page 203 and the third party application 40 that the containing web page 203 hosts. Channels and required communications between hosted third party applications 40 are provided without connection to the associated containing web page 203. The functions of the hub 205 will be explained in more detail later.

The hub 205 may 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 route these communications between the client and the server. It should be understood that this is because round trips should not be delayed. In an alternative embodiment, the hub 205 is implemented in the server 20 of the website building system if the third party application server 50 needs to exchange large amounts of data and it is preferable not to pass this data through the client 10. be able to.

It will be appreciated that communications hub 205 can support various combinations of communications between website building system 30 and one or more third party applications 40 and between multiple third party applications 40. sea bream. For example, hub 205 allows third party application 40 to request website building system 30 to switch to another page within the main site. Additionally, communication hub 205 allows third party applications 40 to request that their windows be resized (which may potentially affect the layout of the containing page). This resizing can be performed through dynamic layout processing, which will be described in more detail later. Alternatively, if (for example) third party application 40 is required to switch to a different version to accommodate a change in display, containing web page 203 may request this switch. This two-way communication is between components of the third-party application 40 and components of the website building system 30 (which display additional information) associated with the third-party application 40 and the multi-part third-party application as described above. It should be understood that between the 40 elements and modular third party applications may also be established.

Additionally, system 100 may be implemented using both online and offline website building systems 30, and system 100 may also include hosting methods (e.g., client-side elements, 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 even for the offline embodiments described above, a server may be required to implement system 100.

Additionally, system 100 may be hosted on another set of servers (not operated by the website building system vendor), such as a private site hosting system at a large organization.

Additionally, system 100 may support all of the instance inclusion options from third-party applications 40 described above. However, system 100 may support only a subset of these options, or may impose limits on inclusion options for instances of third-party application 40.

Additionally, system 100 may also implement multi-part third party applications 40. Multi-part third party application 40 may include multiple display areas, each of which is handled using a separate iframe. These areas can also collaborate (if desired) through communication hub 205, as will be discussed in more detail below.

Reference is now made to FIG. 9, which illustrates an example multi-part third party application 40. As shown in FIG. As shown, the blog's third-party application [a] obtained from AppStore [b] is located in containing web page 203 [c]. The blog third-party application [a] includes three areas: a blog entry area [d], a tag cloud area [e], and a news update area [f]. A multipart third-party application can use its multiple areas in different ways, for example as multiple parts of one application (as in the blog example above), or as multiple parts of one application. It should be appreciated that the application can be used as optional parts of an application, including regions that are always visible and optional regions that are only visible when requested. The display of optional areas can be controlled by the third party application 40 or by the designer 5 (which decides how to configure the third party application when it is included). Additionally, the display can also be controlled as supporting functional areas such as configuration areas and additional dialog areas. Alternatively, the same is true for displaying multi-version third party applications (eg, having a small version and a large version of the third party application, or having a portrait version and a landscape version of the third party application).

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

Additionally, implementing multipart third-party applications 40 requires that third-party applications 40 (within each iframe) be able to control the display of various iframes (e.g., iframe visibility, size, position). be done. Additionally, it should be appreciated that communication hub 205 may enable this display, as will be discussed in more detail below.

Furthermore, even when multipart third-party application 40 (visually) consists of multiple elements and areas, in terms of purchase, installation, configuration, etc. (e.g. in AppStore 25), this application 40 is still one third-party application. It should be understood that 40 is considered.

In existing systems, each third-party application 40 is considered a separate entity, and cooperation between two third-party applications 40 (from the same vendor or from affiliated vendors) is determined on a case-by-case basis. must be developed for each system. It should be appreciated that system 100 can also support modular third-party applications 40 that consist of multiple cooperating submodules that can be purchased and installed individually.

Reference is now made to Figure 10, which shows that the sales management modular third-party application [a] includes, as sub-modules, a customer relationship management (CRM) module [b], a lead management module [c], and an electronic It shows how a commerce module [d] can be included. This one third party application vendor can provide all the necessary third party application modules. Alternatively, the vendor of the third party application may provide a subset of the modules (and functionality) of the third party application 40, and the designer may provide complementary third party application modules to the same or another third party. It can be purchased and installed from the application vendor. Multipart third-party applications are obtained and installed as one third-party application from one vendor (multipart third-party applications only occupy multiple screen areas), whereas modular third-party applications It is to be understood that the application includes multiple modules that can be obtained and installed individually and, in some cases, from multiple third party application vendors. To be able to integrate multiple third-party application modules from multiple vendors, each third-party application module must provide a list of the interfaces/features it requires 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 specification of interface parameters.

A module in third-party application 40 may have interfaces that are required as mandatory (i.e., interfaces without which the module will not function) or interfaces that are optionally required (i.e., without which the module will function, but which provide functionality). (interfaces that are restricted or changed) can be specified. Therefore, the parameters provided for each interface include: a unique interface name, a description of the interface (as shown to the designer 5 so that it (for example) knows the functionality handled by the missing interface), required/optional status, list of interface parameters, and type. It should be understood that each third party application module still belongs to a separate iframe (or set of iframes). The operation of the interface is based on communication channels, which will be explained in more detail below.

It should be appreciated that the modules of third party application 40 can be assembled during the website design stage. Website building system 30 may resolve interface references as additional modules of third party application 40 are added, where the new module of third party application 40 replaces the existing required interface. Resolve, but possibly add new (unresolved) required interfaces.

Furthermore, it should be understood that the designer 5 can edit and run the completed website while the required (and optional) interfaces are still being resolved. However, Designer 5 cannot publish the created website until all required interfaces are resolved, and Hub 205 cannot launch third-party application modules that still have unresolved required interfaces. When you try a feature that requires , a message appears.

Additionally, it should be appreciated that AppStore 25 may include a searcher 26 that attempts to identify third party application modules that resolve the requested third party application module's interface. Searcher 26 may search for a particular third party application module or all third party application modules based on unresolved interfaces. Additionally, the searcher 26 can search based on currently unresolved interfaces or interfaces that have already been resolved, and can further search based on required interfaces, optional interfaces, or both types of interfaces. be able to. Further, it should be appreciated that the searcher 26 may be limited to resolving unresolved interfaces of a particular third party application and searching for a particular third party application vendor. Searcher 26 performs either a first-level search (i.e., modules satisfying currently unresolved interfaces) or a multi-level search (i.e., iterative search, considering third-party application modules found by previous searches). When you add unresolved interfaces, you can also search for modules that satisfy them.

System 100 may use the interface descriptions to provide information to designer 5 regarding the importance of providing some missing interfaces. Hub 205 can provide interface translation between incompatible third-party applications that still need to communicate. This conversion can be performed by an adapter module added by the website building system 30 supplier or an outside vendor, which adapts the required specified interface to another format.

Further, system 100 can be applied to an online application editing system, which is an online application editing system that uses the Internet (or any other network connection) and client-side software that is not a browser to create online applications. Display. Such systems do not require the use of specific technologies used by regular web infrastructure (eg, IP communications, 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. Examples of cross-domain communication methods include:

HTML5 PostMessage: This is a standard feature of HTML5, and by using this feature, secure cross-domain messaging can be provided. HTML5 Windows. Postmessage allows you to securely send messages between windows, iframes, and the main HTML document, even if they belong to different domains. PostMessage provides a tool for a sending iframe to specify the domain to which a message is sent, and a tool for a receiving iframe to confirm the domain from which the message is sent.

URL fragment identifiers for messages: This method uses URL fragment identifiers to send message data from one endpoint to another. Encode the data into plain text and add it (as a fragment identifier) to the URL used to call a service in the target endpoint domain or a hidden iframe inside the target endpoint iframe. The fragment identifier is decoded by code in the target service or iframe.

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

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

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

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

It should be appreciated that the communication hub 205 can act as a broker in all inter-iframe communications using any of the transfer methods described above. Further, it is understood that the hub 205 is 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 and stored in the property sheet 23. I want to be Additionally, third party application 40 may have different parameters when included in different applications and in different instances included within the same application (as discussed above). Such parameters include a unique instance name that can be used for smart addressing (described in more detail below). Additionally, it should be appreciated that hub 205 may also be aware of additional details of third party application 40 that are not stored in property sheet 23.

Additionally, the hub 205 facilitates smart addressing and smart identification, verifies the origin of communications, enforces communication policies, resolves incompatibility issues with third party applications 40, and also provides components from third party applications 40. Please understand that you may be redirected to . Additionally, hub 205 may enable dynamic updates of the layout in third party application 40 based on changes made to containing web page 203, as described in more detail below.

Reference is now made to FIGS. 11A, 11B, and 11C. 11A and 11B illustrate different embodiments of hub 205, and FIG. 11C illustrates the functionality of various elements of hub 205.

The hub 205 includes a smart identifier/addresser 310, an origin verifier 320, a communication policy enforcer 330, a protocol converter 340, a redirector 350, a dynamic layout updater 360, a configuration manager 370, a general updater 380, and a hosted An API (Application Programming Interface) wrapper 390 may be provided. The functions of these elements will be explained in detail later. Note that all functionality can be applied to all cross-domain communication channels (e.g., from a third-party application 40 to a website building system 30, from a third-party application 40 to another third-party application 40). I want to be understood.

Referring now to FIG. 11A, this figure shows a general embodiment of the hub 205 through an intermediate iframe [a] that uses an internal communication API (Application Programming Interface) to Communicate with site construction system 30. This way, messages sent from (for example) TPA (third party application) [d] (using communication API module [f]) to TPA [e] (using communication API module [g]) [c] may be analyzed, verified, or modified in a manner that applies application-specific information.

Referring now to FIG. 11B, this figure depicts an alternative embodiment in which the communication API module [embedded in the third party application [c], without the use of an intermediate iframe, a] and/or the communication API module [b] (embedded in the third party application [d]) uses cross-domain communication. Module [a] and module [b] interact directly with website building system 30 to receive application-specific information and use this information when handling communication message [f]. A disadvantage of this embodiment (as compared to the embodiment shown in FIG. 11A) is that a significant amount of information at the level of the website building system 30 is processed inside modules contained in third-party applications. This information can be accessed (and even 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.), i.e. Direct addressing of the third party application 40 is used when sending messages and when receiving messages (as the sender's name is provided to the recipient). Additionally, sending a message requires that the sender specify the target iframe window (using JavaScript's document.getElementById(”...”).contentWindow call or any other method). be done. Therefore, 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 cumbersome in the environment of system 100. Even if the designer 5 integrates multiple third party applications 40 from multiple unaffiliated third party application 40 vendors, the third party applications 40 supplied by the third party application 40 vendors may initially , but may later be moved to another domain or subdomain. Third party application 40 vendors may change the protocols or ports used to communicate with a particular third party application. Designer 5 may be required to modify the design of containing web page 203 that includes third party application 40 . All of these can occur in a third party application 40 used in a website that is in operation and accessed by a large number of users. Furthermore, a single containing web page 203 may include multiple instances of a single third-party application 40 that can perform different functions. For example, one page within a product support website may contain two instances of a third-party chat application 40, one for user-to-user chat and forums, and one for contactable users. (Instances used to consult with vendor support personnel) may be included.

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 to the website building system 30 by the vendor of the third party application 40). I want you to understand. Addresser/identifier 310 provides addressing of the source or destination third-party application 40 by the unique name of the third-party application 40 (as registered with AppStore 25) and the third-party application in the containing web page 203. 40 and thus the descriptive ID of the instance of the third party application 40 and the type/class of the third party application requested; (e.g., "I would like to send a message <x> to an instance of the event logging third-party application 40 on the containing web page 203"). Can be done. Such identifiers may also describe specific services to be supported by third party application 40. Additionally, the addresser/identifier 310 can use version indication information (e.g., ``Insert transaction <x> into an 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 therefore only needs to know the direct address of the hub 205 and does not need to know the addresses of other third party applications 40. I hope you understand that. This single direct address may be encapsulated by a communication API wrapper provided by the website building 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). The calling third-party application 40 can provide its written addresses (as described above) that the application is aware of, and the addresser/identifier 310 converts these addresses into direct addresses for the third-party application 40. You can perform routing using In this way, third party application 40 does not need to maintain a table of absolute addresses of all third party applications 40 with which it may communicate.

It should be appreciated that verification of the origin of a message is important, and without verification, the receiving third party application 40 may receive messages from a hostile third party application 40. Because all communications occur through hub 205, origin verifier 320 can check the authenticity of all incoming messages from third-party applications. Additionally, origin verifier 320 can provide additional information that can be added to the message and can be used to perform additional verification. All third-party applications 40 included in AppStore 25 and used by system 100 are each registered with website building system 30 so that hub 205 knows that the originator's unique ID contained in the message It should be appreciated that a match can be made by the website building system 30 to match the origin of the message (domain, port, etc.).

The third party application 40 may define a general communication policy that may depend on external information, information on the containing web page 203, etc. The communication policy enforcer 330 can ensure that appropriate communication policies are applied so that communications that do not comply with specifications do not have to be handled. For example, websites that handle sensitive information may give third party applications a sensitivity level field in their profiles. A third party application 40 providing a backend event logging database that is authorized to handle sensitivity level X may define a policy of not accepting and logging events with a sensitivity level higher than X. In such a situation, the communication policy enforcer 330 may perform the necessary pre-filtering to prevent highly sensitive messages from even reaching applications that can only handle lower sensitivity levels.

Furthermore, Designer 5 created two (or more) third-party applications on the same website that could work together but never actually work together due to protocol compatibility issues. Please understand that you may wish to include: Referring now to Figure 12, for example, as shown in the figure, an online shop's third-party application [a] may be a sourcing and shipping third-party application [b], such as a third-party application (provided by a different vendor). The party application may have the ability to send purchase order messages. 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 vendors of the third-party applications involved, but in some cases such resolution is not possible (for example, if one of the two third-party applications (not updated at this time). Protocol converter 340 may convert the associated message from [a] to [b] (eg, by providing the necessary additional fields). Such conversion may be performed by a protocol converter 340 or may involve interaction with the website in which the application is embedded and the containing webpage 203 (e.g., if additional information is required) .

Additionally, it should be appreciated that a third party application 40 may have functionality that requires it to send messages to another third party application 40 or receive messages from such third party application 40. (eg, the online shop/sourcing third party application 40 pair described above). However, in some cases part of the solution may not exist, and in the above example, there may not be a corresponding or appropriately sourced third party application 40. In such a case, by using the redirector 350, the designer 5 can route a particular message to or 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 components can provide. This allows a complete website to be built without the need to build a dedicated third party application 40. Accordingly, the transaction can be sent to a component of the website building system 30 that can log the transaction into a database, which can later be used (by another program) to perform offline sourcing and shipping. can do.

Third party application 40 may provide multiple configurations with different capabilities that use the same code base but enable different functionality. For example, third party application 40 may provide basic functionality through a free version and additional functionality through a purchased premium version, multiple paid versions, or additional functionality purchased through third party application 40. .

It should be appreciated that the system 100 may include functionality based on the website building system 30 that manages per-user (and indeed per-designer) third-party application 40 purchases. Additionally, all designers can be registered users of the website building system 30, and thus the website building system 30 can manage a database of each designer's 5 purchase status of third party applications 40. I want to be understood. This information may be stored in the property sheet 23 by the TPA coordinator 24 during the design stage and by the configuration manager 370 at runtime. For example, third party application 40 may send a version inquiry message to a client-side component of website building system 30. The client-side elements of website building system 30 query repository 22, or a locally cached copy of the repository, to send a response message to third-party application 40 containing information regarding the capabilities that third-party application 40 has to offer. return.

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

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

It should be appreciated that, at runtime, updater 380 may implement messages and responses between components of containing web page 203 and third party application 40. For example, third party application 40 may change/modify or query the visual/display attributes of components of containing web page 203 (such as component position, size, color, transparency, etc.). Additionally, updater 380 allows third party application 40 to read or write the content of components of containing web page 203, and further allows third party application 40 to read or write content for components of containing web page 203, and further allows third party application 40 to It is possible to instruct a component to pass a video segment to a media player component, or to request a media player component to pause playback for a specified period of time.

Further, updater 380 facilitates components of website building system 30 to specify the type of access to allow third party applications 40, in this case access to protect files on modern operating systems. In a manner similar to how permission bits and access control lists (ACLs) function. Such permissions can 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, third party application 40 may be able to access text fields outside of third party application 40 within containing web page 203. In the case of the blogging third party application 40, this text field can be used to edit the blog entry and requires more screen real estate than can be provided inside the blogging third party application 40 area itself. provided. For third-party applications 40 that are embedded in a particular mini-page inside a multi-page container, website building system 30 limits access from third-party application 40 to only the components within that particular mini-page. I hope you understand that you can.

Additionally, it should be appreciated that updater 380 allows third party applications 40 to affect elements throughout the site. Examples include the process of obtaining and setting attributes such as the current page within the site, the current mini-page within the container containing the third-party application 40, and the page history. Additionally, updater 380 may filter or limit such requests.

Additionally, updater 380 allows website building system 30 to change and modify the style and display of third party application 40. Updater 380 may implement calls that website building system 30 uses to provide formatting and style guidelines to third party application 40 . Guidelines can include properties such as color and color scheme, font, font size, transparency, animation and special effects (eg, blur). Color schemes include, among others, general color schemes (for example, use the following x colors) and high-level color schemes (for example, use color x for text and color y for frames).

One preferred way to express complex style information is to use cascading style sheets (CSS), which can express combinations of multiple style directives such as font, size, and color. I want you to understand that I can do it. Updater 380 can send such CSS-based messages to third party application 40. The style sheet can be generic in nature or include unique style names defined by the third party application 40, thus allowing the website building system 30 to provide better guidelines to the third party application 40. (eg, a style sheet may reference elements of a particular third-party application 40 to provide these guidelines).

Third-party applications 40 can then use these guidelines to create their own look and feel that better matches the containing web page 203. This is particularly important for third party applications 40 that are included in or visible from multiple containing web pages 203 within the same site (multiport inclusion as described above). Multiple contained web pages can employ 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 better match each containing page, and to eliminate discordant color schemes compared to the containing web page. It is possible to avoid the appearance/operation feeling from being displayed.

Dynamic layout updater 360 updates website building system 30 and third-party application 40, or third-party application 40 and ancillary third-party applications, when processing display changes as a result of dynamic layout events. Please be understood to enable us to cooperate. Website building system 30 may change the size and position of components within a page in order to maintain the page design upon the occurrence of an event that changes some of the components within the page. These dynamic layout events include, for example, viewing a website on screens with different sizes, rotating the display device between portrait and landscape modes, and changing the size or position of some components. , modifying the content of a particular component (resulting in a request to resize the component). In addition, dynamic layout events include server-based content updates (e.g., in a component that displays information from a data feed), or changes to the content of a component by another concurrent user of the same website. Updates can be mentioned. Additionally, it should be understood that dynamic layout events can occur in the runtime environment as well as in the design environment. In particular, depending on the component and third party application 40, the content and size/position of the component may be changed at runtime (ie, by the end user) as well as by the designer.

Additionally, it should be appreciated that dynamic layout events may also be generated by third party applications 40. For example, an online shop's third party application 40 may require a size change when a user moves from displaying a product catalog to displaying a shopping cart (which has a different size). As another example, a product catalog third party application 40 may include an option to highlight products, which may cause the third party application 40 to display a larger catalog with more content. View the page. A further example includes a multi-region third party application 40 that can start or stop displaying additional regions.

Here, reference is made to FIG. 6 mentioned above. In existing systems, this situation is typically handled, if at all, by truncating the third-party application's display, adding scroll bars to the display, or changing other parts of the page, as shown in Figure 6. Handle by simply resizing the display as a popup window that hides the component. Dynamic layout updater 360 may implement collaborative dynamic layout, where website building system 30 and third party application 40 collaborate to perform the dynamic layout and update containing web page 203. maintain the basic design. Dynamic layout functionality is further described in US Pat. 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, widgets in website building system 30 may be designed to be resizable to any size (within a certain range), but third party application 40 may not support arbitrary resizing. The third party application 40 may, for example, have multiple display settings with different sizes (e.g., displaying more or less detailed information), the ability to resize some of the internal elements of the third party application 40, the third party Any combination of the following may be provided: the ability to display some of the text elements of application 40 using multiple font sizes.

Further, third party application 40 may be provided with a limited number of possible display sizes and may have a whole range of possible sizes. Therefore, a resize request from the containing web page 203 to the third party application 40 can be made by the third party application 40 switching to the closest possible size, or by providing the third party application 40 with a list of possible sizes (which allows the web page to The site building system 30 can select the appropriate size to use.

Dynamic layout updater 360 may implement collaborative dynamic layout [from containing web page 203 to 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). Dynamic layout updater 360 can send a message to third party application 40 requesting that third party application 40 resize its content to a particular desired size (eg, X1*Y1 pixels). Third party application 40 may adjust to the specified size by using alternative display settings, internal resizing operations, internal dynamic layout operations, or any other means. Additionally, 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).

Additionally, it should be appreciated that third party application 40 may only be capable of resizing to a limited set of possible sizes (eg, certain user interface configurations). Accordingly, dynamic layout updater 360 may use the following alternative algorithms that third party application 40 may use to provide a set of possible sizes.

When the containing web page 203 is resized, 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. Third party application 40 determines the closest possible size (e.g., X2*Y2 pixels) and uses alternative display settings, internal resizing operations, internal dynamic layout operations, or any other means. This will resize it to that size. Updater 380 can then send a response message to containing web page 203 confirming the resizing process and providing the actual new size (X2*Y2). Containing web page 203 may resize the external iframe window containing 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 if there are multiple third party applications 40 (or multi-area third party applications 40) within the containing web page 203. In this embodiment, the containing web page 203 is configured such that the embedded third party application 40 can attempt to optimize the look/feel by considering multiple options of the multiple third party applications 40. The embedded third-party application 40 can be queried to obtain a list of display sizes. This embodiment is also relevant when third party application 40 is displayed across multiple areas.

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

Loop from 1 to n for i.

For each TPA[i], calculate the following.

Minimum size Xmin[i]*Ymin[i],
Maximum size Xmax[i]*Ymax[i],
Optimal size Xopt[i]*Yopt[i],
Dynamic layout updater 360 may send a message to TPA[i] enumerating the above minimum/maximum/optimal sizes and request information regarding possible sizes of third party application 40.

Third party application 40 can provide dynamic updater 360 with a set of possible size options (Xposs[i][j]*Yposs[i][j]) that it can employ.

The containing web page 203 is based on the Xposs[][]/Yposs[][] information gathered as described above, and includes (for example) a complete evaluation of all possible size combinations of third-party applications, linear programming, Alternatively, the solution to the dynamic layout computation 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.

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

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

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

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

As mentioned above, third party application 40 may also occasionally need to resize its display window. Since the size of the window displaying the iframe is managed by the hosting page (i.e. 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 party Party application 40 requests containing web page 203 (via dynamic layout updater 360) to change the window size.

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

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

It is recognized that third-party applications 40 often require a wide range of complex services for use internally or downstream by designers using third-party applications 40 within their own sites. I want to be understood. Such services include user management and billing/shipping management. The vendor of 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). Furthermore, these services may not be suitable for "packaging" alone as a third party application 40. Additionally, the vendor of the third-party application 40 may provide a plurality of such services (e.g., multiple third-party billing APIs) to the designer using the third-party application 40 so that the designer 5 can select the appropriate service. You may need options to make them available.

For example, in the website building system 30, an API hosted by PayPal ^TM may be provided that is used directly by the third party application 40 or provided by the third party application 40 to the designer 5 who uses the API. can do. Additionally, the third-party application 40 may provide its own set of options (i.e., use a particular billing type, e.g., one-time billing, automatic recurring billing, revenue sharing) and use the hosted PayPal These options can also be implemented by calling APIs.

Thus, a designer 5 using the website building system 30 can develop a unique service (such as an online shop that sells music) that uses advanced billing. The designer 5 may use the hosted billing API directly or through a third party application 40 that provides an additional level of abstraction to create a specific relationship with the provider of the billing API. The need to negotiate clearing agreements or merchant agreements can be avoided. In this sense, website building system 30 may act as an agent for the vendor of the hosted API.

Hosted API wrapper 390 facilitates this communication between multiple different parts of the system (e.g., 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 can reside in the website building system 30 itself or in another third party application 40. A vendor (or designer 5) of a third-party application 40 can use the hosted API through the hosted API's wrapper 390 without knowing how the actual underlying API is implemented.

In a supplementary alternative embodiment of the present invention, Applicant provides an integration system in which additional templates and components of the website building system are associated with third party applications at the AppStore 25 level and instances of associated third party applications. It has further been recognized that by using the model, smart integration between 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 domain where the content is hosted in a separate domain (whether the third party application vendor's domain or otherwise) that is different from the domain in which the main site is hosted. This is an iframe. Therefore, the "same origin policy" of the browser is applied to communication between a plurality of different iframes, and the above-described method is required to be used.

Existing systems implement the third party application 40 as a unitary, less flexible object that is included in the containing web page 203 but does not otherwise affect the look/feel of the containing web page 203 itself. . An instance of third party application 40 is placed within a (generally rectangular) area and performs all of its operations/functions within this area.

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

It should be appreciated that the system 100 can support publishing third party applications 40 with multiple associated templates, allowing the designer 5 to select the most appropriate template according to their needs.

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

Reference is now made to FIG. 13, which illustrates an example of the use of associated templates, according to an embodiment of the present invention. As shown, third party application [a] is placed 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 specified 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 should be appreciated that the system 100 can support multiple ways to place instances of the associated template components (e.g., [d'] and [e'] above) into the containing web page 203[f]. . Placement methods include absolute placement (i.e., using the size and position of the original components [d] and [e] as specified in the associated template [c]), placement relative to the target ( i.e., adjusting the size and position of the new instances [d'] and [e'] according to the containing web page 203[f]); adjusting the size and position of the new instances [d'] and [e'] with respect to the size and position specified for the inner third-party application instance [g]. The placement method to be adopted can be determined based on the settings included with the associated template [c], and the designer 5 can use another placement method if necessary.

Furthermore, it should be appreciated that designer 5 can modify the instances of components [d] and [e] in [f] that are inherited from template [c]. Changes are made to the use of [d] and [e] in [f] (and in some cases inheriting pages from within website building system 30 that support inter-page inheritance). It only applies and does not affect the "original" template [c] associated with the third party application [a] in AppStore [b].

Understand that changes to instances in [d] and [e] above may include, among other things, assigning specific content (text, images, etc.) to instances of a field or changing regular attributes. I want to be Further, referring to FIG. 14, if the third-party application 40 is included inside a mini-page, the associated template is applied to the particular mini-page in which the third-party application 40 is included, as shown in FIG. I hope you understand that this will happen. As shown, third party application 40 is included in minipage [x], and therefore components [d] and [e] are added to [x], but a further minipage of the same multipage container [g] It is not added to pages [y] and [z].

Additionally, it should be understood that in the case of section type mini-pages, the associated template (if present) is applied to the virtual (and empty) containing web page 203 created to contain the third-party application 40. .

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

Additionally, website building system 30 also enables multi-port inclusion, where the same instance of third-party application 40 is visible from and "belongs to" multiple pages of the main site. Multiport inclusion is different from multiple inclusion of a particular third party application 40 within the main site (creating multiple instances of the third party application 40). Thus, the content of a third party application 40 (which is instance specific) is shared between multiple displays of the same multiport third party application 40.

In such multi-port inclusions, the associated template can be applied separately to each page and mini-page to which an instance of third-party application 40 is added.

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

Accordingly, it should be appreciated that a vendor of a 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 templates that are actually distributed (ie, associated with the currently distributed third-party application version).

As mentioned above, third-party applications 40 may be distributed through AppStore 25 and may also be distributed through alternative channels that are not associated with or controlled by the vendor of website building system 30. However, associated templates distributed with third-party application 40 may be strongly associated with application repository 22 because the associated templates are components managed by website building system 30, base templates. , and other elements.

Furthermore, elements of the website building system 30 underlying such individually distributed associated templates may need to be modified or removed (which may cause the associated templates to become "broken"). ”). To solve this problem, system 100 may implement these associated templates in separate areas within application repository 22 (possibly for each vendor of third-party application 40). Website construction system 30 can manage these templates in the same way as other templates of website construction system 30.

Additionally, the vendor of the third party application 40 may be provided with a unique ID (development ID) for each template created, and the vendor of the third party application 40 may use this ID during the development and testing process of the third party application 40. Please understand that you can use At the time a 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 (publication ID); The ID can be referenced in the third party application 40 that is used. Once the public ID is provided, a separate locked copy of the template is created. This copy is the copy that is referenced by the third party application 40 and used when creating an instance of the third party application 40. This way, the vendor of the third-party application 40 cannot inadvertently modify the templates associated with the "raw" third-party application 40 (included by the designer), and referential integrity is maintained. be done. Additionally, system 100 can cross-reference relationships between such locked templates and underlying components and base templates. Using this cross-reference, for example, an attempt is made to modify a component of the website building system 30 or the base template contained in such locked template (and such modification does not affect the template or third party). The website building system 30 staff can be alerted if the party application 40 is likely to break in some way.

Accordingly, system 100 may provide a two-way communication channel between third party application 40, components within containing web page 203, and website building system 30. The components of the containing web page 203 may be based on template(s) associated with a third party application, or based on another template of the website building system 30, or unrelated to the template. Can be done.

As discussed above, communication hub 205 can facilitate communications and provide a backchannel between containing web pages and third party application 40. Applicants have further recognized that the data passed back and forth between the containing web page and the third party application 40 is useful once it has been collected, processed, and integrated.

For example, website owners need to manage the number of users and membership per their site, which are different from values based on registered users of the associated website construction system 30. Users of the website may register or not register (anonymous), and the website may provide different levels of functionality to different levels of users. Furthermore, users (even anonymous users) may be personally Often provides information or contact information (e.g. data in a contact form). It is understood that this information may be entered directly into the site created or made available as part of interaction with a third party application embedded within the site.

Further, it should be understood that this information is unorganized, unrelated, sometimes contradictory, and often not stored. For example, a user may enter their private email address into a contact form (managed directly by the site) and, in the same session, enter their work email address into a contact form (maintained directly by the site). You may complete a separate subscription form (administered by 40).

Furthermore, this "fluid" information may include different permissions regarding the use of that information. For example, a user who enters his or her e-mail address in a subscription form expects to receive the e-mail-based subscription to which he or she has subscribed and possibly an associated e-mail newsletter. On the other hand, users who have disclosed their e-mail address as their registered ID may not wish to receive e-mails addressed to their registered address, except for e-mails regarding handling of their account or security warnings. be.

Reference is now made 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. It shows. System 200 includes 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 facilitate communication between website building system 30 and multiple third party applications installed on server 270 and multiple different third party applications, as described above in connection with hub 205. It should be understood that communication between 40 people can be facilitated. Contact database 245 and activity stream database 255 may maintain contact and activity information and information extracted from message streams, as described in more detail below.

16A and 16B, FIG. 16A shows elements of client hub 210, and FIG. 16B shows elements of server hub 230, contact coordinator 240, and activity coordinator 250. ing. Client hub 210 includes a router 211, a converter/adapter 212, and a privacy policy enforcer 213. 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 . Contact coordinator 240 includes a data extractor 241 , a contact handler 242 , a data merger 243 , and a data/authorization handler 244 . The activity coordinator 250 includes a stream creator 251, a stream merger 252, and a log creator 253. The functions of these elements will be explained in more detail later.

16C and 16D, FIG. 16C shows elements of stream merger 252 and FIG. 16D shows elements of 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 . Horizontal contact merger 277 further includes a virtual horizontal merger 278. Vertical contact merger 276 further includes a virtual vertical merger 279. The functions of these elements will be explained in more detail later.

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

Further, the system 200 can extract information related to the user and merge them (combining information from multiple sources and information already present in the system 200). Merging can be done through merging rules that reconcile different types of, and possibly mutually contradictory, information. The combined information may be stored in contact database 245. This information may further include use permission fields that control allowed uses of the collected 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 can be installed locally on the associated client.

Additionally, system 200 provides, as an additional component, third-party application 40 to manage user contact activities (e.g., mass newsletter sending) while enforcing usage limits set by users themselves. It should be understood that enabling components may be included. Such components may also isolate the user's private data from third-party applications 40 (thus allowing third-party applications 40 to perform their respective operations without actually accessing the user's private data). can). Such functionality may be implemented using, for example, private data proxy 234, as described in more detail below.

Additionally, it should be appreciated that contact database 245 can be specific to each site. However, website building system 30 allows you to define a metasite/metaproject level that includes a collection of websites (owned by the same site owner), and allows contacts to be stored at the metasite level rather than at the single site level. Processing and merging can be specified. Other elements of the site (such as included third party applications 40) may also be defined at the metasite level rather than the site level. Other than supporting metasites, system 200 generally does not share contacts between different sites or between different site owners (except in the circumstances described below), nor does it aggregate contact information ( 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 making a purchase, adding an item to a shopping cart, or entering contact information. One third party application 40 can specify which activities it supports, and other third party applications 40 can "listen" for particular activities and act on the received activities and information associated therewith. be able to. It will be appreciated that the list of activities that are 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 more detail below. sea bream.

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 that can be defined through inheritance between each other or through a third party application 40 (with the option of extending the activity data structure by adding fields). It can also be defined. The activity data structures may be system-specific or may be based on or include standardized data structures. The activity data structure may also be encoded in some way (such as using XML, JSON data, or a binary object encoding scheme).

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

Additionally, the activity data structure may include a callback link, such as "more information" (return to the activity data structure). Callback links can be used to provide additional critical information, such as complete order tracking information and order history in the case of e-commerce activity data structures, and for chats. 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 record. Thus, a complete activity data structure as an example would be 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), creation site ID, site member database ID, ID/URL of the site page where the activity took place, description of the activity provided by the third party application 40, used by the third party application 40. further information links and user details obtained.

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

As described above in connection with FIG. 16C, stream merger 252 includes activity-stream merger 261 and stream-stream merger 262. Activity-to-stream merger 261 can associate an activity with a stream associated with an identified contact, and stream-to-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 a common primary ID, and the vertical stream merger 264 can merge streams created for anonymous contacts and These two streams can be merged when the stream associated with a registered user is associated at login or registration. It should be appreciated that stream merger 252 can access previously created streams in activity stream database 255 when needed.

For example, an anonymous user fills out a contact form within your site. Stream creator 251 creates a new activity stream (with ID "anon1") and 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 out a schedule form using another browser. Since there is no interaction with the first user, stream creator 251 creates a new activity stream with ID "anon2" and contact handler 242 creates a new contact with ID "anon2."

This user then makes a purchase from this site. Stream merger 252 merges this new activity into the "anon2" activity stream and updates contact "anon2" (eg, with the "customer" tag).

This user also uses 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 a different browser and chats with the site owner. Since this website does not use cookies, 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 into the website. At this point, there is a contact with ID "anon3" and ID "user x". The data merger 243 can merge contact "anon3" with "user x" such that both the login activity in the stream of "user x" and the login activity of contact "user x" are It points to the streams "user x" and "anon3". Stream merger 252 may merge additional actions performed by the user in this session into "user x"'s activity stream. Logger 253 may log all activity data from these streams and save a copy of the logs to activity database 255.

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

Furthermore, it should be appreciated that in parallel, the contact coordinator 240 can gather information from the data provided by the activity streams (messages) to build a contact profile for the target user. A data extractor 241 can extract data from activity messages and activity streams, and a data merger 243 can merge related data to a particular contact, whose details are stored in a contact database 245. can be stored and accessed from contact database 245. Contact handler 242 can create new contacts and process site user identities (such as anonymous users), and data/permission handler 244 can handle privacy protection and permissions for associated data. can be processed. The data merger 243 includes the horizontal contact merger 277 and the vertical contact merger 276, as described above. Horizontal contact merger 277 can merge two unrelated contacts due to the detection of a common primary ID, and vertical contact merger 276 can associate anonymous contacts with registered users. The anonymous contact may be merged with the contact associated with a registered user when the contact is associated during login or registration. Horizontal contact merger 277 may further include a virtual horizontal merger 278 that maintains the two contacts as separate contacts, but where the two contacts represent the same contact. Link them together (with or without merging the actual contact information) to indicate that. Vertical contact merger 276 may further include a virtual vertical merger 279 that maintains anonymous contacts and contacts associated with registered users as separate contacts, but Link two contacts together to show that they represent the same contact (with or without merging the actual contact information). Additionally, data merger 243 can merge contact information (generally extracted from data extractor 241) into existing contacts. It should be appreciated that contact identifier 272 may use cookies to track user identification information and to recognize contacts to be merged, as will be discussed in more detail below.

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

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

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

TPA1 and TPA2 may exchange messages on the client (between component D' and component E') or on the server (between component D and component E), or on both the client and the server. I want you to understand. However, communication with ETPA3 must occur only on the server. Furthermore, it should be understood that there are advantages and disadvantages to using one method or the other. Sending activity messages on the client side can be more interactive, resulting in faster user responses. Sending activity messages on the server side can increase robustness and reliability (e.g. the user cannot close the browser window in the middle of the process) and ensure that messages are received in the correct order. , and may even send activity messages to a backend third party application 40 or application dashboard installed on the backend. It should be understood that these backend third party applications 40 are not visible to the client side.

As a case in which multiple third-party applications 40 are used, for example, a user adds an item to a shopping cart in third-party application A (the activity type is "change cart"). Third party application A then sends an activity message to website construction system 30 regarding the addition of the product. Website building system 30 forwards this activity to all third party applications 40 that are registered with "Modify Cart". Third party application B receives this activity because it is registered. Third-party application B can display a message to the user such as "If you also purchase product X, a discount will be applied" or "If you share this site, a discount will be applied."

As another example, a user "presses the like button" on something in third party application A (e.g. via Facebook). Third party application A then sends an activity message to website building system 30 regarding the activity type "Facebook Likes." The website building system 30 forwards this activity to all third party applications 40 that are registered with the "Press Like Button" activity. Third party application B receives this activity because it is registered. Third-party application B presents a re-engagement widget to the user, asking ``If you like this site, why not contact the site owner?'' or ``Would you like a discount coupon?'' ” can be displayed.

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

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

Router/tracker 231 can route messages between the website and any third party application 40, and can also track messages. Additionally, it should be appreciated that third party application 40 can listen for messages on both the client and the server. Additionally, it is understood that third party application 40 can explicitly specify one or more activities that it listens for (e.g., listens to all "Shopping Cart: Add Item" activities). sea bream. Additionally, third party application 40 can specify the class of activities it listens to (eg, listen to all activities related to Facebook). Additionally, a third party application may use a wildcard expression (applied to the activity name) that is used for the purpose of determining whether an activity should be sent to that third party application.

Additionally, it should be appreciated that third party applications 40 can 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 (e.g. registered users only, European users only), website attributes or structures (e.g., only listen for certain activities on pages created from a particular page template), user history (e.g., only check out cart if the user has made more than X purchases in the past) Activities). Such queries may be specified by the third party application 40, but may also be editable by the designer.

Accordingly, router/tracker 231 may also track messages being listened to by third party application 40. Such an activity listener query architecture is best implemented at the activity routing level (rather than being performed by an API call inside the third-party application 40), since it allows the website designer to It should be appreciated that this is because adjustments and customizations can be made without the need for the third party application 40 to be highly programmable and customizable. Furthermore, the router/tracker 231 also helps protect user privacy, since the website designer is required to provide additional information (necessary for routing decisions) to the participating third-party applications 40. This is because there is no Additionally, router/tracker 231 can suppress performing unnecessary communications with third party applications 40 (often hosted by another server).

It is understood that users (website visitors) are the ones who visit the website, register with the website, or provide information to the website. Users are aware that the website they are accessing is actually built using a combination of website building systems 30, components, authored websites, and third party applications 40. There are things I haven't done yet. Therefore, the responsibility for user privacy ultimately lies with the website owner (who is also responsible for the activities performed by third party applications 40 included on their website).

Additionally, third-party applications 40 (and other components of website building system 30) can access user profiles through APIs provided by website building system 30 based on privacy rules defined by website building system 30. Please understand that you can access the information. Additionally, the containing site and the third party applications 40 included therein may use the contact information to communicate with the user (via email or other means).

It should be understood that there can be three major issues related to privacy. The first issue is the interaction between the website and website building system 30 and the third party application 40 provider. A website (and website building system 30) may not be able to fully trust a third party application 40 with respect to its use of user data; for example, if a third party application 40 (and do not send bulk e-mail (using this address), do not send spam to users who have requested to be removed from your e-mail distribution list, or transfer your personal information to other parties; It's about that. However, this problem can be solved in the following way.

The vendor of the website building system 30 signs a Terms of Use (ToU) agreement with the provider of the third party application 40 when adding the provider to the application market of the website building system 30. You can request to do so. Such agreement may state that the third party application 40 (and the provider of the third party application 40) may not misuse your information or disclose it to any third party. can. This allows the vendor of the website building system 30 to apply penalties to the provider of the third-party application 40 if the provider uses the information improperly (e.g., disabling the third-party application 40, (Delete the third party application 40 from the application market of the website construction system 30). Privacy policy enforcers 213, 233 and private data proxy 234 may enforce privacy policies for third party applications 40, as described in more detail below.

A second privacy-related issue is the interaction between websites and website building system 30 and users (site visitors). Websites must provide users with a clear understanding of how their personal data will be used, obtain consent from users, and comply with the terms to which users have agreed. The website construction system 30 requests all publicly available sites to present users with a terms of use document that defines the permitted uses of personal information belonging to users; You will be asked to electronically 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 enforcer 213, 233 may ensure that the terms and conditions of the terms of use document are followed. Further, the privacy policy enforcer 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. Sites must provide users with the option to unsubscribe from any marketing emails. This can be handled by the data/authorization handler 244, which is described in more detail below.

The data/permission handler 244 can also handle different user permissions set by different users, as will be explained in more detail below.

Website building system 30 (and the websites built therein) maintains all or some private data in a secure repository managed by website building system 30 via private data proxy 234. The private data proxy 234 can provide the third-party application with an alternative unique ID (instead of the private data), and the third-party application can use this ID to data can be obtained. For example, the email address may be replaced with an alternate "email address ID" provided to the third party application 40, so that the third party application 40 cannot access the actual email address.

Additionally, private data proxy 234 may provide a set of interfaces for various communication methods (e.g., email, social network messaging), and third-party application 40 may use these interfaces to The third party application 40 may contact or send a message to the user without actually accessing the private data associated with the user. Such private data includes any detailed identifying information that can be used to contact you (e.g. name, address, email address, telephone number (including SMS/MMS), unified communication ID (Skype, etc.), social network ID).

Accordingly, private data proxy 234 enforces user permission field restrictions, enforces user unsubscribe requests, and suppresses the sending of messages to users (e.g., specific (allow up to 100 emails per day to third party application 40). Private data proxy 234 can define proxy parameters and private data to be exposed and private data not to be exposed to third-party applications (for each third-party application 40), and these settings can be made on a field-by-field basis.

Private data proxy 234 provides third party application 40 hosted on a server of website building system 30 with an alternate unique ID that is similar in shape to the original private data (e.g., a user's original (provide an alternative dummy email address in place of your private email address) and use that information to "capture" the call and (in this example) forward the email to the correct address. This feature can also be used to detect third party applications 40 that are exceeding their authorized privileges.

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

As an example, a website that handles medical information may prevent access to some of the detailed personal information of the contact information when passing it to a third-party application 40 that analyzes the general geographic distribution of users. There are things I wish I could do. As another example, certain third party applications 40 may experience problems when handling certain types of contact information. Website owners who wish to continue using the third-party application 40 (despite known bugs) may wish to remove contacts that cause known problems or modify the data to prevent the problem from occurring. There is.

The converter/adapter 212, 232 may apply prespecified rules for converting messages and adapting content. Each such rule may include a third-party application 40 to which the rule applies, filtering criteria to select messages to which the rule applies, and transformation rules (e.g., discarding certain messages (associated with a particular third-party application 40)). conditions such as transformations applied to a particular field or fields in the activity data structure.

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

Additionally, the associated website building system 30 may be configured to send messages to harden the system against failures and intrusion attempts (such as man-in-the-middle attacks aimed at altering the payload data of third-party applications 40 messages). verification and signing. Therefore, each third-party application 40 registered with 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. one set is used to decrypt messages sent from the website building system 30 to the third party application 40 (output keys).

For example, third party application A sends a message to website building system 30. This message is sent using the third party application ID at the site (the third party application's external ID (with third party application scope)) and the message is signed by the third party application. Website construction system 30 receives this message. Verifier/signer 235 uses third party application A's input key to verify the signature. If this verification does not pass, verifier/signer 235 reports the input message as invalid and the message is not sent further.

Verifier/signer 235 may convert the external ID associated with the message using the internal site ID. Verifier/signer 235 can verify which third party applications 40 should receive the message.

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

As mentioned above, system 200 may employ multiple types of communication between website building system 30 and third party application 40. Such communications include, for example, control communications (e.g., website building system 30 instructs third-party application 40 to shut down) and functional communications (e.g., third-party application 40 instructs shopping cart third-party application 40). sends the total purchase amount through the website building system 30 to the billing third party application 40 (thus modifying the payment or activity communication in the example described in this application). It is to be understood that different networks have different profiles and requirements (e.g., regarding volume of messages sent, priority, robustness, response time).

In particular, system 200 may have very frequent activity reporting (eg, where events in a graphical user interface (GUI) of third party application 40 are reported as activities of third party application 40). Such large numbers of activity reports can overwhelm parts of the system that handle more important messages. Accordingly, system 200 may implement multiple communication channels (eg, using different ports or multiple simultaneous sessions) such that each class of messages is sent via a separate channel. In this way, side channels are used for activity reporting and occur in parallel with instructional and functional communications without interfering with the latter.

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

Thus, for each activity stream, contacts associated with each can be built, and the built contacts can be progressively refined using data extracted from 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 contacts that are related to each other (multiple contact records found to describe the same person). Contact identifier 272 can recognize such records by matching primary ID fields (email address, phone number, social security number, Facebook ID, etc.). Some primary ID fields are multi-value fields (e.g. one person can have multiple email addresses that identify that person), whereas some primary ID fields are strictly It should be understood that it is a single value field (eg social security number).

Thus, the data merger 243 can merge the fields of a contact extracted from a new activity into the currently constructed contact, allowing the anonymous user to When an anonymous user performs a login action and becomes an identified user, you can merge the contacts built for the anonymous user into contacts that have already been defined and saved (this can be referred to as ``vertical merge''). ). Further, when the horizontal contact merger 277 detects that two different contacts (constructed contacts or stored contacts) are related contacts representing the same user, the horizontal contact merger 277 You can perform a "horizontal" merge of As mentioned above, such merging can be done by actually merging (i.e. converting two separate contacts into one contact), or by merging one contact into another, or through a virtual merge. (i.e., maintain the two contacts as separate contacts but link them together to show that they represent the same person, merging the actual contact information and activity streams, or This can be done by not merging). Additionally, it should be appreciated that even in the case of a virtual merge, additional information can be added to the virtually merged and linked contacts.

Accordingly, the data extractor 241 can extract contact type information from the associated activity data structure, and the data merger 243 can extract this contact type information from the associated activity data structure (anonymous or identified). Can be integrated into Contacts. If the contact type information I includes a primary ID field, the data merger 243 checks whether there are any mutually related contacts based on the value of the primary ID field, and if found, merges these contacts. . Additionally, data merger 243 can check whether an activity establishes a user's identity within a site (e.g., site login activity) and, if so, sends an anonymous contact to that user. Merge with an existing contact record stored for that contact, making that contact an identified contact from now on.

It should be appreciated that contact identifier 272 can implement multiple methods for identifying site users. For example, sites that use cookies to track sessions by a single anonymous user (who is not logged in to the site), sites that use site login in the case of registered users, sites whose accounts are associated with social networks. In the case of users, social login is used by matching primary ID fields (email address, phone number, etc.) to identify that two user profiles describe the same user.

Additionally, site users whose details are stored in the contact database 245 may include anonymous users who have not registered with the site, registered users, and potential users (who are not yet officially registered with the site). However, it is understood that records imported from external sources can be categorized as:

Associated websites can install persistent cookies that persist across sessions, so information from multiple anonymous sessions performed on the same computer using the same browser to the same contact record can continue to obtain. Therefore, even anonymous users can have a significant amount of context and contact information.

Registered users must provide an ID that is unique to that particular site. Multiple types of IDs can be used, such as IDs unique to individual sites (e.g., usernames), external identifiers (email addresses, phone numbers, social security numbers, etc.), or by another system. The provided external identifier (social network ID, Google ID, OpenID ID, etc.).

When a user registers through a login to a social network, the site can use the personal information available in the social network to populate the same user's site profile. Additionally, the data extractor 241 can revisit the social network profile to detect any changes to the personal information and update the site user's profile.

Registered users typically must log into the system to establish their identity, but the system may provide an option to "remain connected to this system." Such login steps may be explicit (the user invokes a login dialog) or implicit (e.g., requiring the user to provide some identifying information when adding a post to a blog). ), or based on an external login (the system invokes a login procedure associated with another system, such as a social network login or OpenID login). In addition, through physical devices (e.g. security tokens connected directly to the system or via a wireless interface) or through the use of biometric information (e.g. user biometric parameters (e.g. fingerprint, iris scan) and user behavior detection) (including typing pattern detection, etc.) or through any combination of the methods detailed above.

Additionally, it should be understood that information can be passed back and forth between social login procedures and regular logins. For example, a social ID can be associated with a site member ID, so logging in socially is implicitly logging into the site, or a site member ID can be associated with one or more social network IDs, thus When you log into the site, you are identified in one or more social networks.

When a user performs an explicit logout, contact handler 242 can generate a new anonymous user cookie and thus open a new anonymous session (or set of sessions), and the activity of this session will be updated to that new anonymous user's cookie. Saved under anonymous contacts. At further logins, this new anonymous contact can be merged with the contacts identified at that login.

Referring now to FIG. 19, this figure illustrates the login/logout process for an anonymous user. Users can begin using the system anonymously. When the user performs 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. Stream merger 252 merges the information from act1 and the information from the next activities act2 and act3 to user anon1.

Once the same user performs a login as User X, data merger 243 merges anon1's contacts (and other related contact data obtained from the activity stream) with User Furthermore, it should be appreciated that stream merger 252 merges the information extracted from further activities act4 and act5 into one stream, and data extractor 241 then extracts user X's contact information. When User X logs out, contact handler 242 creates a new cookie and disconnects User X from further activity. Therefore, when the new activity act6 is executed, the contact handler 242 creates a new anonymous contact anon2, and the data extractor 241 extracts that contact's extracted contact details (and activity) from the newly created contact anon2. Save under anonymous contact anon2.

If user anon2 performs a second login as user Y (as in scenario A), data merger 243 stores user anon2's contact information (updated by act6 and act7) along with further activities. Then, the contact details of the identified user Y are merged with the contact details information of the identified user Y.

If user anon2 performs a second login as user Then, it is merged with the detailed contact information of user X (which has already been updated to reflect acts 1 to 5).

It should be appreciated that the activity data structure associated with an activity may also include contact detail information. Data extractor 241 can extract and forward this information to data merger 243, which integrates this information with existing contact information in contact database 245 and Quality can be improved. Furthermore, the data extractor 241 can extract detailed information from a particular activity message, the entire stream, another contact, or an external source (such as an IP-to-geographical address translation service, discussed in more detail below). I want you to understand. As discussed above, contacts in the contact database 245 may be contacted by contact details that you explicitly provide as part of the registration or sign-up process, or by signing up to the website (via the social login/registration feature). It may also include contact details extracted from the social networking account you use when uploading or that you provide when updating your user profile. In addition, data extractor 241 can also obtain contact information from external sources (for example, when a user specifies only a US zip code, the site can use this information to perform zip code decoding). (retrieving complete address information from an external web service).

As discussed above, contact identifier 272 may recognize two contacts as related to each other based on a primary ID field (user name, email address, phone number, etc.). If contact A (new) and contact B (existing) are found to be related to each other, data merger 243 can merge A into B (B is the master). This process is performed using, for example, the following field merging rules.

B1=B or A (e.g. "B||A"): Take B, and if B is null or empty, take A.

B1=mathematical function (A, B): Important cases of private data are as follows.

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

B1=list-unit(B,A): Connect list A to the end of list B, and delete elements of A that overlap with elements of B (ie, B1=B&(AB)). Data merger 243 can determine overlap between list elements according to the following rules.

For lists of ordinary values (i.e. scalars), use ordinary value comparisons.

For a list of structures, use specific subfields of the structures as comparison keys. For example, the type of address (home, business, shipping address, etc.) in a website building system 30 that supports multiple addresses.

Comparison of normalized numbers. See (for example) the handling of telephone numbers below.

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

Higher certainty score: A certainty score can be attached to a value (e.g., information provided directly by the user may be given a different certainty score than information that is inferred about the user). do). Data merger 243 can select the value with the higher certainty score.

It is understood that some field types have a normalized format. For example, a telephone number may be normalized to a normalized US format (eg, (999) 555-1234) or an international format (eg, +1-999-555-1234). Data merger 243 may convert field values to a normalized format for comparison, for example when comparing primary keys of contacts (such as phone numbers) or checking for duplicates in a merged list. can.

Data merger 243 can compare two structured values that have the same basic structure (eg, an address value consisting of multiple subfields (country, state, zip code, street, house number, etc.)). The value of each non-empty field in structure structure Y is a detailed version of structure X. Thus, data merger 243 can combine A with B if A is a detailed version of B and A is not identical to 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 only used when the activity originates from a browser session and the user's address is not captured. Therefore, the data extractor 241 can extract state/country information according to the geographic information of the IP address. In this case, the address is marked as "estimated geographic IP address". This marking is necessary because the address field already contains a (possibly incorrect) address based on the IP mapping, which conflicts with later address merging operations, which may cause a later This is so as not to prevent storing detailed (but essentially different) addresses from contacts in the contact database 245.

Data merger 243 can also handle tag conflicts in merged lists. It should be understood that when merging lists, a situation may arise where there are two entities (one from contact A and the other from contact B) that have different but the same tags. In this scenario, data merger 243 includes both entities with the same tag in the list.

Therefore, if you perform the join [{tag: “home”, email: “a@b.com”}] + [{tag: “home”, email: “c@d.com”}], [ {tag: "home", e-mail: "a@b.com"}, {tag: "home", e-mail: "c@d.com"}] are created. Use this method when the fields being merged are marked as "Allow non-unique list tags."

Additionally, data merger 243 may use language parsing, parsing, or other text analysis methods and referencing and utilizing external data sources or services when attempting to combine contact information. For example, a user may enter the street name of their home address in two different formats in two activity records, but enter the same street address, city, and zip code. The combiner 273 may apply text analysis (e.g., a soundex algorithm) when comparing the two entries, and may also combine the two versions of the street name into street names from external sources for a given city and zip code. can be compared with the name. In such a case, combiner 273 will match the standard street name if both addresses are similar (but possibly not the same) to standard street names and all other address data fields have correct values. You can choose a unique street name.

Additionally, data merger 243 can merge contact information according to login/session information. You may begin a session using the Site without logging in or registering, perform some activity as part of that session, and later register or log in, so that session , 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), contact identifier 272 can track the user for the duration of the session (using cookies, session IDs, etc.), and contact handler 242 initiates an anonymous session. Based on the activities performed by the user during the process, a structured contact can be created for that particular anonymous user. Additionally, router/tracker 231 can continue to track the anonymous user across multiple sessions from the same computer. This tracking can be done through the use of persistent cookies (rather than session cookies).

Once a user registers, the data merger 243 can use the established contact information to make initial entries into the user profile. When a user logs in, data merger 243 may initially merge the established contact information with an existing user profile. The information of the constructed contact is merged according to the user's site ID, because the data merger 243 uses the primary ID (email address, etc.) used for merging in addition to the site ID of the constructed contact. Please understand that this is because the information is not retained in the information. Furthermore, it should be understood that such a merge may result in inconsistencies in the information gathered. Unavoidable inconsistencies may occur when merging anonymously constructed contacts with existing profile data. For example, an anonymous user may enter a data form (displayed by some third-party application 40) with the name John Smith, and then (using the same or another browser session) enter a data form with the name Jane Doe. Let's say you log in to your account. In this case, the subsequent login (for example) is either actually a login performed by a different person using the same computer, or the first user uses a pseudonym in the contact form to protect his or her privacy. It is possible that it did. The same applies when data merger 243 merges multiple anonymous constructed contacts.

The conflict resolver 274 can generally automatically handle conflicts 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. Conflicts that cannot be resolved (e.g. by merging multiple values into a list value) can be manually addressed by the site owner or end user (who can decide which value to use), or It can be flagged so that it can be addressed using another technique.

Therefore, the contact information constructed may not reflect a single person, but rather a series of users accessing the same site through the same computer.

As mentioned above, data merger 243 typically merges contacts according to a 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) that has one or more primary ID fields with one or more values (e.g., has two email addresses and three phone numbers). contact record). Users may (for example) have home/work/mobile phone numbers and home/work email addresses, and users may use any of these interchangeably in contact forms. Because there are multiple primary ID fields, multiple primary ID fields may be required.

The data merger 243 normalizes the primary ID values and generates a query that searches for contact records that include any of the normalized primary ID values (e.g., "(phone=P1 OR phone=P2)" or "(email=P2)"). E1 OR email=E2)") can be created. Additionally, data merger 243 can limit queries to contact database 245 for a particular site. Further, the data merger 243 can query the contact database 245 and obtain a list L of matched contacts (including the entered contact C).

If the entered contact 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. Can be done. Data merger 243 can then save updated contact C back to contact database 245 and delete all remaining contacts in list L from contact database 245. Alternatively, data merger 243 can perform a virtual merge as described above, i.e., combine all contact information (i.e., merge all contact records so that all available information is included). ), mark matching contact records as belonging to the same person (instead of deleting "duplicate" contact records). This may be necessary, for example, if the internal ID unique to the contact record is stored or used by third-party applications 40, and therefore deleting the contact record will cause these third-party applications 40 to not function properly. This is the case. The same process (ie, marking contacts as related to each other rather than deleting them) can also be applied in other cases, which will be discussed in more detail below.

If the entered contact is "not" a registered site member, data merger 243 may check the number of site member contacts included in list L. If site members are zero, data merger 243 may remove contact C from list L and merge all remaining contacts in list L with contact C. Data merger 243 can then save updated contact C back to contact database 245 and delete all remaining contacts in list L from contact database 245.

If one site member (contact D) exists, data merger 243 deletes contact D from list L and merges all remaining contacts in list L (including contact C) with contact D. Can be done. Data merger 243 can then save updated contact D back to contact database 245 and delete all remaining contacts in list L from contact database 245.

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

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

For example, data merger 243 merges the following contacts.

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

Data merger 243 can generate combined contacts as follows.

Combined Contact = [Phone = [Phone 1, Phone 2], Email = [Email 1, Email 2]].

It should be appreciated that contact database 245 may include contact information from multiple sources and with different levels of permission for use. Although the following discussion uses e-mail as an example, the following description and techniques apply to any of the aforementioned types of information used to contact you (phone number, fax number, Skype ID, instant messaging ID, etc.). This also applies to social network IDs, etc.).

For example, permissions for use of an e-mail address may vary depending on the route through which the e-mail address was provided to the site. Some possible paths to obtaining an email address are registration ID, contact form, newsletter sign-up, and unsubscribe request. Additionally, email addresses may differ in terms of "permitted use consents" that are electronically signed by the user.

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

Data/permission handler 244 may enforce correct usage policies for third party applications 40 used within the site to assist website owners in managing this information.

Accordingly, two information fields may be included in the contact record of the associated contact. The first field is the Website Permissions field, which contains the permissions calculated or suggested by the website from the user's activities. A contact form only implicitly specifies a functional email, whereas a subscription form implicitly specifies a recurring email. The second field is a site owner permission field based on the value of the website permission field. Site owners can change the website's recommended permissions and set them as they wish, but are responsible for any use beyond the scope of the permissions defined by the website permissions field.

It is understood that the value of the website permission field represents the website's best understanding 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 distribution).

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

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

Email ID: Email address provided for the purpose of registration. It may not be used for the purpose of sending e-mails, except for registration-related content (e.g., registration confirmations, forgotten passwords, notifications of suspected security breaches, etc.).

Functional Email: Provided for specific functions and allowing one-time email. For example, purchase confirmation emails or emails provided in response to certain contact forms.

Recurring emails: Allowing certain websites to send you multiple recurring subscriptions and advertisements. Explicit subscription/approval is required in this case.

Shareable Email: Allows the website and its partners (third party applications 40, 4 ^th parties) to send multiple recurring subscriptions and advertisements. Explicit subscription/approval is required in this case and can include detailed information about allowed sharing.

Opt-out: The user explicitly unsubscribes. You cannot send email to that user (except in some cases with opt-out notices).

The data/permission handler 244 recognizes that alternative methods can be used, such as permission bitmasks (similar to those used in UNIX and Linux systems) and ACL (access control list) mechanisms. I want to be understood. Additionally, data/permission handler 244 may implement separate permission fields that target separate portions of contact information (eg, email address, instant messenger address, social network ID, etc.).

In a typical usage scenario, contact database 245 includes a first set of email addresses collected from contact forms and a second set of email addresses from subscription requests. The website may call a third party application 40 for newsletter distribution, where the third party application 40 is provided only to users belonging to a second set of users (users who have sent subscription requests). Recognize sending email.

The advantage of such a system is that it protects both the website and the website owner (both technical and legal) against users being accidentally spammed or their personal information being misused. ) and the ability to actually enforce privacy policies when the system is used in conjunction with the private data proxy 234 as described above. Furthermore, requests to stop distribution can be more strictly enforced.

Accordingly, 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. Additionally, if it is determined that different activity streams have the same origin, the activity data structures of the individual streams may be merged to form a contact. For example, a user may conduct activities anonymously across two devices (e.g., a mobile device and a computer). Two anonymous streams are generated by such users and messages are stored under these anonymous streams. Once these streams 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 programs according to the teachings herein, or it may be advantageous to construct specialized equipment to perform the desired method. The desired structure for a variety of these systems will be apparent from the above description. Furthermore, embodiments of the invention are not described with respect to any particular programming language. It should be understood that a variety of programming languages may be used to implement the inventive teachings described herein.

Unless otherwise specified, as is clear from the foregoing discussion, throughout this specification, references to terms such as "processing," "computing," "determining," etc. a computing system, or similar electronic computing device (data represented as physical quantities, e.g., electronic quantities in registers or memory of a computing system; It is understood to mean the operation or processing of a transmitting device, a display device, or a device that manipulates or converts data into other data similarly represented as physical quantities.

Embodiments of the invention may include apparatus for performing the acts/operations described herein. The apparatus may be specially constructed for the desired purpose, or the apparatus may include a general purpose computer that can be selectively activated or reconfigured by a computer program stored in the computer. can. Such computer programs may be stored on a computer readable storage medium, such as, but not limited to, any type of disk (floppy disk, optical disk, magneto-optical disk, etc.), read-only memory (ROM), compact disk, etc. 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 The instructions may be stored on any other type of medium suitable for storing instructions and coupled to a computer system bus.

While certain features of the invention have been illustrated and described, numerous modifications, substitutions, changes, and equivalents will become apparent to those of ordinary skill in the art. It is therefore to be understood that the appended claims are intended to cover all such modifications and changes that fall within the essential concept of the invention.

[Related applications]
This application claims priority to U.S. Provisional Patent Application No. 61/911,485, filed December 4, 2013, which is incorporated herein by reference in its entirety. .

Claims (14)

A system for a website hosted by a website building system (WBS), the system comprising:
at least one database storing activity streams of data extracted from activity messages between anonymous users of the website and at least one third party application instantiated in pages of the website;
a hub that facilitates communication of activity messages between the website and the at least one third party application, the hub facilitating at least one of routing, tracking, translation, and verification of the activity messages; with a hub that runs
a processing unit that captures the activity message;
The processing unit comprises:
a contact handler that creates an anonymous user ID for the anonymous user;
creating an activity stream for the activity message associated with the anonymous user ID, and sending the activity message as a first message in a sequence for the activity stream when a contact is initially identified as the anonymous user ID; a stream creator stored in the at least one database;
an activity-stream merger that adds further activity messages of the anonymous user to the activity stream associated with the anonymous user ID;
a stream-stream merger that combines the plurality of activity streams with the anonymous user ID;
A system equipped with. The hub is embedded in the website, and the hub includes:
a router and tracker that routes and tracks the activity messages between the anonymous user of the website and the at least one third party application;
a private policy enforcer that enforces the terms of a privacy agreement between the website and the at least one third party application;
a private data proxy that implements at least one of a private data proxy and a private data substitution and enforces user permission field restrictions between the website and the at least one third party application;
verifying the signature of the activity message using an input key of the at least one third party application, converting an external ID associated with the activity message to an internal ID of the website; a verifier and a signer for signing the activity message using an output key;
2. The system of claim 1, comprising at least one of: associating the anonymous user ID with a registered user of the website, and storing the activity stream associated with the anonymous user ID together with data associated with the registered user in the at least one database; 2. The system of claim 1, further comprising a data merger for storing. The stream-stream merger is a horizontal stream merger for merging at least two separate streams according to a common anonymous user, and associating the activity stream created for the anonymous user with a known user. 2. The system of claim 1, comprising at least one of: a vertical stream merger that merges the activity streams at login or registration that may connect the two. The data merger is
identifying identical primary ID field values in at least two contact records; identifying primary key field values in said at least two contact records that are the same when normalized; and using a cookie. to identify users of the site using site logins for registered users and through social logins for site users who have an account associated with a social network. a contact identifier that identifies at least one of: identifying a site user;
a combiner that combines contact information using at least one of linguistic analysis, syntactic analysis, and text analysis and references to external data sources and external services;
a conflict resolver that resolves conflicts between contact records according to predefined rules;
a list value generator that creates a list value field between contact records to prevent the inconsistency;
a horizontal contact merger merging two unrelated activity streams associated with the anonymous user upon detection of a common anonymous user ID;
a vertical contact merger that merges the activity stream associated with the anonymous user into a contact record associated with a registered user at login or registration;
4. The system of claim 3, comprising at least one of: 6. The system of claim 5, wherein the horizontal contact merger comprises a virtual merger that maintains at least two contact records as separate and links them together such that they are marked as representing the same user. . The vertical contact merger is a virtual contact merger for keeping the anonymous user and the registered user separate and linking them to each other so that they are marked as representing the same user. 6. The system of claim 5, comprising a merger. A method for a website hosted by a website building system (WBS), comprising:
storing in at least one database an activity stream of data extracted from activity messages between anonymous users of the website and at least one third party application instantiated in pages of the website; and,
facilitating communication of activity messages between the website and the at least one third party application, the facilitating communication comprising routing, tracking, translation, and verification of the activity messages; facilitating said communication, including at least one of:
capturing the activity message, the capturing comprising:
creating an anonymous user ID for the anonymous user;
creating an activity stream of the activity messages associated with the anonymous user ID;
storing the activity message in the at least one database as a first message in a sequence for the activity stream if a contact is initially identified as the anonymous user ID;
adding further activity messages of the anonymous user to the activity stream associated with the anonymous user ID;
combining a plurality of said activity streams with said anonymous user ID;
A method of providing. Facilitating said communication includes:
routing and tracking the activity messages between the anonymous user of the website and the at least one third party application;
implementing the terms of a privacy agreement between the website and the at least one third party application;
implementing at least one of a private data proxy and private data substitution to enforce user permission field restrictions between the website and the at least one third party application;
verifying the signature of the activity message using an input key of the at least one third party application;
converting an external ID associated with the activity message to an internal ID of the website;
signing the activity message using an output key of the at least one third party application;
9. The method of claim 8, comprising at least one of: associating the anonymous user ID with a registered user of the website; and storing the activity stream associated with the anonymous user ID together with data associated with the registered user in the at least one 9. The method of claim 8, further comprising: storing in two databases. The combining of the plurality of activity streams includes merging at least two separate streams according to a common anonymous user and associating the activity stream created for the anonymous user with a known user. 9. The method of claim 8, comprising at least one of: merging the activity streams at login or registration that may connect the two. Making the association includes:
identifying identical primary ID field values in at least two contact records; identifying primary key field values in said at least two contact records that are the same when normalized; and using a cookie. to identify users of the site using site logins for registered users and through social logins for site users who have an account associated with a social network. at least one of: identifying a site user;
combining contact information using at least one of linguistic analysis, syntactic analysis, and text analysis and references to external data sources and external services;
Resolving conflicts between contact records according to predefined rules;
To prevent said inconsistency, creating a list value field between contact records;
merging two unrelated activity streams associated with the anonymous user due to detection of a common anonymous user ID;
merging the activity stream associated with the anonymous user with a contact record associated with the user registered at login or registration;
11. The method of claim 10, comprising at least one of: The merging of the two mutually unrelated activity streams includes maintaining at least two contact records as separate and linking them together such that they are marked as representing the same user. 13. The method of claim 12, comprising: The merging of the activity streams maintains the anonymous user and the registered user as separate and links them together so that they are marked as representing the same user. 13. The method of claim 12, comprising: