JP2022068338A - System and method for website - Google Patents

Abstract

PROBLEM TO BE SOLVED: To create and process activity streams.

SOLUTION: In a system 200, a server includes: at least one hub that adjusts at least one activity message between a website and at least one third party application; an activity coordinator that listens the at least one activity message, and at least adds data extracted from the at least one message to an activity stream associated with at least one of an identified contact, which is a website user, and an anonymous contact; a contact coordinator that acquires and analyzes contact-related information from the activity stream and enhances quality of previously held information on the contact; and at least one database that stores the activity stream and the contact-related information so that they can be used by the website and the contact.

SELECTED DRAWING: Figure 15

COPYRIGHT: (C)2022,JPO&INPIT

Description

The present invention relates to an online application and, in particular, a method of use in combination with a third party application contained therein.

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

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

The website building system can be partially online or completely online. For partially online systems, edit the website locally on the user's machine and later upload and deploy it to one or more central servers. Once the websites are uploaded, these website building systems function exactly like online website building systems.

The website building system has an internal data architecture for the purpose of systematizing the data and elements in the system. This architecture may differ from the appearance of the site of interest to the user, and may also differ from the way common HTML (Hypertext Markup Language) pages are sent to the browser. For example, the internal data architecture can include additional properties for each element on the page (author, date and time of creation, permissions, links to templates, etc.), and these additional properties are the website building system. It is essential for editing and maintaining the site internally, but it is not visible to external end users (and in some cases some users who edit). The general architecture of a site based on a website building system can consist of pages containing components (eg, shape components, photo components, text components, as well as single-page and multi-page containers containing mini-pages). can.

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

Designers using such a website building system can either design a new site from scratch (starting with a blank screen) or predefined by the designer himself, the system creator, or a community of designers. You can use the created application template. A website building system can support a template that is just a collection of components, a template that is a complete page (or minipage) or a set of pages, and a template that is a complete website.

When a template for an application is provided, the designer is free to customize it and add, remove, or modify all the elements of the template to create a version of the designer's own template. Such customization can be accomplished by creating a modified version of the template (a separate version that differs from the template). Alternatively, the website building system can apply customizations through an inheritance-type mechanism, which maintains a link to the original template and is therefore done later on the template. The changes will be reflected.

In addition, the website building system can be extended using third-party applications and the components embedded within them. Such third-party applications may be included in the design environment of the website building system, or through various distribution mechanisms, for example from the application store (AppStore) built into the website building system, or. It can 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. In addition, the third-party application can also be obtained directly from the vendor of the third-party application (through or without the App Store), in which case the vendor will provide the actual installation module, or an activation code or access code. Only provide.

Third-party applications may include any combination of front-end (display) and back-office elements (which do not appear on the website). Third-party applications can be wholly back office (ie, contain no display elements), wholly front-end (ie, launched only when used on a website), or a combination of the two. be.

Back office elements of third-party applications may include features such as database communication options and external update options. For example, a blog's third-party application can be a stand-alone source that can post blog entries from non-human sources (eg, RSS news feeds from major news services) and from non-website sources (eg, blog entries). It may contain back office elements that can receive updates from smartphone applications).

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

Furthermore, the third party application (both widget type and section type) can be a single page third party application or a multi page third party application (having an internal minipage represented as an internal URL structure). .. 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 usually provide a default "landing" mini-page, which can be an opening page, a specific internal mini-page (eg, the latest blog entry in a blog's third-party application), or a mini. A page selection screen or other mini-page.

The use of third-party applications on websites based on the website building system is done through instances of third-party applications. Website building systems can support multiple uses of third-party applications at multiple levels, for example, multiple thirds inside a website, allowing one instance of the third-party application throughout the website. Allows you to create instances of party applications (but only one instance per third party application), allows you to create multiple instances of multiple third party applications (but only one instance per page) ). In addition, you can allow multiple instances per page of a component-type third-party application (not a section-type third-party application), and without restrictions on the number, multiplicity, or location of third-party application instances. You can also allow multiple instances of multiple third-party applications.

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

For purposes of illustration, a website page (or minipage) (ie, a "wrapper page") containing a third party application and its minipages or elements shall be referred to as a containing web page and throughout the website. It shall be known as the main site. The integrated page shown to the user (including the main page and the embedded TPA minipage / component) is referred to as a synthetic page. For section-type third-party applications, the "virtual page" containing the third-party application acts as the containing web page.

Third-party applications are typically deployed on the website-building system vendor's server, the third-party application vendor's server, an external (force-party) server, or any combination of these servers. Third-party applications are dynamically executed inside the elements that actually run on the end user's machine (for example, statically installed browser extensions or, as shown in Figure 1, the client-side code of the website building system. It can also include Javascript® components, etc. that are executed in. In the following, reference will be made to FIG.

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

An instance of the included third-party application can have its own internal content, just as a regular component contains internal content. With reference to Figure 2, as shown in this figure, third-party applications may 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 can have shared content, for example, two online shop instances on two separate website pages can reference the same product database.

The output from the included third-party application can be incorporated into the contained web page in various ways, for example:

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

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

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

US Patent Application Publication No. 2013/0219263

According to a preferred embodiment of the invention, a system that can be implemented on a website via a client / server system, wherein the client / server system has at least one processor that processes the instructions that define the system. Provides the system. The system is at least one hub that coordinates at least one activity message between a website and at least one third party application, where at least one activity message has a standardized format. Including hub. In addition, the system listens to at least one activity message and adds at least the data extracted from these at least one message to the stream associated with at least one of the identified and anonymous contacts, the activity coordinator. And at least one of the identified and anonymous contacts includes an activity coordinator, who is a user of the website. In addition, the system retrieves and analyzes contact-related information from streams to improve the quality of previously held information for contacts, activity streams and contact-related information for use by contact coordinators and websites and contacts. Includes at least one database for storing information.

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

Further, according to a preferred embodiment of the invention, the activity coordinator is a stream creator and at least one that identifies the contacts associated with at least one activity message and creates a stream of data if no associated contacts exist. A stream merger that merges data from one activity message into an existing stream and data from at least two of the activity streams into one stream, and records activity data from the activity stream in at least one database. Includes a log creator and at least one of them.

Further, according to a preferred embodiment of the invention, the contact coordinator is a data extractor that extracts contact-related information from at least one of at least one activity message, stream, another contact, and an external source, and at least two. A data merger that merges two contact information records and merges the extracted contact-related information into the relevant information of an existing contact according to predefined merge rules, where the record is the same identified contact. Contact handlers and extracted contact-related information that create at least one of the relevant new and identifiable contacts and anonymous contacts with the data merger and track the activity of the contact during the session of the website. Includes at least one of a data / permission handler that processes the privacy protection and permission of.

Further, 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 the data into the stream associated with the identified contact, an activity-to-stream merger and at least two separate streams. Includes stream-to-stream merger, which merges into one stream.

Further, according to a preferred embodiment of the invention, a stream-stream merger is a horizontal stream merger that merges at least two individual streams according to a common contact identified, and an anonymous contact and registration. With a vertical stream merger that merges a stream created for an anonymous contact into the stream associated with the registered contact when the contact is joined at login or registration. , At least one of them.

Further, according to a preferred embodiment of the invention, the data merger is normalized in at least two of the contact information records, specifying the same primary ID field value in at least two of the contact information records. Identify primary ID field values that are the same when you use cookies to identify site users, use site login to identify site users for registered users, and social networks Includes a contact classifier, which performs at least one of identifying site users through social login in the case of site users with associated accounts. In addition, the data merger uses at least one of linguistic analysis, syntax analysis, and text analysis, and the reference and utilization of external data sources and external services to combine contact information between the combiner and the contact record. A common primary ID was found with a conflict resolver that resolves inconsistencies according to predefined rules, and a list value creator that creates list value fields and defines a clear priority between contact records. By doing so, when a horizontal contact merger that merges two unrelated contacts, an anonymous contact, and a contact associated with a registered user are combined at login or registration. Includes, vertical contact merger, which merges anonymous contacts into contacts associated with registered users.

Further, according to a preferred embodiment of the invention, the horizontal contact merger maintains at least two contact records as separate records, and the two contacts are shown to represent the same contact. Includes a virtual merger, which links records to each other.

Further, according to a preferred embodiment of the invention, the vertical contact merger keeps the anonymous contact and the contact associated with the registered user as separate contacts and associates them with the anonymous contact and the registered user. Includes virtual mergers, which link to each other so that the contacts that are attached 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 is a format defined by a predefined schema, a format defined by inheritance, a format defined by a callback link, at least one third party. At least one of a format encoded and defined by the application, 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 that can be implemented on a website via a client / server system, wherein the client / server system has at least one processor that processes the instructions that define the method. Providing a method. The method is a step of coordinating at least one activity message between a website and at least one third party application, wherein the at least one activity message has a standardized format and at least one. The step of listening to activity messages and adding the data extracted from at least one of these messages to the stream associated with at least one of the identified and anonymous contacts, the identified and anonymous contacts. Includes steps, where at least one of the contacts is a user of the website. In addition, the method retrieves and analyzes contact-related information from the stream to improve the quality of the contact's previously retained information, as well as the activity stream and contact-related information for use by websites and contacts. Includes steps to store and.

Further, according to a preferred embodiment of the invention, the coordinating steps are a step of routing and tracking at least one activity message between the website and at least one third party application, and a step of routing and tracking the website and at least one third party. A step to enforce a privacy policy with your application, a step to apply at least one pre-specified message conversion / content adaptation rule between your website and at least one third-party application, and a private data proxy. And at least one of the private data replacements, the step of enforcing the restriction of user permission fields between the website and at least one third-party application, and the signing of at least one activity message. Validate using the input key of a third-party application, translate the external ID associated with at least one activity message using the internal website ID, and send at least one activity message to at least one third party. Includes at least one of the steps of signing with the output key of the application.

