CN105940391B - 用于第三方应用活动数据收集的系统和方法 - Google Patents

Abstract

一种系统包括：至少一个中心，用于在网站和至少一个第三方应用之间协调至少一个活动消息，其中所述至少一个活动消息具有标准化格式；以及活动协调器，用于收听所述至少一个活动消息，并至少将从所述至少一个消息中提取的数据添加到与识别出的联系人和匿名联系人中的至少一个相关联的流上，并且其中所述识别出的联系人和匿名联系人中的至少一个是所述网站的用户。所述系统还包括联系人协调器，用于从所述流取回并分析联系人相关信息，并充实所述联系人在先前保存的信息；以及至少一个数据库，用于存储所述活动流以及所述联系人相关信息，以供所述网站和所述联系人使用。

Description

用于第三方应用活动数据收集的系统和方法

技术领域

本发明涉及在线应用，并且特别地涉及它们与包含的第三方应用的使用。

相关申请的交叉引用

本申请要求2013年12月4日递交的美国临时专利申请No.61/911,485的权益，其全文通过引用合并于此。

背景技术

存在许多市场上可买到的网站建设系统和其它交互应用建设工具，其能够用于创建和编辑网站和其它在线应用。终端用户可以利用在多种不同平台上的客户端软件访问这种网站，例如，常规的个人计算机、智能电话、平板计算机和其它台式或移动设备。

这些网站建设系统可以具有不同配置，例如，完全在线网站建设系统，其以连接到互联网的一个或多个服务器为主机，并利用诸如超文本传输协议(HTTP)的互联网通信协议对其进行访问。创建、编辑和部署这些网站建设系统均通过服务器直接在线进行。

网站建设系统还可以部分在线或者甚至有时完全离线。对于部分在线系统，在用户机器上局部地执行网站创建，并稍后上载到一个或多个中央服务器以供部署。一旦被上载，这些网站建设系统将以与完全在线网站建设系统相同的方式运行。

网站建设系统具有内部数据架构，以便在系统内组织数据和元素。该架构可以不同于用户所看到的正在讨论的站点的外部视图，并还可以不同于将典型的超文本标记语言(HTML)页面发送给浏览器的方式。例如，内部数据架构可以包含页面上每个元素的额外属性(创建者、创建时间、访问许可、到模板的链接等)，其对于编辑和维持网站建设系统内的站点是必要的，但是对于终端用户(或者甚至对一些编辑用户)从外部看不到。基于网站建设系统的典型架构的站点可以包括包含部件(例如，形状部件、图形部件、文本部件、包含迷你页面的单页面和多页面容器，等)的页面。

部件可以是无内容的，例如星形，其不具有任何内部内容(但是它具有颜色、尺寸、位置和一些其它属性)；或者可以具有内部内容，例如文本段部件，其内部内容包括所显示的文本以及字体、格式和布局信息。该内容自然可以从文本段部件的一个实例到另一实例而变化。

使用这种网站建设系统的设计者可以从头(从空白屏幕开始)设计新的创建，或者可以依靠设计者自身或系统创建者或通过设计者团队创建的预先定义的应用模板。网站建设系统可以支持模板，所述模板可以仅是部件集合、完整页面(或迷你页面)或甚至是页面集合和完整的网站。

当提供应用模板时，设计者能够随意进行定制—添加、移除或修改模板的所有元素，以创建他或她的模板版本。可以通过创建模板的修改版本(其与模板不同且分离)来实现这种定制。可替代地，网站建设系统可以通过继承类机制应用定制，所述继承类机制保持到原始模板的连接，并因此反映对模板做的后续改变。

还可以利用第三方应用和嵌入到其中的部件扩展网站建设系统。这种第三方应用可以包含于网站建设系统设计环境中，或者可以通过多个分布机构单独购买(或以其它方式获取)，例如从集成到网站建设系统的应用商店(AppStore)，或者从网站建设系统(WBS)提供商或另一实体运营的单独的、基于网络或独立的应用仓库(或AppStore)。还可以直接从第三方应用供应商(通过或不通过AppStore)获得第三方应用—这将提供实际安装模块，或者进激活或访问码。

第三方应用可以包括前端(显示)元件与后台业务元件(其不是视觉网站显示的一部分)的任意组合。第三方应用可以完全是后台业务的(即，不包括显示元件)、完全是前端(即，仅在网站使用背景下被激活)或者是两者的组合。

第三方应用的后台业务元件可以包括例如数据库通信、外部更新选项等的功能。例如，博客第三方应用可以包括后台业务元件，其允许从非人类来源(例如，从主要新闻服务馈送的RSS新闻)接收更新，以及从与网站不相关的人类资源(例如，允许提交博客条目的独立智能电话应用)接收更新。

可以通过多种方式将第三方应用的视觉元件集成到包含网站。微件型第三方应用可以作为部件嵌入到网站页面中，而区段型第三方应用可以作为一个或多个额外页面而被添加到网站上。

此外，第三方应用(微件和区段)可以是单页面第三方应用或多页面第三方应用(其具有表示为内部URL结构的内部迷你页面)。系统可以实现四种可能组合(微件或区段，单页面或多页面)的任一种或全部。

多页面第三方应用通常提供默认的“着陆”迷你页面，其可以是开始页面、特定的内部迷你页面(例如，在博客第三方应用中最近的博客条目)。迷你页面选择屏幕或一些其它迷你页面。

通过第三方应用实例实现在基于网站建设系统的网站中使用第三方应用。网站建设系统可以支持在多个级别多次使用第三方应用，例如允许在整个网站中的单个第三方应用实例；允许在网站中创建多个第三方应用的实例(但是不多于任意给定第三方应用的一个实例)；以及允许创建多个第三方应用的多个实例，但是每个给定页面不多于一个实例。还可以允许每个页面部件第三方应用有多个实例，但是不是区段第三方应用，并且还允许创建多个第三方应用的多个实例，而无需限制第三方应用实例的数量、多样性或位置。

第三方应用实例可以具有实例特有内容。例如，电子商店第三方应用可以具有与特定实例相关联的产品数据库，其与和同一电子商店第三方应用(在相同站点或其它站点)的其它实例相关联的产品数据库不同。

出于讨论的目的，包含第三方应用的网站页面(或迷你页面)及其迷你页面或元件(即，“包装页面”)已知为包含网页，并且对于整个网站为主站点。向用户示出的集成的页面(包括主页面和嵌入式TPA迷你页面/部件)将被称作组合页面。对于区段型第三方应用，包含第三方应用的“虚拟页面”将用作包含网页。

第三方应用通常部署于网站建设系统供应商服务器上、在第三方应用供应商服务器上、在外部(第四方)服务器上、或其任意组合。第三方应用还可以包括实际在终端用户机器上运行的元件，例如，静态安装的浏览器扩展或在网站建设系统客户端侧代码内运行的动态运行JavaScript部件，如现在参考的图1所示。

网站建设系统供应商的服务器用作终端用户的接触点，并响应于请求(可能连接到第三方应用供应商的服务器以接收所要求的信息)。例如，当需要视频流送时，网站建设系统可以(按照需要)创建客户端计算机和第三方应用供应商的服务器之间的直接连接。

所包含的第三方应实例可以具有自己的内部内容，类似于常规部件包括内部内容的方式。第三方应用可以独立于网站建设系统并独立于利用如现在参考的图2所示的网站建设系统生成的网站而管理该内容。(单个或多个第三方应用的)多个第三方应用实例可以具有共享内容，例如，在两个单独的网站页面中的两个电子商店实例可以涉及同一产品数据库。

可以以多种方式将来自包含的第三方应用的输出集成到包含网页中，例如：

服务器侧处理：在现在参考的图3所示的该替代中，第三方应用[a](包括设计和显示元件)和用户专用第三方应用[b]由在第三方应用供应商的服务器[d]上运行的第三方应用服务器代码[c]合并。通过通信介质[e]将它们发送到网站建设系统服务器代码[f]，该代码将它们与包含网页信息[g]合并，并发送它们以供在用户客户站点[h]处显示。

客户端侧处理：在现在参考的图4所示的该替代中，第三方应用[a](包括设计和显示元件)和用户专用第三方应用[b]由在第三方应用供应商的服务器[d]上运行的第三方应用服务器代码[c]合并。通过通信介质[e]将它们发送到客户端侧处理部件[h]。网站建设系统服务器代码[f]将包含网页信息[g]发送给该客户端侧处理部件[h]。客户端侧处理部件[h]执行信息的两个来源的合并，并向浏览器(或其它客户端代理)[i]呈现统一应用。

iFrame包含：在现在参考的图5所示的该替代中，第三方应用[a](包括设计和显示元件)和用户专用第三方应用[b]由在第三方应用供应商的服务器[d]上运行的第三方应用服务器代码[c]合并。通过通信介质[e]将它们发送到在用户代理(例如，网络浏览器)[i]内运行的基于浏览器的应用[h]。网站建设系统服务器代码[f]将包含网页信息[g]发送给该基于浏览器的应用[h]。包含网页用作包含一个或多个iframe指令的网页，其包括来自第三方应用服务器[d]的内容。也可以应用额外的和替代的方法。

发明内容

根据本发明优选实施例提供了一种在网站上经由客户端/服务器系统实现的系统，所述客户端/服务器系统具有用于处理定义所述系统的指令的至少一个处理器。所述系统包括：至少一个中心，用于在网站和至少一个第三方应用之间协调至少一个活动消息，其中所述至少一个活动消息具有标准化格式。所述系统还包括活动协调器，用于收听所述至少一个活动消息，并至少将从所述至少一个消息中提取的数据添加到与识别出的联系人和匿名联系人中的至少一个相关联的流上，并且其中所述识别出的联系人和匿名联系人中的至少一个是所述网站的用户。所述系统还包括联系人协调器，用于从所述流取回并分析联系人相关信息，并充实所述联系人在先前保存的信息；以及至少一个数据库，用于存储所述活动流以及所述联系人相关信息，以供所述网站和所述联系人使用。

此外，根据本发明的优选实施例，所述至少一个中心包括以下中的至少一个：路由器和跟踪器，用于在所述网站和所述至少一个第三方应用之间路由和跟踪所述至少一个活动消息；私人策略强制器，用于在所述网站和所述至少一个第三方应用之间强制实施隐私策略；转换器和适配器，用于在所述网站和所述至少一个第三方应用之间应用预先指定的至少一个消息转换和内容适配规则；私人数据代理，用于实现私人数据代理和私人数据替代中的至少一个，并用于在所述网站和所述至少一个第三方应用之间强制实施用户许可字段限制；以及验证器和签名器，用于利用所述至少一个第三方应用的输入键验证所述至少一个活动消息的签名，以将与所述至少一个活动消息相关联的外部ID与内部所述网站ID进行转换，并用于利用所述至少一个第三方应用的输出键对输出的所述至少一个活动消息进行签名。

此外，根据本发明的优选实施例，所述活动协调器包括以下中的至少一个：流创建器，用于识别与所述至少一个活动消息相关联的所述联系人，并用于在没有相关联的联系人存在时创建所述数据流；流合并器，用于将来自所述至少一个活动消息的数据合并到现有流，并将来自至少两个所述活动流的数据合并到单个流中；以及日志创建器，用于将来自所述活动流的活动数据记录到所述至少一个数据库中。

此外，根据本发明的优选实施例，所述联系人协调器包括以下中的至少一个：数据提取器，用于从所述至少一个活动消息、所述流、其它联系人和外部源中的至少一个提取联系人相关信息；数据合并器，用于合并至少两个联系人信息记录，其中所述记录与同一识别出的联系人相关联，并且用于根据预先定义的合并规则将所述提取出的联系人相关信息合并到现有联系人的联系人相关信息中；联系人处理器，用于创建可识别的新联系人和匿名联系人中的至少一个，并用于在所述网站的会话期间跟踪联系人活动；以及数据和许可处理器，用于处理所提取出的联系人相关信息的隐私保护和许可。

另外，根据本发明的优选实施例，所述路由器和跟踪器支持利用所述至少一个第三方应用指定收听查询来路由所述至少一个活动消息。

此外，根据本发明的优选实施例，所述流合并器包括活动到流合并器，以将所述数据合并到与所述识别出的联系人相关联的所述流，以及流到流合并器，以将至少两个单独的流合并到单个流。

此外，根据本发明的优选实施例，所述流到流合并器包括水平流合并器和垂直流合并器中的至少一个，所述水平流合并器用于根据识别出的共同联系人合并所述至少两个单独的流，所述垂直流合并器用于在连接匿名联系人和注册的联系人用户的登录或注册时合并针对匿名联系人创建的流和与注册的联系人用户相关联的流。

此外，根据本发明的优选实施例，所述数据合并器包括以下中的至少一个：联系人识别器，用于以下至少一项：在至少两个所述联系人信息记录中定位相同的主要ID字段值，在至少两个所述联系人信息记录中定位当被规范化时相同的主要键字段值，利用网络跟踪器识别站点用户，利用针对注册用户的站点登录来识别站点用户，以及通过针对站点用户利用与社交网络相关联的账户的社交登录识别站点用户。所述数据合并器还包括联合器，用于利用语言、语法、文本分析和向外部数据源和服务的咨询中的至少一个来联合联系人信息；矛盾解决器，用于根据预先定义的规则解决联系人记录之间的矛盾；列表值创建器，用于创建列表值字段，以定义在所述联系人记录之间的净优先；水平联系人合并器，用于由于检测到的共同主要ID合并两个不相关的联系人；以及垂直联系人合并器，用于在连接匿名联系人和注册用户的登录或注册时合并匿名联系人和与注册用户相关联的联系人。

另外，根据本发明的优选实施例，所述水平联系人合并器包括虚拟合并器，用于将至少两个联系人记录维持为分离的，并将其链接到一起，从而将其标记为表示同一联系人。

此外，根据本发明的优选实施例，所述垂直联系人合并器包括虚拟合并器，用于将匿名联系人和与注册用户相关联的联系人维持为分离的，并将其链接到一起，从而将其标记为表示同一联系人。

此外，根据本发明的优选实施例，所述用户许可字段是所述网站确定的和所述网站拥有者确定的中的至少一个。

此外，根据本发明的优选实施例，所述标准化格式是以下中的的至少一种：由预先定义的方案、继承、回叫链路定义的、由所述至少一个第三方应用进行编码和定义的、或基于外部正式的工业或事实标准。

根据本发明的优选实施例，提供了一种在网站上经由客户端/服务器系统实现的方法，所述客户端/服务器系统具有用于处理定义所述方法的指令的至少一个处理器。所述方法包括：在所述网站和至少一个第三方应用之间协调至少一个活动消息，其中所述至少一个活动消息具有标准化格式；收听所述至少一个活动消息，并至少将从所述至少一个消息中提取的数据添加到与识别出的联系人和匿名联系人中的至少一个相关联的流上，并且其中所述联系人和匿名联系人中的至少一个是所述网站的用户。所述方法还包括从所述流取回并分析联系人相关信息，并充实所述联系人在先前保存的信息；以及存储所述活动流以及所述联系人相关信息，以供所述网站和所述联系人使用。

此外，根据本发明的优选实施例，所述协调包括以下中的至少一个：在所述网站和所述至少一个第三方应用之间路由和跟踪所述至少一个活动消息；在所述网站和所述至少一个第三方应用之间强制实施隐私策略；在所述网站和所述至少一个第三方应用之间应用预先指定的至少一个消息转换和内容适配规则；实现私人数据代理和私人数据替代中的至少一个，并在所述网站和所述至少一个第三方应用之间强制实施用户许可字段限制；以及利用所述至少一个第三方应用的输入键验证所述至少一个活动消息的签名，将与所述至少一个活动消息相关联的外部ID与内部所述网站ID进行转换，并利用所述至少一个第三方应用的输出键对输出的所述至少一个活动消息进行签名。