Further, according to a preferred embodiment of the invention, the steps of listening and adding at least identify the contacts associated with at least one activity message and create a stream of data if no associated contacts exist, and at least. The step of merging data from one activity message into an existing stream, merging data from at least two of the activity streams into one stream, and recording the activity data from the activity stream in at least one database. Includes at least one of the steps.

Further, according to a preferred embodiment of the invention, the acquisition and analysis steps include extracting contact-related information from at least one of at least one activity message, stream, another contact, and an external source, and at least. The step of merging two contact information records and merging the extracted contact-related information into the relevant information of an existing contact according to a predefined merge rule, where the record is with the same identified contact. Includes at least one of the relevant steps. In addition, the steps to acquire and analyze create at least one of the new and anonymous contacts that can be identified, track the activity of the contact during the session of the website, and protect the privacy of the extracted contact-related information. And including steps to process permissions.

Further, according to a preferred embodiment of the invention, the routing and tracking steps support 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 merging step comprises merging the data into a stream associated with the identified contact and merging at least two individual streams into one stream. ..

Further, according to a preferred embodiment of the invention, the step of merging data into the stream associated with the identified contact and the step of merging at least two individual streams into one stream combine at least two individual streams. Created for anonymous contacts, with a horizontal merging step according to the identified common contact, and when an anonymous contact and a registered contact are associated at login or registration. Includes at least one of a vertically merging step of vertically merging the stream to 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 is a step of identifying the same primary ID field value in at least two of the contact information records, of the contact information records. Use at least two steps to identify the primary ID field value that is the same when normalized, use cookies to identify site users, and use site login for registered users. Includes at least one of a step of identifying a site user and, in the case of a site user with an account associated with a social network, a step of identifying the site user through social login. In addition, the step of merging at least two contact information records combines contact information using at least one of linguistic analysis, syntactic analysis, and text analysis and reference / utilization of external data sources and external services. Steps to resolve conflicts between contact records according to predefined rules, steps to create list value fields and define clear priorities between contact records, and a common primary ID found By doing so, the step of horizontally merging two unrelated contacts and the anonymous contact and the contact associated with the registered user are anonymous when they are linked at login or registration. Includes a step of vertically merging contacts into the contacts associated with the registered user.

Further, according to a preferred embodiment of the invention, the horizontally merging step keeps at least two contact records as separate records, so that these two contact records represent the same contact. Includes a virtual merging step, in which two contact records are linked together.

Further, according to a preferred embodiment of the invention, the vertically merging step keeps the anonymous contact and the contact associated with the registered user as separate contacts, the anonymous contact and the registered user. Includes a step of linking them together and virtually merging them so that the contacts associated with are shown to 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 is a format defined by a predefined schema, a format defined by inheritance, a format defined by a callback link, at least one third party. At least one of a format encoded and defined by the application, a format based on an external formal standard, an industry standard, or a de facto standard.

The subject matter considered to be the present invention is specifically pointed out and clearly stated in the conclusions of this specification. However, by reading the following detailed description with reference to the accompanying drawings, a deeper understanding of the invention, both in terms of its organization and method of operation, and the purpose, features and advantages of the invention. Can be done.

Schematic diagram of the deployment configuration between the website building system and the third party application Schematic diagram of internal content management for third-party applications Schematic diagram of including a third-party application in the contained web page by server-side processing Schematic diagram of including a third-party application in the contained web page by client-side processing Schematic diagram of including third-party applications in contained web pages with iframe inclusions Schematic of the display of existing non-optimal third-party applications when changing page layouts Schematic of a system that integrates a website building system with one or more third party applications, built and operating in accordance with the present invention. Schematic of a system that integrates a website building system with one or more third party applications, built and operating in accordance with the present invention. Schematic diagram of the Document Object Model compared to the component model Schematic diagram of an example multipart third-party application for a blog Schematic of an example of a modular third-party application for sale Schematic of different implementations of communication hubs built and operating according to the present invention Schematic of different implementations of communication hubs built and operating according to the present invention Schematic of the elements of the communication hub of FIGS. 11A and 11B that are constructed and operate according to the present invention. Schematic of the communication conversion process performed by the communication hubs of FIGS. 11A and 11B constructed and operated in accordance with the present invention. Schematic of containing web pages dealing with third party applications with associated templates that are built and work in accordance with the present invention. Schematic of a contained web page containing a third party application with associated templates inside a mini page that is built and works according to the present invention. Schematic of a system built and operating 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 of the elements of the system of FIG. 15, constructed and operating in accordance with the present invention. Schematic of the elements of the system of FIG. 15, constructed and operating in accordance with the present invention. Schematic of the elements of the system of FIG. 15, constructed and operating in accordance with the present invention. Schematic of the elements of the system of FIG. 15, constructed and operating in accordance with the present invention. Schematic of an example of a graphical user interface that displays an activity stream associated with a contact, constructed and operating in accordance with the present invention. Schematic diagram of message passing for activity messages for client-side and server-side third-party applications Schematic diagram of login / logout processing during a user's website session

It should be understood that the elements shown in the drawings are not always drawn to the correct scale for the sake of brevity and clarity. For example, for clarity, the dimensions of some elements may be exaggerated more than others. Further, where appropriate, the corresponding or similar elements are represented by the same reference numerals in multiple drawings.

In the following detailed description, a huge amount of specific details are given for the purpose of fully understanding the present invention. However, those skilled in the art will appreciate that the invention can be practiced without these specific details. Furthermore, well-known methods, procedures, and components are not described in detail so that the invention is not obscured.

Applicants may find that there are many restrictions on the current way in which third-party applications are generally integrated into the website building system and the current way in which the integrated third-party application interacts with the website building system. Recognized.

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

Third-party applications may have their own display style (color scheme, font, font size, etc.). These styles are compatible with some containing web pages, but may be visually problematic or incompatible with other containing web pages.

Another limitation is the inflexibility of displaying third-party applications from the perspective of the containing site. If you need to visually modify your site (for example, to deploy to platforms with different screen sizes, or due to dynamic layout events), resize the windows assigned to third-party applications. May be required on web pages contained in. In such cases, the display of the third-party application is cut off in the middle, requiring scrolling through the scroll bar to reach the various sub-areas of the third-party application. With reference to FIG. 6, this figure shows an example of a situation that can occur when resizing the contained web page [a]. Since the area allocated to the third party application [b] of the online shop is reduced and the "purchase" button [c] cannot be displayed together with the contents of the shopping cart [d], the purchase must be completed. Several scrolling operations are required, greatly reducing the likelihood that the purchase will actually be completed.

It should be understood that third-party applications cannot interact with other components within the contained web page, and such dialogue may be required to achieve complex functionality. In particular, third-party applications cannot perform different behaviors depending on the type and content of the components within the contained web page. One example of this is a website that streams online cooking classes. In the background of watching a video, the user wants to display a small screen area dedicated to delivering the latest news and weather information (such as a live stream from CNN) in another area of the screen. There is. Users may wish to automatically suspend their learning sessions when the weather forecast for their area begins.

Moreover, there is no clear and standard way for these third-party applications to work together, especially if multiple third-party applications are offered by different vendors. Therefore, designers have no clear way to combine multiple third-party applications from different vendors. One example of this is for 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 the shipping schedule.

Applicants are both structured between the website building system and the third-party application instances contained therein, and between several different third-party application instances that can be implemented within the same content page. We realized that this integration could be achieved by using forward communication channels. These channels can also transfer information about layouts, styles, and additional information.

The following description focuses on the iframe inclusion method, which is preferred as it is built into and integrated with modern browsers and does not require the creation of dedicated integration code. Please understand. In addition, the iframe inclusion method provides browser-supported encapsulation and sandboxing capabilities, as well as essential protection against hacking techniques such as cross-site scripting attacks that can be adopted by malicious third-party applications. To.

Next, with reference to FIGS. 7A and 7B, these figures show a system 100 that integrates a website building system with 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 run time. As can be seen in FIG. 7A, the system 100 is installed on the client 10, the website construction system 30 installed on the website construction system (WBS) server 20, and one or more third party application servers 50. It includes one or more third-party applications 40 that are installed. The website construction system 30 includes a WBS coordinator 21, an application repository 22, a WBS-side TPA property sheet 23, a third-party application (TPA) coordinator 24, and an AppStore 25 (which can include a searcher 26). There is. The client 10 includes a page composer 12 and a client-side display of the TPA property sheet 23. In some embodiments, the client 10 may further comprise a client-side display of the App Store 25. The page composer 12 includes a linker 13, which will be described in more detail later. The third-party server 50 includes a third-party application 40, an external TPA coordinator 51, and a TPA database 52, and the TPA database 52 stores components, templates, and the like of the third-party application 40 so that they can be used. .. The system 100 can include a plurality of third party servers 50 belonging to a plurality of vendors of the third party application 40.

It should be understood that the TPA property sheet 23 can be called when the attributes of the instance of the third party application 40 are specified. Furthermore, it should be understood that when called, the TPA property sheet 23 is displayed as a client-side display of the TPA property sheet 23 on the client 10. Furthermore, it should be understood that offline embodiments may have their own property sheet as part of the installed client software, and therefore there is no application TPA property sheet 23 or repository.

A designer or end user 5 sitting in front of a client 10 can use the page composer 12 to create a website page and an interaction (inter-page dialogue and in-page dialogue) of his website (inter-page dialogue and in-page dialogue). Or understand that you can create other online applications). Designer 5 can select components, templates, etc. that are part of the website construction system 30 stored in the application repository 22 via the WBS coordinator 21. Further, the designer 5 can create an containing web page 203 for embedding a third-party application 40 instance from the third-party application 40, and the third-party application 40 can be purchased in advance and its template, component, or the like can be applied. It can be stored in the repository 22. In the alternative embodiment, the purchased template, component, or the like is stored in the TPA database 52 and can be accessed via the external TPA coordinator 51. In yet another embodiment, templates, components and the like for the third party application 40 can be purchased via the App Store 25 as needed. The property sheet 23 can be specified by the designer 5 and can hold information (permissions, installation guides, payments, etc.) about the purchased instance of the third party application 40, which will be described in more detail later. Further, the designer 5 can manually specify the communication channel (if necessary) between the plurality of included third-party applications 40 using the linker 23. Further, it should be understood that Designer 5 can use the linker 23 to specify unique communication connections and rules between the contained web page it is building and the instances of the third party application 40 contained therein. (As mentioned above, videos and CNN news reports are displayed at the same time). It should be understood that the links created by the linker 23 can be modified for the life of the website.

It should be appreciated that Designer 5 may acquire the Third Party Application 40 through an external channel of the App Store 25, such as an external App Store operated by a vendor of the Third Party Application 40 or an outside vendor. In such a case, the website construction system 30 will install the third party application 40 and its configuration data (configuration) when the third party application 40 is first installed on the website created through the website construction system 30 by the designer 5. data) can be registered.

In order for the linker 23 to be able to establish a communication channel if necessary, the third-party application 40 may use a component (an instance of another third-party application 40) in the containing web page 203 (which it is trying to communicate with). Please understand that it is necessary to be able to correctly recognize and identify (including). For components based on the associated template (discussed in more detail later), this identification is pre-performed by the vendor of the third-party application 40. The components in the associated template can be given unique reference IDs, and the third-party application 40 can use these IDs when communicating with these components.

Further, in the case of a multipart third party application 40 (ie, one third party application 40 distributed across multiple iframes) (discussed in more detail later), the plurality of parts automatically recognize how to communicate with each other. Please understand that you can.

For contained website page components (more on this later) that are not included in the associated template, the third-party application 40 is required (required or optional) to be present for it to function. ) Can include a list of components of contained web page 203. This list can be stored in the property sheet 23 with a unique ID, description and component details (eg, must be a text component, used as a blog talkback label). Can be included. 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 for the components (fields) in the contained web page 203 that meet the requirements of the third party application 40. Can be specified. The website building system 30 can dynamically create the missing components of the contained web page 203 when the instance of the third party application 40 is created, and the designer 5 will later create these components. It should be understood that it can be moved, resized, and fully specified.

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

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

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

In addition, a link (eg, a broadcast link) between the contained web page 203 and an instance of the third-party application 40 can be automatically created, in which the third-party application 40 sends a communication at run time to identify. Please understand that you can record the event of. This communication can be optional or mandatory (ie, the third party application 40 will not work or will not install unless there is a corresponding third party application 40 linked to receive such a message. ). For example, the third-party application 40 can broadcast information packets about the operation / function to be executed by the third-party application 40, and the installed logging third-party application 40 can receive these information packets.

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

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

Hub 205 can be implemented on the client 10, because both the inclusion of the contained web page 203 and the inclusion of the third party application 40 are the interactive parts of the visible website and these communications are between the client and the server. It should be understood that this is because it should not be delayed by a round trip. In the alternative embodiment, if the third party application server 50 needs to exchange a large amount of data and it is preferable not to pass these data through the client 10, the hub 205 is mounted on the server 20 of the website construction system. be able to.

It is understood that the communication hub 205 can support various combinations of communication between the website building system 30 and one or more third party applications 40 and communication between the plurality of third party applications 40. sea bream. For example, the hub 205 allows a third party application 40 to request the website building system 30 to switch to another page within the main site. In addition, the communication hub 205 allows the third party application 40 to request that its window be resized (which in some cases may affect the layout of the contained pages). This resizing can be done through a dynamic layout process, which will be described in more detail later. Alternatively, if the third party application 40 is required to switch to another version in order to (eg) change the display, the contained web page 203 may request this switch. This two-way communication is between the components of the third-party application 40 and the components of the website building system 30 (which display additional information) related to the third-party application 40, and as described above, the multi-part third-party application. It should be understood that it can also be established between the 40 elements and the modular third party application.

Further, the system 100 can be implemented using both online and offline website building systems 30, and the system 100 can also be implemented by hosting methods (eg, client-side elements, vendors of the website building system 30). It should be understood that any combination of servers, third-party application 40 vendor servers, other force-party servers, etc.) can be used. It should be understood that the server may be required to implement the system 100 even in the case of the offline embodiment described above.

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

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

Further, the system 100 can also implement the multipart third party application 40. The multipart third party application 40 can include a plurality of display areas, each of which is processed using a separate iframe. These areas can also cooperate (if necessary) through the communication hub 205, as described in more detail later.

Next, with reference to FIG. 9, this figure shows an example of a multipart third party application 40. As illustrated, a blog third-party application [a] obtained from the App Store [b] is located on the containing web page 203 [c]. The blog third-party application [a] includes three areas, namely, a blog entry area [d], a tag cloud area [e], and a news update area [f]. Multipart third-party applications can use their multiple areas in different ways, for example as multiple co-existing parts of an application (as in the blog example above), or one. It should be understood that it can be used as multiple parts of an application that exist as options, including multiple areas that are always displayed and multiple areas of options that are only displayed when requested. The display of the optional area can be controlled by the third party application 40 or by the designer 5 (which determines how to configure it when including the third party application). Furthermore, the display can be controlled as a support function area such as a configuration area or an additional dialog area. The same is true for displaying multi-version third-party applications (eg, having small and large versions of third-party applications, or having portrait and landscape versions of third-party applications) as an alternative.

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

Further, in order to implement the multipart third party application 40, it is required that the third party application 40 (inside each iframe) can control the display of various iframes (for example, the visibility, size, and position of the iframe). Will be done. Further, it should be understood that the communication hub 205 can enable this display, as will be described in more detail later.

Moreover, even when the multipart third party application 40 (visually) consists of multiple elements and areas, the application 40 is still one third party application in terms of purchase, installation, configuration, etc. (eg, in the App Store 25). Please understand that it is considered to be 40.

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

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

A module in a third-party application 40 is either a required interface (ie, an interface that the module does not work without it) or an optional interface (ie, the module works but is provided without it). Interfaces that are restricted or change) can be specified. Therefore, the parameters provided for each interface are a unique interface name, an interface description (shown to Designer 5 so that Designer 5 can (eg) recognize the features handled by the missing interface), required / optional. Status, list and type of interface parameters. 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 the communication channel, which will be described in more detail later.

It should be understood that the modules of the third party application 40 can be assembled during the design phase of the website. The website building system 30 can resolve interface references by adding an additional module of the third party application 40, in which case the new module of the third party application 40 will provide the existing required interface. Resolves, but in some cases adds new (unresolved) required interfaces.

In addition, it should be understood that Designer 5 can edit and run the completed website while the required (and optional) interface is still unresolved. However, Designer 5 will not be able to publish the created website until all the required interfaces have been resolved, and Hub 205 will launch a third party application module that still has the required unresolved interfaces. A message is displayed when you try a function that requests.

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

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

In addition, the system 100 can be applied to an online application editing system, which is an online application created using the Internet (or any other network connection) and client-side software that is not a browser. Is displayed. Such systems do not need to use the specific techniques used by conventional web infrastructure (eg, IP communications, HTTP, HTML, etc.).

It should be understood that cross-domain communication can be facilitated using standard cross-domain communication methods known in the art. Examples of the cross-domain communication method include the following.

HTML5 PostMessage: A standard feature of HTML5 that can be used to provide secure cross-domain messaging. HTML5 Windows. Postmessage allows you to securely send messages between windows, iframes, and main HTML documents, even if they belong to different domains. PostMessage provides a tool for the sending frame to specify the domain to which the message is sent, and a tool for the receiving frame to confirm the domain from which the message is sent.

Message URL Fragment Identifier: In this method, the URL fragment identifier is used 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 the service in the target endpoint domain, or the hidden frame inside the target endpoint iframe. The fragment identifier is decrypted by the code in the target service or iframe.

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

HTML5 Local Storage: HTML5 provides a structured local storage feature that allows you to store queued messages. However, local storage can only be accessed by web content that belongs to the same domain as the stored iframe. Solutions developed in this field include the basic technology used by Meebo XAut products (currently owned by Google), which requires a small server to provide the required intermediate frame. It provides support for creating, which allows domain-specific local storage to be accessed from an iframe belonging to an external domain.

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

Dedicated Browser Plugin: You can create a dedicated browser (or other user agent) plugin to manage cross-frame message queues. Such plugins must be installed by users of Website Builder System 30 (at all levels), but provide the necessary services for all iframes and the main page of Website Builder System 30. ..

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

In addition, the hub 205 facilitates smart addressing and smart identification, identifies sources, applies communication policies, solves incompatibilities with third-party applications 40, and even components from third-party applications 40. Please understand that you can redirect to. Further, the hub 205 can allow dynamic updates of the layout in the third party application 40 based on the changes made to the contained web page 203, which will be described in more detail later.

Next, reference is made to FIGS. 11A, 11B, and 11C. 11A and 11B show different embodiments of the hub 205, and FIG. 11C shows the function of the various elements of the hub 205.

Hub 205 is hosted with a smart identifier / addresser 310, a source confirmer 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 host. It can be equipped with an API (application programming interface) wrapper 390. The function of these elements will be described in detail later. All functionality can be applied to all cross-domain communication channels (eg, the channel from the third party application 40 to the website building system 30, the channel from the third party application 40 to another third party application 40). I want you to understand.

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