此外，根据本发明的优选实施例，所述收听和所述至少添加包括以下中的至少一个：识别与所述至少一个活动消息相关联的所述联系人，并在没有相关联的联系人存在时创建所述数据流；将来自所述至少一个活动消息的数据合并到现有流，并将来自至少两个所述活动流的数据合并到单个流中；以及将来自所述活动流的活动数据记录到所述至少一个数据库中。

此外，根据本发明的优选实施例，其中所述取回和分析包括以下中的至少一个：从所述至少一个活动消息、所述流、其它联系人和外部源中的至少一个提取联系人相关信息；合并至少两个联系人信息记录，其中所述记录与同一识别出的联系人相关联，并且根据预先定义的合并规则将所述提取出的联系人相关信息合并到现有联系人的联系人相关信息中。所述取回和分析还包括创建可识别的新联系人和匿名联系人中的至少一个，并在所述网站的会话期间跟踪联系人活动；以及处理所提取出的联系人相关信息的隐私保护和许可。

此外，根据本发明的优选实施例，所述路由和跟踪支持利用所述至少一个第三方应用指定收听查询来路由所述至少一个活动消息。

另外，根据本发明的优选实施例，所述合并包括将所述数据合并到与所述识别出的联系人相关联的所述流，以及将至少两个单独的流合并到单个流。

此外，根据本发明的优选实施例，将所述数据合并到与所述识别出的联系人相关联的所述流和将至少两个单独的流合并到单个流包括水平合并和垂直合并中的至少一个，所述水平合并根据识别出的共同联系人合并所述至少两个单独的流，所述垂直合并在连接匿名联系人和注册的联系人用户的登录或注册时合并针对匿名联系人创建的流和与注册的联系人用户相关联的流。

此外，根据本发明的优选实施例，所述合并至少两个联系人信息记录包括以下中的至少一个：在至少两个所述联系人信息记录中定位相同的主要ID字段值，在至少两个所述联系人信息记录中定位当被规范化时相同的主要键字段值，利用网络跟踪器识别站点用户，利用针对注册用户的站点登录来识别站点用户，以及通过针对站点用户利用与社交网络相关联的账户的社交登录识别站点用户。所述合并至少两个联系人信息记录还包括：利用语言、语法、文本分析和向外部数据源和服务的咨询中的至少一个来联合联系人信息；根据预先定义的规则解决联系人记录之间的矛盾；创建列表值字段，以定义在所述联系人记录之间的净优先；由于检测到的共同主要ID水平合并两个不相关的联系人；以及在连接匿名联系人和注册用户的登录或注册时垂直合并匿名联系人和与注册用户相关联的联系人。

此外，根据本发明的优选实施例，所述水平合并包括虚拟合并以将至少两个联系人记录维持为分离的，并将其链接到一起，从而将其标记为表示同一联系人。

此外，根据本发明的优选实施例，所述垂直合并包括虚拟合并以将匿名联系人和与注册用户相关联的联系人维持为分离的，并将其链接到一起，从而将其标记为表示同一联系人。

另外，根据本发明的优选实施例，所述用户许可字段是所述网站确定的和所述网站拥有者确定的中的至少一个。

此外，根据本发明的优选实施例，所述标准化格式是以下中的至少一种：由预先定义的方案、继承、回叫链路定义的、由所述至少一个第三方应用进行编码和定义、或基于外部正式的工业或事实标准。

附图说明

在说明书的结论部分特地指出并明显要求保护关于本发明的主题。然而，通过当结合附图阅读时参考下面的具体实施方式可以理解关于操作的组织和方法以及其目标、特征和优点，在附图中：

图1是在网站建设系统和第三方应用之间部署配置的示意图；

图2是第三方应用内部内容管理的示意图；

图3是通过服务器侧处理包含于包含网页中的第三方应用的示意图；

图4是通过客户端侧处理包含于包含网页中的第三方应用的示意图；

图5是通过iframe包含而包含于包含网页中的第三方应用的示意图；

图6是在页面布局变化期间的现有和非最优第三方应用显示的示意图；

图7A和7B是根据本发明构造和操作的用于集成网站建设系统和一个或多个第三方应用的系统的示意图；

图8是与部件模型相比的文档对象模型的示意图；

图9是样本多方博客第三方应用的示意图；

图10是样本模块化销售第三方应用的示意图；

图11A和11B是根据本发明构造和操作的通信中心的不同实现方式的示意图；

图11C是根据本发明构造和操作的图11A和11B的通信中心的元件的示意图；

图12是根据本发明构造和操作的由图11A和11B的通信中心所执行的通信翻译场景的示意图；

图13是根据本发明构造和操作的处理具有相关联模板的第三方应用的包含网页的示意图；以及

图14是根据本发明构造和操作的包括在迷你页面内具有相关联模板的第三方应用的包含网页的示意图；

图15是根据本发明构造和操作的用于协调和收集来自在王振建设系统和一个或多个嵌入式第三方应用之间交换的不同消息的数据的系统的示意图；

图16A、16B、16C和16D是根据本发明构造和操作的图15的系统的元件的示意图；

图17是根据本发明构造和操作的显示与联系人相关联的活动流的样本图形用户界面的示意图；

图18是客户端侧和服务器侧第三方应用活动消息传递的示意图；以及

图19是在用户网站会话期间登录/注销处理的示意图。

将会意识到的是，为了图示的简洁和清晰，在图中示出的元件不必按比例绘制。例如，为了清晰起见，可以将一些元件的尺寸相对其它元件进行扩大。此外，当认为合适时，可以在图中重复附图标记以表示对应或类似的元件。

具体实施方式

在下面的具体实施方式中，阐述了多个具体细节以便提供对本发明的透彻理解。然而，本领域技术人员可以理解的是，可以在不具有这些特定细节的情况下实践本发明。在其它实例中，没有详细描述已知的方法、过程和部件，以免模糊本发明。

申请人已经认识到当前方法在以下方式中存在多种限制：第三方应用通常集成到网站建设系统，以及集成的第三方应用和网站建设系统相互作用的方式。

这些限制包括第三方应用显示器受限于包含网页内的单个矩形区域，所述区域包含于iframe内。它们还包括第三方应用控制其自己的窗口大小和位置的能力，以及在实际第三方应用显示窗口(例如，在第三方应用窗口周围的专门显示框架)外部的视觉元件。

第三方应用可以具有其自己的显示风格(颜色方案、字体、字符大小等)。这些风格对于一些包含网页可能是好的，但是对于其它包含网页可能是视觉有问题的或不和谐的。

另一限制是从包含站点角度的第三方应用显示的刚性。如果站点必须被视觉修改(例如，由于部署到具有不同屏幕尺寸的平台或由于动态布局事件)，则可能要求包含网页改变分配给第三方应用的窗口的尺寸。在这种情况下，将修剪第三方应用显示，并要求经由滚动条滚动到第三方应用中的不同子区域。现在参考图6，其示出了当对包含网页[a]调整大小时所发生的情景的例子，分配给电子商店第三方应用[b]的区域被减小，并且不能同时看到“购买”按钮[c]和购物车[d]的内容—需要多个滚动动作来完成购买，并更不可能地使得购买实际完成。

可以理解的是，第三方应用不能与包含网页内的其它部件交互，并且有时需要这种交互来实现复杂的功能。特别地，对于第三方应用而言不能根据在包含网页中的部件的类型和内容进行不同的执行。这种的例子是流送在线烹饪过程的网站。用户希望在背景中观看他的电影，他的屏幕的一较小区域专用于馈送新闻并且在他的屏幕的另一区域更新天气(例如，来自CNN的现场流)。他可能想要在他居住区域的天气预报开始时自动暂停他所学习的会话。

对于多个第三方应用也没有任何清楚的、标准的方式来彼此合作，尤其是当它们是由不同供应商提供的时。因此，设计者没有清楚的方式来组合来自不同供应商的多个第三方应用。这种的例子可以是电子商务网站，其运行来自第三方订购系统的模块以及运送系统的不同模块。期望的是，根据运送调度等订购供应物。

申请人已经认识到，可以通过使用在网站建设系统和包含于其中的第三方应用实例之间的以及在实现于同一包含页面中的不同第三方应用实例之间的有结构的双向通信信道，来实现该集成。这些信道还可以传送关于布局、风格的信息以及额外信息。

可以理解的是，下面的讨论集中于iframe包含方法，这是一种内置且集成于现代浏览器的优选方法，其不要求创建特殊的集成代码。Iframe包含还提供浏览器支持封装和沙盒，以及固有的保护免受黑客技术，例如可以由恶意第三方应用采用的跨站点脚本攻击。

现在参考图7A和7B，其示出了根据本发明的用于集成网站建设系统和一个或多个第三方应用的系统100。图7A示出了在设计阶段的系统100，而图7B示出了运行时的系统100。如图7A所示，系统100包括客户端10、安装在网站建设系统(WBS)服务器20上的网站建设系统30，以及安装在一个或多个第三方应用服务器50上的一个或多个第三方应用40。网站建设系统30包括WBS协调器21、应用库22、WBS侧TPA属性表单23、第三方应用(TPA)协调器24和AppStore 25(其可以包括搜索器26)。客户端10包括页面编排器12以及TPA属性表单23的客户端侧视图。在一些实施例中，客户端10还可以包括AppStore 25的客户端侧视图。页面编排器12包括链接器13，其将在下文更详细地描述。第三方服务器50包括第三方应用40、外部TPA协调器51和TPA数据库52，所述TPA数据库52存储第三方应用40部件、模板等以供使用。注意，系统100可以包括术语多个第三方应用40供应商的多个第三方服务器50。

可以理解的是，当针对给定的第三方应用40实例指定属性时，可以调用TPA属性表单23。还可以理解的是，当被调用时，TPA属性表单23可以在客户端10上表现为TPA属性表单23的客户端侧视图。还可以理解的是离线实施例可以具有其属性表单作为安装的客户端软件的一部分，因此将不具有其TPA属性表单23或其库。

可以理解的是，坐在客户端10处的设计者或终端用户5可以利用页面编排器12创建网站页面和交互(中间页面以及内部页面)，从而创建他的网站(或任意其它在线应用)。设计者5可以经由WBS协调器21选择存储于应用库22中的网站建设系统30的一部分的部件、模板等。设计者5还可以创建包含网页203，其嵌入来自第三方应用40的第三方应用40实例，所述第三方应用40是已经预先购买的并且它的模板、部件等可以存储在应用库22上。在替代实施例中，所购买的模板、部件等可以存储于TPA数据库52上，并经由外部TPA协调器51进行访问。在另一实施例中，可以根据需要经由AppStore 25购买第三方应用40模板、部件等。属性表单23可以由设计者5指定，并保存关于已经购买的第三方应用40实例的信息，例如，许可、安装指令、支付等，如下文更详细描述的。设计者5还可以使用链接器13来手动指定在包含的第三方应用40之间的任意通信信道(如果需要的话)。还可以理解的是，链接器13还允许设计者5指定在正在建设的包含网页和正被包含的第三方应用40实例(例如，如上文所述同时示出的电影和CNN新闻报道)之间的任意的特定通信连接和规则。可以理解的是，可以通过网站试用期修改由链接器13创建的链接。

可以理解的是，设计者5可以通过AppStore 25外部的信道获取第三方应用40，例如第三方应用40供应商或外部方操作的外部AppStore。在这种情况下，当第三方应用40第一次安装到由设计者5通过网站建设系统30创建的网站上时，网站建设系统30可以注册第三方应用40及其配置数据。

可以理解的是，为了链接器13提供建立可能通信信道的能力，第三方应用40需要能够正确地识别和辨识在包含网页203内的(将可能与其通信的)部件—包括其它第三方应用40实例。对于基于相关联的模板的部件(在下文中更详细描述)，通过第三方应用40供应商提前执行所述识别。在相关联模板中的部件可以是给定的特定参考ID，并且这些ID可以在与其通信时由第三方应用40使用。

还可以理解的是，对于多方第三方应用40(将在下文更详细描述)，即分别在多个iframe上的单个第三方应用40，多方可以自动知道彼此如何进行通信。

对于不包括于相关联模板中的包含网站页面部件(如将在下文更详细描述的)，第三方应用40可以包括所需要的(强制的或可选的)包含网页203部件(其应该存在从而可以运作)的列表。所述列表可以存储于库表单23中，并包括唯一的ID、描述和部件细节(例如，必须是文本部件，将被用作博客对话标签)。该列表可以在进入AppStore 25的第三方应用40中详细说明，并且设计者5可以使用链接器13来指定在复合第三方应用40要求的包含网页203中的部件(字段)。可以理解的是，当创建第三方应用40实例时，网站建设系统30可以动态地创建丢失的包含网页203部件，并可以允许设计者5移动、调整大小并随后完全指定它们。

可替代地，网站建设系统30可以将包含网页203的全部或部分部件暴露给包括于包含网页203中的第三方应用40。可以理解的是，这可以是部件模型，而不是包含网页203的文档对象模型(DOM)。包含网页203DOM可以比部件模型更复杂和详细，这是因为实际的包含网页203可以包含(隐藏的和可见的)多种HTML元件，其是网站建设系统30基础结构的一部分，或者其支持包含网页203部件。部件模型因此可以更简单。

现在参考图8，其示出了利用多个HTML构造(例如，封闭div标签[b]、内部div标签[c]、框架“迷你微件”[d1]..[d5]等)如何实现文本部件[a]。用于包含网页203的DOM模型[e]可以包含用于这些子元件中的每个的单独DOM树节点。部件[f]更简单，其仅包含单个部件节点[g]。

可以理解的是，系统100还可以支持选择性部件暴露——设计者5可以经由链接器13指定应该将哪些部件暴露给第三方应用40，并且只有这些部件(可能包括通向它们的“包含路径”)可以包括于对第三方应用40可见的简化部件模型中。可以通过明确地标记所包括的部件，根据它们的类型或任意其它网站建设系统30属性，执行指定。然后，第三方应用40可以遍历包含网页203部件模型，并定位所需要的部件。

还将意识到的是，在包含网页203和第三方应用40实例之间的链路还可以自动创建，例如，广播链接，在其中第三方应用40可以在运行时期间发送通信以记录特定事件。该通信可以是可选的或强制的(即，第三方应用40可以不起作用或安装，除非存在已经链接以接收这种消息的匹配第三方应用40)。例如，第三方应用40可以广播关于其执行的活动的消息分组，并且任意安装的记录第三方应用40可以接收这些信息分组。

现在通过设置完成的新创建的网页可以(经由WBS协调器21)存储于应用库22中，以在运行时被调用，如下文更详细描述的。

现在返回参考图7B。在该实施例中，元件与图7A的相同，除了客户端10的元件。在运行时期间，客户端10包括观察器201以显示包含网页203。可以理解的是，观察器201可以包括多个观察端口202，其每一个显示第三方应用40的不同实例(根据一个或多个第三方应用40导出的实例)。客户端10还包括通信中心205，以促进通信并提供在包含网页203和任意第三方应用40之间的反向通道，其与在所托管的第三方应用40之间要求的任意通信一起托管，而无需任何到相关包含网页203的连接。将在下文中更详细地描述中心205的功能。

将会意识到的是，中心205可以在客户端10上实现，因为包含网页203以及任意第三方应用40包含都是可见网站的交互部分，并且它们的通信应该被客户端-服务器双程所延迟。在替代实施例中，在第三方应用服务器40需要交换大量数据并且优选最好不将通过客户端10进行路由的情况下，中心205可以实现于网站建设系统服务器20上。

可以理解的是，通信中心205可以支持在网站建设系统30和一个或多个第三方应用40之间以及在多个第三方应用40之间的不同组合的通信。例如，中心205可以使得第三方应用40请求网站建设系统30切换到主站点的另一页面。通信中心205还可以使得第三方应用40请求重新调整其可能影响包含页面部件的窗口的大小。这可以通过动态布局处理进行，将在下文中更详细的描述。可替代地，如果需要在显示中容纳变化，则包含网页203可以请求(例如)第三方应用40切换到不同版本。可以理解的是，这种2路通信还可以在第三方应用40部件和与第三方应用40相关的网站建设系统30部件之间开始，其显示额外信息以及在多方第三方应用40的元件和模块化第三方应用之间的通信，如上文所描述的。

还可以理解的是，还可以利用在线和离线网站建设系统30实现系统100，并且其还可以使用托管方法的任意组合，例如，客户端侧元件、网站建设系统30供应商服务器、第三方应用40供应商服务器和其它第四方服务器。可以理解的是，对于如上所述的离线实施例，仍可以要求服务器实现系统100。

系统100还可以托管在不同的服务器集上(不由网站建设系统供应商操作)，例如，针对较大组织的私人站点托管布置。

系统100还可以支持来自第三方应用40的第三方应用40实例包含选项，如上所述。然而，系统100还可以支持这些选项的子集，或可以对第三方应用40实例包含概率放置约束。

系统100还可以实现多方第三方应用40。多方第三方应用40可以包括多个显示区域，利用单独的iframe处理每个显示区域。这些区域还可以(根据需要)通过通信中心205合作，如下文更详细描述的。

现在参考图9，其示出了多方第三方应用40的例子。如图所示，从AppStore[b]获取的博客第三方应用[a]放置在包含网页203[c]中。博客第三方应用[a]包括如下三个区域：博客条目区域[d]，标签云区域[e]，新闻更新区域[f]。可以理解的是，多方第三方应用可以以多种方式使用其多个区域，包括如在上述博客例子中或如在单个应用的多个可选驻留部分一样多的单个应用的并发驻留部分，多个区域总是可见，并且多个区域是可选的且仅在需要时显示。可以通过第三方应用40或通过设计者5(当包括第三方应用时决定如何配置该第三方应用)控制可选区域的显示。还可以控制该显示作为支持功能区域，例如配置或额外对话区域；或者作为针对多版本第三方应用的替代显示(例如，具有第三方应用的较小和较大版本，或具有第三方应用的肖像和风景版本)。

可以理解的是，可以利用针对第三方应用40元件显示的iframe实现上述功能，因此增加基于iframe架构的封装和安全性优点。

还可以理解的是，多方第三方应用40的实现方式要求第三方应用40(在其iframe内部)控制各个iframe的显示(例如，其可见性、尺寸和位置)。还可以理解的是，通信中心205可以支持该显示，如下文更详细描述的。

还可以理解的是，即使当多方第三方应用40(视觉)包括多个元件和区域，但在购买(例如，在AppStore 25中)、安装、配置等方面仍将其视为单个第三方应用40。

在现有系统中，每个第三方应用40可以被视为单独的实体，并且在(来自同一供应商或其它合作供应商的)两个第三方应用40之间的任意合作在逐一基础上专门开发。可以理解的是，系统100还支持模块化第三方应用40，其包括能够单独购买和安装的多个合作子模块。

现在参考图10，其示出了模块化销售管理第三方应用[a]如何包括下列子模块：CRM模块[b]，线索管理模块[c]以及电子商务模块[d]。单个第三方应用供应商可以提供所有要求的第三方应用模块。可替代地，第三方应用供应商可以提供第三方应用40模块(及功能)的子集，并允许设计者从同一或额外的第三方应用供应商处购买/安装补充第三方应用模块。可以理解的是，多方第三方应用被作为来自单个供应商的单个第三方应用获取和安装，这只发生用于占据多个屏幕区域，模块化第三方应用包括可以单独获取和安装的多个模块，并且可以包括来自多个第三方应用供应商的模块。为了提供集成来自多个供应商的多个第三方应用模块的能力，每个第三方应用模块必须提供其获取的接口/功能以及其提供的接口/功能的列表。例如，这可以通过使用基于层级点号隔开命名规范(例如，My_CRM_TRA.NewClient.GetInfo)的接口名称和接口参数规范的列表来实现。

第三方应用40模块可以指定要求的接口作为强制的(即，模块在不具有它们的情况下不工作)或作为可选的(即，模块可以工作，但是可能提供减少的或修改的功能)。因此，为每个接口提供的参数为：接口唯一名称；接口描述—向设计者5显示，从而他或她可以知道(例如)丢失接口所处理的功能；强制/可选状态；接口参数列表和类型。可以理解的是，每个第三方应用模块仍驻留在单个iframe(或iframe集合)中。接口的操作基于在下文更详细描述的通信信道。

可以理解的是，可以在网站设计阶段组装第三方应用40模块。网站建设系统30可以在添加额外的第三方应用40模块时解决接口参考—新的第三方应用40模块解决现有要求的接口，但是可能添加新的(未解决的)要求接口。

可以理解的是，设计者5可以编辑和运行完整的网站，但是强制的(或可选的)接口仍未解决。然而，设计者5可以不公布所创建的网站，直到所有强制接口被解决，并且当试图使函数要求中心205激活尚未解决的强制接口的第三方应用模块时进行提示。

还将意识到的是，AppStore 25可以包括搜索器26，其试图定位解决了所要求的第三方应用模块接口的第三方应用模块。搜索器26可以基于未解决的接口搜索特定第三方应用模块或所有第三方应用模块。搜索器26还可以搜索当前未解决的接口或甚至搜索已经解决的接口，并搜索强制、可选或两种类型的接口。可以理解的是，搜索器26还可以限制于解决特定第三方应用未解决接口，并都说特定第三方应用供应商。搜索器26可以执行第一级搜索(即，满足当前未解决接口的模块)或多级搜索(即，执行重复搜索)，还查找在考虑由先前搜索循环发现的第三方应用模块时添加的满足未解决接口的模块。

系统100可以使用接口描述来向设计者5提供关于一些丢失接口的重要性的信息。中心205可以提供不相容但仍需通信的第三方应用之间的接口转换。这可以通过网站建设系统30提供商添加的适配器模块或通过将给定的要求接口适配到不同格式的外部方实现。

系统100还可以应用于离线应用编辑系统，其使用互联网(或任意其它网络连接)并使用非浏览器客户端侧软件来查看所创建的在线应用。这种系统不需要使用常规网络基础设置所使用的特定技术(例如，IP通信、HTTP、HTML等)。

可以理解的是，在本领域中已知的标准跨域通信方法可以用于促进跨域通信。这些方法可以包括：

HTML5 PostMessage：这是一种标准的HTML5特征，其可以用于提供安全的跨域消息传送。利用HTML5Window.Postmessage，即使当驻留在不同域中时，消息也可以被安全地在窗口、iframe和主HTML文档之间发送。Postmessage提供工具用于发送iframe以指定将消息所发送到的域，并接收iframe来验证消息发送自的域。

消息的URL片段标识符：该方法依赖于使用URL片段标识符来从一个端点发送消息到另一端点。所述数据以明文编码并添加(作为片段标识符)到用于调用在目标终端域上的服务或在目标终端iframe内的隐藏iframe的URL上。然后通过在目标服务或iframe中的代码对片段标识符进行解码。

专用通信网络服务：网站建设系统30提供托管在网站建设系统服务器20上的专用网络。各种通信端点连接到该服务器上—发送消息或检查等待消息。这可以经由本领域已知的方法实现，例如技术的预先HTML5Comet集、基于HTML5的WebSocket或任意其它排队、轮询、服务器推送或类似技术。

HTML5本地存储：HTML5提供结构化本地存储设施，其可以用于存储排队消息。然而，本地存储仅可以通过与存储iframe属于同一域的网络内容进行访问。在本领域中已经开发了解决方案，例如，Meebo XAuth产品(现在术语Google公司)所使用的底层技术，其中小服务器提供支持用于创建所需要的中间iframe，其允许从以异地域为基础的iframe访问特定域本地存储。

HTML5本地文件系统访问应用编程接口(API)：类似于使用上述本地存储，可以利用通过HTML5文件访问API(文件API、FileWriter API和FileReader API)访问的用户代理的本地存储上的本地文件构造跨iframe通信信道。然而，需要注意的是，由HTML5文件系统访问API创建的沙盒化本地文件系统仍是私人起源，并因此要求中间iframe/服务器部件桥接相同起源的限制。

专用浏览器插件：可以创建专用浏览器(或其它用户代理)插件以管理跨iframe消息队列。这种插件将由网站建设系统30的(所有级别的)用户安装，并将向所有iframe的主网站建设系统30页面提供必要服务。

可以理解的是，通信中心205可以用作利用任意上述讨论的传输方法的所有iframe间通信的代理。还可以理解的是，中心205完全知道由第三方应用40供应商提供并存储于属性表单23内的包含网页203结构和第三方应用40细节。第三方应用40在包含于不同应用并用于同一应用中的不同包含实例时还可以具有不同的参数(如上所述)。这种参数可以包括唯一实例名称，其可以用于智能寻址(如下文更详细描述的)。还可以理解的是，中心205还可以知道不存储于属性表单23中的额外的第三方应用40细节。

还可以理解的是，中心205还可以促进智能寻址和识别，验证通信起源，强制通信策略，解决第三方应用40非兼容性问题，并还从第三方应用40重定向到部件。中心205还可以基于对包含网页203所做的改变使能动态更新在第三方应用40中的布局，如下文更详细描述的。

现在参考图11A和11B，其示出了中心205的不同实现实施例，以及参考图11C，其示出了其不同元件的功能。

中心205可以包括智能标识符和寻址器310、起源验证器320、通信策略强制器330、协议转换器340、重定向器350、动态布局更新器360、配置管理器370、通用更新器380和托管应用编程接口API包装器390。将在下文更详细描述这些元件的功能。可以理解的是，所有功能都可应用于所有的跨域通信信道，例如第三方应用40到网站建设系统30信道和第三方应用40到另一第三方应用40通道。

现在参考的图11A示出了通过中间iframe[a]的中心205的典型实施例，所述中间iframe[a]使用内部通信应用编程接口(API)来接触网站建设系统30。这样，可以对(例如)从TPA[d]发送到TPA[e](其分别使用通信API模块[f]和[g])的消息[c]以施加专用知识的方式进行分析、验证或修改。

在现在参考的图11B中示出的替代实施例不使用中间iframe，但是在(分别嵌入到第三方应用[c]和[d]中的)一个或两个通信API模块[a]和[b]中使用跨域通信。模块[a]和[b]直接与网站建设系统30相互影响，以接收专用知识并在处理通信消息[f]时进行处理。该实施例的缺点(与图11A所述的实施例比较)在于可以在包含于第三方应用中的模块内处理客观量的网站建设系统30级别信息，并且可以通过恶意第三方应用访问(或甚至修改)该信息。

如上所述，在本文上述描述的所有跨通信方法中，iframe寻址基于iframe的起源，包括来源域、协议和端口，即，当发送消息(以指定接收方)时以及当接收消息(按照提供给接收方的发送方名称)时使用直接第三方应用40寻址。另外，消息发送需要发送方指定目标iframe窗口(利用JavaScirpt的document.getElementById(“…”).contentWindow调用或任意其它方法)。因此，在现有技术中，每个第三方应用40必须包含任意其它第三方应用40利用其可以进行通信的全部和特定细节(包括域、协议、端口和iframe ID)。

可以理解的是，可以在系统100的环境中不方便地使用这种类型的直接寻址。即使设计者5可以集成来自多个非协调第三方应用40供应商的第三方应用40，第三方应用40供应商可以供应托管在给定域中的第三方应用40，但是后续会将其移动到不同于或子域。第三方应用40供应商可以改变用于接触任意给定第三方应用的协议或端口。可以要求设计者5修改包含第三方应用40的包含网页203的设计。所有这些可以发生于在由多个用户操作和访问的网站中使用的第三方应用40内。另外，单个包含网页203可以包括一个第三方应用40的多个实例，其可以服务多个功能。例如，在产品支持网络站点中的单个页面包含两个聊天第三方应用40实例—一个用于用户-用户和论坛，另一个在可用时用于与供应商的客服人员交谈。

可以理解的是，智能标识符和寻址器310可以完全知道包含网页203的结构以及第三方应用40的细节(如第三方应用40供应商提供给网站建设系统30的)。智能标识符和寻址器310可以利用以下中任一种彼此提供来源或目标第三方应用40的寻址：第三方应用40唯一名称(如在AppStore25中注册的)；添加到在包含网页203内的每个第三方应用40实例上的第三方应用40实例描述ID，从而允许同一第三方应用40的多个实例的寻址；用于所要求的第三方应用类型/类别的通用标识符(例如，“我想要将消息<x>发送给在包含网页203中的任意事件记录第三方应用40实例”)。这种标识符还可以描述应该由第三方应用40支持的特定服务。智能标识符和寻址器310还可以使用版本识别例如：“我想要将事务<x>发送给计数包<y>的实例，但仅在其是版本<z>时”。

可以理解的是，在运行时期间，第三方应用40仅与中心205通信，并因此只需要知道中心205的直接地址，而无需知道任意其它第三方应用40。这种单向地址可以通过由网站建设系统30提供给第三方应用40提供商的通信API包装器(例如，如图11A所示的通信模块f和g，以及如图11B所示的通信模块a和b)进行封装。调用第三方应用40可以提供应用感知第三方应用40描述性地址(如上所述)，并且智能标识符和寻址器310可以将其转换为直接第三方应用40地址并进行路由。这样，第三方应用40不需要维持与其通信的所有可能第三方应用40的绝对地址的表。

可以理解的是，消息起源验证是关键的，否则接收第三方应用40可能接收来自敌对第三方应用40的消息。因为所有的通信可以经由中心205发生，所以起源验证器320可以检查从第三方应用进入的所有消息的真实性。起源验证器320还可以提供可以添加到消息上并可以用于进行额外验证的额外信息。可以理解的是，因为在AppSotre 25中包括并由系统100使用的每个第三方应用40注册到网站建设系统30中，所以中心205可以验证网站建设系统30是否在消息中包含的唯一起源ID与消息起源(域、端口等)匹配。

第三方应用40可以定义通用通信策略，其可以取决于外部信息、包含网页203信息等。通信策略强制器330可以确保强制执行讨论中的通信策略，而不必处理非复合通信。例如，在经分类的信息处理网站中，第三方应用可以在其简档中标记有分类级别字段。被证明为分类级别X的提供后端事件记录数据库的第三方应用40可以定义策略，由此不接受注册具有比X大的分类级别的事件。在这种情况下，通信策略强制器330可以执行所要求的预备过滤，并高度防止经分类的消息甚至到达较低分类的应用。

可以理解的是，设计者5可能希望在同一创造的网站中包括可以合作的两个(或更多)第三方应用，但是由于一些协议兼容性问题而实际不能如此。例如，如现在参考的图12所示，电子商店第三方应用[a]可能能够将购买订单消息发送到履行和运输第三方应用，例如(不同供应商所提供的)第三方应用[b]。然而，第三方应用[a]所提供的信息可能不包括第三方应用[b]所要求的一些字段。这种情况通常由所涉及的第三方应用的第三方应用供应商来解决，但是在一些情况下，这种解决方案是不可行的(例如，两个第三方应用之一由于一些原因当前未更新)。协议转换器340可以将相关的消息从[a]转换到[b](例如，通过提供额外所需要的字段)。这种转换可以由协议转换器340执行，或者可能涉及与嵌入式网站和包含网页203的一些交互(例如，当需要额外的信息时)。