Next, with reference to FIG. 11B, this figure shows an alternative embodiment, in which the communication API module (embedded in the third party application [c]) without the use of an intermediate frame [c]. Cross-domain communication is used in one or both of a] and the communication API module [b] (embedded in the third party application [d]). When handling the communication message [f], the module [a] and the module [b] directly interact with the website construction system 30 to receive information specific to the application and use this information. The disadvantage of this embodiment (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 the module contained in the third party application. This information may be accessed (and possibly modified) by malicious third-party applications.

As mentioned above, in all the cross-communication methods described above, the addressing of the iframe is based on the origin of the iframe (source domain, source protocol, source port, etc.), i.e. (to specify the receiver). The direct addressing of the third-party application 40 is used when sending the message and when receiving the message (as the sender's name provided to the receiver). In addition, in order to send a message, the sender is required to specify the target's iframe window (using Javascript's document.getElementById ("..."). ContentWindow call or any other method). Will be done. Therefore, in an existing system, 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 understood that this type of direct addressing can be awkward in the environment of system 100. Even if Designer 5 integrates multiple third-party applications 40 from multiple unaffiliated third-party application 40 vendors, the third-party application 40 supplied by the third-party application 40 vendor will initially have a particular domain. Hosted at, but may later move to another domain or subdomain. Third Party Application 40 Vendors may change the protocol or port used to communicate with a particular third party application. Designer 5 may be required to modify the design of the contained web page 203 that includes the third party application 40. All of this can happen in the third party application 40 used in a website that is in operation and accessed by a large number of users. Further, one containing web page 203 may include multiple instances of one third party application 40 capable of performing different functions. For example, on one page within a product support website, two instances of a third-party application 40 for chat (one for user-to-user chat and forums, and the other reachable. Sometimes it contains an instance) that is used to consult with the vendor's support personnel.

The addresser / identifier 310 is fully aware of the structure of the contained web page 203 and the details of the third party application 40 (provided to the website building system 30 by the vendor of the third party application 40). Please understand. The addresser / identifier 310 identifies the addressing of the source third-party application 40 or the destination third-party application 40 with the unique name of the third-party application 40 (registered in the AppStore 25) and the third-party application on the containing web page 203. Descriptive ID of an instance of a third-party application 40 and the type / class of the required third-party application that are added to each instance of 40 and thus allow the addressing of multiple instances of the same third-party application 40. Provide each other using one of the generic identifiers (eg, "I want to send a message <x> to an instance of a third-party application 40 for event logging on contained web page 203"). Can be done. Such an identifier can also describe a particular service to be supported by the third party application 40. Further, the addresser / identifier 310 can use the version instruction information (eg, "only if the accounting package <y> is the version <z>, the transaction <x> is sent to the instance of the accounting package <y>. 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, not the addresses of the other third-party applications 40. Please understand that. This one direct address can be encapsulated by the 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, etc.). The calling third-party application 40 can provide its own (described above) descriptive addresses known to the application, and the addresser / identifier 310 translates these addresses into the direct addresses of the third-party application 40. Can be routed. By doing so, the third-party application 40 does not need to maintain a table of absolute addresses of all third-party applications 40 with which it can communicate.

It should be understood that confirmation of the origin of the message is important and that without confirmation, the receiving third party application 40 may receive the message from the hostile third party application 40. Since all communication is done via the hub 205, the originator 320 can check the reliability of all input messages from third party applications. In addition, the originator 320 can provide additional information that can be added to the message, and this additional information can be used to make additional confirmations. Since each of the third party applications 40 included in the AppStore 25 and used by the system 100 is registered with the website building system 30, the hub 205 has a unique ID of the originator contained in the message. It should be understood that the website construction system 30 can confirm whether the message matches the source (domain, port, etc.).

The third-party application 40 can define a general communication policy that can depend on external information, information on the contained web page 203, and the like. The communication policy Enforcer 330 can be made to apply the corresponding communication policy so that it is not necessary to handle the communication that does not conform to the specifications. For example, on websites dealing with sensitive information, third-party applications may be given confidentiality level fields in their profiles. A third-party application 40 that provides a back-end event logging database that is allowed to handle confidentiality level X can define a policy of accepting and not logging events with a higher confidentiality level than X. In such situations, the Communication Policy Enforcer 330 can perform the necessary pre-filtering to prevent high-level confidential messages from even reaching applications that can only handle low-level confidentiality.

In addition, Designer 5 has created two (or more) third-party applications on the same website that can be collaborated but not in practice due to protocol compatibility issues. Please understand that you may want to include it. Here, with reference to FIG. 12, for example, as shown in this figure, the third party application [a] of the online shop is a third party of procurement / shipment such as the third party application [b] (provided by a different vendor). The party application may have the ability to send a purchase order message. However, the information provided by the third-party application [a] may not include some of the fields required by the third-party application [b]. Such situations should generally be resolved by the vendor of the third-party application involved, but in some cases such a solution cannot be achieved (eg, one of the two third-party applications for some reason). Not updated at this time). The protocol converter 340 can convert the relevant message from [a] to [b] (eg, by providing the required additional fields). Such conversion can be performed by protocol transducer 340 or may involve interaction with the website in which the application is embedded and the containing web page 203 (eg, if additional information is required). ..

Further, it should be understood that the third party application 40 may have the ability to send a message to or receive a message from such a third party application 40. (For example, the online shop / procurement third party application 40 pair described above). However, in some cases, some of the solutions may not exist, and in the above example, there may not be a corresponding or well-procured third-party application 40. In such cases, by using the redirector 350, the designer 5 may route a particular message to a component of containing web page 203, or route a particular message from a component of containing web page 203. Comparable features can be specified to be resolved by the components of contained web page 203 and the features that the components can provide. This allows you to build a complete website without having to build a dedicated third party application 40. Therefore, a transaction can be sent to a component of the website building system 30 that can log the transaction to a database, and this database can be used later (by another program) to perform offline procurement and shipping. can do.

The third-party application 40 can provide a plurality of configurations with different capabilities that use the same code base but enable different functions. For example, the third-party application 40 may provide basic functionality through a free version and may provide additional functionality through a premium version to purchase, multiple paid versions, or additional functionality to purchase from the third-party application 40. ..

It should be understood that the system 100 can include features based on the website building system 30 that manage the purchase status of the third party application 40 per user (actually per designer). Furthermore, all designers can be registered users of the website construction system 30, and therefore the website construction system 30 can manage a database of purchase status of the third party application 40 of each designer 5. I want to be understood. This information can be stored in the property sheet 23 by the TPA coordinator 24 at the design stage and by the configuration manager 370 at the time of execution. For example, the third party application 40 can send a version inquiry message to the client side element of the website construction system 30. The client-side element of the website building system 30 queries the repository 22 or a copy of the locally cached repository to send a response message to the third-party application 40 that contains information about the capabilities that the third-party application 40 should provide. return.

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

As mentioned above, the third party application 40 can communicate directly with a particular component of contained web page 203. The third-party application 40 can identify the component with which it communicates in various ways, i.e., directly identify the component based on the associated template (as described in more detail later), or the designer. Following the (possibly selective) component model identified through the access ID explicitly specified for a particular component of contained web page 203 by 5, or provided to a third party application 40 by contained web page 203. Identify by.

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

In addition, the updater 380 makes it easy for the components of the website building system 30 to specify the types of access allowed to the third party application 40, in this case access to protect files in modern operating systems. By a method similar to how permission bits and access control lists (ACLs) work. Such permissions can be defined for each component to apply to all third-party applications 40, third-party applications 40 from specific vendors, or specific third-party applications 40. For example, the third-party application 40 may be able to access text fields outside the third-party application 40 within the contained web page 203. For the blog's third-party application 40, this text field can be used to edit the blog entry, providing a larger screen area than can be provided inside the blog's third-party application 40 itself. Provided. For a third-party application 40 embedded in a particular mini-page inside a multi-page container, the website building system 30 limits access from the third-party application 40 to only the components within that particular mini-page. Please understand that you can.

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

In addition, the updater 380 allows the website building system 30 to change / modify the style and display of the third party application 40. The updater 380 can carry out the calls used by the website building system 30 to provide formatting and style guidelines to the third party application 40. Guidelines can include properties such as color and color scheme, font, font size, transparency, animation and special effects (eg blur). Examples of the color scheme include a general color scheme (for example, using the following x color) and a high-level color scheme (for example, using the color x for the text and using the color y for the frame).

One preferred way to represent complex style information is to use a cascading style sheet (CSS), which represents a combination of multiple style directives such as font, size, and color. Please understand that you can. The updater 380 can send such CSS-based messages to the third party application 40. The stylesheet can be generic in nature or contain a unique style name as defined by the third party application 40, so the website building system 30 provides the third party application 40 with more relevant guidelines. (For example, the style sheet can refer to the elements of a particular third party application 40 to provide these guidelines).

This allows the third party application 40 to use these guidelines to create its own look and feel that is well suited to the contained web page 203. This is of particular importance for the third party application 40 (multiport inclusion described above) that is contained in or is visible to the plurality of contained web pages 203 within the same site. Multiple containing web pages can adopt different color schemes and basic designs. The third-party application 40 uses the information provided through these style messages to adapt its display color and style to fit each of the contained pages well, with a color scheme that does not match the contained web page. Can be avoided from being displayed or causing an appearance / operation feeling.

When the dynamic layout updater 360 processes the display change as a result of the dynamic layout event, the website building system 30 and the third-party application 40, or the third-party application 40 and the auxiliary third-party application, may use the dynamic layout updater 360. Please understand that it makes it possible to cooperate. The website building system 30 can change the size and position of the components in the page for the purpose of maintaining the page design when an event occurs that changes some of the components in the page. These dynamic layout events include, for example, browsing a website on screens of different sizes, rotating the display between portrait mode and landscape mode, resizing and repositioning some components. , Modifying the content of a particular component (resulting in a requirement to resize the component). In addition, dynamic layout events include server-based content updates (for example, in a component that displays information from a data feed), or content changes by another concurrent user on the same website. Updates can be mentioned. Furthermore, it should be understood that dynamic layout events can occur not only in the design environment but also in the run-time environment. In particular, some components and third-party applications 40 can change the content and size / position of the component at run time (ie, by the end user) as well as by the designer.

Further, it should be understood that dynamic layout events can also be triggered by the third party application 40. For example, a third-party application 40 for an online shop may require a resizing when a user moves from a product catalog display to a shopping cart display (which has a different size). As another example, the third-party application 40 in the product catalog may include an option for highlighting the product, and due to this option, the third-party application 40 may include a larger catalog containing more content. Display the page. A further example is a multi-region third party application 40 that can start or stop displaying additional regions.

Here, refer to FIG. 6 above. In existing systems, such situations are generally dealt with, in general, by cutting the display of a third-party application prematurely and adding scrollbars to the display, or other pages on the page as shown in Figure 6. Handle it by simply resizing the display as a pop-up window that hides the component. The dynamic layout updater 360 can implement a cooperative dynamic layout, in which case the website building system 30 and the third party application 40 work together to perform the dynamic layout and contain web pages 203. Maintain the basic design of. The function of the dynamic layout is further described in Patent Document 1 (Filing date: February 20, 2013, assigned to a common assignee of the present invention). However, even in systems that support cooperative dynamic layout, the dynamic layout mechanism in contained web page 203 does not completely control the internal layout of the third party application 40. Furthermore, the widgets of the website building system 30 may be designed to be resized to any size (within a certain range), but the third party application 40 may not support any resizing. The third-party application 40 may include, for example, multiple display settings with different sizes (eg, displaying more or less detail), the ability to resize some of the internal elements of the third-party application 40, third-party. It may provide any combination of the ability to display some of the text elements of application 40 using multiple font sizes.

In addition, the third party application 40 may have a limited number of possible display sizes and may have an entire range of possible sizes. Therefore, a resizing request from the contained web page 203 to the third party application 40 either by switching to the closest possible size for the third party application 40 or provides a list of possible sizes for the third party application 40 (thus the web). The site construction system 30 can be solved by selecting an appropriate size to be used).

The dynamic layout updater 360 can implement a collaborative dynamic layout [from contained 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 contained web page 203 to a particular desired size (eg, X1 * Y1 pixels). The dynamic layout updater 360 can send a message to the third party application 40 requesting that the third party application 40 resize its content to a particular desired size (eg, X1 * Y1 pixels). The third-party application 40 can be adjusted to a specified size by using alternative display settings, internal resizing processing, internal dynamic layout processing, or any other means. Further, it should be appreciated that the contained web page 203 can resize the external iframe window containing the third party application 40 to a new size (X1 * Y1).

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

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

In particular, it should be appreciated that if there are a plurality of third party applications 40 (or multi-domain third party applications 40) within the contained web page 203, another embodiment may be applicable. In this embodiment, the contained web page 203 allows the embedded third party application 40 to attempt to optimize the appearance / operation feeling in consideration of the plurality of options of the plurality of third party applications 40. You can contact the embedded third-party application 40 to get a list of display sizes. This embodiment also relates to the case where the third party application 40 is displayed over a plurality of areas.

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

Loop from 1 to n for i.

For each TPA [i], the following is obtained.

Minimum size Xmin [i] * Ymin [i],
Maximum size Xmax [i] * Ymax [i],
Optimal size Xopt [i] * Yopt [i],
The dynamic layout updater 360 can send a message enumerating the above minimum / maximum / optimum sizes to TPA [i] to request information about possible sizes of the third party application 40.

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

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

The results are stored in Xfinal [i] / Yfinal [i] for all TPA.

Loop from 1 to n for i.

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

The containing web page 203 resizes the external iframe window containing the 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 understood that dynamic layout processing may generally require the third party application 40 to be moved rather than simply resized. However, the third-party application 40 should be invariant to the exact position of its frame inside the contained web page 203.

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

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

Hub 205 may provide additional messages specific to the class of third-party application 40, or additional messages specific to third-party application 40, such as the website building system 30 itself, specific contained web pages 203, or ancillary third parties. It should be appreciated that the party application 40 can also implement additional messages, which can affect the third party application 40. For example, a blog third-party application 40 may define a new blog entry, or an input message that can post a new response to the current blog entry. Such messages can be used by the contained web page 203 (eg, as a way to post a blog entry from a large editing field outside the area of a third party application). In addition, such messages can also be used to link between higher level applications, allowing, for example, a supporting third-party application to post a blog entry to a blog's third-party application.

Third-party applications 40 often require a wide range of complex services for designers using the third-party application 40 within their site to use internally or downstream of the third-party application 40. I want you to understand. Examples of such services include user management and billing / shipping management. The vendor of the website building system 30 may not be able to provide such services as part of the website building system (eg, for technical or business reasons). Moreover, these services may not be suitable for "packaging" alone as a third-party application 40. In addition, the vendor of the third party application 40 provides a plurality of such services (eg, multiple third party billing APIs) to the designer using the third party application 40, and the designer 5 selects the appropriate service. You may need an option to make it available.

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

Therefore, the designer 5 who uses the website construction system 30 can develop a unique service (such as an online shop that sells music) that uses advanced billing. Designer 5 identifies the billing API provider by using the hosted billing API directly or through a third-party application 40 that provides an additional level of abstraction (or layer of abstraction). It is possible to avoid the need to negotiate a clearing agreement or a merchant agreement. In this sense, the website building system 30 can be an agent of a hosted API vendor.

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

In a complementary alternative embodiment of the invention, Applicants integrate an additional template and component of a website building system with a third-party application at the AppStore 25 level and an instance of the associated third-party application. It was further realized that by using the model, smart integration between the website building system 30 and one or more third party applications 40 could be achieved. Third-party applications 40 can also communicate with these components (and unrelated components) to exchange data and control messages. As mentioned above, the third-party application area 40 within the contained web page 203 is a separate domain whose content is hosted in a separate domain (the domain of the third-party application vendor or otherwise) that is different from the domain in which the main site is hosted. It is an iframe of. Therefore, the browser's "same origin policy" is applied to communication between a plurality of different iframes, and it is required to use the above-mentioned method.

In the existing system, the third-party application 40 is implemented as an integrated inflexible object that is included in the contained web page 203 but does not otherwise affect the appearance / operation feeling of the contained web page 203 itself. .. Instances of the third-party application 40 are located in an area (generally rectangular) and perform all of their actions and functions within this area.

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

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

When creating an instance of a third-party application 40 within contained web page 203, the components in the associated template can be merged with contained web page 203 along with other components within contained web page 203. Please understand that it can be displayed.

Next, with reference to FIG. 13, this figure shows an example of using the associated template according to an embodiment of the present invention. As illustrated, the third party application [a] is located in the App Store [b], along with the associated template [c] containing the components [d] and [e]. When the third-party application [a] is included in the contained web page 203 [f], the third-party application [a] can be displayed in the specified area [g] inside the page [f]. It should be appreciated that instances [d'] and [e'] of components [d] and [e] can be displayed on page [f] along with pre-existing components [h] and [i].

It should be appreciated that system 100 can support multiple methods of placing instances of associated template components (eg, [d'] and [e'] above) within web page 203 [f]. .. Placement methods include absolute placement (ie, using the size and position of the original components [d] and [e] specified in the associated template [c]), and target-based placement (ie). That is, the size and location of the new instances [d'] and [e'] are adjusted according to the contained web page 203 [f]), the placement relative to the third party application 40 (ie, the contained web page 203 [f]). Adjust the size and position of the new instances [d'] and [e'] relative 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.

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

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

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

In an alternative embodiment, the pre-created associated template can be applied to a newly created page or mini-page that is "parallel" to the containing web page 203. You can initialize this newly created page or mini-page with a template and modify it as needed.

In addition, the website building system 30 also enables multiport inclusion, in which case the same instance of the third party application 40 is visible from multiple pages of the main site and "belongs" to these pages. Multiport inclusion is different from multiple inclusions of a particular third party application 40 within the main site (creating multiple instances of the third party application 40). Therefore, the content of the third party application 40 (which is unique to the instance) is shared among multiple views of the same multiport third party application 40.

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

As mentioned above, the system 100 can provide a bidirectional communication link between the third party application 40 and the component in the contained web page 203. It should be understood that such components include components of contained web page 203 as a result of merging associated templates from third-party applications, and components not related to such associated templates.

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

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

In addition, it may be necessary to modify or remove the elements of the website building system 30 that underlie such individually distributed associated templates (which in some cases "break" the associated templates. "). To solve this problem, the system 100 can implement these associated templates in a separate area inside the application repository 22 (possibly per vendor of the third party application 40). The website construction system 30 can manage these templates in the same manner as other templates of the website construction system 30.

Further, the vendor of the third-party application 40 can be provided with a unique ID (development ID) of each template created, and the vendor of the third-party application 40 can use this ID during the development and testing process of the third-party application 40. Please understand that you can use. At the time the third-party application 40 is published / distributed, the vendor of the third-party application 40 may be required to apply and receive an alternative unique ID (public ID), and the vendor is published. The ID can be referred to in the third-party application 40. Once the public ID is provided, a separate locked copy of the template is created. This copy is referenced by the third party application 40 and is the copy used when creating an instance of the third party application 40. By doing so, the vendor of the third-party application 40 will not be able to accidentally modify the template associated with the "raw" third-party application 40 (included by the designer) and referential integrity will be maintained. Will be done. Furthermore, the system 100 can cross-reference the relationship between such a locked template and the underlying components and base template. By using this cross-reference, for example, the components and base templates of Website Builder 30 contained in such a locked template will be modified (and such modifications will attempt to modify the template or third party. If the party application 40 can be broken in any way), the staff of the website construction system 30 can be warned.

Therefore, the system 100 can provide a bidirectional communication channel between the third party application 40, the components in the contained web page 203, and the website building system 30. The components of contained web page 203 may be based on a template (s) associated with a third-party application, or based on another template of Website Builder System 30, or be independent of the template. Can be done.

As mentioned above, the communication hub 205 can facilitate communication and provide a back channel between the contained web page and the third party application 40. Applicants further realized that the data sent bidirectionally between the contained web page and the third party application 40 would be useful once they were collected, processed and integrated.

For example, a website owner needs to manage the number of users and membership per site, which is different from the value based on the registered users of the related website construction system 30. Website users may or may not register (anonymously), and websites may provide different levels of functionality to different levels of users. In addition, users (even anonymous users) are individuals when launching instant messenger software to contact site owners or when connecting to social networks as part of their activity on the site. Often provide information and contact information (eg, data in contact forms). It should be understood that this information will be entered directly into the created site or will be available as part of the interaction with third party applications embedded within the site.

Furthermore, it should be understood that this information is not organized, unrelated to each other, may contain inconsistencies, and is often not preserved. For example, one user enters his private email address into a contact form (managed directly by the site) and, in the same session, a work email address (third-party application). You may fill out another subscription form (managed by 40).

Moreover, this "fluid" information may include different permissions for the use of that information. For example, a user who enters his or her email address in a subscription form expects to receive an email-based subscription that he or she has subscribed to and, in some cases, an associated email newsletter. On the other hand, a user who discloses an e-mail address as a registration ID may not want to receive e-mail addressed to his / her registered address except for e-mails related to the handling of his / her account and security warnings. be.

Next, with reference to FIG. 15, this figure is a system 200 that coordinates and collects data from various messages exchanged between the website building system 30 and one or more embedded third party applications 40. Is shown. The system 200 includes a client hub 210 installed on the client 220, a server hub 230 installed on the server 260, a contact coordinator 240, an activity coordinator 250, a contact database 245, and an activity stream database 255. The hub 210 and hub 230 are the communication between the website building system 30 and the plurality of third party applications installed on the server 270 and a plurality of different third party applications, as described above in relation to the hub 205. It should be understood that communication between 40 can be facilitated. The contact database 245 and the activity stream database 255 can hold contact information and activity information and information extracted from the message stream, as will be described in more detail later.

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

Next, with reference to FIGS. 16C and 16D, FIG. 16C shows the elements of the stream merger 252, and FIG. 16D shows the elements of the data merger 243. The stream merger 252 includes an activity-stream merger 261 and a stream-stream merger 262. The Stream-Stream Marger 262 further comprises a horizontal Stream Marger 263 and a vertical Stream Marger 264. The data merger 243 includes a contact classifier 272, a coupler 273, a contradiction resolver 274, a list value generator 275, a vertical contact merger 276, and a horizontal contact merger 277. The horizontal contact merger 277 further comprises a virtual horizontal merger 278. The vertical contact merger 276 further comprises a virtual vertical merger 279. The function of these elements will be described in more detail later.

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

Further, the system 200 can extract information related to the user and merge them (combining information from a plurality of sources and information already existing in the system 200). Marging can be done through merging rules that coordinate different types of information that are in some cases inconsistent with each other. The combined information can be stored in the contact database 245. This information may further include license fields that control the allowed use of the collected information, as described in more detail later.

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

Further, the system 200, as a further component, allows the third-party application 40 to manage activities to contact the user (eg, mass transmission of newsletters) while enforcing usage restrictions set by the user himself / herself. It should be understood that the components that enable it can be provided. Such components may also isolate the user's private data from the third-party application 40 (thus the third-party application 40 may perform its actions without actually accessing the user's private data. can). Such a function can be performed, for example, by using the private data proxy 234, which will be described in more detail later.

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

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

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

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

In addition, the activity data structure can include a callback link, such as "further information" (returning to the activity data structure). Callback links can be used to provide additional important information, for example, in the case of electronic commerce activity data structures, such as complete order tracking or order history, in chat. In the case of an activity data structure, it is a complete chat log, and in the case of a phone activity data structure, it is a call log. Therefore, the complete activity data structure as an example is unique to the following fields: creation time, activity type, activity origin (third-party application 40 / component ID), activity stream ID, activity type: Information (depending on the type of activity), created site ID, site member database ID, 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 to be made and detailed information of the acquired user can be included.

The activity coordinator 250 can be thought of as a logging element and receives data from the message passed from the hub 230. The stream maker 251 can create an initial stream (which can be thought of as a log or chain structure), and the stream merger 252 can add subsequent incoming activities to this initial stream. At this time, each stream is unique to the contact. It should be understood that the stream maker 251 does not have to create a new stream for each individual activity contained in different messages. Furthermore, it should be understood that the activities contained in the stream may not be in the correct order (eg, some third party application 40 may be delayed in reporting the activity). The Stream Marger 252 can merge multiple streams when they belong to the same contact at operation, and the Log Creator 253 will use the Log Creator 253 for all previously created activity streams. Log files can be stored in the activity stream database 255.

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

For example, an anonymous user fills out a contact form on the site. The stream maker 251 creates a new activity stream (with the ID "anon1") and the contact handler 242 creates a new contact (with the ID "anon1" as described in more detail later). This same user then chats with the site owner. Stream Marger 252 merges this activity into the "anon1" activity stream and updates the contact "anon1" (as described in more detail later). The user then uses another browser to fill out a schedule form. Since there is no interrelationship with the first user, the stream maker 251 creates a new activity stream with the ID "anon2" and the contact handler 242 creates a new contact with the ID "anon2".

Next, this user shop from this site. Stream Marger 252 merges this new activity into the "anon2" activity stream and updates the contact "anon2" (eg, using the "customer" tag).

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

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

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

Next, with reference to FIG. 17, it should be understood that the site owner can access the history of the activity stream of a particular contact through the relevant user interface provided by the website building system 30, as shown in FIG. You can easily access the usage history of the website for one contact "Dani Bronstein". Further, it should be understood that the website building system 30 or the third party application 40 can also provide APIs for accessing log information. It should be understood that activity logs can be used for purposes such as optimization, improving the user interface, and targeting ads.

Furthermore, in parallel with this, it should be understood that the contact coordinator 240 can collect information from the data provided by the activity stream (message) to build a contact profile for the target user. The data extractor 241 can extract data from the activity message and activity stream, the data merger 243 can merge the relevant data into a particular contact, and detailed information about this contact can be found in the contact database 245. It can be stored and accessed from the contact database 245. The contact handler 242 can create new contacts and can process site user identification information (such as anonymous users), and the data / authorization handler 244 can protect and authorize the privacy of related data. Can be processed. As described above, the data merger 243 includes a horizontal contact merger 277 and a vertical contact merger 276. The horizontal contact merger 277 can merge two contacts that are not related to each other due to the detection of a common primary ID, and the vertical contact merger 276 is associated with an anonymous contact and a registered user. The anonymous contact can be merged into the contact associated with the registered user when the contact is associated at login or registration. The Horizontal Contact Marger 277 can further include a Virtual Horizontal Marger 278, which maintains the two contacts as separate contacts, but the two contacts represent the same contact. Link these to each other as indicated (merge or not merge the actual contact information). The Vertical Contact Marger 276 may further include a Virtual Vertical Marger 279, which maintains the anonymous contact and the contact associated with the registered user as separate contacts. Link them together (merge or do not merge the actual contact information) so that it is shown that the two contacts represent the same contact. In addition, the data merger 243 can merge the contact information (generally extracted from the data extractor 241) into the existing contact. It should be understood that the contact classifier 272 can use cookies to track the user's identification information and recognize the contacts to be merged, as will be described in more detail later.

See again FIG. 15, FIG. 16A, and FIG. 16B, message passing can be performed on the client 220 and / or server 260. It should be understood that the third party application 40 generally has a client side element and a server side element, or at least has a server side connection with the server 270 of the provider of the third party application 40. The hub 210 can process the message between the client 220 and the third party application 40, and the hub 230 can process the message between the server 260 and the third party application 40. It should be appreciated that the data received by the hub 210 can be processed and then transferred to the hub 230 for further processing described below.

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

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

TPA1 and TPA2 can exchange messages on the client (between component D'and component E'), on the server (between component D and component E), or both on the client and server. Please understand. However, communication with ETPA3 must only be done on the server. Furthermore, it should be understood that there are advantages and disadvantages to using either method. Sending activity messages on the client side can be more interactive and the user response is faster. Sending activity messages on the server side can be more robust and reliable (for example, the user cannot close the browser window in the middle of the process) so that the messages are received in the correct order. In addition, you can send activity messages to the 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 on the client side.

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

As another example, a user "presses a like button" for something in a third-party application A (eg via Facebook). The third-party application A then sends an activity message regarding the activity type "Facebook Likes" to the website building system 30. The website building system 30 transfers this activity to all third party applications 40 registered in the "push like button" activity. Since the third-party application B is registered, it receives this activity. Third-party application B presents the re-engagement widget to the user, "If you like this site, why not contact the site owner?" Or "Would you like a discount coupon?" ] And other messages can be displayed.

As mentioned above, all communication can be done via hub 210 and hub 230.

Router 211 can route client-side messages between the website and any third-party application 40. Further, the router 211 can route messages between hub 210 and hub 230 for further processing, as will be described in more detail later.

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

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

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

It should be understood that it is the user (website visitor) who visits the website, registers with the website, and provides information to the website. You are actually aware that the website you are visiting is built using a combination of the website building system 30, components, created websites, and third party applications 40. It may not be. Therefore, the responsibility for the privacy of the user ultimately rests with the owner of the website (and the owner is also responsible for the activities performed by the third party application 40 contained in his website).

Furthermore, the third party application 40 (and other components of the website building system 30) is subject to the user profile through the API provided by the website building system 30 based on the privacy rules defined by the website building system 30. Please understand that you can access the information. Further, the containing site and the third party application 40 contained therein can use the contact information to communicate with the user (via e-mail or other means).

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

When the vendor of the website construction system 30 adds the provider of the third-party application 40 to the application market of the website construction system 30, the vendor of the website construction system 30 signs the terms of use (ToU) agreement with the provider of the third-party application 40. You can request that you do. Such agreements may state that the Third Party Application 40 (and the provider of the Third Party Application 40) must not misuse or disclose your information to any third party. can. This allows the vendor of the website building system 30 to impose penalties on the provider of the third-party application 40 if the provider misuses the information (eg, disables the third-party application 40). Remove the third party application 40 from the application market of the website construction system 30). The privacy policy Enforcer 213,233 and the private data proxy 234 can implement a privacy policy for the third party application 40, which will be described in more detail later.