还将意识到的是，第三方应用40可以具有要求从另一第三方应用40(例如，如上所述的电子商店/履行第三方应用40对)发送或接收消息的一些能力。然而，在一些情况下，可能丢失一部分解决方案，在上述例子中，可能发生不存在匹配或适当的履行第三方应用40。在这种情况下，重定向器350可以允许设计者5指定给定的消息可以路由到或路由自包含网页203部件，并且可以通过包含网页203部件和部件可以提供的功能来解决匹配能力。这可以允许构造完全网站，而不要求构造专用第三方应用40。因此，可以将事物公布到网站建设系统30部件，其可以将事物记录到数据库，并且所述数据库稍后可以(由单独的程序)用于执行离线履行和运输。

第三方应用40可以提供多个配置，具有不同能力，利用相同的代码基但是具有不同的启用功能。例如，第三方应用40可以通过自由版本提供基本功能，并且通过购买的高级版本、多个付费版本或额外的购买的第三方应用40特征提供额外功能。

可以理解的是，系统100可以包括每个用户(或实际上每个设计者)第三方应用40购买状态的基于网站建设系统30的管理。还可以理解的是，设计者都可以是注册的网站建设系统30用户，并且网站建设系统30因此可以管理每个设计者5的第三方应用40购买的数据库。该信息可以通过TPA协调器24在涉及阶段期间以及通过配置管理器370在运行时期间存储于属性表单23中。例如，第三方应用40可以向网站建设系统30客户端侧元件发送版本查询消息。网站建设系统30客户端侧元件可以与库22或与其本地高速缓存副本咨询，并向第三方应用40返回具有关于其应该提供的能力的信息的响应消息。

在替代实施例中，网站建设系统30可以经由替代信道为第三方应用40提供所要求的第三方应用40配置信息，例如加密的iframe参数，而无需先前的查询消息。

如上文所讨论的，第三方应用40可以与特定包含网页203部件直接通信。第三方应用40可以以多种方式识别进行通信的部件：针对基于相关联模板的部件直接地(将在下文更详细描述)；通过由设计者5明确地提供给特定包含网页203部件的访问ID；通过遍历由包含网页203提供给第三方应用40的(可能选择的)部件模型。

可以理解的是，在运行时期间，更新器380可以实现在包含网页203部件和第三方应用40之间的消息和响应。例如，第三方应用40可以影响或查询包含网页203部件的视觉和显示属性(例如，其位置、尺寸、颜色、透明度等)。更新器380还可以使能第三方应用40读取或写入包含网页203部件的内容，并还可以允许第三方应用40指导执行媒体功能的部件，例如，发布给定音频或视频片段到媒体播放器部件，或要求其暂停播放达给定时间段。

更新器380还便于网站建设系统30部件指定它们允许第三方应用40具有的访问类型—类似于在现代操作系统中保护文件的访问许可位或访问控制列表(ACL)功能。可以为每个部件定义这种许可，以便针对来自特定供应商的所有第三方应用40或针对特定第三方应用40而应用。例如，可以允许第三方应用40访问在第三方应用40外部的包含网页203的一部分的文本字段。该文本字段可以用于针对博客第三方应用40编辑博客条目，提供比在博客第三方应用40区域本身内所提供的更多的屏幕空间。可以理解的是，针对嵌入到在多个页面容器中的特定迷你页面中的第三方应用40，网站建设系统30可以限制第三方应用40独自对在特定迷你页面中的部件的访问。

可以理解的是，更新器380还可以允许第三方应用40影响站点全局元件。这可以包括获得并设置属性，例如站点中的当前页面、在容器包含第三方应用40中的当前迷你页面以及页面历史。更新器380还可以过滤或限制这种请求。

更新器380还可以使得网站建设系统30影响第三方应用40的风格和显示。更新器380可以实现调用，网站建设系统30可以通过该调用向第三方应用40提供格式化和风格指南。这些可以包括如下属性：颜色和颜色方案，字体，字符大小，透明度，动画和特殊效果(例如，模糊)。特别地，颜色方案可以包括通用颜色方案(例如，使用下述x颜色)，或者作为高级颜色(例如，对文本使用颜色x，对框架使用颜色y)。

可以理解的是，表达复杂风格信息的一种优选方法是使用层叠样式表单(CSS)，其可以表达多种风格指示的组合，包括字体、大小、颜色等。更新器380可以将这种基于CSS的消息发送给第三方应用40。风格表单本质上是通用的，或者包括由第三方应用40定义的特定风格名称，从而网站建设系统30可以为第三方应用40提供更好的指南(例如，风格表单可以指的是特定第三方应用40元件并为其提供指南)。

然后，第三方应用40可以使用这些指南来制造其自己的外观和感觉并更好适应包含网页203。这对于包含于相同站点或从相同站点中的多个包含网页203可见的第三方应用40是尤其重要的(上述多端口包含)。多个包含页面可以采用不同的颜色方案或一般设计。第三方应用40可以使用通过这些风格消息提供给其的信息，并适配其自己的显示颜色和风格以更好地适应每个包含页面，并避免与包含页面相比显示不和谐颜色方案或外观以及感觉。

可以理解的是，动态布局更新器360可以使得网站建设系统30/第三方应用40或第三方应用40和次级第三方应用合作能够处理由动态布局事件引起的显示变化。网站建设系统30可以改变页面中部件的大小和位置，以便防止页面设计处于改变页面中的一些部件的事件中。这些动态部件事件例如可以包括：在具有不同尺寸的屏幕上查看网站；在肖像和风景模式之间旋转显示设备；改变一些部件的尺寸或位置以及改变给定部件的内容(以要求它们改变其尺寸的方式)。动态布局事件还可以包括由(例如，在来自数据馈送的部件显示信息中的)基于服务器的内容更新引起的部件更新，或由于相同网站的另一并发用户的内容改变引起的部件更新。还可以理解的是，动态布局事件可以发生于设计环境以及运行时环境中。特别地，一些部件和第三方应用40可以允许在运行时期间(即，通过终端用户)而不是仅通过设计者进行部件内容变化或尺寸/位置变化。

还可以理解的是，动态布局事件还可以由第三方应用40引起。例如，电子商店第三方应用40可以在用户从产品目录视图移动到(具有不同尺寸的)购物车视图时要求尺寸改变。又如，产品目录第三方应用40可以包括用于产品突出性的选项，其可以使得它们显示包括更多内容的较大的目录页面。第三个例子是多区域第三方应用40，其可以开始或停止显示额外区域。

现有的系统通常在如返回当前参考的图6所示弹出窗口隐藏其它页面部件时通过剪辑第三方应用显示、向其添加滚动条或仅调整其大小来处理这种情形(如果发生的话)。动态布局更新器360可以实现合作动态部件，其中网站建设系统30和第三方应用40合作执行动态布局并保持包含网页203的基本设计。动态布局的功能被进一步在2013年2月20日提交并指定为本发明的共同受让人的美国专利应用13/771,119中描述。然而，即使在合作动态部件支持系统中，包含网页203中的动态布局机制对第三方应用40的内部布局不具有完全控制。此外，可以设计网站建设系统30微件，从而可以对它们调整大小到(在给定范围内的)任意随意尺寸，但是第三方应用40不能支持随意调整大小。第三方应用40例如可以提供以下项的任意组合：具有不同尺寸的多个显示配置(例如，显示更多或更少细节)；调整其一些内部元件大小的能力，以及利用多个字体尺寸显示其一些内部文本元件的能力。

第三方应用40仍提供有限数量的可能的显示尺寸，并可以具有可能尺寸的整个范围。因此，[包含网页203→第三方应用40]调整大小请求可以由第三方应用40解决切换到最近的可能尺寸，或者通过提供可能的第三方应用40尺寸的列表(并允许网站建设系统30选择合适的一个进行使用)解决。

动态布局更新器360可以利用以下序列实现[包含网页203→第三方应用40]合作动态布局：

例如，在包含网页203中嵌入的第三方应用40不需要被调整大小到给定的期望尺寸(列，X1*Y1像素)。动态布局更新器360可以向第三方应用40发送消息请求第三方应用40调整其内容的大小到给定的期望尺寸(X1*Y1)。第三方应用40可以调整到所述尺寸——通过使用替代显示配置、内部调整大小、内部动态布局处理或任意其它方式。还可以理解的是，包含网页203可以将包含第三方应用40的外部iframe窗口调整大小到新的尺寸(X1*Y1)。

还可以理解的是，第三方应用40可以仅允许调整大小到可能尺寸的有限集合(例如，特定的用户接口配置)。因此，动态布局更新器360可以使用下列替代算法，其允许第三方应用40提供可能的尺寸集合。

包含网页203被调整大小，并且动态布局更新器360向第三方应用40发送消息请求第三方应用40调整其内容的大小到给定的期望尺寸(X1*Y1)。第三方应用40然后可以确定最近的可能尺寸(例如，X2*Y2像素)，并因此通过使用替代显示配置、内部调整大小、内部动态布局处理或任意其它方式进行调整大小。更新器380然后向包含网页203发送确认调整大小的响应消息，并提供实际的新尺寸(X2*Y2)。包含网页203可以对包含第三方应用40的外部iframe窗口调整大小到实际的新尺寸(X2*Y2)。包含网页203可以基于实际的新尺寸(X2*Y2)继续动态布局处理。

可以理解的是，另一实施例也是可应用的，尤其当在包含网页203中存在多个第三方应用40(或多区域多个第三方应用40)时。在该实施例中，包含网页203可以查询嵌入的第三方应用40以获得显示尺寸的列表，从而它们可以试图考虑用于多个第三方应用40的多个选项来优化外观和感觉。该实施例在第三方应用40在多个区域上显示的情况下也是相关的。

包含网页203可以执行动态布局处理，发现一个或多个第三方应用40(TPA[1]到TPA[n])嵌入在包含网页203内，并应该使用下列算法调整大小：

Loop on i from 1to n:

For each TPA[i]determine

The minimal size Xmin[i]*Ymin[i]；

The maximal size Xman[i]*Ymanx[i]；

The optimal size Xopt[i]*Yopt[i]；

动态布局更新器360可以向TPA[i]发送消息，详述上述min/max/opt尺寸，并请求关于可能的第三方应用40尺寸的信息。

第三方应用40可以向动态更新器380提供一组可能的尺寸选项，其可以假设Xposs[i][j]*Yposs[i][j]。

基于以上收集的Xposs[][]/Yposs[][]信息，通过使用(例如)所有可能的第三方应用尺寸组合的全面评价、线性编程技术或动态布局算法使用的任意其它技术，包含网页203可以计算动态布局计算的解。

为所有TPA在Xfinal[i]/Yfinal[i]中存储结果。

Loop on i from 1to n:

包含网页203然后可以将调整大小消息以及Xfinal[i]/Yfinal[i]发送给TPA[i]；

包含网页203将包含TPA[i]的外部iframe窗口调整大小到Xfinal[i]/Yfinal[i]；

基于实际的新尺寸，包含网页203继续动态布局处理。

可以理解的是，动态布局处理可以通常要求移动第三方应用40并不仅对其调整大小。然而，第三方应用40应该对其在包含网页203内的框架的准确位置不变。

如上文所讨论的，第三方应用40还需要不时地改变其显示窗口尺寸。因为显示iframe的窗口的尺寸由托管页面(即，包含网页203)所管理，所以第三方应用40窗口尺寸变化必须由包含网页203所执行——第三方应用40(经由动态布局更新器360)从包含网页203请求改变窗口尺寸。

还可以理解的是，第三方应用40还可以(经由动态布局更新器360)请求改变其在包含网页203内的位置。这可能不内部地(如尺寸变化那样)影响第三方应用40，但是要求在包含网页203内的显示变化。动态布局更新器360可以集成该请求与动态布局。包含网页203可以激活动态布局更新器360，以改变第三方应用40窗口尺寸(以及可能地改变其位置)，并确认尺寸和位置变化回第三方应用40。

可以理解的是，中心205还可以实现额外的第三方应用40类别专用或第三方应用专用消息，通过该消息，网站建设系统30自身、特定包含网站203或次级第三方应用40可以影响第三方应用40。例如，博客第三方应用40可以定义输入消息，其可以发布新的博客条目，或者新的对当前博客条目的对话。这种消息可以由包含网页203使用(例如，作为从在第三方应用区域外部的较大编辑字段发布博客条目)。其还可以用于更高级别的应用到应用链接，例如，允许支持第三方应用以向博客第三方应用发布博客条目。

可以理解的是，第三方应用40通常要求多种复杂服务—用于第三方应用40内部使用，或者用于由设计者使用在其站点处的第三方应用40的下游使用。这种服务可以包括用户管理、记账和运输管理。网站建设系统30供应商可能不能提供这种服务作为网站建设系统的一部分(例如，由于技术或商业考量)。此外，这些服务可能不适于独立地“封装”为第三方应用40。另外，第三方应用40供应商可能需要选项来利用第三方应用40(例如，多个第三方记账API)为设计者提供多个这种服务，并允许设计者5选择合适的一个用于其使用。

例如，可以在网站建设系统30中提供Paypal^TM托管API，并且可以直接由第三方应用40使用或者由第三方应用40将其提供给设计者5来使用它。第三方应用40还可以提供其自己的选项集合(即，使用特定的记账类型，如一次性、循环或收益分享)，并通过调用所托管的Paypal API实现这些选项。

因此，利用网站建设系统30的设计者5可以开发特定提供(例如，售卖歌曲的电子商店)，其使用预开账单。设计者5可以通过使用托管的记账API——直接或通过第三方应用40提供额外的抽象级别(或层)——而避免与记账API提供商谈判特定的结算或批发合同。在这种情况下，网站建设系统30可以成为托管API供应商的经销商。

托管API包装器390可以促进在系统的不同部分(例如，网站建设系统30，托管的API代码和所包含的第三方应用40)之间的该通信。可以理解的是，API包装器层和实际的API实现可以驻留在网站建设系统30本身或者另一第三方应用40中。第三方应用40供应商(或设计者5)可以通过托管的API包装器390使用托管的API，而无需知道实际基本API的实现方式。

在本发明的替代和补充实施例中，申请人还认识到在网站建设系统30以及一个或多个第三方应用40之间的智能集成还可以通过使用集成模型实现，在该集成模型中，额外的网站建设系统模板和部件与在AppStore 25的级别处的第三方应用以及与相关的第三方应用实例相关联。第三方应用40还可以与这些部件(以及不相关联的部件)通信，以交换数据和控制消息。如上文所述，在包含网页203内的第三方应用区域40是单独的iframe，其内容托管于单独的域中(第三方应用供应商或其它)——不同于托管主站点的域。因此，在不同iframe之间的通信经受浏览器的“相同来源策略”并要求使用如上所述的技术。

现有的系统将第三方应用40实现为整体地、刚性对象，其包含于包含网页203中，但是不影响包含网页203本身的外观和感觉。第三方40实例放置在(通常是矩形的)区域中，并在该区域内执行其所有的活动。

申请人还认识到，根据本发明的实施例，可以通过使得(可选)额外的网站建设系统30模板与第三方应用40相关联(被称作相关联模板)来扩展该概念。还可以理解的是，该关联可以在开发和公布第三方应用40期间执行，并且可以作为(从AppStore 25的)第三方应用40选择/购买过程以及第三方应用40实例创建的一部分呈现给设计者5。TPA协调器24可以取回与第三方应用40相关联的模板(作为AppSotre 25管理的应用库的一部分或者由第三方应用40供应商提供)，并可以将所述模板存储于库22中以供后续使用，如上所述。

可以理解，系统100可以支持公开具有多个相关联模板的第三方应用40——允许设计者5选择最适于其使用的模板。

可以理解的是，当在任意包含网页203中创建第三方应用40的实例时，在相关联模板中的部件可以与包含网页203合并，并且可以与在包含网页203中的任意其它部件一起显示。

现在参考图13，其示出了根据本发明实施例的相关联模板的使用的例子。如图所示，第三方应用[a]与包括部件[d]和[e]相关联模板[c]一起放置于AppStore[b]中。还可以理解的是，当第三方应用[a]包括于包含网页203[f]时，第三方应用[a]可以在页面[f]内的其指定区域[g]中显示，并且部件[d]和[e]的实例[d’]和[e’]可以与现有部件[h]和[j]一起显示在页面[f]上。

可以理解的是，系统100可以支持相关联模板部件实例(例如，上述[d’]和[e’])放置在包含网页203[f]内的多种方式。这些可以包括：绝对布置(即，利用在用于原始[d]和[e]的相关联模板[c]中指定的尺寸和位置)；目标相关放置(即，根据包含网页203[f]调整新实例[d’]和[e’]的尺寸和位置)；以及第三方应用40相对放置(即，相对于针对包含网页203[f]内的第三方应用实例[g]的尺寸和位置，挑中新实例[d’]和[e’]的尺寸和位置)。确定特定放置方法可以基于与相关联模板[c]一起被包括的设置进行，可能允许设计者5对其进行覆写。

还可以理解的是，设计者5可以修改继承自模板[c]的部件[d]和[e]的[f]中的实例。改变可能仅应用于使用在[f]中的[d]和[e](并可能继承自支持页面间继承的网站建设系统30的页面)，但是可能不影响与在AppSotre[b]中的第三方应用[a]相关联的“原始”模板[c]。

可以理解的是，上述对[d]和[e]实例的改变可能尤其包括将特定内容(文本、图像等)分配给字段实例，并且常规属性改变。还可以理解的是，如果第三方应用40包含于迷你页面内，则相关联的模板被应用于包括第三方应用40的特定迷你页面，如现在参考的图14所示。如图所示，第三方应用40包含于迷你页面[x]中，因此将部件[d]和[e]添加到[x]上，但是不添加到同一多页面容器[g]的额外迷你页面[y]和[z]上。

还可以理解的是，对于区段类型的迷你页面，相关联的模板(如果有的话)被应用于被创建以包含第三方应用40的虚拟(和空的)包含网页203中。

在替代实施例中，预先创建的相关联模板可以被应用于新创建的页面户迷你页面中，其与所包括的包含网页203“平行”。可以通过模板初始化该新创建的页面或迷你页面，之后再按照需要进行修改。

网站建设系统30还可以允许多端口包含，在其中相同的第三方应用40实例从主站点的多个页面可见并且“驻留”在所述多个页面中。这不同于给定第三方应用40在主站点的多个包含，所述主站点创建了第三方应用40的多个实例。(实例特定的)第三方应用40内容因此在相同多端口第三方应用40的多个视图之间共享。

在这种多端口包含中，可以将相关联的模板单独施加于添加了第三方应用40的页面和迷你页面的每一个上。

如上文所述，系统100可以提供在第三方应用40和包含网页203中的部件之间的2路通信链路。可以理解的是，这包括由合并来自第三方应用的相关联模板造成的包含网页203部件，以及与任何这种相关联模板不相关的模板。

因此，可以理解的是，第三方应用40供应商通常可以创建与由供应商生产的第三方应用40相关联的多个模板。除了实际被分布的模板(即，与当前分布的第三方应用版本相关联)外，这些模板还可以包括测试、开发和其它模板。

如上文所述，第三方应用40可以通过AppStore 25分布，并还可以通过不相关的替代信道分布或由网站建设系统30供应商管理。然而，与第三方应用40一起分布的相关联模板可能与应用库22高度相关并与其耦合，因为它们是利用部件、基础模板和网站建设系统30管理的其它元件建设的。

此外，在这种单独分布的相关联模板下的网站建设系统30元件可能不得不被修改或删除，这可能“破坏”相关联的模板。为了解决这个问题，系统100可以在应用库22内的单独区域(可能每个第三方应用40供应商)中实现这些相关联的模板。网站建设系统30可以用与其它网站建设系统30模板相同的方式管理这些模板。

还可以理解的是，可以为第三方应用40供应商提供用于每个创建牡丹的唯一ID(开发ID)，并可以在第三方应用40开发和测试过程期间使用该ID。一旦将要公布/分布第三方应用40，则可以要求第三方应用40供应商申请和接收替代的唯一ID(公布ID)，并可以在公布的第三方应用40中引用该ID。一旦提供了公布ID，则创建单独锁定的模板副本。这是由第三方应用40参考并在创建第三方应用40的实例时使用的副本。这样，第三方应用40供应商不能错误地修改与(正被设计者包括的)“现场”第三方应用40相关联的模板，并且保留参照完整性。此外，系统100可以交叉引用在这种锁定模板与根本部件和基础模板之间的关系。例如，当修改网站建设系统30部件或包含于这种锁定模板内的基本模板(并且这种修改可能以某种方式破坏模板或第三方应用40)时，这种交叉引用可以用于向网站建设系统30职员提供警告。

因此，系统100可以在第三方应用40、包含网页203内的部件以及网站建设系统30之间提供双向通信信道。包含网页203部件可以基于与第三方应用相关联的模板，基于其它网站建设系统30模板，或者与任何模板都不相关。

如上文所讨论的，通信中心205可以促进通信，并可以提供在包含网页和任意第三方应用40之间的反向通道。申请人还认识到在包含网页和任意第三方应用40之间前向和后向移动的数据一旦被收集、处理和集成将是有用的。

例如，网站拥有者需要管理其每个站点用户群体或成员，其不同于相关网站建设系统30的注册用户基础。网站用户可以注册或不注册(匿名)，并且网站可以对不同级别的用户提供不同级别的能力。此外，用户通常可以提供个人或联系人信息(即使是匿名用户)，例如，联系人表格中的数据，当它们激活即时消息软件以连续站点拥有者时，或者当它们连接到作为与站点一起工作的一部分的社交网络上时。可以理解的是，可以之间将该信息输入到所创建的站点，或者可以作为与嵌入到站点内的第三方应用40交互的一部分而可用。

还可以理解的是，这些信息可能是未组织的、不相关的、潜在矛盾的并且多次根本未保存。例如，单个给定用户可以在(由站点直接操作的)联系人表格上输入他的个人电子邮件，并在同一会话中在(由第三方应用40操作的)单独的订阅表格中输入他的工作电子邮件。

此外，那些“漂浮”的信息可以包括对其使用的不同许可。例如，在定于表格中填上电子邮件地址的用户完全期望接收它们订阅的基于电子邮件的订阅以及可能相关的电子邮件简报。在另一方面，提供电子邮件地址作为注册ID的用户可能除与他的账户处理、安全警告等有关的电子邮件之外，不希望在其注册地址接收任何电子邮件。

现在参考图15，其示出了系统200，用于协调和收集来自在网站建设系统30与一个或多个嵌入式第三方应用40之间交换的不同消息的数据。系统200包括安装在客户端220中的客户端中心210，以及安装在服务器260中的服务器中心230、联系人协调器240、活动协调器250、联系数据库245以及活动流数据库255。可以理解的是，中心210和230可以促进网站建设系统30和安装在服务器270上的多个第三方应用40之间的通信以及在如上所述与中心205相关的不同的第三方应用40之间的通信。联系数据库245和活动流数据库255可以保存联系人/活动信息以及从消息流提取出的信息，如下文更详细描述的。

现在参考图16A和图16B，图16A示出了客户端中心210的元件，而图16B示出了服务器中心230的元件、联系人协调器240和活动协调器250。客户端中心210包括路由器211、转换器和适配器212以及隐私策略强制器213。服务器中心230包括路由器和跟踪器231、转换器和适配器232、隐私策略强制器233、私人数据代理234以及验证器和签名器235。联系人协调器240包括数据提取器241、联系人吹起242、数据合并前243以及数据和许可处理器244。活动协调器250包括流创建器251、流合并前252以及记录创建器253。这些元件的功能将在下文更详细描述。

现在参考图16C和图16D，图16C示出了流合并前252的元件，而图16D示出了数据合并前243的元件。流合并器252包括活动到流合并器261和流到流合并器262。流到流合并器262还包括水平流合并器263和垂直流合并器264。数据合并前243包括联系人识别器272、联合器273、矛盾解决器274、列表值创建器275、垂直联系人合并器276和水平联系人合并器277。水平联系人合并器277还包括虚拟水平合并器278。垂直联系人合并器276还包括虚拟垂直合并器279。这些元件的功能将在下文更详细地描述。

可以理解的是，系统200可以支持在系统200和多个第三方应用40之间传递消息，同时提供各种能力，包括通过流的活动消息组织、存储活动消息历史、多级别活动消息传递、针对活动消息利用边带信道、活动消息转换和内容适应、活动消息验证和签名，以及利用下文详细描述的监听器查询进行动态活动消息路由。

此外，系统200可以提取用户相关信息并对其进行合并—联合来自多个源的信息以及在系统200中已经存在的信息。这可以通过合并使不同且可能矛盾的信息一致的规则进行。该联合的信息可以存储于联系人数据库245中。该信息还可以包括使用许可字段，控制所允许的收集到的信息的使用，如下文更详细描述的。

在本发明的替代实施例中，客户端中心210和服务器中心230可以单独用于与安装于服务器270上的多个第三方应用40通信。可以理解的是，在仅使用客户端中心210的情形下，联系人协调器240、活动协调器250与数据库245和255一起可以本地安装在相关客户端中。

还可以理解的是，系统200可以包括其它部件，其可以允许第三方应用40管理用户联系活动(例如，简报的邮件群发)，同时强制实行由用户自己设置的使用限制。这种部件甚至可以隔离用户私人数据与第三方应用40——从而第三方应用40可以执行它们的动作，而不能实际访问私人用户数据。例如，可以通过私人数据代理234实现这种能力，如下文更详细描述的。

还可以理解的是，联系人数据库245可以专用于每个站点。然而，网站建设系统30可以定义包含(同一站点拥有者所拥有的)网站的集合的元站点(meta-site)/投影级别，并允许指定在元站点级别而不是单个站点级别处存储、处理和合并联系人。还可以在元站点而不是站点级别处定义其它站点元件(例如，所包括的第三方应用40)。除了元站点支持外，系统200还通常不共享联系人(除了下文描述的之外)，或集成在不同站点或不同站点拥有者之间的联系人信息(从而给定的终端用户提供给一个站点的数据不会泄露给另一站点)。

如上文所述，系统200可以支持在网站建设系统30和一个或多个第三方应用40之间的多个交互。这种交互可以是预先定义的活动，例如，购买、添加项目到购物车、填充联系人信息等。第三方应用40可以指定其支持哪些活动，并且其他第三方应用40可以“监听”特定活动并在接收到活动及其相关联信息时进行动作。可以理解的是，对于给定的第三方应用40监听活动的列表可以被明确设置为一个或多个活动，或可以由监听查询的活动所确定，如下文更详细描述的。

可以理解的是，可以将每个活动视为消息，并且每个消息可以包括活动数据结构。活动数据结构是预先定义的数据类型，但是可以通过它们之间的继承以及通过具有通过添加字段而对其进行扩展的选项的第三方应用40进行定义。它们可以是对系统特定的，或者可以基于或包括标准化的数据结构。它们还可以以某种方式进行编码，例如XML、JSON数据，或使用二进制对象编码方案。

活动数据结构还可以包括在“描述”字段提供的第三方应用40。这是基于第三方应用40的活动描述(其可以比网站建设系统30所知道的更详细)。例如，VOIP通信第三方应用40可以提供“在999-555-1234-01:15呼叫John Smith”的活动描述文本。

活动数据结构还可以包括回叫链路，例如，“更多信息”，其返回活动数据结构。这可以用于提供额外的实质信息，例如，对于电子商务活动数据结构：完全命令跟踪信息、命令历史等；对于聊天活动数据结构：完全聊天副本；以及对于电话活动数据结构：记录电话。因此，样本完全活动数据结构可以包含以下字段：创建时间戳；活动类型；活动来源(第三方应用40/部件ID)；活动流ID；活动类型特定信息(取决于活动类型)；创建站点ID；站点成员数据库ID；活动发生的站点页面的ID/URL；由第三方应用40提供的活动描述；由第三方应用40使用的更多信息链路和捕获的用户细节等。

可以将活动协调器250视为记录元件，并且可以从中心230接收传递消息。流创建器251可以创建被视为记录或链路状结构的初始流，并且流合并器252可以将向其添加任意额外的输入活动，每个流对联系人是唯一的。可以理解的是，流创建器251不能为包含于不同消息中的每个单独的活动创建新的流。还可以理解的是，在流中包含的活动可以是失序的(例如，第三方应用40可以延迟报告活动)。流合并器252可以在操作期间当流属于同一单个联系人时合并流，并且记录创建器253可以在所有先前创建的活动流的活动流数据库255上保存记录文件。

如以上关于图16C所讨论的，流合并器252包括活动到流合并器261和流到流合并器262。活动到流合并器261可以将活动与关联于识别出的联系人的流相关联，并且流到流合并器262可以将两个单独的流转换为单个流。水平流合并器263可以将两个不相关的流合并成检测到的共同初始ID，而垂直流合并器264可以合并为匿名联系人创建的流以及与注册的用户相关联的流，当登录或注册时，其可以连接两者。可以理解的是，在必要时，流合并器252可以从活动流数据库255访问先前创建的流。

例如，匿名用户填充站点中的联系人表格。流创建器251可以创建新的活动流(具有ID“anon 1”)，并且联系人处理器242可以创建新的联系人(具有ID“anon 1”，如下文更详细描述的)。然后，同一用户可以与站点拥有者聊天。流合并器252然后可以将该活动合并到“anon 1”活动六，并且更新联系人“anon 1”(如下文更详细描述的)。然后，使用不同浏览器的用户填充调度表格。因为与原始用户无关，所以流创建器251可以创建具有ID“anon 2”的新的活动流，并且联系人处理器242可以创建具有ID“anon 2”的新的联系人。

然后，用户从站点购买事物。流合并器252将新的活动合并到“anon 2”活动流，并且更新联系人“anon 2”(例如，利用“顾客”标签)。

使用另一浏览器的用户向站点注册。当注册时，所有的用户从站点的成员处理器处接收到“用户x”ID。在此时，流创建器251可以创建新的活动流(具有ID“用户x”)，并且联系人处理器242可以创建新的联系人(具有同一ID“用户x”)。

稍后，用户从另一浏览器返回，并与站点拥有者聊天。当站点不具有网络跟踪器(cookie)时，流创建器251可以创建又一新的流ID“anon 3”，并且联系人处理器242可以创建新的联系人“anon 3”。

现在，用户登录到网站。此时，存在具有“anon 3”ID和“用户x”ID的联系人。数据合并前243可以将联系人“anon 3”合并到“用户x”中，从而在“用户x”流中的登录活动和联系人“用户x”的登录活动两者都指向活动流“用户x”和“anon 3”。流合并器252可以将用户在该会话中执行的任意额外动作合并到“用户x”活动流中。日志创建器253可以记录来自流的所有活动数据，并在活动数据库255中保存日志的副本。

可以理解的是，站点拥有者可以针对给定联系人通过由网站建设系统30提供的相关用户接口访问活动流的历史，如现在参考的图17所示。对于单个联系人“DaniBronstein”，可以容易的访问到他的网站的历史。还可以理解的是，网站建设系统30或第三方应用40还可以提供API来访问日志信息。还可以理解的是，活动日志可以用于进行优化、用户接口改善、广告目标等。