The second privacy-related issue is the interrelationship between the website and the website building system 30 and the user (site visitor). The website must provide you with a clear understanding of how your personal data will be used, receive your consent, and comply with the terms you have agreed to. The website construction system 30 requires all published sites to present to the user a Terms of Service document that defines the permitted uses of personal information belonging to the user, in which case the user You will be required to digitally sign the document. The site must comply with these terms and permitted uses. Further, the website construction system 30 can include a sample terms of use page in each of the website templates provided by the website construction system 30. The Privacy Policy Enforcer 213,233 can ensure that the terms of use of the Terms of Service document are adhered to. In addition, the Privacy Policy Enforcer 213,233 may delete or reorganize relevant data so that only authorized information is provided to third party applications.

The third privacy issue is to support unsubscribe requests. The site must provide users with the option to unsubscribe from any marketing emails. This can be handled by the data / permission handler 244, which will be described in more detail later.

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

In the website building system 30 (and the websites built therein), the private data proxy 234 keeps all or part of the private data in a secure repository managed by the website building system 30. The private data proxy 234 can provide an alternative unique ID (instead of private data) to the third party application, which the third party application can use to hide private. You can get the data. For example, the email address is replaced with an alternative "email address ID" and provided to the third party application 40, so that the third party application 40 cannot access the actual email address.

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