还可以理解的是，并行地，联系人协调器240可以从活动流(消息)提供的数据收集信息，以构建正在讨论的用户的联系人简档。数据提取器241可以从活动消息和流中提取数据，数据合并器243可以将相关数据合并到特定联系人，其细节被存储并可以从联系人数据库245访问。联系人处理器242可以创建新的联系人，处理站点用户身份、匿名用户等，并且数据和许可处理器244可以处理隐私保护和许可相关数据。如上文所讨论的，数据合并器243可以包括水平联系人合并器277和垂直联系人合并器276。水平联系人合并器277可以由于检测到的共同主要ID而合并两个不相关联系人，并且垂直联系人合并器276可以合并匿名联系人和与注册用户相关联的联系人，当登录或注册时，是可以连接两者。水平联系人合并器277还可以包括虚拟水平合并器278，以将两个联系人维持为分离的，但是将其链接到一起，从而它们可以被标记为表示同一联系人——具有或不具有合并实际的联系人信息。垂直联系人合并器276还可以包括垂直虚拟合并器279，以维持匿名联系人和与注册的用户相关联的联系人分离，但是将其链接到一起，从而它们被标记为表示同一联系人—具有或不具有合并的实际联系人信息。数据合并器243还可以将联系人信息(通常由数据提取器241提取)合并到现有联系人中。还可以理解的是，联系人识别器272可以利用网络跟踪器跟踪用户身份，并可以识别应该合并的联系人，如下文进一步讨论的。

返回参考图15、16A和16B，可以在客户端220、服务器260或两者上执行消息传递。可以理解的是，第三方应用40通常具有客户端侧元件以及服务器侧元件，或者至少到第三方应用40提供商服务器270的服务器侧连接。中心210可以处理在客户端220和第三方应用40之间的任意消息，并且230在服务器260和第三方应用40之间。可以理解的是，由中心210接收到的数据可以被处理并转发到中心230以供进一步处理，如下文更详细描述的。

现在参考图18，其示出了在不同平台之间的消息传递场景。用户客户端机器X可以连接到服务器Y上的网站建设系统30。可以利用网站建设系统30客户端部件A’和网站建设系统30服务器部件A，实现网站建设系统30。当现实所创建的站点时，其可以包括客户端侧元件(数据/代码)B’和服务器侧元件B。所创建的站点还可以包括三个第三方应用40—TPA1、TPA2和ETPA3。

可以通过客户端侧部件D’和与TPA1供应商服务器H连接的服务器侧元件D实现TPA1。可以通过客户端侧部件E’和与TPA2供应商服务器I连接的服务器侧部件E实现TPA2。然而，EPTA3可以是由连接到网站建设系统30第三方应用40支持后端F的服务器侧部件G实现的仅服务器侧第三方应用40。该两者可以与第三方应用40供应商服务器J通信。

还可以理解的是，TPA1和TPA2可以在(部件D’和E’之间的)客户端上、在(部件D和E之间的)服务器上或在两者上交换消息。然而，与EPTA3的任意通信必须仅在服务器上进行。还可以理解的是，使用任一种方法都存在优点和缺点。客户端侧活动消息发送可以是更交互的，并且提供更快的用户响应。服务器侧活动消息发送可以是更健壮的、更可靠的(例如，用户在该过程中间不能关闭浏览器窗口)，提供更好的保证消息接收的正确顺序，并还可以允许活动消息发送到安装到后端或应用仪表板上的后端第三方应用40。

利用多个第三方应用40的情况的例子是用户将产品添加到在第三方应用A中的购物车中(活动类型是“车变化”)。第三方应用A然后可以将活动消息与添加的产品发送给网站建设系统30。网站建设系统30然后可以将活动转发给向车变化注册的所有第三方应用40。由于第三方应用B已经注册，所以其接收活动。第三方应用B然后可以向用户显示消息，例如“如果你还添加产品X，则你可以获得折扣”或者“分享该站点以获得折扣”。

另一例子是用户(经由例如Facebook)“喜欢”在第三方应用A中的事物。第三方应用A然后可以将活动消息与活动类型“Facebook喜欢”发送给网站建设系统30。网站建设系统然后可以将活动转发给注册到“喜欢”活动的所有第三方应用40。由于第三方应用B已经注册，所以其接收活动。第三方应用B可以向用户显示重新介入微件，并显示消息例如“如果你喜欢该站点，联系站点拥有者如何？”或“你想要打折券吗？”

如上文所述的，可以经由中心210和230发生所有通信。

路由器211可以在网站和任意第三方应用40之间路由客户端侧消息。路由器211还可以在中心210和中心230之间路由消息，以供进一步处理，如下文更详细描述的。

路由器和跟踪器231开在网站和任意第三方应用40之间路由消息，并还可以跟踪消息。可以理解的是，第三方应用40还监听在客户端和服务器上的消息。还可以理解的是，第三方应用40可以明确地指定其监听的一个或多个活动，例如，监听所有的“购物车-添加项目”活动。第三方应用40还可以指定其监听的活动类别，例如，监听所有的Facebook相关活动。此外，第三方应用可以包括通配符表达(应用于活动名称上)，其用于确定活动是否应该被发送到第三方应用。

还可以理解的是，第三方应用40可以使用活动监听器查询。这种查询可以指的是额外的系统信息，包括通常不可用于第三方应用本身的信息，例如：用户属性(例如，仅注册的用户，仅欧洲用户等)，网站属性或结构(例如，仅监听在从给定页面模板导出的页面上的给定活动)，用户历史(例如，当用户过去购物总共超过X时仅监听购物车结账活动)等。这种查询可以由第三方应用40指定，但是还可以由设计者编辑。

因此，路由器和跟踪器231还可以跟踪第三方应用40正在监听的消息。可以理解的是，这种活动监听器查询架构最佳地实现于活动路由级别(而不是由第三方应用40内部的API调用实现)，因为其可以允许网站设计者执行裁剪和定制，而不要求第三方应用40高度可编程和可定制。路由器和跟踪器231还有助于保存用户隐私，因为网站设计者不对所涉及的第三方应用40提供(路由决策所需要的)额外信息。其还可以保存通常托管在单独的服务器上的不需要的与第三方应用40的通信调用。

可以理解的是，用户(网站访问者)向网站访问、注册和提供信息。用户实际上不知道他或她所访问的网站是利用网站建设系统30、部件、构造网站和第三方应用40的组合建设的。因此，用户隐私的责任最终取决于网站拥有者(其还负责在他或她的网站中包含的第三方应用40所采取的动作)。

还可以理解的是，可以基于由网站建设系统30和由网站建设系统30提供的API定义的隐私规则，通过第三方应用40(和其它网站建设系统30部件)访问用户简档信息。此外，包含站点以及其内包含的第三方应用40可以使用联系人信息来与用户(经由电子邮件或其它方式)进行通信。

可以理解的是，存在三种主要的隐私相关问题。第一种是网站和网站建设系统30与第三方应用40提供商的交互。网站(和网站建设系统30)不能完全信任使用其用户数据的第三方应用40，例如，第三方应用40不会(利用站点提供的用户电子邮件)群发邮件，请求从邮件中移除垃圾邮件用户，或将用户个人信息转移到第四方。然而，可以用如下方式进行解决：

网站建设系统30供应商可以要求第三方应用40提供商在将其添加到网站建设系统30应用市场中时签署使用条款(ToU)协议。这种协议可以声明第三方应用40(以第三方应用40供应商)不能滥用或还公开用户的信息。如果第三方应用提供商滥用信息，则网站建设系统30供应商随后可以惩罚第三方应用提供商(例如，禁用第三方应用40，将第三方应用40从网站建设系统30应用市场移除，等)。隐私策略强制器213和233以及私人数据代理234可以对第三方应用40强制实行隐私策略，如下文更详细描述的。

第二种隐私相关问题是网站和网站建设系统30与用户(站点访问者)的交互。网站必须向用户提供清除的理解他或他的个人数据将被如何使用，从用户处接收协议并遵守用户同意的条款。网站建设系统30请求所有的公布站点向用户提供ToU文献，其定义了对术语用户的私人信息的允许使用，并且要求用户电签署所述文献。然后，站点必须遵守这些条款和允许使用。网站建设系统30还可以包括其所提供的每个网站模板中的样本ToU页面。私人策略强制器213和233可以确保保持ToU文献的使用的条款。私人测量强制器213和233还可以确保通过删除或重新排列相关数据而仅向TPA提供所允许的信息。

第三种隐私相关问题是支持取消订阅请求。站点必须向用户提供取消定于任何营销电子邮件的选项。这可以通过数据和许可处理器244处理，如下文更详细描述的。

数据和许可处理器244还可以处理由不同用户设置的不同用户许可，如下文更详细描述的。

私人数据代理234可以允许网站建设系统30(和在期内建设的网站)在网站建设系统30管理的安全库中保持所有或一些私人数据，并可以向第三方应用提供替代的唯一ID(而不是私人数据)，其可以由网站建设系统30用于取回隐藏的私人数据。例如，电子邮件地址由提供给第三方应用40的替代“电子邮件地址ID”所代替，从而第三方应用40不能访问实际的电子邮件地址。

私人数据代理234还可以提供一组接口用于各种通信方法(例如，电子邮件、社交网络消息传送等)，其可以由第三方应用40用于接触/发送消息给用户，而无需第三方应用40实际访问与用户相关联的私人数据。这种私人数据可以包括所有的识别细节，通过这些细节可以联系用户，包括(例如)：名称、地址、电子邮件、电话(包括SMS/MMS)、统一通信ID(Skype等)以及社交网络ID。

私人数据代理234因此可以强制实施用户许可字段限制，强制实施用户取消订阅请求，并限制用户消息发送，例如，对于为给定站点工作的给定第三方应用40允许每天不超过100封电子邮件。私人数据代理234可以定义代理参数，以及哪些私人数据用于揭露给第三方应用和哪些用于隐藏—基于每个第三方应用40，并基于逐字段进行设置。

对于托管在网站建设系统30服务器上的第三方应用40，私人数据代理234可以提供替代的唯一ID，其在形式上类似于原始私人数据(例如，提供替代的虚拟电子邮件，而不是原始私人用户电子邮件)，然后“捕捉”使用该信息的调用并转发电子邮件(在该例子中)到正确的地址。这还可以用于检测超过其允许权限的任意第三方应用40。

可以理解的是，网站拥有者可能希望向任意特定第三方应用40提供有限的或修改的信息。这可能例如由于一般的安全考虑，关于用户数据的任意元素的特定隐私承诺或特定工业或应用所特有的管理要求。私人策略强制器213和233可以实现网站拥有者所做出的任意这种改变，并覆写当前设置。

例子可以是处理医疗信息的网站，其可能对在向一般地理用户分布分析第三方应用40传递时阻挡一些个人系列到联系人信息中感兴趣。在另一例子中，第三方应用40可能在处理某些类型的联系人信息方面存在问题。想要继续使用第三方应用40的网站拥有者(即使已知故障)可能希望过滤掉触发已知问题的联系人，或修改数据从而不触发问题。

转换器和适配器212和232可以应用预先指定的消息转换和内容适配规则。每个这种规则可以包括条件，例如其应用于那些第三方应用40，选择其应用于那些消息的过滤标准，转变规则(例如，涉及丢弃给定消息(关于相关的第三方应用40))或将应用于在活动数据结构中的给定的一个或多个字段的转变。

这样，根据站点拥有者制定的规范，中心210和230可以向不同的第三方应用40输送不同版本的活动数据结构(或根本不输送)。

相关网站建设系统30还可以支持消息的验证和签名，以增强系统免于失败和中断试图(例如，想要修改第三方应用40消息有效载荷数据的中间人攻击)。因此，向网站建设系统30注册的每个第三方应用40可以具有两组私人/公共秘钥：一组用于对从第三方应用40发送到网站建设系统30的消息(输入密钥)进行解码，并且另一组用于对从网站建设系统30发送给第三方应用40的消息进行编码(输出密钥)。

例如，第三方应用A可以向网站建设系统30发送消息。可以连通用于站点的第三方应用ID一起发送消息，所述第三方应用ID是第三方应用外部ID(具有第三方应用范围)并且可以由第三方应用签名。网站建设系统30可以接收消息。验证器和签名器235可以利用第三方应用A的输入秘钥验证签名。如果所述验证失败，则验证器和签名器235可以将输入消息报告为无效的并且不再传送该消息。

验证器和签名器235可以利用内部站点ID转换与消息相关联的外部ID。验证器和签名器235可以确定哪些第三方应用40应该获得消息。

例如，对于每个第三方应用B1..Bn，验证器和签名器235可以发现第三方应用B的外部ID。验证器和签名器235然后可以创建到第三方应用B的消息，并指示转换器和适配器212/232应用如上所述的任意可应用过滤和转变规则。验证器和签名器235然后可以利用第三方应用B的输出秘钥对消息签名，并经由路由器和跟踪器231(或路由器211)将该消息发送到第三方应用B。然后，第三方应用B可以接收消息并验证签名。如果当前验证失败，则将该消息报告为无效的并不进行进一步处理。可以理解的是，验证器和签名器235仅可以执行服务器侧而不可以执行客户端侧处理，以确保不会将秘密验证数据发送给不信任的客户端。

如上所讨论的，系统200可以在网站建设系统30和第三方应用40之间采用多种类型的通信。这些可以包括例如控制通信，例如，网站建设系统30命令第三方应用40关闭；功能通信，例如，购物车第三方应用40通过网站建设系统30向记账第三方应用40发送总的购买量，从而影响在本说明书中讨论的例子的支付或活动通信。可以理解的是，这些不同种类的通信具有不同的简档和要求，例如，在消息发送量、健壮性、响应时间要求等方面。

特别地，系统200可以包括非常频繁的活动报告(例如，如果第三方应用40图形用户界面(GUI)事件在被报告的第三方应用40活动中)。这种多个活动报告可能覆盖系统处理更多关键消息的部分。因此，系统200可以实现多个通信信道(例如，利用不同的端口、多个并发会话等)，从而经由单独的信道发送每类消息。这样，活动报告使用边带信道，并平行于且不干扰命令和功能通信。

如上所讨论的，系统200可以收集活动信息，以便经由联系人协调器240和活动协调器250创建并增强联系人信息，并且核对与特定联系人相关联的活动事件。对于通过中心210和230路由的每个活动消息，联系人协调器240和活动协调器250可以处理信息。流创建器251可以根据活动消息创建联系人专用数据流，并且联系人协调器240的元件可以提取数据，并在将其存储到联系人数据库245之前进行处理。

因此，每个活动流可以具有与其相关联的构造的联系人，其可以通过从在数据流下执行的活动中提取出的数据进行增强。可以理解的是，联系人协调器240还可以识别相关联系人的存在—被发现用于描述同一人的多个联系人记录。联系人识别器272可以通过匹配主要ID字段(例如，电子邮件、电话号码、社会安全号码、Facebook ID等)来识别这种记录。可以理解的是，一些主要ID字段是多值字段(例如，人们可以具有多个识别电子邮件)，而一些是严格的单值字段(例如，社会安全号码)。

因此，数据合并器243可以将从新活动提取出的联系人字段合并到当前构造的联系人中，并且一旦匿名用户执行了登录操作并已经变成识别出的用户，可以将为匿名用户在使用网站期间构造的构造的联系人合并到预先定义的保存的联系人中(这已知为“垂直”合并)。水平联系人合并器277还可以在检测到这些是涉及同一用户的相关联系人时，执行个不同联系人(构造的联系人或存储的联系人)两的“水平”合并。如上文所讨论的，这种合并可以通过将一个联系人合并到另一个的实际合并(即，将两个单独的联系人转换为单个联系人)，或通过虚拟合并(即，将两个联系人维持为单独的但将其链接到一起，从而它们被标记为表示同一用户——具有或不具有合并实际联系人信息和活动流)执行。还可以理解的是，即使在虚拟合并中，也可以将另外添加的信息添加到多个链接的虚拟合并联系人中。