Therefore, the private data proxy 234 enforces restrictions on user permission fields, enforces user unsubscribe requests, and suppresses sending messages to users (eg, certain operating on a particular site). Allows up to 100 emails per day for the third party application 40). The private data proxy 234 can define proxy parameters and private data to be disclosed to third-party applications and private data not to be disclosed (for each third-party application 40), and these settings can be made on a field-by-field basis.

The private data proxy 234 provides the third party application 40 hosted on the server of the website construction system 30 with an alternative unique ID that resembles the original private data (eg, the user's original). It can provide an alternative dummy email address instead of a private email address), "capture" calls that use that information, and forward the email to the correct address (in this example). This feature can also be used to detect third party applications 40 that have exceeded their granted privileges.

It should be understood that the website owner may wish to limit or modify the information provided to a particular third party application 40. Reasons for this include, for example, general security concerns, specific privacy commitments regarding any element of user data, and regulatory requirements specific to a particular industry or application. The Privacy Policy Enforcer 213,233 may make such changes made by the website owner and override the current settings.

As an example, websites dealing with medical information will not be able to access some of the detailed personal information of the contact information when passing the contact information to the third party application 40 that analyzes the general geographical distribution of users. I may want to. As another example, a third party application 40 may have problems dealing with certain types of contact information. Website owners who want to use the third-party application 40 as-is (although bugs are known) want to exclude known problem-causing contacts or modify the data so that the problem does not occur. There is.

The transducers / transducers 212,232 can apply pre-specified rules for translating messages and adapting content. For each of these rules, the third-party application 40 to which the rule applies, the filtering criteria for selecting the message to which the rule applies, and the conversion rule (eg, discarding a specific message (related to a particular third-party application 40)). ), Can include conditions such as transformations that apply to one or more specific fields in the activity data structure.

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

In addition, the relevant website building system 30 is intended to enhance the system against failures and intrusion attempts (such as man-in-the-middle attacks aimed at tampering with the payload data of the message of the third party application 40). Can support verification and signing. Therefore, each of the third party applications 40 registered in the website construction system 30 can have two sets of private / public keys, and one set is sent from the third party application 40 to the website construction system 30. It is used for the purpose of decrypting the message (input key), and one set is used for the purpose of encoding the message sent from the website construction system 30 to the third party application 40 (output key).

For example, the third party application A sends a message to the website construction system 30. This message is sent using the third party application ID at the site (the external ID of the third party application (having the third party application scope)) and the message is signed by the third party application. The website construction system 30 receives this message. The verifier / signaturer 235 verifies the signature using the input key of the third party application A. If this validation is not passed, the verifier / signer 235 reports the input message as invalid and no further messages are sent.

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

For example, the verifier / signer 235 can recognize the external ID of the third-party application B for each of the third-party applications B1 to Bn. The verifier / signer 235 then composes a message to the third-party application B and commands the transducers / transducers 212,232 to apply the applicable filtering and conversion rules described above. The verifier / signer 235 then signs the message using the output key of the third party application B and sends the message to the third party application B via the router / tracker 231 (or router 211). The third-party application B receives the message and verifies the signature. If the validation does not pass, the message is reported invalid and will not be processed further. It should be understood that the verifier / signer 235 performs only server-side processing without performing client-side processing so that confidential verification data is not sent to untrusted clients.

As mentioned above, the system 200 can employ multiple types of communication between the website building system 30 and the third party application 40. Such communications include, for example, control communications (eg, the website building system 30 orders the third party application 40 to shut down) and functional communications (eg, the third party application 40 in the shopping cart). Sends the total purchase amount to the billing third-party application 40 through the website building system 30 (thus modifying the payment or activity communication in the examples described in this application), these different types of communication. It should be understood that has different profiles and requirements (eg, regarding the amount of messages sent, priority, robustness, response time).

In particular, the system 200 may have very frequent activity reports (eg, when events in the graphical user interface (GUI) of the third party application 40 are reported as activities of the third party application 40). Such a large amount of activity reporting can put pressure on parts of the system that handle more important messages. Thus, the system 200 may implement multiple communication channels (eg, using different ports or multiple simultaneous sessions) such that messages of each class are sent over separate channels. By doing so, the side channel is used for activity reporting, which is performed in parallel with instruction communication and functional communication, and does not interfere with the latter communication.

As mentioned above, the system 200 collects activity information for the purpose of creating and improving contact information through the contact coordinator 240 and activity coordinator 250 and for matching activity events associated with a particular contact. Can be done. The contact coordinator 240 and the activity coordinator 250 can process information for each activity message routed through hub 210 and hub 230. The stream creator 251 can create a contact-specific data stream from the activity message, and the plurality of elements of the contact coordinator 240 extract and process the data and then store it in the contact database 245. Can be done.

Therefore, for each activity stream, you can build the contacts associated with it, and gradually quality the built contacts with the data extracted from the activities running under each data stream. Can be enhanced. It should be appreciated that the contact coordinator 240 can also recognize 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-valued fields (eg, one person can have multiple email addresses that identify that person), whereas some primary ID fields are strictly Please understand that it is a single value field (eg social security number).

Therefore, Data Marger 243 can merge the fields of contacts extracted from the new activity into the currently constructed contacts to the anonymous user while the anonymous user is using the website. A contact built against it can be merged into a contact that has already been defined and saved when the anonymous user performs a login action to become the identified user (this is a "vertical merge"). May be called). Further, when the horizontal contact merger 277 detects that two different contacts (constructed contacts or stored contacts) are related contacts representing the same user, these two contacts. You can perform a "horizontal" merge of. As mentioned above, such a merge actually merges (ie, transforms two individual contacts into one contact), or merges one contact into another, or through a virtual merge. Perform (ie, keep the two contacts as separate contacts, but link them together so that they represent the same user, and then merge the actual contact information and activity stream, or It can be done by (do not merge). Furthermore, it should be understood that even in the case of virtual merging, additional additional information can be added to multiple contacts that are virtually merged and linked.

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

It should be understood that the contact classifier 272 can implement multiple methods for identifying site users. For example, tracking sessions by one anonymous user (not logged in to the site) using cookies, using site login for registered users, sites where accounts are associated with social networks. By using social login for users, matching primary ID fields (email address, phone number, etc.) to identify that two user profiles describe the same user.

Furthermore, site users whose detailed information is stored in the contact database 245 are anonymous users who are not registered on the site, registered users, and potential users (who are still officially registered on the site). It should be understood that it can be categorized as (has records imported from external sources, but not).

Related websites can install persistent cookies that persist across session changes, so information from multiple anonymous sessions running on the same computer using the same browser to the same contact record. Can continue to be acquired. Therefore, even anonymous users can have a considerable amount of contextual and contact information.

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

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

Registered users generally have to log in to the system to establish their identity, but the system can offer the option to "keep connected to this system". Such login procedures may be explicit (the user calls the login dialog) or implicit (eg, requesting the user to provide some identification information when adding a post to the blog). ), Or can be based on an external login (the system calls a login procedure associated with another system, such as a login to a social network or an OpenID login). In addition, through physical devices (eg security tokens connected directly to the system or via a wireless interface) or through the use of biometric information (user biometric parameters (eg fingerprints, iris scans) and user behavior detection). The login procedure can also be modified through both (including typing pattern detection, etc.) or through any combination of the methods detailed above.

In addition, it should be understood that information can be exchanged bidirectionally between social login procedures and normal login. For example, a social ID is associated with a site member ID, and thus social login is implicitly logging in to the site, or a site member ID can be associated with one or more social network IDs, thus. When you log in to the site, you are identified on one or more social networks.

When a user performs an explicit logout, the 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 is that new. Saved under anonymous contacts. Upon further login, this new anonymous contact can be merged with the contact identified at that login.

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

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

If user anon2 performs a second login as user Y (as in scenario A), the data merger 243 will combine user anon2's contact information (updated by act6 and act7) with further activity. To merge into the contact details of the identified user Y.

If user anon2 performs a second login as user X (as in scenario B), the data merger 243 will combine user anon2's contact information (updated by act6 and act7) with further activity. To, merge into the contact details of user X (which has already been updated to reflect act1 to act5).

It should be understood that the activity data structure associated with the activity can also contain contact details. The data extractor 241 can extract this information and transfer it to the data merger 243, which integrates this information with the existing contact information in the contact database 245 and of the existing contact information. The quality can be improved. Furthermore, the data extractor 241 can extract detailed information from a specific activity message, an entire stream, another contact, or an external source (such as an IP to geographic address conversion service, which will be described in more detail later). Please understand. As mentioned above, the contact in the contact database 245 signs the contact details or website (via social login / registration function) explicitly provided by the user as part of the registration or sign-up process. It can also include contact details extracted from the social networking account you use when uploading, or contact details you provide when you update your user profile. In addition, the data extractor 241 can also obtain contact information from an external source (eg, when a user specifies only a US zip code, the site will use this information to zip code decode). Get complete address information from external web services).