因此，数据提取器241可以从相关数据活动结构中提取联系人类型信息，并且数据合并器243可以将联系人类型信息集成到与活动流相关联的联系人中(匿名的或识别出的)。如果联系人类型信息I包含主要ID字段，则数据合并器243可以基于主要ID字段值检查相关联系人，并且如果发现了，则合并这些联系人。数据合并器243还可以检查活动是否在站点中建立了用户身份(例如，站点登录活动)，如果是，则合并匿名联系人与为该用户记录的现有联系人记录，并自此使其成为识别出的联系人。

可以理解的是，联系人识别器272可以实现多种方法来识别站点用户，例如，通过使用网络跟踪器来跟踪单个匿名用户(其未登录到站点)的会话，利用已注册用户的站点登录，通过账户与社交网络相关联的站点用户的社交登录，或通过匹配主要ID字段(例如，电子邮件/电话)以识别描述同一用户的两个用户简档。

还可以理解的是，细节存储于联系人数据库245内的站点用户可以被分类为没有在站点处注册的匿名用户；注册用户和潜在用户—尚未正式在站点注册的潜在用户的(从外部源导入的)记录。

因为相关网站可以安装永久的从会话到会话坚持的网络跟踪器，所以在同一计算机上利用相同浏览器运行的多个匿名会话可以继续想同一联系人记录贡献信息。因此，即使匿名用户可以可以具有相当多的文本和联系人信息。

注册用户必须提供对特定站点唯一的ID。可以使用多种类型的ID，例如，单独的站点特有ID(如，用户名)，外部标识符(如，电子邮件、电话号码或社会安全号码)，或者不同系统提供的外部标识符(如，社交网络ID、OpenID识别等)。

通过社交网络登录所注册的用户可以允许站点使用在社交网络中可用的个人信息来填充同一用户的站点简档。数据提取器241还可以重新访问社交网络简档，以检测对该个人信息的任意变化，并可以更新站点用户简档。

注册用户必须一般登录到系统中以便建立她或他的身份，但是系统可能提供“使我保持连接到该系统”选项。这种登录过程是明确的(用户调用登录对话)、隐含式的(要求用户提供一些识别细节，例如在对博客添加对话时)，或者可以是基于外部登录的(系统调用与不同系统相关联的登录过程，例如社交网络登录或OpenID登录)。还可以通过物理设备(例如，直接或经由无线接口连接到系统上的安全令牌)或通过生物统计信息使用(包括用户的生物统计参数，例如指纹或虹膜扫描；以及用户的行为检测，例如键入模式检测)或者以上详述的方法的任意组合影响登录过程。

还可以理解的是，社交登录过程可以在两个方向上与常规登录交互。例如，社交ID与站点成员ID相关联，从而社交登录将暗示站点登录，或者站点成员ID可以与一个或多个社交网络ID相关联，从而站点登录还可以识别一个或多个社交网络的用户。

当用户执行明确的注销时，联系人处理器242可以生成新的匿名用户网络跟踪器，并因此打开新的匿名会话(或会话系列)，其活动将保存于该新的匿名联系人下。在以后续识别出的联系人再次登录时，可以合并该新的匿名联系人。

现在参考图19，其示出了匿名用户的登录和注销过程。用户可以匿名地开始使用系统。联系人处理器242可以创建联系人，并且在用户执行第一个第三方应用动作act1时，流创建器251可以自动创建活动流anon1。流合并器252可以将来自act1和来自后续活动act2和act3的信息合并到用户anon 1。

一旦相同用户作为用户X执行登录，则数据合并器243将anon 1联系人(以及从活动流取回的任意其它相关联系人数据)合并到用户X的联系人信息中。可以理解的是，流合并器252还可以将从其它动作act4和act5提取出的信息合并到单个流中，并且数据提取器241然后可以提取用户X的联系人信息。当用户X执行注销时，联系人处理器242可以创建新的网络跟踪器，从用户X出分离其它的活动。因此，当执行新的活动act6时，联系人处理器242可以创建新的匿名联系人anon2，并且数据提取器241可以将提取出的联系人细节(和活动)保存到新创建的匿名联系人anon2下。

如果(如在场景A中)用户anon2作为用户Y执行第二次登录，则数据合并器243可以将联系人anon2(如由act6和act7所更新的)以及任意进一步的活动合并到识别出的用户Y的联系人细节中。

如果(如在场景B中)用户anon 2作为用户X(重复)执行第二次登录，则数据合并器243可以将用于用户anon2的联系人信息(如由act6和act7所更新的)与任意其它活动一起合并到用户X的联系人细节(已经被更新以反映act1-act5)中。

可以理解的是，与活动相关联的活动数据结构还可以包括联系人细节。数据提取器241可以提取该信息，并将其转发到数据合并器243，该数据合并器243可以将其与现有联系人信息集成到可能增强其的联系人数据库245中。还可以理解的是，数据提取器241可以从特定活动消息、从整个流、从其它联系人或从外部源(例如，IP)到地理地址转换服务提取细节，如下文更详细描述的。如上所讨论的，在联系人数据库245中的联系人还可以包含联系人细节，其由用户明确提供作为对网站的登记或注册过程的一部分，当注册到网站时(经由社交登录/注册特征)从用户所使用的社交网络账户中提取出，或在更新他或她的简档时由用户提供。数据提取器241还可以从外部源取回联系人信息(例如，当用户仅指定美国邮政编码时，并且这由站点用于从外部邮政编码解码网络服务取回完整地址信息)。

如上所讨论的，联系人识别器272可以基于主要ID字段(例如，用户名称、电子邮件或电话号码)将两个联系人识别为相关的。一旦发现联系人A(新的)和B(现有的)相关，则数据合并器243可以将A合并到B(B是主要的)。这可以利用诸如以下的字段合并规则进行：

B1＝B或A(如“B||A”)；取B，并且如果B为空或空的则取A；

B1＝math-func(A,B)；重要的私人情况是：

B1＝A+B；例如，访问次数，总共购买次数；

B1＝min(A,B)；例如，日期联合站点；

B1＝max(A,B)；例如，最后的活动日期；

B1＝list-unit(B,A)；在B的结尾处串联列表A，移除A中与B中元素重复的元素(即，B1＝B&(A-B))。数据合并器243可以根据以下规则确定在列表成员中的重复：

对于包括正则值(即，标量)的列表，使用正则值比较；

对于包括结构的列表，使用结构的特定子字段作为比较键。例如，在支持多个地址的网站建设系统30中的地址类型(家庭、办公、送货…)；

正规化值比较。参见(例如)以下处理电话号码：

如果结构A是结构B的更详细版本则将A联合到B中(在下文更详细的描述)，以及

较高确定性分数—值可以具有附到其上的确定性分数(例如，对由用户直接提供的信息与关于用户推理出的信息具有不同的确定性分数)。数据合并器243可以选择具有较高确定性分数的值。

可以理解的是，一些字段类型具有规范化格式。例如，电话号码可以规范化为美国格式(例如，(999)555-1234)或国际格式(例如，+1-999-555-1234)。数据合并器243可以将字段值转变为规范化格式已进行比较，例如当比较主要联系人键(例如，电话号码)时，以及当检查合并列表中的重复时。

数据合并器243可以比较具有相同根本结构的两个结构值—例如，包括多个子字段(国家、州、邮政编码、街道、号码等)的地址值。如果在结构X内的非空字段的值等于结构Y中相同字段的值，即，Y包括X的所有非空字段值以及可能的一些额外字段值，则结构Y是结构X的详细版本。因此，如果A是B的详细版本并且A不等同于B，则数据合并器243将A联合到B中。

可以理解的是，数据提取器241可以根据活动所来自的IP地址推理联系人地址。这仅用于活动已经从浏览器会话到达并且用户不具有地址时。因此，数据提取器241可以根据IP地址的地理信息提取州/国家信息。在这种情况下，地址被标记为“估计的地理IP地址”。这是必需的以便不干扰将来的地址合并—由于基于IP映射的包含现有(以及可能不准确的)地址的地址字段，这可以防止后续详细(但基本不同的)地址保存到联系人数据库245中。

数据合并器243还可以处理用于合并列表的标签冲突。可以理解的是，在合并列表的情况下，可以进入到存在两个实体的情形中，一个实体来自联系人A且另一个来自联系人B，两者不同但是具有相同的标签。在这种情形下，数据合并器243可以通过在列表中以同一标签具有两者而合并列表。

因此，组合[{tag:”home”,email:”a@b.com”}]+[{tag:”home”,email:”c@d.com”}]可以创建[{tag:”home”,email:”a@b.com”}]，[{tag:”home”,email:”c@d.com”}]。这可以在合并字段被标记为“允许非唯一列表标签”时使用。

数据合并器243还可以在试图联合联系人信息时使用语言、语法或其它文本分析方法，以及向外部数据源或服务咨询。例如，用户还可以在两个活动记录中以两种不同方式书写他或她的家庭街道名称，但是指定相同的家庭号码、城市和邮政编码。联合器273在比较两个实体时可以应用文本分析(例如，探测算法)，并还可以针对给定城市和邮政编码比较两个版本的街道名称与街道名称的外部源。在这种情况下，如果两个街道类似于(但可能不同于)规范的名称并且所有其它地址数据字段具有适当的值，则联合器273可以选择规范的街道名称。

数据合并器243还可以根据登录/会话信息合并联系人信息。用户可以使用站点而不进行登录或注册，开始会话，执行作为该会话的一部分的一些活动，并稍后进行注册或登录，因此使得会话与新创建或现有的注册用户简档(包含联系人信息)相关联。

一旦用户开始会话(匿名的)，联系人识别器272就可以在会话期间(利用网络跟踪器、会话ID等)跟踪用户，并且基于用户在匿名会话期间执行的活动，联系人处理器242可以为特定匿名用户创建构造的联系人。路由器和跟踪器231还可以跨来自相同计算机的多个会话继续跟踪匿名用户。这可以通过使用持续网络(而不是会话网络跟踪器)跟踪器进行。

当用户注册时，数据合并器243可以使用构造的联系人信息来初始填充用户简档。如果用户登录，则数据合并器243可以初始地联合构造的联系人信息与现有的用户简档。可以理解的是，根据用户的站点ID合并构造的联系人信息，因为数据合并器243可能不具有任意其它主要ID(电子邮件等)来用于构造的联系人以供合并。还可以理解的是，任意这种合并可以揭露在收集到的信息中的矛盾。当合并匿名构造的联系人与现有的简档数据时，矛盾会发生并且不可避免。例如，匿名用户以姓名John Smith填充数据表格(由一些第三方应用40所显示)，然后(利用相同或单独的浏览器会话)稍后登录到姓名Jane Doe的账户下。(例如)可能的是，稍后登录实际上是第二个人使用同一计算机进行的，或者用户使用联系人表格中的假名来保存他或她的隐私。当数据合并器243合并多个匿名构造的联系人时可能发生同样的情形。

矛盾解决器274通常可以自动处理矛盾，因为大部分字段(包括主要关键字段，例如电子邮件和电话)是可能包含多个值的列表字段。这可以仅应用于同一根本站点的多次使用。不能(例如，通过将多个值合并到列表值中)解决的任意这种矛盾可以被标记，以供站点拥有者可能通过终端用户(其可以确定使用哪个值)或利用其它技术进行手动处理。

因此，可能的是，构造的联系人信息可以反映不仅单个人，而是经由相同计算机访问相同站点的用户的组合集合。

如上所讨论的，数据合并器243通常在联系人被创建或修改时根据主要ID字段(例如，电子邮件和电话号码)合并联系人。

输入是联系人记录(输入的联系人C)，其包括具有一个或多个值的一个或多个主要ID字段(例如，具有2个电子邮件和3个电话号码的联系人记录)。可以要求多个主要ID字段，因为用户可能具有(例如)家庭/工作/蜂窝电话号码和家庭/工作电子邮件，并且用户可能在联系人表格中互换地使用其中的任一个。

数据合并器243可以规范化主要关键值，并创建针对包含任意规范化主要关键值的联系人记录的查询，例如，“(电话＝P1或电话＝P2)或者(电子邮件＝E1或电子邮件＝E2)”。数据合并器243还可以限制对特定站点的联系人数据库245的查询。数据合并器243还可以查询联系人数据库245，并取回匹配的联系人列表L(其包括输入联系人C)。

如果输入联系人是(特定站点的)注册的站点成员，则数据合并器243可以从列表L中移除联系人C，并将在列表L中剩余的所有联系人合并到联系人C中。数据合并器243然后可以将更新后的联系人C保存回联系人数据库245，并从联系人数据库245中移除在列表L中剩余的所有联系人。如上所讨论的，数据合并器234可以替代地执行虚拟合并，联合所有的联系人信息(即，更新所有联系人记录以包含所有可用的信息)并标记匹配的联系人记录作为属于同一人(而不是删除“重复的”联系人记录)。例如，这在第三方应用40存储或使用联系人记录专用的内部ID时是需要的，从而删除联系人记录将使得这些第三方应用40失败。相同的处理(即，标记联系人为相关的而不是删除联系人)可以应用于在下文更详细讨论的其它情形中。

如果输入联系人不是注册的站点成员，则数据合并器243可以检查在列表L中存在多少站点成员联系人。如果存在0个站点成员，则可以从列表L中移除联系人C，并将在列表L中剩余的所有联系人合并到联系人C中。数据合并器243然后可以将更新后的联系人C保存回联系人数据库245，并从联系人数据库245中移除在列表L中剩余的所有联系人。

如果存在1个站点成员(联系人D)，则数据合并器243可以从列表L中移除联系人D，并将在列表L中剩余的所有联系人(包括联系人C)合并到联系人D中。数据合并器243然后可以将更新后的联系人D保存回联系人数据库245，并从联系人数据库245中移除在列表L中剩余的所有联系人。

如果存在两个或更多个站点成员联系人(D、D1、D2…)，则数据合并器243可以从在(D、D1、D2…)中发现的站点成员联系人中选择联系人D，并从列表L中移除联系人D。然后可以根据包括在列表L中不是站点成员的联系人的列表L创建子列表LL。数据合并器243然后可以将在列表LL上剩余的所有联系人合并到联系人D。数据合并器243然后可以将更新后的联系人D保存到联系人数据库245，并从联系人数据库245中移除在列表LL中剩余的所有联系人。

如上文针对登录合并所讨论的，可能发生数据中的矛盾。然而，因为列表值创建器275可以创建列表值字段(具有多个值)，并可以定义在联系人之间的净优先(clearprecedence)，所以在大部分情况下不会发生问题。

例如，当数据合并器243合并以下联系人时：

Contact1＝[Phone1,em1]；

Contact2＝[Phone1,em2]；

Contact3＝[Phone2,em2]；

可以生成组合的联系人：

Combined-Contact＝[Phone＝[Phone1,Phone2],Email＝[em1,em2]]。

可以理解的是，联系人数据库245可以包括来自多个源的联系人信息，并具有不同级别的许可以供使用。下述讨论设计电子邮件；然而，讨论和技术应用于如上所述用于联系用户的任意类型的信息(电话、传真、Skype ID、即时消息传送ID、社交网络ID等)。

例如，将电子邮件地址提供给站点的方式可以指示不同的许可以供使用。对电子邮件地址的一些可能的来源是：注册ID；联系人表格，简报注册和取消订阅请求。在由用户电签署的“允许的使用协议”方面，电子邮件地址还可以不同。