As mentioned above, the contact classifier 272 can recognize the two contacts as related to each other based on the primary ID field (user name, email address, telephone number, etc.). If contact A (new) and contact B (existing) are found to be related to each other, the 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 (eg, "B || A"): Take B, and if B is null or empty, take A.

B1 = Mathematical Function (A, B): Important cases of private data are:

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

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

For lists of regular values (ie, scalars), use regular value comparisons.

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

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

If structure A is a more detailed version of structure B, then A is attached to B (more on this later).

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

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

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

It should be understood that the data extractor 241 can infer the address of the contact from the IP address from which the activity originated. This feature is only used if the activity originated in a browser session and the user's address has not been obtained. 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". Such markings are required because the address field already contains an address based on IP mapping (which may be inaccurate), which conflicts with later address merging. This is to ensure that the detailed (but basically different) address from is not prevented from being stored in the contact database 245.

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

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

In addition, the data merger 243 can use language parsing, parsing, or other text parsing methods and references / uses of 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, with the same street address, city, and zip code. The combiner 273 can apply text parsing (eg, the soundex algorithm) when comparing two entries, and also two versions of the street name, a street by an external source for a given city and zip code. Can be compared with the name. In such cases, the combiner 273 will use the standard if both addresses resemble standard street names (but not the same in some cases) and all other address data fields have the correct values. Street name can be selected.

In addition, the data merger 243 can merge contact information according to login / session information. You may use the site to initiate a session without logging in or registering, perform some activities as part of that session, and then register or log in later, so that session is , Associated with a newly created user profile or an existing profile (including contact information) of a registered user.

When a user initiates a session (as anonymous), contact identifier 272 can track the user (using cookies, session ID, etc.) during that session, and contact handler 242 can use the anonymous session. Based on the activities performed by the user during it, it is possible to create a built contact for that particular anonymous user. In addition, Router / Tracker 231 can continue to track its anonymous user over multiple sessions from the same computer. This tracking can be done by using persistent cookies (rather than session cookies).

Once the user has registered, the data merger 243 can use the information of the constructed contacts to make the first input to the user profile. When the user logs in, the data merger 243 can first combine the information of the constructed contact with the existing user profile. The information of the constructed contact is merged according to the user's site ID, because the data merger 243 has a primary ID (such as an email address) used for merging other than the site ID of the constructed contact. Please understand that this is because it is not retained in the information. In addition, it should be understood that such merges can lead to inconsistencies in the information gathered. Inevitable inconsistencies can occur when merging anonymously constructed contacts into existing profile data. For example, an anonymous user fills out a data form (displayed by some third party application 40) with the name John Smith and then (using the same or another browser session) with the name Jane Doe. To log in to your account with. In this case, the later login (for example) is a login actually made by another person using the same computer, or the first user uses a pseudonym in the contact form to protect their privacy. It may have been done. The same is true when Data Marger 243 merges multiple anonymously constructed contacts.

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

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

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

The information entered is a contact record (contact C entered) with one or more primary ID fields with one or more values (eg, having two email addresses and three phone numbers). Contact record). The user may have (for example) a home / company / mobile phone number and a home / work email address, and the user should replace one of these in the contact form. Because of this, multiple primary ID fields may be required.

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

If the entered contact is a registered site member (of a particular site), the data merger 243 removes contact C from list L and merges all remaining contacts in list L into contact C. Can be done. The data merger 243 can then store the updated contact C back in the contact database 245 and delete all the remaining contacts in the list L from the contact database 245. Alternatively, the data merger 243 can perform a virtual merge as described above, i.e. combine all contact information (ie, all contact records to include all available information). (Update), mark matching contact records as belonging to the same person (instead of deleting "duplicate" contact records). Such processing is required, for example, because the internal ID unique to the contact record is stored or used by the third-party application 40, and therefore, if the contact record is deleted, these third-party applications 40 do not operate properly. This is the case. The same process (ie, marking contacts as related to each other rather than deleting them) can be applied in other cases, which will be described in more detail later.

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

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

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

Data inconsistencies can occur as described above for merging at login. However, this problem occurs in most cases because the list value maker 275 can create a list value field (with multiple values) and can also define a clear priority between contacts. do not.

For example, Data Marger 243 merges the following contacts.

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

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

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

It should be understood that the contact database 245 may contain contact information from multiple sources with different levels of permission for use. Although the following description takes email as an example, the following description and method will use any of the above-mentioned types of information (phone number, fax number, Skype ID, instant messaging ID, etc.) used to contact the user. It also applies to social network IDs, etc.).

For example, the route through which an email address was provided to a site may have different permissions for the use of that email address. Some possible acquisition routes for email addresses are registration IDs, contact forms, newsletter sign-ups, and unsubscribe requests. In addition, email addresses may differ in terms of "agreement for permitted use" that is digitally signed by the user.

In general, it should be understood that the website building system 30 has information about the permitted uses of a given email. However, the website owner may have different, personalized, or additional information. For example, contacts from different sources that are due to the nature of different sign-up forms within the site or that contain additional license information may be imported into the system by the website.

The data / authorization handler 244 may implement the correct usage policy for third party applications 40 used within the site for the purpose of assisting the website owner in managing this information.

Therefore, the contact record of a related contact can contain two information fields. The first field is the website permission field, which contains the permission calculated or derived by the website from the user's activity or the proposed permission. Contact forms only implicitly specify functional emails, whereas subscription forms implicitly specify repetitive emails. The second field is a site owner permission field based on the value of the website permission field. The site owner can change the recommended permissions of the website and set them as he wishes, but is responsible for any use beyond the permissions defined by the website permit field.

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

The data / permission handler 244 can use these permission fields to define permissions in multiple ways. For example, the data / authorization handler 244 can implement any or a combination 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 the purpose of sending an email.

Email ID: The email address provided for the purpose of registration. It cannot be used for the purpose of sending e-mail except for registration-related content (confirmation of registration, notification of suspected security breach if you forget your password, etc.).

Functional Email: Provided for a specific feature and allows one-time email. For example, a purchase confirmation email or an email provided for a particular contact form.

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

Shareable Email: Allows websites and their partners (third-party applications 40, 4th ^parties ) to send multiple subscriptions and advertisements. In this case, explicit subscription / approval is required and can include detailed information about the permitted shares.

Opt-out: The user has explicitly unsubscribed. You will not be able to send email to that user (except in some cases, opt-out notifications).

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

As a typical usage scenario, the contact database 245 includes a first set of email addresses collected from a contact form and a second set of email addresses from a subscription request. The website may call the newsletter-delivered third-party application 40, at which time the third-party application 40 will be "only" to the users (users who sent the subscription request) belonging to the second set of users. I am aware of sending an email.

The advantage of such a system is that it is against both the website and the website owner (both technical and legal) regarding the accidental sending of spam emails to users and the unauthorized use of personal information. (In) good protection and the ability to actually enforce the privacy policy when the system is used in combination with the private data proxy 234 as described above. In addition, the unsubscribe request can be made more rigorous.

Therefore, it is possible for the user to generate a stream of activity between the associated website building system 30 and any associated third party application 40. These streams may be referred to as activity streams. Each activity stream can be used as a source of information about a single contact. In addition, if it is determined that the sources of different activity streams are the same, the activity data structures of the individual streams can be merged to form a contact. For example, one user may perform activities anonymously through two devices (such as a mobile device and a personal computer). Two anonymous streams are generated by such a user, 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 indications described herein are not inherently relevant to any particular computer or other device. Various general-purpose systems can be used in combination with the programs according to the teachings herein, or it may be convenient to construct dedicated equipment for performing the desired method. The desired structure of the various these systems will be apparent from the above description. Moreover, embodiments of the present invention are not described in the context of a particular programming language. It should be understood that various programming languages can be used for the purposes of carrying out the teachings of the present invention described herein.

Unless otherwise stated, as is clear from the description so far, throughout this specification, the description using terms such as "process", "calculate", and "seek" are used in computers and computing. An ing system, or similar electronic computing device (data expressed as a physical quantity, such as a computing system register or electronic quantity in memory, a computing system memory, register, or other such information storage device, It should be understood that it means the operation or processing of a transmitter (a device that manipulates or converts to another data that is also represented as a physical quantity in a display device).

Embodiments of the present invention can include devices that perform the operations and operations described herein. The device may be built specifically for a desired purpose, or the device may be equipped with a general purpose computer, which is selectively started or reconfigured by a computer program stored in the computer. can. Such computer programs include computer-readable storage media, such as, but not limited to, any type of disk (floppy (registered trademark) disk, optical disk, optical magnetic disk, etc.), read-only memory (ROM), compact disk. Read-only memory (CD-ROM), random access memory (RAM), electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic or optical card, flash memory, or electronic It can be stored on any other type of medium, which is suitable for storing instructions and can be coupled to a computer system bus.

Although the particular features of the invention have been illustrated and described so far, numerous modifications, replacements, modifications, and equivalents will be apparent to those of ordinary skill in the art. Therefore, it should be understood that the appended claims are intended to include all such modifications and modifications contained in the substantive concepts of the invention.

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

Claims (1)

It ’s a website building system.
With at least one processor
Identification extracted from an activity message that runs on said at least one processor and has an activity data structure that is transmitted between the website building system and associated third party applications and includes data associated with identifiable contacts. A unit that creates and processes an activity stream, which is a chain of said data associated with a possible contact.
The unit is equipped with
A stream merger that merges data from at least one activity message into an existing activity stream and merges two activity streams into a single activity stream.
With at least one database that stores the activity stream for use by the website building system.
Website building system.

Images