可以理解的是，网站建设系统30通常具有关于针对给定电子邮件的允许使用的信息。然而，网站拥有者可以具有不同的、独立的或额外的信息。例如，由于在站点中不同注册格式的本质，或者由于在系统中具有由网站从包括额外使用许可信息的不同来源输入的联系人。

数据和许可处理器244可以在于站点中使用的第三方应用40上强制实施正确的使用策略，以便帮助网站拥有者管理该信息。

因此，相关联系人的联系人记录可以包括信息的两个字段。第一字段是包含由网站根据用户活动计算出的导出的或建议的许可的网站许可字段。联系人表格仅暗示功能电子邮件，而订阅表格可以暗示循环电子邮件。第二字段是基于网站许可字段值的站点拥有者许可字段。站点拥有者可以改变网站推荐，并做他或她喜欢的任何事情，但是他或她负责超过由网站许可字段定义的许可的任何使用。

可以理解的是，网站许可字段值表示用户意图的网站的最佳知识。站点拥有者许可值是网站所分配的值，且由第三方应用40和系统的其它部分使用(例如，通过提供简报发送的第三方应用40使用)。

数据和许可处理器244可以使用这些许可字段来以多种方式定义许可。例如，数据和许可处理器244可以实现下述代码或其组合或变形的任意一个(针对电子邮件以及其它联系人ID)：

未知的—电子邮件从未知的源提取，并不能用于任何电子邮件发送。

电子邮件ID—针对注册目的提供的电子邮件。其不能用于任何的电子邮件发送，除了注册相关问题，例如，注册确认，忘记密码和怀疑安全性破坏通知。

功能电子邮件—为特定功能提供并允许一次性电子邮件。例如，购买确认电子邮件，或为特定联系人表格提供的电子邮件。

循环电子邮件—允许特定网站发送多次和周期性订阅和广告。这需要明确的订阅/批准。

可共享电子邮件—允许网站以及其合作伙伴(第三方应用40、第四方)发送多次和周期性订阅和广告。这需要明确的订阅/批准，并可以包括关于允许共享的详细信息。

选择退出—用户明确取消订阅。不向用户发送电子邮件(除了可能的选择退出通知)。

可以理解的是，数据和许可处理器244可以使用替代方法，例如许可位屏蔽(类似于在UNIX和Linux系统上使用的)或ACL(访问控制列表)机制。数据和许可处理器244还可以针对联系人信息的分离部分实现单独的许可字段(例如，电子邮件、即时消息传送者地址、社交网络ID等)。

典型的使用场景是联系人数据库245包含从联系人表格收集的第一组电子邮件和从订阅请求收集的第二组。网站可以调用简报发送第三方应用40，知道该第三方应用40将仅发送电子邮件给属于第二组的用户(其发送订阅请求)。

这种系统的优点包括对网站和网站拥有者更好的(技术和法律)保护，使其免受用户的意外垃圾邮件或私人信息滥用，以及当结合如上所述的私人数据代理234使用时实际上强制实施隐私策略。还可以确保取消订阅请求被更严格的强制实施。

因此，用户可以生成在相关网站建设系统30和任意相关第三方应用40之间的活动流。这种流可以已知为活动流。每个活动流可以用作单个联系人的信息源。如果可以确定不同的活动流来自同一源，则个体流的活动数据结构也可以合并以形成联系人。例如，单个用户可以匿名通过两个设备(如，移动设备和个人计算机)工作。这种用户可以创建可以存储消息的两个匿名流。一旦已经将流识别为与同一用户相关联，则可以将其合并。

这里所呈现的过程和显示并不固有地与任意特定计算机或其它装置相关。各种通用系统可以根据本文的教导与程序一起使用，或者其可以证明便于构造更专门的装置来执行所期望的方法。根据上述描述，用于多种这些系统的所期望的结构将清晰。另外，并不结合任意特定编程语言来描述本发明的实施例。可以理解的是，多种编程语言可以用于实现如本文所描述的本发明的教导。

除非另有明确陈述，否则如前述讨论所显然的，可以理解的是，贯穿说明书，讨论所使用的术语例如“处理”、“计算”、“运算”、“确定”等指的是计算机、计算系统或类似电子计算设备的动作和/或过程，其将表示为计算系统的寄存器和/或存储器内的物理(例如，电子)量的数据操纵和/或转换为类似地表示为在计算系统的存储器、寄存器或其它这种信息存储、传输或显示设备中的物理量的其它数据。

本发明的实施例可以包括用于执行此处的操作的装置。可以为期望的目的构造该装置，或者该装置可以包括由存储计算机中的计算机程序选择性激活或配置的通用计算机。这种计算机程序可以存储于计算机可读存储介质中，例如但不限于，任何种类的盘，包括软盘、光盘、磁光盘、只读存储器(ROM)。压缩盘只读存储器(CD-ROM)。随机存取存储器(RAM)、电可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)。磁或光卡、闪存、或适于存储电子指令并能够耦合到计算机系统总线上的任意其它类型介质。

虽然已经在本文中图示和描述了本发明的某些特征，但是本领域普通技术人员可以想到多种修改、替代、变化和等价物。因此，可以理解的是，随附权利要求意图覆盖落入本发明真实精神内的所有这些修改和变化。

Claims (22)

1.一种能够经由客户端/服务器系统在网站上实现的系统，所述客户端/服务器系统具有用于处理定义所述系统的指令的至少一个处理器，所述系统包括：

至少一个中心，用于使得双向传达信道能够在所述网站和嵌入在所述网站中的至少一个第三方应用之间、以及在所述至少一个第三方应用和至少一个第二第三方应用之间传递至少一个活动消息，其中，所述至少一个活动消息具有标准化格式；

流创建器，用于识别与所述至少一个活动消息相关联的联系人，并且用于在没有相关联的联系人存在的情况下创建数据的流；

活动协调器，用于对所述至少一个活动消息应用活动收听查询，所述至少一个活动消息是在所述网站和至少一个第三方应用之间、以及在所述至少一个第三方应用和至少一个所述第二第三方应用之间经由所述至少一个中心传达的，并且用于至少将从所述至少一个活动消息中作为所述收听查询的结果而提取的数据添加到与匿名联系人和识别出的联系人中的至少一个相关联的所述流上，并且其中所述匿名联系人和识别出的联系人中的至少一个是所述网站的用户；

联系人协调器，用于从所述流取回并分析联系人相关信息，并且充实针对联系人的先前保存的信息；以及

至少一个数据库，用于存储所述流以及所述联系人相关信息。

2.根据权利要求1所述的系统，并且其中，所述至少一个中心包括以下中的至少一个：

路由器和跟踪器，用于在所述网站和所述至少一个第三方应用之间路由和跟踪所述至少一个活动消息；

私人策略强制器，用于在所述网站和所述至少一个第三方应用之间强制实施隐私策略；

转换器和适配器，用于在所述网站和所述至少一个第三方应用之间应用预先指定的至少一个消息转换和内容适配规则；

私人数据代理，用于实现私人数据代理和私人数据替代中的至少一个，并且用于在所述网站和所述至少一个第三方应用之间强制实施用户许可字段限制；以及

验证器和签名器，用于利用所述至少一个第三方应用的输入键验证所述至少一个活动消息的签名，将与所述至少一个活动消息相关联的外部ID与所述网站的内部ID进行转换，并且用于利用所述至少一个第三方应用的输出键对输出的所述至少一个活动消息进行签名。

3.根据权利要求1所述的系统，并且其中，所述活动协调器包括以下中的至少一个：

流合并器，包括活动到流合并器和流到流合并器，所述活动到流合并器用于将数据合并到与所识别的联系人相关联的流，所述流到流合并器用于将至少两个单独的流合并到单个流；以及

日志创建器，用于将来自所述流的活动数据记录到所述至少一个数据库中。

4.根据权利要求1所述的系统，并且其中，所述联系人协调器包括以下中的至少一个：

数据提取器，用于从所述至少一个活动消息、所述流、其它联系人和外部源中的至少一个中提取联系人相关信息；

数据合并器，用于合并至少两个联系人信息记录，其中，所述联系人信息记录与同一识别出的联系人相关联，并且用于根据预先定义的合并规则将所提取的联系人相关信息合并到现有联系人的联系人相关信息中；

联系人处理器，用于创建能够识别的新联系人和匿名联系人中的至少一个，并且用于在所述网站的会话期间跟踪联系人活动；以及

数据和许可处理器，用于处理所提取的联系人相关信息的隐私保护和许可。

5.根据权利要求2所述的系统，并且其中，所述路由器和跟踪器支持利用所述至少一个第三方应用的指定的收听查询来路由所述至少一个活动消息。

6.根据权利要求3所述的系统，并且其中，所述流到流合并器包括水平流合并器和垂直流合并器中的至少一个，所述水平流合并器用于根据识别出的共同联系人合并所述至少两个单独的流，所述垂直流合并器用于在能够连接匿名联系人和注册的联系人的登录或注册时合并针对匿名联系人创建的流和与注册的联系人相关联的流。

7.根据权利要求4所述的系统，并且其中，所述数据合并器包括以下中的至少一个：

联系人识别器，用于以下中的至少一项：在所述联系人信息记录中的至少两个中定位相同的主要ID字段值，在所述联系人信息记录中的至少两个中定位当被规范化时相同的主要键字段值，利用网络跟踪器识别站点用户，利用针对注册用户的站点登录来识别站点用户，以及通过针对站点用户利用与社交网络相关联的账户的社交登录来识别站点用户；

联合器，用于利用语言、语法、文本分析以及向外部数据源和服务的咨询中的至少一个来联合联系人信息；

矛盾解决器，用于根据预先定义的规则解决联系人记录之间的矛盾；

列表值创建器，用于在所述联系人记录之间创建列表值字段，以防止所述矛盾；

水平联系人合并器，用于由于检测到的共同主要ID而合并两个不相关的联系人；以及

垂直联系人合并器，用于在能够连接匿名联系人和注册的联系人的登录或注册时合并匿名联系人和注册的联系人。

8.根据权利要求7所述的系统，并且其中，所述水平联系人合并器包括虚拟合并器，用于将至少两个联系人记录维持为分离的，并将其链接到一起，从而其被标记为表示同一联系人。

9.根据权利要求7所述的系统，并且其中，所述垂直联系人合并器包括虚拟合并器，用于将匿名联系人和注册的联系人维持为分离的，并将其链接到一起，从而其被标记为表示同一联系人。

10.根据权利要求2所述的系统，并且其中，所述用户许可字段是所述网站确定的和所述网站拥有者确定的中的至少一个。

11.根据权利要求1所述的系统，并且其中，所述标准化格式是以下中的至少一种：由预先定义的方案、继承、回叫链路定义的，由所述至少一个第三方应用进行编码和定义的，或基于外部正式的工业或事实标准。

12.一种能够经由客户端/服务器系统在网站上实现的方法，所述客户端/服务器系统具有用于处理定义所述方法的指令的至少一个处理器，所述方法包括：

使得双向传达信道能够在所述网站和嵌入在所述网站中的至少一个第三方应用之间、以及在所述至少一个第三方应用和至少一个第二第三方应用之间传递至少一个活动消息，其中，所述至少一个活动消息具有标准化格式；

识别与所述至少一个活动消息相关联的联系人，在没有相关联的联系人存在的情况下创建数据的流；

对所述至少一个活动消息应用活动收听查询，所述至少一个活动消息是在所述网站和至少一个第三方应用之间、以及在所述至少一个第三方应用和至少一个所述第二第三方应用之间传达的，并且至少将从所述至少一个活动消息中作为所述收听查询的结果而提取的数据添加到与匿名联系人和识别出的联系人中的至少一个相关联的所述流上，并且其中，所述匿名联系人和识别出的联系人中的至少一个是所述网站的用户；

从所述流取回并分析联系人相关信息，并且充实针对联系人的先前保存的信息；以及

存储所述流以及所述联系人相关信息。

13.根据权利要求12所述的方法，还包括以下中的至少一个：

在所述网站和所述至少一个第三方应用之间路由和跟踪所述至少一个活动消息；

在所述网站和所述至少一个第三方应用之间强制实施隐私策略；

在所述网站和所述至少一个第三方应用之间应用预先指定的至少一个消息转换和内容适配规则；

实现私人数据代理和私人数据替代中的至少一个，并且在所述网站和所述至少一个第三方应用之间强制实施用户许可字段限制；以及

利用所述至少一个第三方应用的输入键验证所述至少一个活动消息的签名，将与所述至少一个活动消息相关联的外部ID与所述网站的内部ID进行转换，并且利用所述至少一个第三方应用的输出键对输出的所述至少一个活动消息进行签名。

14.根据权利要求12所述的方法，并且其中，所述应用活动收听查询和所述添加包括以下中的至少一个：

将数据合并到与所识别的联系人相关联的流，并且将至少两个单独的流合并到单个流；以及

将来自所述流的活动数据记录到所述至少一个数据库中。

15.根据权利要求12所述的方法，并且其中，取回和分析包括以下中的至少一个：

从所述至少一个活动消息、所述流、其它联系人和外部源中的至少一个中提取联系人相关信息；

合并至少两个联系人信息记录，其中，所述联系人信息记录与同一所识别的联系人相关联，并且根据预先定义的合并规则将所提取的联系人相关信息合并到现有联系人的联系人相关信息中；

创建能够识别的新联系人和匿名联系人中的至少一个，并且在所述网站的会话期间跟踪联系人活动；以及

处理所提取的联系人相关信息的隐私保护和许可。

16.根据权利要求13所述的方法，并且其中，所述路由和跟踪支持利用所述至少一个第三方应用的指定的收听查询来路由所述至少一个活动消息。

17.根据权利要求14所述的方法，并且其中，所述的将所述数据合并到与所识别的联系人相关联的所述流中和将至少两个单独的流合并到单个流中包括以下中的至少一个：根据识别出的共同联系人水平合并所述至少两个单独的流，在能够连接匿名联系人和注册的联系人的登录或注册时垂直合并针对匿名联系人创建的流和与注册的联系人相关联的流。

18.根据权利要求15所述的方法，并且其中，所述的合并至少两个联系人信息记录包括以下中的至少一个：

在所述联系人信息记录中的至少两个中定位相同的主要ID字段值，在所述联系人信息记录中的至少两个中定位当被规范化时相同的主要键字段值，利用网络跟踪器识别站点用户，利用针对注册用户的站点登录来识别站点用户，以及通过针对站点用户利用与社交网络相关联的账户的社交登录来识别站点用户；

利用语言、语法、文本分析以及向外部数据源和服务的咨询中的至少一个来联合联系人信息；

根据预先定义的规则解决联系人记录之间的矛盾；

在所述联系人记录之间创建列表值字段，以防止所述矛盾；

由于检测到的共同主要ID而水平合并两个不相关的联系人；以及

在能够连接匿名联系人和注册的联系人的登录或注册时垂直合并匿名联系人和注册的联系人。

19.根据权利要求18所述的方法，并且其中，所述水平合并包括虚拟合并以将至少两个联系人记录维持为分离的，并将其链接到一起，从而其被标记为表示同一联系人。

20.根据权利要求18所述的方法，并且其中，所述垂直合并包括虚拟合并以将匿名联系人和注册的联系人维持为分离的，并将其链接到一起，从而其被标记为表示同一联系人。

21.根据权利要求13所述的方法，并且其中，所述用户许可字段是所述网站确定的和所述网站拥有者确定的中的至少一个。

22.根据权利要求12所述的方法，并且其中，所述标准化格式是以下中的至少一种：由预先定义的方案、继承、回叫链路定义的，由所述至少一个第三方应用进行编码和定义的，或基于外部正式的工业或事实标准。

Images