CN107836002B - 用于生成可交换用户简档的方法和系统 - Google Patents

Abstract

用户的简档可以被构建为具有至少一条简档条目。一种具有包括至少一个传感器的集成传感器组件的设备可以与所述用户相关联并且根据传感器配置进行操作。可以对传感器数据进行处理以提取特征。可以基于所提取特征来针对简档条目确定条目数据，使得所述简档条目可以合并所确定条目数据。可以例如通过使用隐私数据来从所构建简档中推导出可交换简档，并且作为对所述可交换简档的交换，可以接收来自第三方的补偿。

Description

用于生成可交换用户简档的方法和系统

相关申请的交叉引用

本申请要求于2015年7月10日提交的名称为“AUCTION MY DATA(拍卖我的数据)”的美国临时专利申请序列号62/190,988以及于2016 年3月16日提交的名称为“METHOD ANDSYSTEM FOR GENERATING EXCHAGEABLE USER PROFILES(用于生成可交换用户简档的方法和系统)” 的美国专利申请序列号15/071,666的优先权和权益。

技术领域

本公开总体上涉及传感器数据，并且更具体地涉及用于在构建用户 简档和获得补偿时采用传感器数据的方法和系统。

背景技术

越来越多的设备配备有传感器并且获得连接。来自这些设备的传感 器数据可以被分析并且用于作出预测和/或构建模型。这些模型将传感器数据转 换成信息和知识并且增加了价值。例如，在对手镯进行监测的活动中，使用模 型和算法将来自设备中的运动传感器的传感器数据转换成用户/穿戴者走过的 步数以及他或她行走的距离。对用户来说，这种步数和距离信息比原始传感器 信号更有价值。根据用户的生活方式来判定这种步数是否足够是一种知识。图 1示出了传感器、数据、信息、知识和智慧(S-DIKW)金字塔，其中，价值 从底部到顶部增大。

将传感器数据转换成信息和知识的模型和算法需要时间和人力来 开发。例如，为了确定运动传感器信号与步数之间的关系，必须确定如何基于 原始传感器信号来检测脚步以及步长如何取决于用户的特性，诸如，例如他或 她的身高或行走的风格/速度。在另一示例中，电子网球拍配备有使用预定义模 型来将球拍的运动转换成网球摆动类型的传感器。这种模型基于利用各种网球 拍和运动员进行的延长测试期。这使得开发模型成本很高并且耗费劳力。通过 从更多运动员和球拍获得更多传感器数据，对传感器数据的分析可以用于作出 更好的模型或更好的算法。

通常，模型和算法是由专业公司开发的。开发模型的一种替代方式 是利用人群的智慧，通过让一群人给出他们各自的(一小片段)知识。换言之， 通过从许多用户那里收集传感器数据，可以对数据中的模式或关系进行研究以 便以更加自动化的方式确定算法和模型。已经存在很多公司收集这种数据(经 常被称为‘大数据’)并且将所述数据转换成公司的价值。在几乎所有情况下， 提供数据的用户对如何处理他或她的数据以及大数据公司如何获利没有任何 看法。此外，用户和数据提供商几乎从不共享这些公司通过增加的价值而获得 的利润。

在本公开中，提出了一种方法和系统，其中，用户控制他或她所提 供的传感器数据，并且可以基于此数据生成潜在的增加价值。这意味着用户可 以确定数据发生了什么，并且意味着用户将接收基于所提供数据作出的任何货 币利益或其他补偿。用户在这些任务中得到帮助用户基于传感器数据构建用户 简档的服务提供商的辅助，并且基于此简档并根据隐私数据(其可以包括用户 的隐私设置)来获得货币化选项。图2示出了由用户产生的数据如何由服务提 供商转换成用户简档以及然后此简档可以如何用于获得补偿的流程。用户简档 可以被认为是一种资产，并且用户通过共享/交换/出售简档信息、或者根据他 或她的隐私道德来保持简档信息是私密的来控制如何使用这种资产并将其转 换为补偿。用户简档具有动态特性，这意味着用户必须继续提供(传感器)数 据以便维护他或她的简档以及相关的货币化选项。

如将在以下资料中描述的，本公开满足了这些和其他需要。

发明内容

如以下将详细描述的，本公开包括一种用于构建用户的具有至少一 条简档条目的简档的方法。所述方法可以涉及：使具有包括至少一个传感器的 集成传感器组件的第一设备与所述用户相关联；根据第一传感器配置来操作所 述传感器组件；获得来自所述传感器组件的传感器数据；确定可以从所述传感 器数据中提取的至少一个特征；对所述传感器数据进行处理以提取所述至少一 个特征；确定至少部分地取决于所述提取特征的至少一条简档条目；至少部分 地基于所述所提取特征来确定所述至少一条简档条目的条目数据；并且通过合 并所确定条目数据来生成所述用户简档的所述简档条目，使得所述简档条目至 少部分地基于来自所述集成传感器组件的传感器数据。

一方面，至少第二设备可以与所述用户相关联，所述第二设备具有 包括至少一个传感器的集成传感器组件，其中，获得传感器数据包括获得来自 所述第一设备和所述第二设备的传感器数据。

一方面，所述第一设备可以与多个用户相关联，进一步包括为所述 多个用户中的每个用户构建简档，其中，所述简档各自具有至少部分地基于来 自所述集成传感器组件的传感器数据的至少一条简档条目。

一方面，可以确定简档条目所需的至少部分地基于所述条目数据的 第二配置传感器配置，使得可以根据第二传感器配置来操作所述传感器组件。 所述第二传感器配置可以至少部分地基于用户设置。

一方面，通过合并所确定条目数据来生成所述简档条目可以包括： 将所述条目数据合并在所述用户简档的多条条目中。

一方面，可以确定所述简档条目的所确定条目数据的置信因数。 所述置信因数可以随时间推移进行调整。

一方面，所述第一传感器配置可以至少部分地基于用户设置。

一方面，所述方法还可以包括：获得对所述至少一条简档条目的请 求。确定特征可以基于所请求简档条目。进一步，所述第一传感器配置可以至 少部分地基于所述请求。

一方面，所述方法还可以包括：输入所述简档条目的条目数据并且 基于所述传感器数据来验证所输入条目数据。可以至少部分地基于所述验证来 确定所输入信息的置信因数。

一方面，所述传感器数据、简档条目或所述完整的用户简档可以被 匿名化。

一方面，所述方法还可以包括：针对所确定条目数据来确定传感器 活动，并且使所述传感器活动与所述简档条目相关联。

一方面，所述简档可以包含与用户状态有关的至少一条简档条目。

一方面，所述用户可以连接到至少一个第二用户。

一方面，所述方法还可以包括：获得与所述用户相对应的隐私数据； 建立所述简档的至少一条简档条目的多个粒度级别；至少部分地基于所述隐私 数据从所述至少一条简档条目的所述多个粒度级别中选择第一粒度级别；以及 变换所述至少一条简档条目以便匹配所选第一粒度级别。建立所述多个粒度级 别可以涉及对多个用户简档进行分析。所述多个用户简档可以选自用户组，所 述选择过程基于对至少一条简档条目的所述条目数据的比较。可以生成包括所 述至少一条经变换简档条目的可交换简档。

一方面，所述隐私数据可以是所述至少一条简档条目的用户设置、 多条简档条目的用户设置或所述简档的用户设置。此外，可以使用与所述简档 条目相关联的公开参数从所述隐私数据中推导出所述简档条目的所述粒度。所 述隐私数据还可以是从多个用户简档中推导出的，和/或所述隐私数据可以是由 服务提供商为所述简档确定的。

一方面，所述方法还可以包括：将所述可交换简档传输到第三方并 且作为交换而接收补偿。所述第三方可以由服务提供商来识别。例如，服务提 供商可以通过将经变换简档条目与请求进行匹配来识别第三方。所述补偿至少 部分地基于所述条目数据的粒度级别。还可以至少部分地基于正提供的所述补 偿来从多个实体中选择所述第三方。

一方面，所述方法还可以包括：在传输之前对所述可交换简档进行 修改。所述修改可以至少部分地基于所述第三方的特性。所述可交换简档的所 述修改还可以与所述补偿的变化有关。

一方面，可以至少部分地基于用户请求来识别所述第三方。所述用 户请求可以至少部分地基于所期望的补偿。

一方面，可以根据预设规则在与所述第三方的自动协商过程中确定 所接收到的补偿。可以在自动协商过程中确定所述可交换简档的内容。进一步 地，所述协商过程包括多个第三方。

一方面，所述可交换简档可以包括关于针对所述第三方的所述用户 的状态的信息。

一方面，所述可交换简档可以包括与连接至所述用户的第二用户有 关的至少一条简档条目。

一方面，所述方法还可以包括建立所述经变换简档条目的值。可以 至少部分地基于与至少一个先前交换的比较来建立所述经变换简档条目的值。 还可以至少部分地基于对所述经变换简档条目的请求来建立所述经变换简档 条目的值。进一步地，可以通过聚集多个经变换简档条目的所建立值来建立所 述可交换简档的值。可以通过选择第二粒度级别并且至少部分地基于所述第二 粒度级别而更新所述经变换简档条目来调整所述经变换简档条目的所建立值。 所述第二粒度级别可以与最大可获得的粒度级别相对应。

一方面，所述方法还可以包括：建立所述值与所述传感器活动之间 的关系和/或使所述所建立值与所述第一传感器配置相关。进一步，可以根据第 二传感器配置来操作所述传感器组件从而生成具有不同值的可交换简档。

一方面，所述方法还可以包括：根据至少部分地基于对先前交换的 数据库的分析的第二传感器配置来操作所述传感器组件。

一方面，所述方法还可以包括：根据至少部分地基于隐私数据的第 二传感器配置来操作所述传感器组件。

本公开还包括一种用于构建用户简档的设备，所述设备具有：传感 器组件，所述传感器组件包括与所述设备集成的至少一个传感器；以及简档模 块，所述简档模块由处理器实施，所述简档模块被配置用于：根据第一传感器 配置来操作所述传感器组件；提供来自所述传感器组件的传感器数据；确定可 以从所述传感器数据中提取的至少一个特征；对所述传感器数据进行处理以提 取所述至少一个特征；确定至少部分地取决于所提取特征的至少一条简档条 目；至少部分地基于所述所提取特征来确定所述至少一条简档条目的条目数 据；并且通过合并所确定条目数据来生成所述用户简档的所述简档条目，使得 所述简档条目可以至少部分地基于来自所述集成传感器组件的传感器数据。

一方面，所述传感器组件可以包括至少一个加速度计、陀螺仪、磁 强计、以及气压计。所述传感器组件可以包括被实施为微机电系统(MEMS) 的惯性传感器。

本公开还包括一种用于构建用户简档的服务器，所述服务器具有处 理器，所述处理器实施简档模块，所述简档模块被配置用于：确定至少部分地 取决于所提取特征的至少一条简档条目，其中，所述特征可以是从自可与所述 用户相关联的设备处获得的传感器数据中提取的，所述设备具有根据第一传感 器配置进行操作的集成传感器组件；至少部分地基于所述所提取特征来确定所 述至少一条简档条目的条目数据；以及且通过合并所确定的条目数据来生成所 述用户简档的所述简档条目，使得所述简档条目可以至少部分地基于来自所述 集成传感器组件的传感器数据。

一方面，所述简档模块可以进一步被配置用于从自所述设备处获得 的传感器数据中提取所述特征。

本公开还包括一种用于构建用户简档的系统，使得所述系统包括： 设备，所述设备具有传感器组件和简档模块，所述传感器组件包括与所述设备 集成的至少一个传感器，所述简档模块由处理器实施，所述简档模块被配置用 于根据第一传感器配置来操作所述传感器组件并且提供来自所述传感器组件 的传感器数据；以及服务器，所述服务器具有简档模块，所述简档模块由处理 器实施，所述简档模块被配置用于：确定至少部分地取决于所提取特征的至少 一条简档条目，其中，所述特征可以从自所述设备处获得的传感器数据中提取； 至少部分地基于所述所提取特征来确定所述至少一条简档条目的条目数据；并且通过合并所确定的条目数据来生成所述用户简档的简档条目，使得所述简档 条目可以至少部分地基于来自所述集成传感器组件的传感器数据。

一方面，所述服务器简档模块可以进一步被配置用于从自所述设备 处获得的传感器数据中提取所述特征。

附图说明

图1是根据实施例的使数据和信息与值相关的示意图。

图2是根据实施例示出了与用户简档有关的数据流和补偿的示意 图。

图3是根据实施例示出了用户与服务提供商之间关系的示意图。

图4是根据实施例示出了提供来自多个用户和多个设备的传感器 数据的示意图。

图5是根据实施例示出了多个服务提供商之间的一种关系的示意 图。

图6是根据实施例示出了多个服务提供商之间的另一种关系的示 意图。

图7是根据实施例示出了用户、服务提供商与第三方之间的关系的 示意图。

图8是根据实施例示出了用户简档的示例性结构的示意图。

图9是根据实施例示出了具有被配置为简档的每个类别的用户简 档的示例性结构的示意图。

图10是根据实施例示出了与用户相关联的多个简档的示意图。

图11是根据实施例示出了具有条目数据的用户简档的示例性结构 的示意图。

图12是根据实施例示出了由多个服务提供商构成的一个简档构建 结构的示意图。

图13是根据实施例示出了由多个服务提供商构成的另一种简档构 建结构的示意图。

图14是根据实施例示出了补偿对供应商利润的影响的示意图。

图15是根据实施例示出了创建货币化选项的示意图。

图16是根据实施例示出了在创建货币化选项时协调服务提供商的 示意图。

图17是根据实施例示出了用户和服务提供商的补偿的示意图。

图18是根据实施例示出了对传感器数据进行融合的示意图。

图19是根据实施例示出了对传感器数据进行部分加密的示意图。

图20是根据实施例的一种用于构建用户简档的系统的示意图。

图21是根据实施例的一种用于构建用户简档的设备的示意图。

图22是根据实施例的一种涉及对用户进行匿名化的系统的示意 图。

图23是根据实施例示出了对传感器数据进行注释的示意图。

图24是根据实施例示出了对置信因数进行调整的示意图。

图25是根据实施例示出了隐私数据对可交换简档的影响的示意 图。

图26是根据实施例示出了生成可交换简档的示意图。

图27是根据实施例示出了将传感器数据转换成简档条目的条目数 据的示意图。

图28是根据实施例示出了基于传感器配置来构建简档的示意图。

图29是根据实施例示出了完成或验证简档条目的请求的示意图。

图30是根据实施例示出了手动简档条目的示意图。

图31是根据实施例示出了使用神经网络来确定简档条目的示意 图。

图32是根据实施例示出了对用户状态进行确定的示意图。

图33是根据实施例示出了用户状态对简档值的影响的示意图。

图34是根据实施例示出了建立可交换简档的值的例程的示意图。

图35是根据实施例示出了可交换简档与补偿之间关系的示意图。

图36是根据实施例示出了构造要约的示意图。

图37是根据实施例示出了在服务提供商与第三方之间交换信息的 示意图。

图38是根据实施例示出了使用购买识别来在服务提供商与第三方 之间交换信息的示意图。

图39是根据实施例示出了涉及可交换简档的拍卖过程的示意图。

图40是根据实施例示出了向用户传送要约的示意图。

图41是根据实施例示出了涉及用户简档的推荐服务的示意图。

图42是根据实施例示出了基于推荐服务而在要约中进行选择的示 意图。

图43是根据实施例示出了基于用户简档来过滤关于服务的信息的 示意图。

图44是根据实施例示出了当创建构造块时应用本体(ontology)的 示意图。

图45是根据实施例示出了使用传感器数据来对构造块进行本体创 建的示意图。

具体实施方式

首先，应当理解的是，本公开并不限于具体例示的材料、架构、例 程、方法或结构，因为这些都可能发生变化。因此，尽管可以在对本公开的实 践或实施例中使用与本文中所描述的类似或相当的许多这类选项，但是本文中 描述了优选材料和方法。

还应当理解的是，本文中所使用的术语仅出于对本公开的特定实施 例进行描述的目的而并不旨在进行限制。

以下结合附图而阐述的具体实施方式旨在作为本公开的示例性实 施例的描述，而不旨在仅表示可以实践本公开的示例性实施例。贯穿本说明书 所使用的术语“示例性的”是指“充当示例、实例或例示”，并且不应当一定 被解释为与其他示例性实施例相比更优选或有利。为了提供对本说明书的示例 性实施例的透彻理解的目的，本具体实施方式包括特定细节。对于本领域的技 术人员将显而易见的是，可以在没有这些特定细节的情况下实践本说明书的示 例性实施例。在一些实例中，以框图形式示出了众所周知的结构和设备，以便 避免模糊本文中所呈现的示例性实施例的新颖性。

仅为了方便和清晰起见，可以相对于附图或芯片实施例使用如顶部 (top)、底部(bottom)、左(left)、右(right)、向上(up)、向下(down)、 之上(over)、上方(above)、下方(below)、下面(beneath)、后方(rear)、 背面(back)和前面(front)等方位术语。这些和类似方位术语不应被解释为 以任何方式限制本公开的范围。

在本说明书中以及在权利要求书中，将理解的是，当元件被称为“连 接至(connected to)”或“耦合至(coupled to)”另一个元件时，其可以直接 连接至或耦合至另一个元件，或者可以存在中间元件。相比而言，当元件被称 为“直接连接至(directlyconnected to)”或“直接耦合至(directly coupled to)” 另一个元件时，不存在中间元件。

随后的具体实施方式中的一些部分是关于对计算机存储器内的数 据位的操作的程序、逻辑块、处理和其他符号表示而呈现的。这些说明和表示 是数据处理领域中的技术人员向此领域中的其他技术人员最有效地传达他们 的工作的主要内容时所使用的手段。在本说明书中，程序、逻辑块、过程等被 设想为是导致期望结果的一系列前后一致的步骤或指令。所述步骤是需要对物 理量进行物理操作的步骤。通常，尽管不是必要的，这些量采用能够在计算机 系统中存储、转移、组合、比较及以其他方式操纵的电信号或磁信号的形式。

然而，应当记住的是，这些和类似术语中的全部术语将与适当的物 理数量相关联并且仅是应用于这些量上的方便标签。除非另外特别说明，否则 如从以下讨论中明显的，应当理解的是，贯穿本说明书，利用如“访问 (accessing)”、“接收(receiving)”、“发送(sending)”、“使用(using)”、 “选择(selecting)”、“确定(determining)”“归一化(normalizing)”、 “相乘(multiplying)”、“求平均(averaging)”、“监测(monitoring)”、“比较(comparing)”、“应用(applying)”、“更新(updating)”、“测 量(measuring)”、“推导(deriving)”等术语来进行的讨论是指计算机系 统或类似电子计算设备的动作和过程，所述计算机系统或类似电子计算设备对 表示为计算机系统的寄存器和存储器内的物理(电子)量的数据进行操纵并且 将其转换成类似地表示为计算机系统存储器或寄存器或其他这种信息存储设 备、传输设备或显示设备内的物理量的其他数据。

可以在处理器可执行指令的一般情境中讨论本文中所描述的实施 例，所述指令驻留于由一个或多个计算机或其他设备执行的如程序模块等某种 形式的非暂态处理器可读存储介质上。一般地，程序模块包括执行特定任务或 实施特定抽象数据类型的例程、程序、对象、部件、数据结构等。程序模块的 功能可以如所期望的那样结合或分布在各种实施例中。

在附图中，可以将单个框描述为执行一项或多项功能；然而，在实 际实践中，由此块执行的所述一项或多项功能可以在单个部件中或跨多个部件 来执行和/或可以使用硬件、使用软件或使用硬件和软件的组合来执行。为了清 楚地说明硬件和软件的这种可交换性，以上已经总体上就它们的功能描述了各 种说明性部件、块、模块、电路和步骤。将这种功能实施为硬件还是软件取决 于强加于整个系统上的特定应用约束和设计约束。技术人员可针对每个特定应 用以不同方式来实施所描述的功能，但是这种实施决策不应当被解释为致使脱 离本公开的范围。而且，示例性无线通信设备可以包括除了所示出的部件之外的部件，包括如处理器、存储器等众所周知的部件。

除非被具体描述为以特定方式实施，可以在硬件、软件、固件或其 任何组合中实施本文中所描述的技术。被描述为模块或部件的任何特征还可以 在集成逻辑设备中一起实施或者被单独实施为分立但彼此协作的逻辑设备。如 果在软件中实施，则所述技术可以至少部分地通过包括指令的非暂态处理器可 读存储介质来实现，所述指令当被执行时执行以上所描述的方法中的一种或多 种方法。非暂态处理器可读数据存储介质可以形成可包括封装材料的计算机程 序产品的一部分。

非暂态处理器可读存储介质可以包括：随机存取存储器(RAM) (如同步动态随机存取存储器(SDRAM))、只读存储器(ROM)、非易失 性随机存取存储器(NVRAM)、电可擦除可编程只读存储器(EEPROM)、 闪存、其他已知存储介质等。另外地或可替代地，所述技术可以至少部分地通 过处理器可读通信介质来实现，所述处理器可读通信介质承载或传达代码，所 述代码采用指令或数据结构的形式并且可以被计算机或其他处理器访问、读取 和/或执行。例如，可以采用载波来承载计算机可读电子数据，比如，用于传输 和接收电子邮件或用于访问如互联网或局域网(LAN)等网络的数据。当然， 在不背离所请求保护的主题的范围和精神的情况下，可以对这种配置进行许多 修改。

结合本文中所公开的实施例而描述的各种说明性逻辑块、模块、电 路和指令可由一个或多个处理器执行，比如，一个或多个运动处理单元(MPU)、 数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、专用指令 集处理器(ASIP)、现场可编程门阵列(FPGA)或其他等效集成或离散逻辑 电路。如本文中所使用的术语“处理器”可以指前述结构或适合于实施本文中 所描述的技术的任何其他结构中的任一者。此类结构的一个示例可以是神经网 络结构。此外，在一些方面，可以在按本文中所描述的方式配置的专用软件模 块或硬件模块内提供本文中所描述的功能。而且，可以在一个或多个电路或逻 辑元件中完全实施所述技术。通用处理器可以是微处理器，但在替代方案中， 所述处理器可以是任何常规处理器、控制器、微控制器、或状态机。处理器还 可以被实施为计算设备的组合，例如，MPU和微处理器的组合、多个微处理 器、结合MPU核的一个或多个微处理器或者任何其他这种配置。

可以在软件中将以上所描述的实施例和技术实施为各种互连功能 块或不同软件模块。然而，这并没有必要，并且可能存在这些功能块或模块等 效地聚集为单个逻辑设备、程序或操作而没有清楚界限的情况。在任何情况下， 实施以上所描述的实施例的功能块和软件模块、或者接口的特征可由其自身实 施，或者在硬件或软件中与其他操作组合地实施(或者完全在设备内，或者结 合设备以及如服务器等与所述设备通信的其他处理器使能的设备)。

除非另有限定，本文中所使用的所有技术术语和科学术语与本公开 相关的领域的技术人员共同理解的意义相同的意义。

最后，除非文中另外明确指明，如在本说明书和所附权利要求书中 所使用的，单数形式的“一种”、“一个”以及“所述”包括复数对象。

定义

用户——用户是用户简档所指的人或法人，意味着简档及其 简档条目以某种方式与用户有关或相对应。用户可以订阅用于生成和构建用户 简档的服务提供商的服务。对于本文档的剩余部分，服务提供商将被称为SP。 用户向SP提供传感器数据，所述SP然后为用户构建简档，并且向用户提供补 偿，比如，货币化选项或货币利益(图3)。用户可以对SP保持匿名，并且 可以通过简单的用户ID(号码)或用户名来识别。如果用户想要保持匿名，则SP必须确保用户的身份不会基于用户提供的数据而被重建。

用户可以是向SP提供他或她的个人(传感器)数据的单个 人。用户可以是一组人，或者代表一组人。例如，用户可以是一个家庭的父亲 或母亲，其代表了可以包括孩子或者甚至宠物的整个家庭。在另一个示例中， 用户可以是医生或护士，代表一组患者。在进一步的示例中，用户可以是农民， 代表他的牲畜，所述牲畜配备有用于例如健康或生产力监测的传感器。一般而 言，用户是代表并且拥有/生成数据的集合以及由此数据构建的简档的实体。

图4示出了一个用户如何可以控制用户组的数据、简档和补 偿的示例。在此情况下，用户1是着眼于SP的用户，因为他或她控制从其他 用户到SP的数据传送以及从SP朝向其他用户的任何潜在的补偿。此用户可以 对其他用户的简档生成和简档设置(比如，例如隐私数据和设置)进行控制。 还可以在其他/次级用户与SP之间直接交换一些数据或补偿，但是这种交换可 以在主用户的控制下设置。

服务提供商——服务提供商是对向用户提供的服务进行控 制和协调的人或实体。SP基于所提供的数据来构建用户简档，并且然后基于 所述简档为用户安排补偿(比如，货币化选项)。货币化选项可以例如采用专 门要约(offer)或折扣的形式来从供应商购买特定的产品或服务。SP构造并 且维护可以为订阅所述服务的用户提供货币化选项的第三方(例如，供应商) 的列表或数据库。

作为提供他或她的传感器数据的交换，用户获得两项服务： 1)创建用户简档；以及2)获得某种形式的补偿的可能性，例如，通过使用货 币化选项。这两项服务都可以由同一服务提供商来提供。然而，这些服务还可 以被分开并且由不同的服务提供商来提供。在此情况下，第一服务提供商接收 用户数据并且构建传送至用户的用户简档。然后，用户可以向第二服务提供商 提出此简档，所述第二服务提供商然后将基于所述简档(图5)来为用户寻找 货币化选项。可替代地，构建用户简档的第一SP可以将所述简档传送至安排 货币化选项(图6)的第二SP。

服务提供商可以充当本地服务、远程服务或这两者的组合。 例如，SP可以对基于云的服务器进行操作，并且用户将传感器数据传输到生 成用户简档的此服务器。然后，可以将所生成或更新的简档信息传输至用户。 在这种使用远程服务的实施例中，SP可以被称为远程SP。可替代地，服务提 供商可以采用本地服务的形式，比如，在与用户相关联的设备上运行的一个或 多个应用。在此示例中，SP将创建例如用户可以在他或她的设备之一上安装 的软件解决方案或应用。然后，此软件将接收传感器数据作为输入并且构建简 档。在此情况下，软件或应用代表了SP。在这类实施例中，SP可以被称为本 地SP(采用软件或应用的形式)。在一些实施例中，可以存在远程服务部件 和本地服务部件的组合，在其中，一些处理可以由SP提供的软件来本地执行， 并且一些处理可以在SP服务器上远程执行。

供应商——供应商是第三方，比如，可以基于由SP向供应 商提供的简档信息来向用户提供补偿的人或实体。例如，供应商可以是基于简 档信息来提出个人化要约或折扣的商店或人。在实际的供应商与SP之间可以 存在中间级。这些中间级可以是公司，比如，例如活动管理方或计算机平台(比 如，例如实时报价服务器)。在这些情况下，术语供应商(Vendor)将适用于 充当至实际供应商的接口的这些后者经纪商。图7中示出了用户、SP与供应 商/第三方之间的三角关系。用户将数据提供给SP，所述SP然后将所述数据转 换成用户简档。SP基于所述简档将关于用户的信息提供给供应商，并且然后 供应商作为交换而将补偿(比如，货币化选项)提供给用户。所述信息可以帮 助供应商基于所述简档来向用户提供最佳可能服务。此信息可能包含与用户 (或任何他或她的联系人)可能带给供应商的潜在收入有关的信息。贯穿本文 档将使用术语供应商或第三方来指示向用户提供某种补偿、货币化选项或货币 利益或奖励的人或实体。供应商当然可以是用户可以获得某种货币利益的商 店、商场、服务提供商等。供应商还可以是某种(官方)组织。例如，(本地) 政府可以向用户安排能量补贴来交换信息并且深入了解他或她的能量使用情 况。

供应商订阅SP的服务，并且例如采用供应商简档的形式向 SP提供关于供应商的信息，所述供应商简档描述了供应商必须提供的服务或 商品。通过订阅服务，SP将让供应商与所选的用户进行联系。SP可以通过提 供工具或典型的示例简档来帮助供应商构建供应商简档。SP还可以向供应商 提供对所述供应商的竞争者的供应商简档的深入了解以便帮助构建供应商简 档。供应商还可以向SP提供期望客户的简档，这将帮助SP将目标对准正确的 用户。SP可以帮助供应商基于例如在供应商域中的过去交易或者与供应商的 竞争者的过去交易来构建期望的用户简档。基于由供应商提供的信息，SP构 造并维护供应商的可以为用户提供货币化选项的数据库。

用户可以对供应商保持匿名。可替代地，例如当使用采用对 购买进行折扣的形式的货币化选项时，可以将用户的(一部分)身份透漏给供 应商以供识别的目的。在一些实施例中，在用户接受要约之前不会透漏他/她的 身份的任何要素。

数据——根据由用户提供给SP的数据来建立简档。此数据 可以是所提供的关于用户、用户动作、用户行为、用户偏好等的任何种类的信 息。此数据可以由用户手动输入，但是还可以来自源自用户的‘在线生活’或 用户的‘离线生活’的其他来源。在线数据包含来自用户在线使用情况的所有 数据或信息，如例如他或她的互联网使用情况或电子邮件。离线数据包含可以 由某种传感器捕获的与用户的在线使用情况无关的所有数据或信息。因此，离 线数据还可以被称为传感器数据。传感器数据可以与用户本身有关，但是还可 以与他或她的环境(例如，房屋)或他或她使用的物品(例如，汽车)有关。 可以通过使具有包括至少一个传感器的集成传感器组件的设备与用户相关联 来获得传感器数据。设备可以与单个用户或者一组多个用户相关联，这意味着 所提供的传感器数据可以用于多个简档。

一般而言，应当将可以用于构建用户简档的任何类型的数据 或信息考虑在内。在此情况下，来自用户的任何支付信息(比如，例如信用卡 或账单)都可以帮助构建简档，因为用户购买的产品透漏了关于用户的相当一 些信息。下文将详细讨论数据，并且更具体的传感器数据。

简档和简档条目——基于用户提供给SP的数据，SP构建简 档。简档是对简档拥有者的特性、习惯、过去动作等的声明、事实、描述的集 合。简档的每一项被称为简档条目。注意的是，至少一条简档条目可以依赖于 传感器数据。换言之，简档表示用户的数字描述，同时保持用户匿名。用户简 档的目的是能够向供应商以及可能潜在地向用户提供个人化货币化选项的第 三方匿名地描述用户。

可以以任何适当的方式组织简档，比如，例如帮助给出不同 简档条目之间的关系概览的树状结构。简档条目可以直接与用户有关，但是还 可以与例如用户的房屋或汽车有关。以下将进一步详细讨论这些不同的简档类 型或简档类别。图8示出了简档被划分成不同的类别的示例用户简档结构，每 个类别具有其条目。图9示出了每个类别可以被自身认为是一个简档的示例结 构，并且简档集合可以被称为用户的简档组合。简档条目的内容(即，包含在 简档条目中的信息)可以被称为条目数据。条目数据可以采用任何形式，例如，采用简单文本的形式，或者采用包含原始传感器数据或经处理传感器数据的形 式。

简档表示用户愿意向第三方显示的他或她的描述。另外，如 果需要的话，简档可以包含访问第三方的服务所需的证书或其他信息。当与不 同的第三方进行交易或联系时，用户可能想要由不同的(个人)简档来代表。 因此，用户可以具有包括描述用户的不同条目的多个(个人的)简档，如在图 10中所示出的。这些不同的简档可能具有共同的简档和条目，所述简档和条目 可能处于不同的细节级别。第三方可以例如是供应商、在线供应商或实体供应 商，但是其可以是用户与之联系并且其中透漏一些(简档)信息的任何实体。 例如，用户可以使用不同的实体进行在线购买、互联网浏览或使用应用。不同 的简档可以表示某些类别，比如，例如体育或财务，并且对应的简档是根据所 讨论的第三方来选择的。例如，用户可以使用第一简档连接至体育应用、使用 第二简档连接至音乐应用、并且使用第三简档连接至社交网络应用。不同的应 用可以组合在一起以便使用同一个简档。所述选择可以由用户手动完成，其中， 用户从图形表示的列表或组中选择某个简档或数字描述。所述选择还可以在通 知或不通知用户的情况下由SP自动完成。在此情况下，SP可以基于首要简档 或主简档来生成对应的子简档。一个优点是用户保持对于第三方而言是未知 的，并且第三方仅访问用户愿意共享的相关信息。

图11示出了具有条目数据和其他信息的示例简档结构。所 述信息在不同的细节级别上可用。例如，用户的年龄可以作为年龄范围(例如， 30-40岁)、或确切年龄(35岁)、或者甚至出生日期(例如，1980年3月4 日)可用。透漏给第三方(比如，供应商)的细节取决于用户的隐私设置，这 将在下文中详细讨论。细节级别也可以被同义地称为条目数据的粒度或粒度级 别，其中，较高粒度对应于较高细节级别，并且较低粒度对应于较低细节级别。简档条目可以包含处于单一粒度级别(例如，最高可能粒度)或者处于不同的 粒度水平(例如，从较高粒度到较低粒度变化)的条目数据。

简档还可以包含关于用户的联系人的信息，比如他或她的朋 友、家庭、熟人、工作关系等。如果这些联系人也订阅SP的服务，则联系人 的简档条目可能仅仅是用于SP的参考号或名称。用户可以指示哪个简档条目 可以通过他或她的联系人来共享，并且处于哪个细节级别。这些设置可以包括 在用户的隐私数据内。如果联系人没有订阅SP的服务，则联系人的简档条目 可以包含具有关于所述联系人的信息的一些实际的简档条目，例如，与用户的 共同之处、用户与联系人多久见面一次等。相应地，用户连接到至少一个第二 用户。用户简档可以包含涉及所述至少一个第二用户的简档条目。

用户的简档可以被认为是使用与用户相关联的设备从用户 的数据建立的资产。用户可以将简档作为资产来进行管理和保护。可以通过补 偿和货币化选项来获得此资产的值。在下文关于数据和简档的值的专门部分中 详细讨论了简档的值。

简档可以是由单个SP构建的，这意味着用户将他或她的所 有数据发送至一个SP。可替代地，简档可以是由若干SP构建的。在此情况下， 用户可以将所有数据发送至所有SP，或者可以将所选数据发送至某些SP(图 12)。例如，用户可以将运动数据发送至专用于运动处理的SP，并且另一SP (比如，例如作为银行)可以处理财务数据。需要协调来确定哪个SP做什么， 并解决任何冲突。这种协调可以由用户或所选择的SP来完成。在实施例中， 一个中心SP可以接收所有数据，并且可以将一些所选数据转发至可以专用于 处理数据的其他SP(图13)。在此情况下，主SP进行所有协调。

补偿和货币化选项——基于所构建简档，SP可以能够为用户 生成和安排某种补偿，例如采用货币化选项的形式。术语货币化选项是指用户 可以基于所述简档而获得的任何财务利益。术语补偿和货币化选项可以互换使 用。例如，如果用户想要购买某个物品，则SP可以基于SP提供给供应商的简 档信息来查找愿意给用户对此物品的个人化折扣的第三方或供应商。以个人化 价格购买物品的这种机会被认为是货币化选项。折扣量可以被称为补偿(图 14)。来自SP能够向一些供应商提供的简档的信息越多，可能愿意提供折扣 的供应商越多。简档的覆盖范围越广，用户可以由于购买不同的物品、商品或 服务而获利越多。SP构造并且维护可以为订阅服务的用户提供补偿选项的供 应商和第三方的列表或数据库。供应商数据库越大，SP可以向用户的集合提 供的选项越多。

可以由单个SP来提供货币化选项。这意味着SP将简档作为 用户的资产进行管理，并且试图使用户的货币化选项和货币利益最大化。类似 于在图12和图13中由若干SP来构建简档，货币化选项也可以由若干SP来创 建。在一个示例中，用户可以将简档传送至每个SP，并且SP将试图获得针对 用户的最佳货币化选项(图15)。SP可以专用于特定领域，并且用户可以仅 向SP发送简档的相关部分。用户可以手动选择相关SP，或者所述选择可以是通过在与用户相关联的设备中运行的软件或应用来自动完成的。在一些实施例 中，SP还可以进行竞争以便提供最佳补偿。在此情况下，所述信息被提供至 多个竞争的SP。所有的SP将所获得的货币化选项传送至用户，然后所述用户 必须对不同的要约进行协调。这些SP可能已经对简档构建做出了贡献。在另 一个实施例中，一个中心SP将处理与用户的通信，但是此SP可以使用其他(专 用)SP的服务来创建货币化选项(图16)。中心SP将确保这些SP接收到相 关简档信息。中心SP将进行对不同货币化选项的协调。

当用户利用货币化选项并且以个人化价格购买物品或服务 时，SP也可以获得奖励，因为SP为用户提供了货币化选项并且使得供应商能 够完成销售(图17)。给SP的奖励还可以被认为是由供应商或者用户必须提 供给SP的费用或佣金。对于本文档的剩余部分，我们将对SP的奖励称为SP 佣金。可以由第三方或供应商直接应用用户补偿或折扣，因此用户支付降低的 价格。在此情况下，供应商将SP佣金传送至SP(图中的实线箭头)。可以立 即传送或者以预定次数(例如，一月一次)传送SP佣金。可替代地，可以由 SP将用户折扣传送至用户。在此情况下，用户最初支付全额价格，并且供应 商将用户折扣和SP佣金传送至SP。SP然后将用户折扣以例如货币的形式传 送至用户(图中的虚线箭头)。此传送可以立即进行或在稍后的时间进行。稍 后的策略具有以下优点：用户将由SP传送的货币看作为传感器数据的价值。

传感器数据

定义——传感器数据是可以由电子设备检测到的数据。可以 使用测量任何类型的物理、化学或生物参数或数量的任何传感器。具有包括至 少一个传感器的集成传感器组件的设备可以与用户相关联以便获得传感器数 据。术语传感器和传感器组件可以互换使用。示例传感器可以包括：加速度计、 陀螺仪、磁力计、压力传感器、温度传感器、位置传感器(例如，全球定位系 统(GPS))、麦克风、光传感器、生物特征传感器、湿度传感器、气体传感 器等。这些传感器可以是MEMS传感器或者任何其他类型的传感器技术。提 供给SP的传感器数据可以是来自传感器的原始信号，或者可以由具有集成传 感器组件的设备或任何其他设备来进行预处理或变换。

传感器数据可以来自单个传感器，或者所述数据可以基于来 自多个传感器的传感器融合。这些传感器可以一起被集成在传感器组件中，或 者可以被分布在不同的组件上。融合可能涉及来自一个设备的不同传感器、或 者来自不同设备的多个传感器。图18示出了使用多个传感器和设备的融合的 不同示例。

传感器不一定是该词的传统意义上的传感器，在传统意义 上，传感器测量任何类型的物理、化学或生物信号。传感器可能不被设计用于 感测任何具体事物。在一个示例中，通过仅知道牙刷是开启还是关闭，电动牙 刷可以被认为是传感器，因为如果用户正在刷牙，则进行此‘感测’。

在另一个示例中，信用卡读卡器可以被认为是传感器，因为 其检测到用户为什么产品以及何地和何时支付了多少钱。更一般而言，可以使 用当用户进行支付时所检测到的任何数据。

提供任何类型的数据或信息的任何传感器、传感器组件、设 备、装置、机器、工具、应用等都可以进一步被称为数据集合对象(DCO)。 由DCO所收集的数据与数据集合事件(DCE)有关。单个事件可以由若干DCO 来覆盖。例如，去跑步(DCE)的用户可以由GPS(DCO 1)和活动手镯(DCO 2)来覆盖。

传感器数据表示经处理的传感器数据。例如，用户已经走过 的步数、用户正在进行的活动、每分钟心跳数等。数据可以直接来自设备，或 者可以已经由其它服务(比如，runkeeper、fitbit等)进行处理。在此情况下， 用户将帮助SP获得对可能存储在其他地方的传感器数据的访问。在此情况下， 对数据进行预处理并且输出经处理的数据的服务可以被认为是DCO。这意味 着提供可以用于推断用户的简档的关于用户的数据或信息的任何服务都可以 被认为是DCO。例如，来自可以将与用户有关的数据提供给SP的服务 runkeeper、fitbit、facebook、linked等的任何账户都可以被认为是DCO。这还 意味着：例如，处理用户的支付数据并且提供支付以及产品购买概况的银行也 可以被认为是DCO。

传感器数据可以来自多个设备，比如，智能电话、手表或手 镯、电子运动设备(例如，网球拍)、所连接的秤、家庭自动化系统、所连接 的汽车……

传感器数据可以与用户直接有关，但是还可以与用户间接有 关。例如，传感器数据可以与用户的房屋(比如，例如室温、能量使用情况、 灯光功能)有关。可替代地，传感器数据可以与用户的汽车有关，比如，平均 油耗、发动机温度、胎压……。可以对传感器数据进行分类以便表示这些不同 的类别(个人、房屋、汽车……)。可以至少基于例如传感器数据本身、传感 器类型、提供传感器数据的信道等之一来自动地检测所述类别。用户拥有的以 及具有可以被测量的感兴趣的属性的任何物品都可以产生某种(传感器)数据。

可以对传感器数据进行注释，这意味着所述传感器数据伴有 描述传感器数据的信息。所述注释可以由单个用户或者一群用户来完成。这种 注释的示例在于2016年2月3日提交的题为“Method,Device and System for Annotated Capture of Sensor Data andCrowd Modelling of Activities(用于传感器 数据的经注释捕获以及活动的人群建模的方法、设备和系统)”的美国专利申 请序列号14/909,961中进行了描述，所述美国专利申请通过引用以其全部内容 结合在此。可以例如使用其他传感器来对传感器数据自动地注释。例如，当用 户正行走或跑步时，来自他或她的活动监测手镯的传感器数据可以与来自GPS的指示轨迹、距离或速度的传感器数据组合。在此情况下，GPS数据被认为是 数据的注释部分，因为其帮助确定了来自活动手镯的运动信号与用户跑步的实 际距离之间的关系。还可以由用户对传感器数据进行手动注释。例如，正使用 他的电子球拍打网球的用户可以提供来自球拍的传感器数据，并且还可以指示 他或她正在执行哪种类型的网球摆动(反手、正手、服务……)。注释可以在 用户主动时或者由SP请求时发生。注释可以采用书面、音频或视频的形式。 伴随传感器数据以便获得对所述数据的意图的更多深入了解的任何形式的数 据都可以被认为是注释。

当用户执行注释时，用户提供附加数据/信息。此数据源自用 户的感测，并且因此还可以被称为某种传感器数据。来自用户的感受的‘传感 器数据’由用户的大脑进行处理，并且然后当用户执行注释时被传送至SP。

依据此推理，我们认为用户的观察结果也是传感器数据。这 种人体传感器数据可以与用户观察到的事物(比如，上述网球摆动类型)有关。 可替代地，传感器数据可以与用户本身有关。例如，用户可以感受他或她是冷、 暖、疲惫、开心、伤心、感觉良好……这种人体传感器数据还可以与用户已经 经历的产品或服务有关，并且可以延伸到偏好或口味。例如，用户可以填写关 于产品或服务的问卷，可能是应SP或供应商的请求。

可以在合同基础上提供传感器数据。例如，如果用户参与向 SP(或者制造商)提供所产生的传感器数据，则用户可以得到对能够提供传感 器数据的产品的特殊折扣或其他利益。可以直接与SP签订合同，或者可以与 供应商或制造商签订合同，然后所述供应商或制造商与SP签订数据合同。例 如，如果用户愿意与SP和制造商共享由汽车产生的传感器数据中的至少一些， 则用户可以购买汽车，并且将得到采用折扣、特殊服务、免费特殊特征等形式 的特殊利益。

提供传感器数据——将传感器数据从用户传输至远程SP的 方法取决于传感器并且取决于结合有传感器或传感器组件的设备。例如，如果 传感器数据源自结合在具有能够与SP通信的无线通信装置的(移动)设备中 的传感器，则可以从设备本身直接发送传感器数据。SP将向用户提供工具或 应用以便使数据匿名化，并且将伴有匿名用户ID的传感器数据传送至SP。例 如，对于在智能电话中的传感器或者与智能电话直接通信的设备，情况可能如 此。在本地SP的情况下，传感器数据被传输至运行SP软件或应用的设备。此 设备可以是用户的移动设备之一(比如，例如用户的智能电话)或者用户的非 移动设备之一(比如，例如用户的家用服务器)。此外，设备可以能够与已经 提供软件或应用的实际(远程)SP进行通信例如以供更新或共享处理。

一些传感器可以在仅具有短距离通信(比如，例如蓝牙通信) 的设备中。在此情况下，传感器设备可以与移动设备(比如，例如智能电话) 通信，所述移动设备能够与远程SP进行通信，或者如果此设备充当本地SP， 则移动设备本身进行所述处理。移动设备可以传输来自在用户身上或靠近所述 用户并且与所述移动设备通信的其他(可穿戴)传感器设备的传感器数据。可 穿戴设备可以将原始数据传输至移动设备，或者可以在发送传感器数据之前执 行某种处理。移动电话还可以在将数据传输至远程SP之前对来自一个或多个 其他设备的传感器数据进行处理。

如果传感器设备是不具有任何无线通信装置的便携式设备， 则用户将必须将传感器数据手动地传送至能够传送传感器数据的另一设备。

如果存在与SP进行通信的装置，则可以将间接链接至用户 的传感器数据(比如来自与像房屋或汽车等物品有关的传感器的数据)直接发 送至远程SP。在此情况下，房屋或汽车可以具有以下本地处理能力：从相关 传感器收集信息并且然后使用一些识别方法将所述传感器数据传输至SP以便 将数据链接至用户。SP可以提供工具与这些设备或传感器相集成以便使数据 匿名化并且将数据与用户相关联。物品的传感器还可以将数据发送至另一所述 用户的设备(比如，例如智能电话)，所述设备然后负责与远程SP进行所需 通信。类似地，在本地SP的情况下，传感器数据将被发送至适当的设备。

用户可以直接提供传感器数据，或者可以由第三方提供传感 器数据。例如，用户可以将来自他或她的活动手镯的传感器数据上载至第三方 (如Fitbit或Runkeeper)。第三方可以对传感器数据进行处理，并且向用户提 供活动报告。用户然后可以例如通过向SP注册第三方并且提供对信息的访问 来授予服务提供商对信息的访问。可替代地，SP可以在用户许可以及与第三 方合作的情况下直接对在第三方处的数据进行访问。

在受限情况下，某个用户的传感器数据也可能来自另一个用 户。例如，具有集成传感器组件的设备可以与多个用户相关联，从而使得可以 至少部分地基于来自集成传感器组件的传感器数据而为所述多个用户中的每 一个用户构建简档，每个简档具有至少一条简档条目。作为说明，用户可以与 朋友一起跑步，并且所述朋友可以能够从所述用户可能不具有的设备(比如， 例如GPS)中提供附加传感器数据。在此情况下，关于轨迹的信息可以被两个 用户使用。这可以由将传感器数据直接传送至用户的所述朋友来完成，或者所述朋友和用户可以通知SP：特定传感器数据适用于这两个用户并且应当被从 一个用户复制到另一用户。所复制的传感器数据可能对用户的状态贡献较小的 权重，因为数据不是源自他或她的传感器。例如通过检测相同数据集的多个部 分，SP必须小心以避免欺诈性的复制实践。

可以在能够将数据立即传输至SP的设备中产生传感器数据。 用户可以决定在线或实时传送数据，但是这可能对用户带来附加成本。SP还 可以与电话载体或网络运营商(进一步地被称为载体)达成协议以便获得特殊 费率或特殊条件来在高峰时间以外发送传感器数据。载体可以根据所述交易来 接收佣金。在此情况下，用户可以存储并且可能压缩传感器数据，直到出了高 峰时间。高峰时间可以是预设时间，或者可以由载体以灵活方式决定。载体可 以对传感器数据何时发送进行直接控制(在SP和用户批准的情况下)。

在任何情况下，无论什么方法用于将传感器数据发送至SP， 传感器数据都可以被匿名化并且伴有用户ID。传感器数据应具有一定意义， 而不只是一系列的零和一。这意味着SP需要知道例如数据指代什么、数据处 于什么单元、使用了什么传感器……这种类型的信息可以来自文件头，或者可 以与传感器数据并行发送。

传感器简档——用户可以具有能够提供传感器数据的多个 传感器或传感器组件。每个传感器将具有特定设置，所述设置可能例如取决于 请求数据的应用/活动、取决于情境或者取决于节能模式。不同传感器的传感器 设置及其各种相关性的集合可以被称为传感器简档或传感器配置。与用户相关 联的具有集成传感器组件的设备可以根据期望的配置进行操作以便获得传感 器数据。传感器简档可以包括来自不同设备的传感器。术语传感器配置和传感 器简档可以互换使用。

每个传感器简档将产生正生成的传感器信号的特定组合。还 可以由用户对这些传感器简档进行手动设置。可替代地，SP可以设置传感器 简档，或者可以向用户提出最优传感器简档。SP可以根据包括用户的隐私设 置的隐私数据来调整传感器简档，从而使得在不同或经修改的传感器配置下操 作传感器组件。根据SP正想要检测、完成或验证的用户简档或简档条目，SP 还可以调整传感器简档，从而使得可以确定简档条目所需的至少部分地基于条 目数据的配置，并且然后可以根据所述传感器配置来操作传感器组件。还可以 针对功率效率或者针对简档构建最大化来优化传感器简档。基于对用于其他用 户的简档构建的分析，可以针对最大值或补偿功率比来优化传感器简档；使用 消耗最少电池和处理能力的传感器简档来获得用户简档的最高可能值/补偿。传 感器简档可以是动态的并且随用户的活动、行为等任何变化而变化。更进一步 地，传感器配置可以与可能为简档条目所建立的值或期望值有关，如以下所描 述的。通过根据不同的传感器配置来操作传感器组件，简档条目的值可以根据 期望而变化。

传感器加密——可以对传感器数据进行加密。当数据被发送 至远程SP时可以发生加密，并且SP可以存储加密的数据。在正发送数据的用 户设备上运行的SP应用可以接收来自传感器的未加密数据，并且然后在发送 之前对数据进行加密。这意味着在设备内数据是未加密的。在一些实施例中， 可以使用同态加密，这使得能够在无需解密的情况下执行计算。

还可以在较低级别上对传感器数据进行加密。可以直接在传 感器级别上(例如，在可能与单个芯片或封装体上的实际传感器结合的传感器 处理器上)对传感器数据进行加密。在此情况下，在不具有解密密钥或信息的 情况下传感器数据在设备内不可使用。

在传感器级别上完成对传感器数据的加密意味着所述数据 对于可能想要使用所述数据的所有程序、应用等都是加密的。如果传感器或包 含所述传感器的设备仅向SP提供数据，则在传感器处的加密不会造成任何问 题。然而，如果其他程序或应用在包含传感器的设备上运行，则这些程序或应 用在不能对数据进行解密或者不具有使用数据的许可的情况下可能无法使用 传感器数据。例如，如果在智能电话中在传感器级别上对数据进行加密，则电 话的OS和应用将不能使用传感器数据。如果用户控制加密设置，则这意味着 用户控制哪个程序能够使用数据，而无需OS在中间或干预。

在一个示例实施例中，可以在传感器级别上对传感器数据进 行部分地加密。这意味着用户控制对传感器数据加密到什么程度、以及在不知 道如何对数据进行解密的情况下可以由其他程序或应用使用什么程度的数据。 例如，对于GPS传感器，绝对GPS坐标可以保持加密，而相对GPS坐标可以 是未加密的。因此，可以由可能在OS控制下的任何程序或应用使用相对坐标， 并且可以仅在用户的专门许可下使用绝对坐标。这种类型的部分加密可能对用 户的传感器数据的隐私具有很大影响。例如，当用户从他或她生活的地方开始 跑步、并且不想透漏他或她的位置、但是仍然想要使用GPS跟踪他或她跑步 的线路时。用户可以决定任何程序或服务都不可以使用绝对GPS坐标，或者 绝对GPS坐标在传感器上被加密并且可以传输至SP，所述SP可以将所述加 密坐标用于简档信息。其他程序或服务(比如，例如OS、Runkeeper等)然后 可以使用相对GPS坐标。在部分加密的另一示例中，音频或视频传感器可以 例如过滤用户的声音或图像，从而使得用户变得不可识别。可以对来自视频传感器的图像进行分析以便描述图像中的‘场景’，而实际上没有显示图像。然 后可以使用这种未加密的信息，同时可以对原始音频和视频信号进行加密，并 且发送至SP。如此，与未加密数据相比，加密数据可以具有不同的细节级别 或粒度级别。

在传感器级别上完成的针对任何传感器的任何处理可以使 用类似的加密技术，其中，处理到不同级别的数据可以具有不同的加密级别。 例如，运动传感器和/或音频传感器可以用于情境检测，但是可以以不同方式对 所检测的情境的不同细节级别进行加密。情境算法可以能够精确地检测用户正 使用什么类型的公共交通，比如，例如公共汽车、火车、有轨电车、地铁等。 然而，用户可以决定未加密的信息可以只是说‘公共交通’，并且细节是加密 的。

图19示出了在部分加密情况下的数据流。从传感器开始， 可以根据什么类型的信息是加密的和什么信息是未加密的来以不同方式处理 数据。根据用户的隐私数据和设置来对加密信息和未加密信息的访问的许可进 行设置。

总之，用户控制对传感器数据加密到什么细节级别。如果传 感器配备有能够进行所述加密的处理器，则这种控制可以直接在(智能)传感 器中完成。用户必须对加密级别进行控制，而不受OS的影响。这种控制可以 由SP或传感器制造商提供的应用或工具来提供。

用户控制——用户可以完全控制他或她的数据。这意味着， 即使数据存储在SP处，用户可以仍是数据的拥有者。对数据执行的所有操作 都可以对用户透明。SP可以提供工具或应用，因此用户可以具有他或她的数 据以及对数据进行的处理的概览。

如果用户控制数据，则用户还可以有可能删除数据，例如， 如果他或她认为所述数据与他或她的隐私道德冲突。数据的删除可能对简档条 目有影响。可能不得不对基于用户已经删除的数据的任何简档条目进行重新确 定以便反映数据的删除。换言之，应当对简档条目进行计算，好像删除的数据 从未存在过一样。这可能对简档的值或者可以由SP提供的货币化选项有影响。 当用户想要删除数据时，用户可能意识到这些影响。SP可以跟踪数据用于哪 条简档条目，从而使得当此数据被删除时，所述SP清楚哪条简档条目应当重 新确定。因此，用户对数据做出的任何改变都应当反映在简档、简档条目、简 档值等上。

架构示例——传感器单元可以包含经由内部通信总线连接 至传感器处理器(例如，MCU)和传感器存储器的传感器或传感器组件。传感 器单元可以集成在单个芯片上或单个封装体中。由于集成处理器，所以这种类 型的传感器单元可以被称为智能传感器。传感器存储器可以用于存储对传感器 数据进行处理所需的数据或算法。传感器可以向处理器提供原始信号，所述处 理器可以对原始数据进行任何类型的处理，比如，例如校准。如果在传感器级 别上进行加密或匿名化，则传感器处理器可以使用存储在处理器存储器中的算法来执行此任务。专用通信线路可以存在以用于在没有例如OS干预的情况下 直接对加密进行设置。

使用第二通信总线将传感器单元连接至设备的其他部件。虽 然图中未示出，其他设备或传感器也可以有线或无线连接至此总线。设备处理 器可以对传感器信号进行处理以进一步地例如用于加密或匿名化(如果此在传 感器单元中尚未完成)。如果多个传感器或传感器单元可用，则处理器还可以 执行任何类型的融合。处理器还可以运行由SP提供的任何类型的工具或应用 来与SP进行通信。这些工具和/或应用以及用户的识别可以存储在存储器中。 存储器可以存储这些类型的处理所需的任何算法。假如数据没有被直接发送，则存储器还可以用于在将数据传送至SP之前存储传感器数据。在进行可选的 匿名化过程和加密过程之后，通信模块将通过任何有线或无线通信协议手段来 将数据传送至SP。

SP将接收数据并且将对数据进行处理以便构建简档以及配 备有处理器、工作存储器和存储系统(比如，例如硬盘阵列)的SP的服务器 系统。SP可以立即开始处理，或者SP可以将数据存储在存储器中并且在稍后 的时间进行处理。算法和模型可以存储在存储器或存储系统中。在存储器系统 中，SP还可以存储用户简档DB和供应商DB。如果数据是加密的，SP将在处 理之前对数据进行解密，但是可以存储数据的加密副本以供稍后使用。可以对 所构建简档进行加密或未加密存储。来自用户的数据可以全部存储在一个地 方，或者可以作为安全措施散布在不同的存储系统上。

为了帮助展示这些方面，在图20中示意性描绘了用于构建 用户简档的代表性系统，其中，设备100由高层次示意框表示。如将理解的， 设备100可以被实施为可由用户在空间中移动的并且由此可以感测其在空间中 的运动、位置和/或取向的设备或装置(如便携式设备或手持式设备)。例如， 这种便携式设备可以是移动电话(例如，智能电话、蜂窝电话、在本地网络上 运行的电话、或者任何其他电话座机)；平板计算机；个人数字助理(PDA)； 视频游戏机；视频游戏控制器；导航设备；可穿戴设备(例如，眼镜、手表、 皮带夹)；健康跟踪器；虚拟或增强现实设备；移动互联网设备(MID)；个 人导航设备(PND)；数字静态相机；数码摄像机；双筒望远镜；远摄镜头； 便携式音乐、视频或媒体播放器；遥控器；或者其他手持式设备；或这些设备 中的一个或多个设备的组合。

如所示出的，设备100包括主机处理器102，所述主机处理 器可以是一个或多个微处理器、中央处理单元(CPU)、或用于运行软件程序 的其他处理器，所述软件程序可以存储在存储器104中，与设备100的功能相 关联。可以在存储器104中提供多个软件层，所述存储器可以是计算机可读介 质(如电子存储器)或与主机处理器102一起使用的其他存储介质(如硬盘、 光盘)的任何组合。例如，可以为设备100提供操作系统层以便实时控制和管 理系统资源，实现应用软件和其他层的功能，并且将应用程序与设备100的其 他软件和功能对接。类似地，可以提供不同软件应用程序，如菜单导航软件、 游戏、相机功能控制、导航软件、通信软件(比如，电话或无线局域网(WLAN) 软件)、或者各种各样的其他软件接口和功能接口中的任何一种。在一些实施 例中，可以在单个设备100上提供多个不同应用，并且在这些实施例中的一些 实施例中，多个应用可以同时运行。

设备100包括如在此采用集成传感器处理单元(SPU)106 的形式示出的至少一个传感器组件，所述集成传感器处理单元以可以通过传感 器总线113进行通信的传感器处理器108、存储器110和内部传感器112为特 征。内部传感器112可以表示单个传感器或者包含多个传感器的传感器组件。 在一些实施例中，内部传感器可以是惯性传感器，并且传感器处理单元106还 可以被称为运动处理单元(MPU)。存储器110可以存储用于使用传感器处理器108的逻辑或控制器来对由内部传感器112和/或下文所描述的其他传感器输 出的数据进行处理的算法、例程或其他指令，以及存储来自内部传感器112或 其他传感器的原始数据和/或经处理的数据。内部传感器112可以是用于测量设 备100的空间运动的一个或多个惯性传感器。相应地，来自内部传感器112的 传感器数据表示设备在从第一时刻到随后的第二时刻的多个时期中的运动。根 据配置，SPU 106测量设备的一条或多条旋转轴线和/或一条或多条加速轴线。 在一个实施例中，内部传感器112可以包括旋转运动传感器或线性运动传感器。 例如，旋转运动传感器可以是用于沿着一条或多条正交轴线测量角速度的陀螺 仪，并且线性运动传感器可以是用于沿着一条或多条正交轴线测量线性加速度 的加速度计。一方面，可以采用三个陀螺仪和三个加速度计，从而使得由设备 100的传感器处理器108或其他处理资源所执行的传感器融合操作对来自内部 传感器112的数据进行组合以便提供六轴线运动确定。对设备运动的分析可以 用于推导出关于用户的活动、姿态、情境和/或行为的信息以便进行简档构建。 如所期望的，可以使用要与SPU 106一起集成在单个封装体中的微机电系统 (MEMS)来实施内部传感器112。可以在共同未决的、共同拥有的美国专利 申请序列号11/774,488(于2007年7月6日提交)和12/106,921(于2008年 4月11日提交)中找到关于主机处理器102和MPU 106的适当配置的示例性 细节。可以从加利福尼亚州森尼维尔市InvenSense公司那里获得设备100中的 SPU 106的适当实施方式。

可替代地或另外地，设备100可以采用外部传感器114的形 式来实施传感器组件。这是可选的并且不是所有实施例都需要的。内部传感器 和/或外部传感器可以是可以测量可能对推断关于用户活动、行为等和/或用户 环境的信息有用的任何类型的物理、化学、环境参数的任何类型的传感器。例 如，传感器可以是加速度计、陀螺仪、磁力计、压力传感器、接近度传感器、 环境光传感器、音频传感器、视频传感器、位置传感器、导航传感器、生物特征传感器、温度传感器、气体或粒子传感器和湿度传感器以及其他传感器。来 自不同传感器的数据可以采用融合算法来组合以便推断相关信息。如本文中所 使用的，“外部”指的是不与SPU 106集成且对于设备100来说可能是远程的 或本地的传感器。同样可替代地或另外地，SPU 106可以从辅助传感器116处 接收数据，所述辅助传感器被配置成用于测量与设备100周围的环境有关的一 个或多个方面。这是可选的并且不是所有实施例都需要的。例如，可以使用气 压计和/或磁强计来改善利用惯性传感器112所进行的位置确定。在一个实施例 中，辅助传感器116可以包括沿着三个正交轴线进行测量的磁强计，并且输出 要与陀螺仪和加速度计惯性传感器数据融合以便提供对九轴线运动确定的数 据。在另一个实施例中，辅助传感器116还可以包括用于提供可以与其他传感 器数据融合以便提供十轴线运动确定的海拔确定的气压计。尽管在一个或多个 传感器基于MEMS的情境下描述了本公开的技术，但是这些技术可以应用于 任何传感器设计或实施方式。一般而言，传感器组件可以包括内部传感器112、 外部传感器114和辅助传感器116中的任何一个或全部。

在所示出的实施例中，设备100的主机处理器102、存储器 104、MPU 106和其他部件可以通过总线118而耦合，所述总线可以是任何适 当总线或接口，比如，外围部件快速互连(PCIe)总线、通用串行总线(USB)、 通用异步接收机/发射机(UART)串行总线、适当的高级微控制器总线架构 (AMBA)接口、集成电路间(I2C)总线、串行数字输入输出(SDIO)总线、串行外围接口(SPI)或其他等同物。根据架构，可以根据期望而采用不同的 总线配置。例如，可以使用附加总线来耦合设备100的各种部件，比如，通过 使用主机处理器102与存储器104之间的专用总线。

可以根据期望而采用多个软件层，并且可以将所述多个软件 层存储在存储器104、存储器110或其他适当位置的任何组合中。例如，运动 算法层可以提供运动算法，所述运动算法提供针对从运动传感器和其他传感器 提供的原始传感器数据的较低级处理，比如，提取可能在传感器数据中识别的 一个或多个特征。作为说明，一个特征可以包括指示用户运动方式的运动模式， 所述运动方式可以包括但不限于行走、驾驶、奔跑、上/下楼、乘坐电梯、行走 于/站在自动扶梯上以及其他类似的运动方式。传感器设备驱动器层可以向设备 100的硬件传感器提供软件接口。进一步地，可以提供适当的应用程序接口 (API)以便促进主机处理器102与SPU 106之间的通信，例如，传输期望的 传感器处理任务。

在此示例性系统中，设备100将原始传感器数据和/或经处理 的传感器数据传达至远程处理资源(比如，服务器126)以便构建用户简档。 对传感器数据的处理可以包括从传感器数据中提取特征，如以下将详细讨论 的。在图20中使用高层次示意框描绘了服务器126的一种适当的架构，并且 所述架构可以包括通过总线132与存储器130进行通信的服务器处理器128。 如以下将进一步详细讨论的，服务器处理器128可以执行在包括简档模块134 的存储器130中所存储的被表示为功能块的指令。简档模块134可以接收来自 设备100的传感器数据、以及可以由设备100已经本地提取的任何特征。相应 地，简档模块134还可以从自设备100接收的传感器数据中提取一个或多个特 征。基于所提取特征，简档模块134可以执行在此被描述为与简档构建相关联 的其他操作，包括：在构建用户简档时，确定取决于所提取的简档条目并且确 定待与这类简档条目相结合的条目数据。存储器130或简档模块134还可以包 含用于提供可交换简档的块，所述可交换简档用于传输至第三方以交换补偿。 如此，对服务器126进行操作并且向用户提供服务的SP是远程SP。存储器130 还可以用于存储来自一个或多个用户的简档条目或完整简档。

在设备100与服务器126之间进行的通信可以采用任何适当 的协议。例如，可以使用短距离、低功率通信协议(比如，

ANT或有线连接)，或者可以使用较长距离通信协议(比如传输控 制协议、互联网协议(TCP/IP)、基于数据包的通信、使用无线局域网(WLAN) 的访问、蜂窝电话协议等)。一般而言，图20中所描绘的系统可以体现网络 化或分布式计算环境的各方面。设备100和服务器126可以比如通过多个互连 的网络直接地或间接地通信。如将理解的，可以采用各种系统、部件以及网络 配置、拓扑和基础设施(比如，客户端/服务器、对等或混合架构)来支持分布 式计算环境。例如，通过本地网络或广泛地分布式网络，可以由有线或无线系 统将计算系统连接在一起。当前，许多网络被耦合到互联网，其为广泛地分布 式计算提供了基础设施并且包含许多不同的网络，尽管任何网络基础设施都可 以用于对在各种实施例中所描述的技术发生的示例性通信。

如所指出的，设备100可以供应原始传感器数据(以及可选 地所提取的特征)，并且服务器126可以执行与用户简档的构建相关联的操作。 然而，简档构建功能中的任何一个或全部都可以由彼此通信的任何数量的分立 设备来执行，或者在其他适当的系统架构中可以由设备100本身来执行。例如， 设备100可以与服务器126进行通信以便传送原始传感器数据和/或经处理的传 感器数据，但是设备100可能不包括任何传感器并且从连接至设备100或与其 通信的其他设备获得传感器数据。如此，设备100可以是专用于简档构建和与 SP服务器进行通信的设备，并且可以从与用户相关联的其它设备接收传感器 数据。相应地，应当理解，在一个设备内或者在多个设备中都可以采用对处理 资源的任何适当划分。进一步地，在软件中实施的各方面可以包括但不限于应 用软件、固件、驻留软件、微代码等，并且可以采用可以从提供程序代码以供 由计算机或任何指令执行系统(比如，主机处理器102、传感器处理器108、 服务器处理器128、设备100、服务器126的专用处理器或任何其他处理资源、 或者其他远程处理资源)使用或与之结合使用的计算机可使用介质或计算机可 读介质中获取的计算机程序产品的形式，或者可以使用软件、硬件和固件的任 何期望组合来实施。

作为另一个说明性但非限制性的示例，图21中示意性描绘 的实施例表示在其中简档构建是在本地被执行的设备。类似的部件具有对应的 参考号(比如，图20的设备100可以对应于图21的设备200)。相应地，设 备200包括主机处理器202，所述主机处理器可以是用于运行软件程序的一个 或多个微处理器、中央处理单元(CPU)或其他处理器，所述软件程序可以存 储在存储器204中，与设备200的功能相关联。可以在存储器204中提供多个 软件层。设备200包括如此处采用集成传感器处理单元(SPU)206的形式示 出的至少一个传感器组件，所述集成传感器处理单元以传感器处理器208、存 储器210和内部传感器212为特征。存储器210可以存储用于使用传感器处理 器208的逻辑或控制器来对惯性传感器212和/或如以下所描述的其他传感器输 出的数据进行处理的算法、例程或其他指令，以及存储惯性传感器212或其他 传感器输出的原始数据和/或运动数据。设备200还可以实施采用外部传感器 214的形式的传感器组件。这是可选的并且不是所有实施例都需要的。同样可替代地或另外地，SPU 206可以从辅助传感器216处接收数据，所述辅助传感 器被配置成用于测量与设备200周围的环境有关的一个或多个方面。这是可选 的并且不是所有实施例都需要的。在所示出的实施例中，设备200的主机处理 器202、存储器204、MPU 206和其他部件可以通过总线218耦合，所述总线 可以是任何适当的总线或接口。设备200还可以具有绝对导航信息源222，比 如，全球导航卫星系统(GNSS)或GPS，这是可选的并且不是所有实施例都 需要的。

在此实施例中，设备200包括表示存储在存储器204中的指 令的简档模块220，所述指令用于由主机处理器202执行以便根据本公开的技 术来构建用户简档。一部分处理还可以由一个或多个SPU来完成。例如，SPU 可以执行对传感器数据的特征提取，并且然后向主机处理器提供所提取特征。 出于简档构建的目的，可以对SPU进行专门的设计和优化。在一个实施例中， 因为简档构建是在用户的设备上完成的，所以与简档模块220相关联的软件可 以由SP(其可以被称为本地SP)供应。根据一种技术，SP可以从设备200接 收所构建简档，从而使得SP可以提供可交换简档以便传输至第三方来交换补 偿。可替代地，SP可以促进第三方与设备200进行通信以便协商对简档的直 接交换以用于补偿。

在一些实施例中，用户可以使用传感器数据在SP的服务器 上运行应用，而不是在与用户相关联的设备之一上运行。用户可以从他或她的 设备之一中使用或控制远程应用，并且所述设备的屏幕可以是完全相同的，就 好像应用正在本地运行一样。如此，SP更多的控制谁对应用中使用的数据进 行访问。以类似的方式，应用可以在属于用户的本地服务器上运行，但是为对 此目的设置。这些策略可以有助于保持用户对应用匿名。

如关于图3所讨论的，用户可以对SP保持匿名，这意味着 传感器数据应当被匿名化或非个人化的(例如，通过使传感器数据与真实用户 的替代身份相关联)。在本文档的剩余部分，术语匿名化(anonymization)将 涵盖对用户数据进行匿名化或去个人化的两个过程。设备100可以因此包含在 传输至SP之前对传感器数据进行变换的匿名化模块。匿名化的级别可以取决 于用户偏好。匿名化处理的一部分还可以包含(部分)加密。SPU 106还可以 执行匿名化或加密的一部分或全部。在源处(即，在传感器处)执行这些操作 的优点还意味着操作系统可以只读取已经变换的数据。在将传感器数据传输至 SP时，还必须通过在传输中使用的设备(比如，通过设备的识别号码或地址， 例如设备IMEI和/或MAC地址)来小心注意删除任何识别的可能性。如图21 中所描绘的，在用户设备上构建简档的实施例中，匿名化可以在条目或简档级 别上来完成。

匿名化还可以由独立的第三方来完成，比如，例如金融机构 或银行。图22示出了一种系统，在所述系统中，原始的或经处理的传感器数 据被发送至负责匿名化的第三方。匿名化数据然后被传输至SP以用于简档构 建。第三方可以知道用户的身份，而对于SP，用户可以由用户号码来识别。 当第三方是像银行这样的金融机构时，第三方还可以负责向用户传输任何补 偿。

简档类型

存在不同的简档类型，并且下文将简要讨论所述不同的简档 类型。用户可以具有或者贡献若干不同的简档。用户‘拥有’的简档是用户简 档组合的一部分。SP可以向用户提供工具或应用来管理他或她的简档组合。 一般而言，每个简档可以具有至少部分地基于传感器数据的至少一条简档条 目。

个人简档——第一类型或类别的简档是直接与用户有关的 简档。这意味着此简档包含与用户的特性、习惯、偏好等有关的简档条目。这 些特性可以指物理特性(诸如，例如用户的性别、体重或身高)。所述习惯和 偏好可以指例如用户的业余爱好、饮食习惯、购物/购买习惯。换言之，与用户 有关的描述用户并且可以用于某种形式的货币化选项的任何信息都可以用于 用户的个人简档。用户已经创建的用于访问供应商或第三方的服务的证书也被 认为是个人数据并且可以同样地包括在简档中。

个人简档还可以包含与用户的联系人(诸如，例如他的或她 的家人和朋友)有关的信息。信息可以与用户与联系人之间的这种关系(例如， 家庭成员(如孩子、父母等))有关。如果联系人也订阅了SP的服务并且具 有简档，则所述简档条目可以仅包含引用。对于一些货币化选项，供应商可能 会对关于客户的联系人的信息感兴趣，例如用于通过用户判定他们的联系人是 否是潜在客户。用户和/或他的联系人可以能够例如在用户和/或联系人的隐私 数据中设置用于调整这种类型的深度链接的权限。从用户到他或她的联系人的链接可以包含多个级别(到所述联系人的联系人)。如果联系人没有简档，则 用户简档可以包含关于联系人的信息。

可以将简档划分成对相关简档条目进行分组的多个类别。例 如，简档类别可以与用户的业余爱好、体育活动、饮食习惯等有关。简档还可 以具有与用户的职业活动或工作相关的类别。此类别可以包括用户的能力、经 历、同事等。被分析用于个人简档或工作简档的数据可以来自不同的来源。例 如，针对个人简档，可以分析个人的电子邮件，并且针对工作简档，可以分析 工作简档。

由于个人简档直接与用户有关，个人简档可以被认为是主要 的或首要的简档。因此，此简档还可以包含其他简档与用户间接有关的某些信 息。其他简档是可以通过在主简档中的链接而可访问的。其他专用简档可以存 储在不同的地方、或甚至在其他服务提供商处。例如，这涉及与物品(像用户 的房屋或汽车)相关的简档。下文将讨论与物品相关的简档。

物品简档——简档不一定必须指人，而是还可以指物品。例 如，用户可以具有与他或她所居住的房屋相关的简档。房屋简档包含例如描述 房屋的条目，所述条目可以由描述房屋的特征组成，而且还由关于能量和电力 使用的信息组成。在另一示例中，简档可以指用户的汽车。汽车简档可以包含 关于如何驾驶汽车、执行什么保养等的信息。物品简档可以由结合在物品中或 在物品的外部的传感器组件构建。可以根据与物品相关的特定传感器配置来操 作物品的传感器组件。

物品可以具有拥有者，所述拥有者将在物品简档中指示。可 以由来自用户或直接来自物品或甚至外部数据库的数据来构建房屋简档。例 如，房屋的温度特性可以来自恒温器，并且居住的时间特性可以来自用户的智 能电话。在房屋内的温度可以与可能来自气象数据库的房屋外的温度比较。

如果对象具有多个拥有者或用户，则对对象简档的构建作出 贡献的数据可以来自多个用户。例如，对于房屋来说，信息可以来自居住在房 屋中的人，并且对于汽车来说，信息可以来自驾驶汽车的人。

尽管物品简档被‘附接’至用户简档，但是物品简档可以属 于物品并且物品可以被认为是简档的‘拥有者’。这意味着，如果因为物品被 出售、赠予或借出而改变了物品拥有者，则可以将用户的简档传送至新的拥有 者(如果用户订阅了由SP提供的服务或类似的服务)。换言之，物品简档变 成(多个)新用户的简档组合的一部分。当对简档进行传送时，可以删除与先 前拥有者相关的或可追踪回的任何信息。

物品的简档可以被认为是物品的可追踪的历史，并且可以从 生产直到物品寿命终止保持与物品一起。考虑汽车的示例。汽车制造商可以为 生产的每辆汽车创建简档。简档可以包含与汽车的生产有关的信息、所使用的 材料、关于替代零件的信息等。然后可以将简档传送至购买汽车的用户。SP 可以与汽车制造商达成协议，并且简档数据可以保持与制造商一起存储。新的 拥有者可以让汽车制造商访问汽车简档(完全或仅某些条目)，并且作为交换 可以获得一些货币化选项。任何类型的零件更换的保养都可以由执行保养的公司输入到简档中。

这种简档的优点是使用(传感器)数据来对信息进行认证和 支持，给用户以可靠的物品历史，并且给制造商以关于产品寿命以及所遇到的 偶然的或系统问题的信息。对于任何简档条目，SP可以提供推断的某种证据 或证明以及支持此推断的数据。

由于动物(如宠物和牲畜)具有拥有者，这些动物可以落入 这种相同类别的简档。对于宠物来说，简档可以包含例如来自动物医生或用户 为宠物购买的食物类型的信息。例如，对于狗来说，简档信息还可以来自遛狗 的用户，诸如，例如行走的平均时间或距离。对于牲畜来说，简档信息可以包 含用于饲养动物的食物、治疗所需的药品等的信息。这种方式，拥有者(即， 农民)可以具有用于他或她饲养的每个动物的可追踪记录。

组简档——组简档也可以描述用户组，其中，基于由所述组 的用户提供的数据来构建简档条目。组可以是具有某种形式的共享兴趣的人的 集合(诸如，例如俱乐部、组织、公司等)，或者为了休闲或者为了专业目的。

当对来自多个用户的组简档并且由所述多个用户对所述组 简档进行管理时，不是所有用户都可以具有同样的权利。所有用户可以贡献他 们的数据，但是也许不是所有用户可以输入或手动编辑简档条目。管理员可以 被指定对简档进行管理并且是SP的联系人。

组简档可以包含与例如组的动态、组的知识以及个体有关的 条目。例如，在公司简档中，简档可以包含来自对员工的电子邮件、讨论、和 移动中的分析的谁与谁关于什么交谈的信息矩阵。可以从他或她的电子邮件、 互联网使用、在电话或直接与其他同事的讨论等中推断每个员工的知识领域。 这种类型的信息可以有助于分析公司内的沟通。

可通过组简档获得的任何补偿都可以分布在属于组的用户 上。每个组可以决定如何在用户分布。

第三方简档——用户数据还可以用于为第三方或特定位置 (诸如，例如餐馆、商场、公园、住址、街道等)构建简档。例如，当用户正 要去餐馆时，音频传感器可以用于推断噪音水平、占用情况或甚至用于确定服 务时间和等待时间。来自用户以及其他用户的传感器数据可以构建用于餐馆的 (取决于时间的)简档。另外，所述信息可以用于推断用户自身的信息。如果 用户总是去具有较低噪音水平的餐馆(或当存在较小噪音时停留更长时间)，则可以推断用户偏好较低噪音的餐馆。根据所有的用户数据，可以推断很多餐 馆的简档，并且然后这种简档可以用于向用户建议具体的餐馆。关于餐馆的信 息还可以由餐馆的拥有者用于市场营销或商用目的，声明已经使用传感器客观 地认证/确认了信息。还可以将来自第三方简档的信息传送至用户(简档)。例 如，当用户正在光顾餐馆时，可以将所确定的噪音水平传送至餐馆的数据以用 于这个餐馆的光顾。

这些类型的简档可以由对简档信息感兴趣的一些人创建，但 是用户也应当具有去如此做的某种权利，例如，因为他或她是拥有者。例如， 餐厅拥有者可以创建用于餐厅的这种开放或第三方简档，或者‘城市’可以创 建用于公共公园的简档。对于SP来说，这些简档具有特殊状态，因为在对应 位置处的任何用户可以对用于简档的数据做出贡献。

基于人群源传感器数据的对特定位置进行的简档可以被称 为地理简档，所述地理简档通过传感器确认来认证。

简档条目输入机制

简档是简档条目的集合，其中，可以根据如何构建简档条目 而将每个简档条目分类成不同的类别或类型。简档条目的类别的第一示例可以 是信息是由用户手动输入的条目。一般而言，这涉及难以或不可能从传感器数 据或其他数据推断出的信息。例如，用户可以输入他或她的个人数据(诸如， 性别或身高)。在简档类别的第二示例中，条目可以是基于提供给SP的数据 的自动构建输入信息的条目。此数据可以是传感器数据、在线数据或任何其他 类型的数据。例如，由电子秤确定的用户体重是自动条目的示例。在又另一类 别中，简档条目可以由已经手动输入的条目组成，但是可能需要基于数据进行 确认。例如，在条目中，用户可以在条目中声明他或她是运动的，但是此条目 可能需要通过基于传感器数据对用户的活动进行测量来确认。另一类别的简档 条目可以由与其他数据库链接、或从其他用户的简档继承的、或与其他用户的 简档共享的条目组成。

在用户设置中，用户可以决定他或她将允许创建哪种类型的 类别的简档条目。用户还可以在通知用户或不通知用户的情况下决定SP是否 可以填写条目，或者决定SP是否必须请求特定权限。当SP完成或填写条目时， 用户可以给出他或她认为此条目是否正确的反馈。SP还可以请求用户提供或 授权给定的简档条目。SP可以接收来自第三方对某些信息的请求，根据所述 请求，SP验证所述条目是否存在，并且如果不存在，则SP可以采取所需动作 来构建简档，例如通过相应地修改传感器配置并且相应地操作传感器组件。因 此，在一些实施例中，简档条目的条目数据可以是根据请求而生成的。此请求 可以来自用户、SP或第三方(直接地或通过SP)。可以允许用户修改条目， 但是SP还可以保持SP所推断的原始条目。

当用户订阅了SP的服务时，将为用户创建空简档。SP可以 询问用户一些问题以便创建某些空简档条目并且可能用于开始填写简档条目。 例如，SP可以询问用户他或她的习惯是什么或者用户是否运动。根据回答， SP可以具体地创建相关简档条目。SP可以询问用户是否有房屋和/或汽车，并 且创建将被填写的对应简档条目。SP还可以提出几种用户可以选择的定型简 档。用户还可以从菜单或列表中选择简档条目以便创建具有用户喜欢或者期望 的简档条目。如果用户期望的话，则他或她还可以能够删除简档条目。

现将更详细地讨论不同类型的简档条目方法。

基于传感器数据的创建——可以基于用户所提供的传感器 数据来自动地输入简档信息。这意味着SP分析传感器数据，提取有用的特征 和信息，并且将这些特征和信息转换成简档条目。简档条目可以是空的或者可 以已经具有值，在已经具有值的情况下，可以基于最新推断值来取代或者更新 此值。

来自DCO的数据可以直接地用作简档条目。例如，如果用 户具有电子连接秤，则每当用户使用所述秤时，用户的重量以及被使用的日期 可以被自动地用于填充正确的简档条目。这种类型的简档条目可以被称为可直 接测量的条目。

在大多数情况下，来自DCO的数据和信息不可以直接地用 作简档条目输入。例如，基于来自活动监测设备的运动数据，可以推断出用户 平均每周跑步三次。在这种情况下，SP可以接收来自活动监测设备的作为原 始传感器数据或者由设备预处理的信息，并且基于随时间推移的数据的模式， 将推断关于用户的跑步活动的信息。可以通过对用户组的分析来推断或者学习 任何类型的模式，并且可以将这种知识用于其他用户以便检测这种模式并且预 测潜在的即将到来的数据收集事件。这种类型的简档条目可以被称为可间接测量的条目。

传感器数据可以来自在一个或多个设备中的多个传感器，并 且SP将组合所收集的数据以便推断简档条目。一方面，具有集成传感器组件 的两个或更多个设备可以与用户相关联，从而使得传感器数据包括来自每个设 备的传感器数据。例如，如果除了来自先前示例中的活动监测设备的数据之外， 用户提供来自电子网球拍的例如，所执行的网球摆动的数据，并且SP可以推 断出跑步和网球摆动是在同一时间被检测到，则SP可以推断用户正在打网球 (而不是跑步)。

基于在线数据的创建——以与基于传感器数据的条目类似 的方式，用户在线数据可以用于推导出简档条目。可以从用户的在线‘生活’ 中推断出的任何信息都可以用于创建简档条目。信息来源的示例可以是用户的 搜索查询、访问过的页面的内容、电子邮件等。基于在线信息，SP可以推断 例如与用户的业余爱好或者兴趣、用户感兴趣的音乐或视频的类型、或者用户 想要购买的产品有关的简档条目。在线数据或信息可以与传感器数据或任何其 他类型的数据组合，以便构建简档条目。SP可以从与分析在线数据的第三方 (诸如，例如Google)的合作中获得在线数据。如果对在线数据提供访问，SP 还可以执行自己的分析。

根据在线数据作出的推断还可以由传感器数据来组合或验 证。例如，如果用户在线购买跑步鞋，这可能触发使用传感器验证用户是否是 跑步者。

基于传感器或在线的确认——基于传感器或在线数据从头 创建完整的简档可能花费一些时间。这将意味着在用户可以能够使用所构建简 档作为资产并且通过补偿机制从简档中获得利益之前需要一定时间。对一些用 户来说，这种延迟可能不是很有激励作用，并且他们可能放弃为SP提供数据 的‘努力’。在开始为SP提供数据之后，用户尽可能快地开始使用他或她的 简档作为资产应当是可能的。

因此，为了使用户尽快地构造简档，可以允许用户手动地输 入简档条目，即使条目理论上可以通过由传感器数据来推断。在用户已经手动 地输入简档条目的条目数据之后，SP可以开始确认过程以便检查手动输入是 否正确并且对应于基于由用户提供的数据可以推断出什么内容。一方面，基于 传感器数据可以验证手动地输入条目数据。SP可以修改传感器配置并且相应 地操作传感器组件以便对条目进行验证。可以根据紧急性和或重要性应用不同 设置，并且所述不同的设置可能影响传感器配置。SP可以为手动输入的数据指定确认或验证值或类以便指示手动输入的信息已经被确认、是正确的、可以 信任、或对应于数据的程度。这种确认是一种安全机制，用于确保用户不会输 入错误的或虚假的简档条目，不可能伪装成他或她不是的某人，以便提高简档 的资产价值并且获得更好的补偿。确认条目所花费的时间可能取决于所述条 目，并且对于每条条目，可以限定检查用于验证所需的相关联数据的具有特定 时间常量的过程。

在一个示例中，确认值或类可以像‘非确认的’和‘确认的’ 一样简单。可替代地，确认类可以表示置信的级别，诸如，例如‘较低置信’ ‘中等置信’以及‘较高置信’。在另一示例中，确认或置信可以被表示为数 字(例如0与1之间)或表示为百分比，其中，较小数字代表较低置信。下文 将详细讨论置信因数。

对于一些简档条目，可以快速地执行确认。例如，如果用户 输入他的或他的体重，则下次用户使用电子秤时可以对此进行验证。对于其他 简档条目，确认过程可能需要较长时间，并且置信可能仅随时间推移而逐渐地 提高。例如，如果声明他或她每周练习一定次数的某项运动，则例如来自活动 监测设备的传感器数据必须支持此条目。在这种示例中，如果将与条目保持一 致的数据提供给SP，则用户每周实际做运动的平均次数的置信将在若干周内 提高。

令用户感兴趣的是他或她的手动输入的简档条目得到快速 确认，因为这将增加用于用户的货币化选项。这意味着SP可以向用户提供有 助于确认过程的选项。例如，如果用户输入他或她一周2次打网球，则用户可 以输入他或她是否具有电子网球拍以及用户在什么地方打网球。SP可以使用 由用户所指示的位置，并且使用定位方法(GPS、wifi…)来进行检查以便了 解用户处于这个位置的频率以及时长。使用用户提供的帮助针对某些条目的确 认所推断的规则还可以用于没有提供任何帮助的其他用户，如以下解释的。

确认某些简档条目的困难也可能与用户输入不是100％真实 的数据有关。例如，为了获得更好的货币选项，网球运动员可能夸大他或她打 网球的次数。如果(传感器)数据不能支持条目或以其他的方式进行证明，则 可能对用户施加惩罚。例如，可以向用户提供较少货币化选项或具有较少货币 利益的选项，或者货币化选项的值不可以超过设置的最大值。

在上文的讨论中，用户手动地输入简档条目，在这之后确认 进程开始。需要确认的简档条目还可以来自用户的联系人。换言之，SP可以 检查用户的联系人的简档条目，并且可以验证他们是否也适用于用户。原因在 于：一般而言，人们与朋友(即，联系人)具有一些共同点。用户花费在他或 她的联系人上的时间越多，他们具有共同简档条目的机会越高。用户的直接联 系人被称为第一级别联系人，并且联系人的联系人对用户来说是第二级别联系 人(以此类推)。SP还可以检查更深级别的联系人，但是类似的简档条目的 概率可能降低。

在上文对传感器数据的讨论中，表明了用户可以提供对所提 供传感器数据的注释。这对于SP是重要的，因为其有助于解释传感器数据以 及创建可能需要的算法和模型。因为用户向SP提供了信息，所以用户手动地 制作的条目可以被认为是隐式注释。此信息与用户数据有关，尽管在多数情况 下没有确切地限定信息指哪个数据。SP可以使用这种隐式注释来推断在手动 条目与(传感器)数据之间的任何已有相关性。SP可以选择已经为某些简档 条目制作了类似的手动条目的那些用户，并且寻找可能存在于所选用户的数据 中的一些相关性。因此，所确定的相关性可以用于制定在(传感器)数据与简 档条目之间的规则和关系。这些规则和关系然后还可以用于不执行任何隐式注 释并且不基于传感器数据来填写简档条目(如上文所述讨论的)的用户。例如， 用户可以手动地输入他或她的业余爱好是打网球。SP可以然后选择已经对他 们的数据进行了类似的声明的用户并且分析他们的数据。对例如这些用户的 GPS数据中的相关性进行分析将透露网球场的位置，从而提供足够可用的统 计。还可以对条目进行组合以便促进对相关性的搜索。在此示例中，SP还可 以询问用户一周打球多少次。此信息可以用于寻找单个用户的GPS数据内的 相关性，或者SP可以对经常打球用户的GPS点给出较大权重。基于此隐式注 释，SP已经确定了GPS数据与球场位置之间的关系。此信息然后可以用于没 有指示他们的业余爱好是打网球的用户，但是如果他们的GPS数据表明他们 经常在网球场处，则用户打网球的可能性很高。对于此示例，执行显式注释的 用户在他或她正在网球场处时将指示他或她正在打网球，从而使得SP可以直 接创建GPS数据与打网球之间的关系。可以对显式注释方法与隐式注释方法 进行组合以便创建在数据与简档条目之间的关系(图23)。

从数据库的连接——简档信息还可以自动地来自与用户相 关联的数据库。例如，如果用户参与了他或她作为业余爱好或专业执行的运动 竞赛，则可以在官方数据中查出排名。此信息可以用于推断用户在这项特定的 运动中有多好。在这种情况下，用户向SP提供用于访问这种数据库并且构建 简档条目的所有所需信息。

在另一示例中，SP可以在官方数据库中查找气象数据以便确 定用户居住地的天气特性。这类信息对一些货币化选项是有用的，例如对于服 装供应商。

数据库还可以包含已经由第三方处理和变换的用户传感器 数据。例如，来自用户活动监测手镯的传感器数据可以由Fitbit或者Runkeeper 等来处理。这种数据可以用于直接地或经过某种形式的转换之后填写简档条 目。

SP可以与第三方建立特定合作以便自动地交换数据，或可以 使用用户的登录数据来访问数据库。

继承的简档条目——简档条目可以不仅基于用户提供的数 据，而且还可以是从其他简档继承的。简档条目可以是从与用户具有(层级) 关系的其他用户的简档条目中继承的。例如，在家庭情形中，每个家庭成员可 以具有他们自己的个人简档，但是来自一个家庭成员的一些条目可以是从另一 成员继承的或与另一成员共享。例如，来自父母中某一位的简档条目可以由孩 子来继承或与任何其他成员共享，诸如，例如房屋的地址或类型。用户之间的 关系可以被自动地检测或被手动地输入并且之后进行确认。

简档条目信息还可以从是用户可能属于的组中继承的。例 如，如果用户属于网球组或俱乐部，则用于业余爱好或体育活动的简档条目可 以来自组简档的条目。例如，属于网球俱乐部的用户将具有网球作为体育活动。 如果俱乐部具有训练日程安排，练习赛和竞赛活动的频率可以是从组简档中继 承的。

简档条目或传感器数据的继承不局限于人。在术语继承 (inheritance)更广泛的意义上来说，物品可以从一个或多个用户处继承简档 条目或传感器数据，反之亦然。例如，如果两个用户(如丈夫和妻子)共享汽 车，则他们的驾驶数据可以用于他们的与驾驶有关的个人简档条目，而且还可 以用于构建用于汽车(例如与如何驾驶汽车有关)的简档。因此，汽车简档是 从汽车用户的数据和条目继承和构建的。

共享的数据条目——原则上，用户的简档至少部分地由来自 用户的数据构建。然而，在一些情形下，用户还可以利用由其他用户生成的数 据。这意味着，贯穿此文档所描述的原则还可以应用于使用来自传感器的数据 或来自第二用户的DCO来构建用于第一用户的简档条目。对此原则的挑战将 用于决定何时可以使用这种传感器数据。此决定的标准可以是例如用户之间的 关系和或不同用户的接近度。

考虑两个用户一起进行活动的示例，诸如，例如进行一些越 野跑步。第一用户可以使用GPS来跟踪跑步，而第二用户可以没有GPS。如 果可以确定第一用户和第二用户一起跑步，则来自第一用户的GPS数据可以 用于第二用户。数据细节可以共享到什么程度取决于以类似的方式执行活动的 两个用户的细节可以确定的多精确。例如，如果可以使用音频信号确定用户总 是在一起，则可以共享跑步的位置以及关于跑步的速度特性的细节。如果不能 保证这种紧密接近(可能一个用户较快并且规律地停止来等待其他用户)，则 仅可以使用关于跑步的位置信息而非跑步速度的任何信息。

换言之，在确认过程后，可以将来自第一用户的、某个数据 事件的数据应用于第二用户。此确认过程可以产生可以应用于数据的置信因 数，从而指示确定来自第一用户的数据可以被应用于第二用户的置信。在一些 情形下，SP可以从第一用户和/或第二用户那里要求共享数据的权限。

置信因数

简档条目基于来自(传感器)数据的推断。这些推断中的一 些是直接的并且简单的，并且一些是间接的并且更复杂。为帮助指示给出简档 条目的可靠性，可以确定置信因数，所述置信因数可以取决于任何适当的标准， 包括下文所讨论的这些。还可以随时间推移对置信因数进行调整：如果条目没 有积极地更新，则作为衰减过程；或者如果简档条目的历史指示增大的可靠性 或确认所述条目的更多传感器数据已经变得可用，则作为增量。

简单且直接的推断可以是上文所述讨论的从电子连接秤‘推 断’的人的重量的示例。即使人的重量变化很小，人的重量的可靠确定也可以 通过一个测量来执行。因此，SP可以根据一个数据事件来确定具有较高置信 因数的体重。可以通过随时间推移对在数据库中的所述用户或用户体重变化的 分析来确定准确性，可以与用于选择与所述用户具有类似简档的用户的过滤器 组合来确定。这将给出用户体重随时间推移而变化的指示，并且因此可以用于 确定置信因数。例如，如果在数据库中用户的分析表明典型的体重变化(对于类似用户)为大约5％，则可以假设我们可以从具有大约相同置信的单一测量 中确定此人的体重。

如更复杂的间接推断的示例(其中，以单个或仅几个数据事 件为基础来确定具有较高置信的正确简介条目是困难的)，考虑健康生活的概 念。此概念不是可直接测量的并且由很多不同因素(诸如，例如用户在超市购 买的食物、用户去的餐馆、用户做训练的数量等)组成。

因为涉及很多因素，存在很多因素有待验证，这可能需要一 些时间。每个数据只揭示一小块拼图并且只有这些拼图块的组合才将揭示完整 的图片。最初，SP仅可以能够确定用户去哪些超市或用户光顾哪个餐馆。但 是因为这只是图片的一部分，仍不能确凿地推断出用户正健康生活。此时，健 康生活条目具有较低置信因数。确切的置信因数取决于已经确定了拼图的哪一 块以及所述块与简档条目之间相关性强度。随着基于数据事件而确认健康生活 概念的其他拼图块，置信因数增大。可以根据由SP设置或限定的规则或算法、或者通过分析类似用户的简档并且确定所述简档条目与某些数据之间的相关 性强度来确定每块拼图或者确认数据事件对简档条目和置信因数作出多少贡 献。此相关性强度然后可以用于计算置信因数。可替代地，还可以根据上文所 讨论的隐式注释来推断根据所检测数据事件来限定置信因数的规则。例如，SP 可以询问用户他或她是否认为他或她生活是健康的(或者用户可以制作这种手 动条目)。然后可以寻找这些用户的回答和他们的数据与简档条目(SP可以 执行一些预选择)之间的相关性。例如，考虑100位用户填写他们是否生活健 康的条目。SP可以检查这些用户他们使用什么超市。假设24个说他们生活健 康的用户光顾超市A并且16个说他们生活不健康的用户光顾超市A。这给出 了光顾超市A与生活健康之间的相关性。现在，如果SP检测到用户正在光顾 超市A，但是用户没有声明他或她生活是否健康，则SP可以确定用户生活健 康的概率。在此示例中，概率将是24/(24+16)＝0.6。SP可以使用此相关性 作为置信因数，这意味着对于光顾超市A的用户而言用户健康生活的条目的置 信因数是0.6。SP还可以寻找生活健康与例如进行体育运动或光顾某些餐馆之间的相关性。可以组合不同相关性的置信因数以便确定健康生活条目的置信因 数。此示例已经示出了可以如何使用来自利用例如隐式注释进行的分析的相关 性强度来为所有用户确定置信因数。

某个条目的置信值还可以影响另一简档条目、较低级别数据 或较高级别数据的置信值。例如，用户在常规基础上练习一些运动或体育活动 的较高置信级别还可以引起用户具有一定的健康或健康生活的较高置信级别。 特定条目的置信级别可以是其他条目的置信级别的数学组合。例如，用户的健 康级别的置信值可以是所有运动相关的置信值的组合。置信值还可以是对每个 类别或甚至整个简档的数学地组合(例如，平均)。这些置信值给出所推断的 简档条目(例如，每个类别或对于整个简档)有多么精确的指示。

在另一示例中，置信值可以数学组合以便特定的货币化选 项。如果对于某种货币化选项，某些简档条目是重要的，这些条目的置信级别 可以单独或组合地使货币化选项的提供者知道。货币化选项的潜在补偿可以与 置信值有关；置信值越高，补偿越高。基本原理是：可以保证用于货币化选项 的简档条目正确的越多，用户可以为此奖励越多。例如，如果置信值表示为百 分比，则实际补偿可以乘以此百分比。这个策略对用户可以是透明的，作为提 供更多数据的激励，其将产生更高的置信级别以及因此更高的补偿。补偿的一 部分还可以被阻止或保留，并且当置信因数增大时可以被释放给用户。如果在 预定时间内置信因数没有增大，则补偿可能被部分地取消。

用户的置信值还可能受用户联系人(例如，朋友、家人等) 的影响，因为用户的生活方式经常与联系人的生活方式具有相似之处。所述影 响可能取决于用户与具体联系人有多接近并且取决于用户花费在其他用户/联 系人上的时间量。例如，如果用户在另一用户上花费大量时间并且他们两者具 有某种(物理)活动的条目。朋友的这个条目的更高的确认值可以增大用户的 这个条目的置信级别。以类似的方式，条目的置信值还可以从用户继承给他的 孩子，因为父母的某种生活方式被转移给孩子。

如上文所提及的，完成确认和验证过程以便检查用户条目是 正确的。此过程还可以被看作认证，意味着SP对用户的简档或某些简档条目 进行认证。所述认证还可以用于官方目的。例如，用户可以接收来自(本地) 政府的用于能量高效生活方式的某些津贴。在这种情况下，官方实例可以针对 津贴的资格建立规则，并且由SP进行的对用户遵循这些规则的认证可以作为 接收津贴的资格标准。可以引入最小置信因数或阈值以便获取认证资格。在这 种情况下，SP可以提供认证文档作为证明。可以随时间推移而监测所述认证， 并且如果发生变化则对其进行调整。

所有简档条目都可以具有与条目一起存储的置信因数。另 外，可以添加获得此置信因数时的日期，并且还可以存储置信因数如何随时间 推移确定或计算的置信因数历史。此置信因数可以对用户是可见的或可以存储 在后台。如果置信因数是可见的，则SP可以具有用户可以对置信因数的增大 作出贡献的选项，例如，通过为用户提供一些注释或建议如何测量或确认条目 (更多)。

简档动态性

人员改变、改变其习惯、改变其偏好，并且可以因此不被认 为是常量。因此，简档不可能被认为是常量或静态的，而相反简档是动态的。 简档条目是从在某个时间点到来的传感器数据中推断出来的。不能假设测量到 所有的事件并且因此检测到任何变化。从一个或多个数据事件中推断的简档条 目必须通过类似的数据事件来得到不断的确认。例如，考虑检测到用户正在打 网球。从一个数据事件，无法推断出打网球是用户的业余爱好。然而，如果检 测到用户每周都打网球，则简档可以指示用户的业余爱好之一是打网球，并且 他或她以每周一次的频率打网球。如果用户在某个周没有打网球，则意味着他 或她只是错过了那个星期，或者用户停止打网球。因此，事实上用户将打网球 作为业余爱好的置信下降。

可以通过限定置信因数的衰减来将此概念引入到简档中，这 意味着某个条目的置信因数具有一定的衰减时间。换言之，在某个所推断的条 目中的置信随时间下降，直到新的数据事件确认所推断的条目。换言之，一般 而言，以单调递减函数随时间推移对置信因数进行调整，直到新事件的新传感 器数据确认所述条目。图24示出了在每个数据事件之后置信因数如何下降(由 箭头指示)。如果用户打破习惯，如以上的示例中，其可能有其他原因。此原 因可能比所预期事件更重要。如果检测到重要的数据事件而不是预期数据事件，则可以调整置信因数的衰减量。

可以根据数据频率或条目类型来推断衰减时间。一般而言， 如果某个数据通常是以一定频率提供的，则衰减时间应当是这个时间间隔的倍 数。在以上的示例中，初始频率为每周一次，并且因此衰减时间应当采用周的 数量级。如以上所解释的，置信因数的起始值取决于推断的置信。

置信因数随时间推移的衰减可以采用与简档条目最相对应 的任何所需的形式，例如，指数、线性等。衰减时间或衰减速度可以是从用户 的数据中推断出的，或者可以基于来自全部或所选用户的数据。换言之，基于 对来自较大用户组的数据的分析，可以确定简档条目或用户习惯的变量的典型 时间特性，根据所述典型时间特性可以推断出衰减时间或速度。例如，练习某 项运动的用户可能在某一时刻变得不太感兴趣，并且逐渐地降低他或她练习运 动的频率。在另一示例中，用户可以遵循某种饮食，但是可能逐渐降低他或她遵循饮食的严格性。这些类型的改变习惯的趋势可以由用户或用户组来确定， 并且有助于预测简档条目的典型预期变化。

如以上所讨论的，置信因数影响简档的值，并且因此置信因 数的衰减还导致了值或补偿的衰减。简档值的这种衰减是不同条目的值的衰减 的组合。因此，简档的值的衰减是单独值中的值的衰减的数学组合。例如，这 可以通过简单地添加各个条目随时间推移的值预测来完成，以便确定整个简档 随时间推移的值预测。可以对不同的条目给出不同的权重来说明例如个人偏好 或过去的货币化选项或用户动作。

隐私管理

隐私vs货币化——用户简档可以被认为是资产。在这种情况 下，用户简档是用户的数字版本，包含可以从他或她的在线和离线数据以及行 为中推断出的所有信息。这些信息既是私密的又是有价值的。简档可以作为资 产来管理，其中，隐私方面和价值方面都应当被考虑在内。事实上，隐私和价 值方面代表可以微调的变量，并且可以帮助决定如何管理用户简档。在任何情 况下，系统都将允许用户相对于供应商或第三方保留他或她的隐私，同时与 SP共享数据。

在一方面，用户可以决定他或她的隐私非常重要，并且在用 户简档中的信息应当仅对他可知。用户不想与任何人共享信息的事实使SP很 难创建货币化选项。这些用户因此选择隐私而不是货币化选项，并且将不能从 简档中收益更多。在此情况下，对使用大量的传感器数据来生成详细的简档可 能不是很令人感兴趣。因此，SP可以对传感器配置进行调整以便提供刚好足 够的传感器数据来构建用户感兴趣的最小化简档，并且根据此配置来操作传感 器组件。这将节省计算资源和功率资源。

另一方面，如果共享简档信息导致货币化选项，则用户可以 决定他或她不介意共享简档信息。在此情况下，将允许SP使用简档信息来找 到并且向所述用户提出货币化选项。这些用户因此选择货币化选项而不是其隐 私。

换言之，用户对他或她简档的隐私进行控制，但是他或她必 须在保留(部分)简档私密或者使用其作为用于货币化的资产之间进行选择。 可以由用户使用隐私数据(比如，隐私参数)来做出此选择，范围从较高隐私 并且较低货币化选项到较低隐私并且较高潜在货币化选项。

隐私参数——在将用户简档作为资产进行管理时，用户可以 设置指示用户是优选隐私还是货币化选项的隐私参数或货币化参数。这些和其 他相关的参数可以被认为是与用户相对应的隐私数据。可以在所有不同级别 (比如，例如在完整简档级别上、或在较低级别上(比如，每个类别(个人、 汽车、房屋)、或者甚至每个简档条目))设置参数，以使得隐私数据可以是 针对至少一条简档条目的用户设置。参数可以是简单的并且二元的，其中，用 户不想使用或共享的信息被归类为‘私密的’，并且没有标记‘私密的’或标 记例如‘货币化’的所有条目都可以用于货币化选项。由于私密方面和货币化 方面是有点相互对立的，所以如果其不是其中一项，则其可以被认为是其中另 一项。隐私参数还可以具有更多选项或者不同粒度级别的尺度，并且可以被设 置在例如0与1之间，其中，0意味着信息是私密的，并且1意味着信息可以 用于货币化选项。在0与1之间的参数值可以指示信息被透露到什么水平。例 如，如图11中所指示的那样考虑用户的年龄。如图中所示，可以在若干不同的隐私或粒度层次上透露年龄：30-40岁、35岁、或作为实际生日03/04/1980。 在此情况下，如果用户将隐私参数设置为0，则这意味着年龄保持未知或者设 置为最大范围(如从用户数据库的统计资料中所推断的)，而如果隐私参数被 设置为1，则出生数据是可用的。由于在这种情况下3个层次是可用的，这将 意味着隐私参数0.33对应于‘30-40岁’，而0.66对应于‘35岁’。因此， 可以获得与用户相对应的隐私数据。可以针对简档的至少一条简档条目建立多 个粒度级别。通过基于隐私数据从所述多个粒度级别中选择第一粒度级别，可 以对简档条目进行变换以便匹配所选的粒度级别。在一些实施例中，可以部分 地通过对用户组的多个用户简档进行分析来建立所述多个粒度级别。例如，当 不同的用户被要求输入其出生数据时，他们选择以其希望的粒度来输入他们的 数据，例如，确切的日期或者只是年龄。通过对来自不同用户的这些简档条目 进行分析，SP可以推导出可能或最常使用的粒度级别。当用户在简档中输入 了他或她的确切的生日但是根据隐私数据应当只透露出生年份时，所请求的粒 度设置选自所述多个推断的可能的粒度设置。可以基于一些选择标准从较大的 用户列表或数据库中选择所述用户组，例如为了以某种方式选择类似于所述用 户的用户。这种选择过程可以基于更多条不同简档条目之一的条目数据的比较 来进行。选择标准可以由用户和/或SP来确定。

图25示出使用用户的年龄来展示隐私设置对所构建的简档 如何被转换成可以与公共(比如，供应商或其他第三方)交换的简档的影响的 示例。至少部分地基于传感器数据而构建的简档可以被称为私密简档，并且包 含如可以由传感器和/或手动条目获得的尽可能多的细节。术语私密用于指示在 没有用户的知识和批准的情况下来自简档的任何信息都不能用于货币化选项。 可交换简档基本上是经过滤的私密简档，其中，过滤是基于隐私数据完成的， 从而使得可交换简档包括根据隐私数据变换的至少一条简档条目。可交换简档 可用于SP来创建货币化选项。可交换简档还可以被称为公共简档，但是术语 ‘公共’不意味着简档被公开供每个人看到，其仅仅指出这是SP将与之合作 的简档，并且为了货币化选项或其他形式的补偿将以示例的方式向供应商或第 三方透露。私密简档可以是加密的，而可交换简档不是。用户可以将隐私设置 作为数值参数输入，或者可以使用如图25中所示的具有例如滑块或拨号盘的 某种图形界面。当改变滑块或拨号盘的位置时，可交换简档将立即发生变化以 查看隐私设置对可交换简档的条目的影响。如果用户设置了某些隐私参数，可 以选择最接近的相应类(0.5透露35岁)或者在透露信息之前，参数必须高于 相应类(0.5透露30-40岁)。图26示出了生成可交换简档的流程图。

可以由SP确定每个条目的不同可用粒度级别。在年龄的示 例中，SP可以限定存在4个粒度级别：1)实际出生日期，2)年份年龄，3)5 年窗口内的年龄(例如，20-25、25-30、30-35……)，4)10年窗口内的年龄 (例如，20-30、30-40……)。还可以通过设置最小窗口大小和最大窗口大小 以及其间的粒度量来限定粒度级别。在此示例中，最小窗口大小为1天，并且 最大窗口大小为10年。可以从用户条目中推导出最小值和最大值。在年龄的 示例中，所输入的用户年龄可以在例如15岁至80岁之间变化。在此情况下， 最大范围可以设置为65岁窗口，或者例如在条目中观察到的扩展的最大值的 至少一半。可以使用线性或对数或任何其他比例来确定最小窗口与最大窗口之 间的不同粒度细节。还可以根据用户条目自动地确定粒度。在以上示例中，用 户已经在私密简档中输入了生日日期。然而，一些用户可能不想以此准确度输 入其生日日期或年龄。一些人可能想将其年龄输入为35岁或30-40岁。对条 目的分析可以用于确定最常见的条目，并且对它们进行选择和排序以获得可 用、逐渐的以及全面覆盖的选择。

在隐私过滤之后获得的可交换简档条目指示用户想要‘公 开’和用于货币化选项的最大细节。然而，这并不意味着与货币化选项和其他 形式的补偿的所有供应商或提供商共享此条目。SP将确保补偿提供商将不会 接收到比所需更多的详细信息。例如，运动商品的供应商(像跑步鞋)将只需 要知道5年或10年窗口内的年龄，而花的供应商可能想知道生日日期(几天 之内)以便提供与生日有关的特殊要约。最小所需细节可以由SP从用户条目中推断出来。例如，在跑步鞋的示例中，可以对购买这些或类似的跑步鞋的用 户的年龄分布进行分析。所观察的年龄窗口可以用于设置透露给鞋的供应商的 最大细节。在花的供应商的示例中，SP可以寻找家庭成员的生日与购买鲜花 之间的关系。这种关系大多会在特殊的日子(比如，例如生日和/或母亲节)附 近产生特定的峰值。这些特殊日子和在这些日子附近的扩展的日子可以用于限 定用于花的供应商的有用信息细节，而不会透露太多细节。这些示例表明：透 露给供应商或第三方的(隐私)细节和信息粒度可以根据对与第三方可以提供 的产品或类似产品有关的用户的数据和简档的分析来推断。此数据的分布宽 度、方差或任何其他类似的参数都可以推导出来，并且直接应用于确定透露给 供应商的粒度级别。这表明对(私密)简档的被执行以便生成可交换简档的过 滤或修改可以至少部分地基于可以提供补偿的第三方的特性。

作为可替代选项，用户还可以能够确定他或她的可交换简档 的确切细节。这意味着对于每个条目或者条目的类别或分类，用户可以手动地 设置他或她想要透露的信息粒度和细节。这些设置可以取决于第三方或者第三 方的类别或分类。尽管此选项可以由SP提供给用户，但是其将需要用户的大 量关注和工作。用户可以在初始阶段做这一点，并且SP可以学习关于用户的 隐私设置，并且使用此来推断SP可以向用户提出来除了手动方式之外应用的 一些隐私参数和规则。

用户可能不想针对每个简档条目设置隐私参数，并且可能想 仅针对整个简档或者可以包括多个简档条目的每个类别设置总体隐私参数。在 一个示例实施例中，这种总体隐私参数然后由在此类别中的所有条目来继承。 然而，不同简档条目对隐私的影响可能改变。换言之，不同简档条目不会透露 关于用户的相同信息‘数量’。例如，一般认为用户播放或喜欢的音乐类型不 如用户服用的药物类型更加私密。如果用户仅设置总体的隐私参数，则SP必 须为不同条目分配相应的隐私参数，考虑到此条目透露或公开了关于此人的多 少信息。公开参数可以由SP使用和应用，所述SP考虑和量化条目公开的关于 人的数量。公开参数可以被认为是隐私数据的一部分，或者可以基于隐私数据 来计算。公开参数还可以与隐私数据组合。例如，隐私数据可以包含用于例如 简档或简档类别的隐私参数、以及简档条目的粒度，所述简档条目的粒度是使 用与简档条目相关联的公开参数从隐私数据中推导出的。此公开参数可以被限 定为不同的分类，例如，低、中、高。类似于隐私参数，公开参数也可以在0 与1之间变化。在此情况下，0可以指示条目未关于用户透露太多，这对于人们不介意彼此共享的信息(比如，他们的音乐偏好)是典型的。公开参数1可 以指示其关于用户透露了很多，这对于人们一般不喜欢与其他人共享的信息 (比如，例如他们使用的药物)是典型的。对于不同条目的公开参数可以例如 由SP进行手动设置。公开参数还可以由用户设置或者从用户学习到。例如， SP可以从进行设置个体化条目的用户中学习到这一点。在此情况下，假设如 果用户将不同的隐私参数给予不同的条目，则用户感觉他们公开了不同数量的 用户。当然，每个用户可以关于某个条目公开多少具有不同的意见，但是对许 多不同用户的统计可以给出公开参数的良好平均估计。如此，可以从多个用户 简档中推导出隐私数据。如以上所解释的，可以基于某个选择标准从用户的列 表或数据库选择不同用户组。甚至在已经基于总体隐私参数和公开参数而确定 了个体化隐私设置之后，用户可以能够对所提出的个体化参数进行调整。这种 调整还给SP以关于用于此特定用户的公开参数的信息，并且还作为公开参数 的一般推断策略的一部分。一般而言，任何用户做出的改变对一组简档条目中 的简档条目的隐私设置的任何调整都可以由SP用来学习关于条目组的此条目 的公开参数。大多数情形下，当用户降低可交换简档的条目的粒度时，意味着 用户感觉到先前的粒度透露了关于用户太多。这种修改变化可以用于增大此条 目的公开参数。公开参数的变化可以与可帮助选择标准从用户列表或数据库中 选择所述用户组的其他简档条目相关联。可以以不同的方式使用公开参数来确 定条目的个体化隐私参数。例如，可以通过将总体隐私参数与1减去用于条目 的公开参数相乘来推断个体化隐私参数。这意味着条目关于人透露越多，个体 化隐私参数减小的越多。在另一个实施例中，公开参数可以用作只有这些条目 被公开(或使用)的阈值，其中，公开参数低于所设置的总体隐私参数。例如， 如果隐私参数设置为0.5，则具有在0.5以下的公开参数的所有条目都可以变得 可用。

隐私设置还可以以定型或模型的形式呈现给用户，这意味着 用户选择他或她最常识别的某个模型或定型。SP还可以基于SP推断出的作为 基于用户简档的最相应定型的来向用户提出定型。例如，用户可以构建定型或 模型‘X代(Generation X)’‘Y代(Generation Y)’。主要在数字时代成 长的Y代可能更倾向于共享其数据。SP可以基于作为Y代的一部分用户隐私 设置来构建此简档。

当用户改变总体隐私设置时，应当立即(或‘实时’)示出 对他或她的可交换简档的影响，如关于图25所讨论的。代替只示出1个条目， 根据他或她正改变的参数影响了哪些条目，用户界面可以示出完整简档或简档 的一部分。

通过隐私数据和(多个)参数，用户选择他的简档的哪一部 分保持私密、以及哪一部分变成公开的，所述公开部分意味着可以用于货币化 选项或其他形式的补偿的部分。因此，所生成的私密简档可以被限定为包含可 以关于用户学习到的每件事物(添加所有可能的细节)的简档。然后，可交换 简档被限定为私密简档的过滤版本，其中，过滤是使用隐私数据来完成的。被 执行用于获得可交换简档的过滤和修改可以由隐私管理器或隐私管理模块来 执行，所述隐私管理器或隐私管理模块可以是在用户或SP设备/服务器之一上 运行的软件应用。在用户可以获得他或她的私密简档和可交换简档的概览的用 户界面中，隐私参数的影响应当对用户清晰可见，从而使得他或她可以改变隐 私参数，并且看到所产生的可交换简档变成了什么。

私密简档和可交换简档的值——简档可以被认为具有值，所 述值是基于由订阅服务的用户和/或其他用户获得的补偿。所述值取决于简档中 的信息。此信息在(私密)简档与可交换简档之间是不同的。因此，私密简档 和可交换简档还具有不同的估计值。因为可交换简档包含较少的细节信息，所 以可交换简档具有比私密简档较小的值。

用户可以从他或她的数据中获得的最大值是私密简档的值。 如果用户将隐私参数设置成最小值，则可交换简档等于私密简档，并且因此可 交换简档具有与私密简档相同的值。因为隐私参数影响可交换简档，所以其还 影响简档的值。为了示出隐私参数对用户的影响，可以在用户控制隐私设置的 界面中示出私密简档和可交换简档的值。这意味着当用户改变隐私数据时，简 档的值‘实时’变化。

灵活的隐私vs货币化选项的值——提出给用户的货币化选 项和其他形式的补偿的值可以取决于透露的信息。例如，如果用户提供更多细 节信息，则供应商或第三方可能倾向于给出更好的交易。这个原则被结合到协 商过程中以便获得以下将要描述的补偿。

在补偿协商过程中，SP可以通过向用户提供基于隐私数据用 户允许使用的限制以下的简档信息来开始。这种方式，在协商中，如果供应商 提供更好的补偿，则SP可以透露更多关于用户的信息(在他或她的限制以上)。

在一个实施例中，如以上所讨论的用户的隐私限制可能是固 定设置或不灵活的。在另一实施例中，这些限制可以根据补偿的预期值而是灵 活的。这意味着用户设置他愿意从他或她的简档中交出更多细节来交换更多补 偿值。这种灵活性或弹性规则或参数可以在隐私数据中针对个体化条目或者针 对类别或者针对完整简档来进行设置。这种隐私弹性参数可以例如以货币单位 或百分比来表示。换言之，用户可以设置隐私参数如何取决于补偿值(更多补 偿是更少隐私)。当弹性参数表示为百分比时，其意味着补偿值应当以一定百 分比增大，然后限定隐私参数降低多少。

从传感器到简档条目

如以上所讨论的，简档条目可以被划分成2个类别：可直接 测量的条目和可间接测量的条目。对于可直接测量的条目，从传感器到简档条 目的步骤是直接的。如在电子连接秤的示例中所示出的，传感器的输出(其中， 输出为体重并且秤是传感器)可以用作指示用户当前体重的简档条目来直接使 用。如此，对于一些简档条目，传感器数据可以直接转换成简档条目的条目数 据。

然而，许多简档条目是可间接测量的条目，其需要某种模型、 算法或规则来从传感器数据中推断简档条目。图27示出了传感器信号到简档 条目的涉及若干不同步骤的转换的示例实施例。

第一步骤可以是特征提取过程。在此步骤中，将原始传感器 信号转换成更多有意义的特征。如此，可以确定可从所述传感器数据中提取的 至少一个特征。例如，SP可以请求将需要确定特征的简档条目。这些特征还 可以被认为是构造块，因为其将在接下来的步骤中使用以便构建简档条目。一 方面，可以对传感器数据进行处理以便提取至少一个特征。例如，可以将来自 GPS传感器的原始坐标转换成用户光顾的地方或者用户花费一定时间量(例 如，大于10分钟)的地方。为此，系统检查何时用户处于某个位置大于预定 时间，并且如果情况是这样，则使用例如查找表来确定在那个地方有什么。在 此情况下，特征提取过程将原始GPS坐标转换成用户花费他或她的时间的地 方的列表。所提取的特征可以被看作构造块，根据所述构造块在下一步骤中构 建简档条目。所以，在此示例中，每个构造块包含用户光顾的地方，并且每个 构造块可以包括附加属性，比如，例如在那个位置花费的时间。

在另一示例中，将来自一个或多个惯性传感器的原始信号转 换成用户的姿势或活动。姿势可以是表示移动电话、智能手表、运动装备等的 移动的姿势。活动可以是人的一系列的一些基本活动(比如，例如行走、跑步、 站立、坐、躺)。在此情况下，特征提取过程将原始惯性传感器信号转换到用 户执行的姿势和/或活动的(时间戳)列表中。这里，每个构造块表示人的姿势 或活动，并且可以包括此姿势/活动的时间和持续时间。

特征提取过程需要两种类型的知识：首先，可以从哪种传感 器推断哪种特征；并且第二，如何将传感器信号转换成特征或构造块。SP将 创建并维护指示可以针对每个传感器推断的特征以及使用哪个模型/算法来将 传感器信号转换成特征的数据库。

下一步骤是简档条目推断过程。在此步骤中，将所提取的特 征转换成简档条目和条目数据。初步地，可以识别至少部分地取决于特征的至 少一条简档条目。换言之，根据构造块来构造简档条目。例如，使用用户去过 的地方的列表，可以从用户光顾的杂货店推断出许多事情：用户一直去同一家 杂货店吗？用户去所述杂货店的频率如何？用户是否购买了有机食品？在活 动的示例中，可以推断出：用户是否有办公室工作；用户是否行走足够；用户 是否执行规律的物理活动等。所推断的信息然后可以用作针对用户简档条目的 输入。

相应地，可以确定至少一条简档条目的至少部分地基于所识 别特征的条目数据。例如，对于每条简档条目，必须对所需的特征或构造块进 行限定，并且模型/算法应当可用于将(多个)特征转换成简档条目。此信息可 以以数据库的形式提供。

在最后的步骤中，将所推断的条目输入到用户简档中。这可 以包括通过合并所确定的条目数据来生成简档的简档条目。还可以将条目数据 合并到多个简档条目中。基于所提取的特征，可以确定哪些简档条目可以被创 建或修改。一方面，可以针对条目数据来确定传感器活动，从而使得传感器活 动可以与简档条目相关联。这意味着关于针对推断简档所需的和所使用的传感 器和传感器数据(数量)的信息可以与简档条目相关联。所推断的条目数据可 以用于仍然是空的简档条目，或者用于已经具有信息的简档条目。可以在不通知用户的情况下对简档进行更新或编辑。可替代地，当他或她的简档已经被修 改时，用户接收到消息。在另一个示例中，在对简档进行任何修改之前，首先 必须向用户要求许可。如果新条目与已有条目一样，则用户可能不需要意识到。 则还可以增大那个特定条目的置信因数。如果新条目与已有条目不同，则可以 取代已有条目。如果条目是不同的或者是矛盾的，则系统可以暂时停止任何改 变，并且在做出决定之前等待更多传感器信息。系统还可以从用户那里请求信 息/帮助，以便试图解决任何分歧问题。

可以以不同的方式或模式来控制或驱动将传感器数据转换成简档条目的整个过程。所述过程可以是传感器驱动的，其中，只要有可能就对传感器数据进行分析，并且将其转换成简档条目。可替代地，所述过程可以是简档或条目驱动的。在此情况下，请求填写或验证特定的简档条目，并且根据所述条目，对一个或多个传感器的数据进行分析直到可以推断出简档条目。此请求可以来自用户、SP或者甚至第三方。不同模式的操作和/或切换可以由SP来手动或自动地管理。

当简档具有许多需要填写的条目和/或足够的电池和处理能 力可用时，可以使用传感器驱动过程(图28)。用户或SP可以选择传感器是 ‘一直开启’的传感器配置或传感器简档，以便收集最大的传感器数据。对于 每个有源传感器，推断出可直接推断的简档条目或可能的特征和构造块。接下 来，可以验证可基于所产生的构造块来推断哪些简档条目，并且对于这些条目 是否所有所需的块都是可用的。可能会发生在条目中使用了某个构造块，但是 此条目另外需要其他不可用的块，因为适当的传感器不是可用的或有源的，或 者没有足够的数据可用。在此情况下，SP可以调整传感器配置以便获得丢失 的传感器数据和信息。这种修改可以取决于可用的传感器以及处理资源和功率 资源。SP可以根据经修改的传感器配置来自动操作传感器组件，或者可以首 先向用户要求许可。这种传感器配置修改可以是即时静态修改，或者可以是随 时间推移而变化的动态配置，以便在适当的时间收集传感器数据。

当用户或系统(SP)请求对某个简档条目的验证或填写时， 可以使用简档驱动过程。请求还可以间接地来自第三方。当用户手动输入简档 条目并且系统请求验证或确认条目以便查看条目是否是正确的(即，用户是否 说实话)时，可以启动简档或条目驱动过程。例如，假设用户指示他或她吃的 健康。为了验证此手动条目，系统可以检查用户光顾的杂货店以及餐馆来查看 是否与健康饮食习惯对应。类似地，如果用户指示他或她经常地练习运动，则 系统可以决定监测GPS和惯性传感器数据来验证此条目。对于验证过程，系 统可以首先检查所需的传感器数据或特征是否已经可用并且为用户存储。如果 情况是这样，则此数据可以用于验证简档条目。如果一些或所有数据或特征丢 失，则系统可以建立使能进行验证条目的传感器配置或简档。

图29中示出了在请求之后用于完成或验证简档条目的简档 驱动过程。此过程使用如图27和图28中的相同数据库。首先，‘特征到条目’ DB用于确定当验证某个条目时来寻找什么特征。如果所述特征不存在(例如， 存储在某种形式的存储器上)或者无法从已有传感器数据中推断，则接下来‘每 个传感器的特征’DB用于确定使用哪个传感器以及如何将传感器数据转换成 特征。

可以以不同的方式构建用于将特征转换成简档条目的数据 库。DB可以由SP或第三方手动创建(可能是来自用户的建议)。在此情况下， 在某个条目与某些特征之间手动地限定规则集。在健康饮食的示例中，这意味 着提供了与健康饮食相对应的杂货店和餐馆的列表。手动创建需要大量精力来 试图覆盖所有可能的特征(在此情况下可能是商店和餐馆)。因此，可能优选 的是在任何可能的地方和时间的自动创建过程。这意味着在传感器数据、特征 与简档条目之间的所需关系可以基于对多个用户简档以及用于获得这些简档 中的简档条目的传感器、传感器数据和特征的分析。在一个示例中，可以使用 由不同用户进行的手动条目来构建数据库规则。用户组可能都指出他们吃的健 康。对于这个组，系统可以监测他们光顾的杂货店和餐馆。通过具有足够的数 据和统计，可以在饮食健康和与其相关联的杂货店和餐馆之间建立关系。可以 计算在特征与条目之间的相关性强度，这可以帮助确定置信因数。

图30中示出了此过程，其表明某些用户的手动条目可以用 于构建可以用于其他用户的‘特征到条目’DB。可以基于不同用户的历史来 调整他们的贡献权重。例如，已知添加正确数据的用户的贡献可以增大。可以 使用类似的方法来构建用于了解要从传感器中提取哪个特征的数据库。

当传感器数据到来时可以立即完成特征提取，或者可以在稍 后的(预定)时间完成。特征越复杂并且需要越多的数据，此过程需要一定时 间的可能性越高。换言之，构建构造块可能需要一定时间量。当这些块所需的 一些数据已经被传送时，可以开始构建构造块。可以启动过程来检查是否所有 数据都可用以及数据是否丢失，可以启动对此数据的周期性检查，直到构造块 完成。这意味着构造块可以具有对来自预定DCO的数据的某种‘订阅’，并 且产生新数据的任何时间都执行构造块过程，并且验证是否所有所需数据都已 经可用，这样构造块可以完成。基于可用以及将变得可用的构造块，可以使用 类似的过程来构建简档条目。同样的数据‘订阅’也可以用于验证条目没有随 时间推移而改变。

在以上关于简档条目从传感器数据的推断的讨论中，作为示 例呈现了2步法。使用更多或更少步骤的其他方法同样存在，并且可以导致相 同的结果。在一些实施例中，可以使用神经网络，其可以取代以上所讨论的所 有或一些算法或步骤。还可以使用将神经网络与例如以上所讨论的2步法组合 的混合策略。例如，对于一些简档条目可以使用2步法，并且对于其他简档条 目可以使用神经网络。最佳选项可以取决于需要分析和变换的传感器数据的类 型和复杂度。在一些示例中，神经网络可以用于从传感器数据到简档条目的完整推断，这意味着传感器数据是神经网络的输入，并且简档条目是神经网络的 输出。在其他示例中，第一步骤可以由从传感器数据中提取一个或多个特征组 成，并且在第二步骤中，这些特征用作到神经网络的输入以便推断简档条目(图 31)。可以由用户例如通过使用来自其他用户的手动输入的数据来提供用于神 经网络的训练数据。在一些实施例中，神经网络可以输出可以用于简档条目的 分类的混淆矩阵。另外，混淆矩阵可以用于计算置信因数。

用户状态

在SP看来或者在不同的供应商或第三方看来，不同的用户 可能具有不同的重要性。这种重要性可以表示为状态，并且因此用户针对SP 和针对特定的第三方具有不同的状态。用户简档的一个或多个简档条目可以与 用户状态有关。如将从以下的示例中变得明显的，可以链接SP和第三方的状 态，其中，SP的高状态同样意味着第三方的高状态。SP的状态和第三方的状 态作为简档条目可以是简档的一部分，或者可以是在货币化选项、数据再利用 或其他形式的补偿中使用的单独的参数。

SP的状态——SP从用户提供的数据中构建简档条目。一些 数据可以是不言自明的并且可立即用于简档条目，但是一些数据在其可以用于 简档条目之前需要使用例如算法或模型来进行处理。为了开发这些模型，SP 可能需要用户的帮助。用户的帮助可以采用用户注释的形式。

对于SP，当需要时，理想用户提供具有高质量和高频率、覆 盖宽范围的不同领域、并且具有良好的注释的大量数据。这将帮助针对用户构 建良好简档，并且另外开发算法或模型，所述算法或模型可以帮助其他用户构 建他们的模型，即使他们提供具有很少或没有注释的较差数据。不同的用户具 有每个特定领域的不同的能力和知识，并且因此可以在一定水平上提供注释。 例如，具有电子球拍的网球运动员可以提供来自他或她的球拍的传感器数据， 并且可以注释摆动类型。此用户可能不能够确定摆动是否正确执行。另一方面，网球教练将能够更精确的对网球摆动进行注释，指示所述摆动是较好还是较 差，以及可能为什么。另外，网球教练将更经常打网球，并且因此可以提供更 多的网球相关数据。因此，对于SP来说，网球教练比普通网球运动员更重要， 因为教练可以提供使用更多信息或更精确的进行注释的更多数据。注释还可以 是用户手动填写的一些简档条目，并且可以指示哪个数据事件与此条目有关。 例如，用户可以指示他或她饮食健康，并且当用户去杂货店或餐馆时，用户可 以指示他或她是否认为此位置符合健康饮食条目(或不符合)。

在介绍中已经提到，收集传感器数据和传感器数据注释的目 的是为了构建(更好的)模型和算法。可能具有某些技术背景的高级用户还可 以能够提供深入了解或帮助构建这些模型。在此情况下，用户可以是个人或公 司。这些因素也可以考虑在内以供状态定义。

图32示出了通过状态定义算法来将用户数据转换成用户状 态的原理。从用户数据中提取不同的重要因素，并且可以在算法中给予每个因 素不同的权重。所示出的因素仅仅充当示例。

状态可以具有动态特性，其中，用户必须继续贡献他或她的 传感器数据以便维持当前状态。这避免了一旦实现某个状态用户就停止做贡 献。因此，传感器数据和传感器数据注释的贡献频率是重要的。状态的动态行 为可以直接链接到传感器数据贡献的动态行为。SP可以限定对此动态链接进 行控制的规则或算法。

可以考虑整个简档来限定状态，或者可以每个(感兴趣的) 类别或领域来限定状态。用户可以在一个领域中具有高状态并且在其他领域中 具有其他状态。可以组合不同领域的不同状态来生成整体状态。

具有较高状态的用户可以从SP接收更多和/或更好的交易。 例如，用户可以为货币化选项提供较高频率，或者可以收取较少的佣金来支持 用户的货币利益。

高SP状态可能对用户有好处。例如，SP可以通过提高货币 化选项和其他形式的补偿的数量和质量来给用户有利的处理。

供应商的状态——供应商或第三方可能不关心用户向SP提 供了多少数据，而是可能对用户是否帮助供应商销售更多供应商的商品和/或服 务感兴趣。用户本身可以从供应商购买某物，或者可以激励他的联系人中的一 个或多个来进行购买。例如，考虑喜欢去越野跑步并且想要购买新的越野跑鞋 的用户。如果此用户跑步很多，则他或她将经常需要新鞋，并且因此，此用户 将比跑步很少并且因此不用很经常买新鞋的用户更感兴趣。类似地，如果此用 户具有同样进行大量越野跑步的朋友，则这将使得所述用户对于供应商甚至更 感兴趣。因此，大量跑步并且具有同样跑步的许多朋友的用户对于销售跑步鞋 的供应商来说具有高状态。显然，如果用户不会或者很少购买类似于供应商销 售的那些产品的产品，则此用户对于供应商或第三方来说具有非常低的状态。

使用网球运动员和教练的示例，在SP的状态与第三方的状 态之间存在的联系变得明显。网球教练将最可能知道更多打网球的人。因此， 如果网球产品的供应商向教练提供感兴趣的交易，则教练可以向供应商发送更 多潜在的客户。在此情况下，对于SP以及对于网球产品的供应商来说，教练 具有高状态。常常，在某个领域中具有较高知识量的用户同样在那个领域具有 许多联系人。

供应商感兴趣的是向具有高状态的用户提供感兴趣的货币 化选项，因为这将使用户满意，这意味着他或她可能会回来，甚至更重要的是， 可能会激励他或她的联系人之一到供应商。

可以考虑整个简档来限定状态，或者可以每个(感兴趣的) 类别或领域来限定状态。用户可以在一个领域中具有高状态并且在其他领域中 具有其他状态。可以组合不同领域的不同状态来生成整体状态。供应商通常只 对供应商领域中的状态感兴趣。

跑步者买鞋的示例是具有非常低频率的购买事件的示例。对 于一些类型的供应商，用户光顾的频率可能同样是重要的。继续跑步者的示例； 用户可以在供应商附近经常跑步，所述供应商可以在跑步之后向他或她提供清 凉的饮料。对于供应商来说，感兴趣的是定期返回的客户。所以，对于此供应 商，是潜在高频客户的用户应当具有较高状态。另外，如果用户是通常与其他 跑步者一起跑步的跑步者，则这意味着所述用户可以为供应商带来更多潜在的 客户。群体效应甚至可能超过线性，因为一个组中的跑步者更有可能为了社交 影响而喝饮料(跑步者本身可能只是在他回家后才喝饮料)。第三方状态可以 包括用户可以如何为第三方带来生意或收入的不同特性，比如，例如生意的频 率、用户可以激励的联系人等。

用户的第三方状态可以在用户可能为供应商带来的潜在收 入中表示。潜在收入的计算还可以将用户的联系人考虑在内。图33示出了状 态计算的示例，如作为用户可以带给供应商的总潜在值来表示的。将继续想要 购买新越野跑鞋的跑步者的示例来解释所述附图。用户可以向SP表明他或她 想要买新越野跑鞋，并且SP联系供应商来为用户制作个人化要约(关于此机 制的更多详细信息，参见以下进一步的讨论)。基于SP向供应商提供的关于 例如用户跑步习惯的简档信息，供应商提出提议。可以将所提出的产品的销售 值(或利润)乘以将购买概率考虑在内的因数，从而给出可能值。如果用户住 在附近，或者他或她上班时路过，则概率可能较高。如果用户住的很远，则概 率要低得多。SP可以基于用户过去的习惯(例如，用户通常开车多远去买东 西)、或者基于对用户组或所有用户的一般分析来估计这些重要因素。

除了用户的可能值之外，还可以确定用户联系人的可能值。 对于每个联系人，应当确定购买概率。对于联系人，这可能涉及附加因素。在 示例中，用户已经声明他或她正想要购买新鞋。然而，联系人可能没有发表这 种声明。因此，SP必须包括考虑到联系人购买的可能必要性的因素。SP可以 通过比较最新购买的跑步鞋的日期与购买新鞋之间的平均时间(或公里)量来 做到这一点。需要考虑的附加因素是用户激励联系人去供应商的可能性。可以 基于用户的先前动作和货币化选项来确定此因素。SP或供应商可以刺激用户 这样做，例如通过许诺如果他或她的联系人进行购买则给予附加折扣。

在此示例中，可能值的计算只集中在用户请求货币化选项的 产品上。然而，如果供应商还有用户可能感兴趣的其他产品提供，如果用户感 兴趣的产品的可能性也考虑在内，则这些产品同样可以包括在计算中。

为供应商计算可能值取决于产品。这意味着一旦知道用户的 请求就可以计算所述值。如果没有请求，基于例如用户过去的购买历史同样可 以推导出所述值。供应商的可能值(其在这种情况下可以表示用户的状态)可 以与对货币化选项的请求一起被发送给供应商(参见以下进一步的讨论)。

值

将所生成的简档用于货币化选项来为用户获得补偿。这意味 着用户简档具有值。因为简档是由数据构成的，所以数据具有值。由于用户、 SP和第三方之间的三角关系，存在针对每一方的值。一般而言，任何适当的 技术都可以应用于建立简档条目的值。

简档值——当用户基于从简档提取的一定量信息而获得具 有来自第三方的某些补偿的货币化选项时，可以声明此信息具有此值。例如， 如以上所描述的通过变换至少一条简档条目而推导出的可交换简档可以被传 输至第三方并且可以接收补偿作为交换。术语传输可以不必意味着信息传输至 另一设备，例如，设备属于第三方。第三方可以由在SP服务器上运行的模块 或应用来表示，并且在此情形下，术语传输意味着第三方将访问‘所传输的’ 信息。图34示出了计算简档值的概率。SP通过分别向第三方A和第三方B传 输可交换简档提取A和B来为用户安排补偿A和B。这意味着简档提取的组 合值具有值A+B。可交换简档的值等于所有简档提取的值之和。换言之，对 于用户来说，简档的值是他或她已经获得的所有补偿的值的总和。此值可以被 称为实际值、历史值或获得值，因为所述值基于已经发生的动作。此值可以是 自从用户创建他或她的简档之日起的总和，或者可以表示为时间段，比如，例 如每月或每年。对于用户组(例如具有与所述用户类似简档的用户)，或者对于订阅服务的所有用户，可以根据用户来确定每个时间段的平均历史值。因此， 可以通过聚集多个经变换简档条目的所建立的值来确定所述可交换简档的值。

在大多数情形下，供应商将货币化选项与信息集合交换，并 不只是单个信息项。图34示出了例如对于补偿A和B分别使用了条目2-3和 条目6-8。从这些方程中不可能推断出特定变换条目的实际值。然而，随着使 用越来越多的货币化选项，利用不同的条目组合，可以为用户推断出实际的单 独条目值。例如，可以至少部分地基于与至少一个完成的交换的比较来建立经 变换简档条目的值。所述至少一个完成的交换可以是涉及用户的先前交换，但 是还可以涉及其他用户。通过对交换数据库进行维护，可以针对简档条目确定 平均值。此外，将所述值与用于获得传感器数据的传感器配置相关联可以用于 引导配置设置。所述值还可以基于来自第三方的请求来建立。进一步地，通过 分析一组不同用户的货币化选项，产生某个值的条目组合的组合数量可以使能 确定用于每个特定的经变换简档条目的值。这可以是每个简档条目的平均值。 然而，当与其他值组合时，某个条目可以仅具有值。在此情况下，可以确定条 目组合的值。假设，在统计上，不同用户具有不同的隐私设置，还可以针对每 条简档条目确定隐私设置的影响，比如通过将所述值与在经变换简档条目中的 条目数据的给定粒度相关联。换言之，对具有不同条目和隐私设置的所有货币 化选项和其他形式补偿进行的统计分析使能计算每条简档条目的平均值(根据 隐私设置或粒度)。隐私对值的影响帮助SP向用户显示当他或她改变隐私设 置时所述值如何变化。例如，所述补偿可以至少部分地基于条目数据的粒度级 别。对所有用户的统计分析可以包括具有许多不同特性、习惯等的用户。如果 统计允许，则可以对减小的用户组执行类似的分析，其中，可以做出选择以便 选择与特定用户尽可能类似的用户。如此计算的简档条目值与这个特定用户更 相关。相应地，可以通过选择和应用不同的粒度级别来调整针对经变换简档条 目所建立的值。为了优化补偿，不同的粒度级别可以对应于最大可获得的粒度 级别。

用于某个用户的简档条目的单独值可以进行求和以便确定 完整简档的值。然而，对用户来说，充分利用每个简档条目可能是非常困难的。 此简档值因此可以被称为理论或假设简档值。通过对所有用户或用户组的值进 行平均，SP可以确定平均理想简档值。

代替此理想简档值，SP还可以能够针对特定的用户确定预期 的或投影的简档值。例如，假设用户订阅服务并且以空简档开始。此时，关于 用户一无所知，并且因此预期的简档值可以等于平均简档值。随着用户贡献数 据并且构建简档，用户与逐渐地与具有类似简档的较小组的用户进行比较。预 期值然后等于所述较小用户组的平均简档值。用户构建他或她的简档越多，预 期的值可以确定的越准确。如果已知用户的购买/花费习惯(例如，通过购买记 录或银行记录)，则SP可以能够基于用户建档和其他用户用于类似产品和/或 商品的历史货币化选项来为用户计算预期的货币收益。这里同样的推理是有效 的；SP关于用户知道的越多，类似用户的组就越小，并且预期值的估计就越 好。

以上讨论集中在针对用户的简档和条目的值。在大多数情形 下，当用户使用货币化选项时，SP将接收较小的佣金。这意味着还可以针对 SP的佣金而不是用户的补偿来完成以上的许多计算。例如，基于在使用货币 化选项时SP所接收的所有佣金，可以确定用户简档或简档条目的平均总佣金。

这里讨论的所有不同类型的值都可以根据简档类别来确定。 这意味着例如用户可以得到关于与他或她的汽车、房屋等有关的简档的值的反 馈。

如在关于简档的动态性的部分中所讨论的，简档不是静态 的。必须通过提供数据来保持简档最新，这样SP可以继续验证所有简档条目 仍然正确。如以上所讨论的，在某个简档条目中的置信随时间推移而下降。在 一个示例实施例中，可以假设在值与置信因数之间存在直接/线性关系，这意味 着如果置信由于某个因素而下降，则所述值由于同一因素而下降。结合上文的 值计算，这意味着对于所讨论的所有不同类型的值，可以基于置信因数随时间 推移的变化来预测这些值随时间推移的变化。甚至对于所述值与置信因数之间的非线性关系，可以进行这种预测。

数据值——

以上讨论表明可以采用相当简单的方法从所获得的补偿中 来确定简档的值。当更详细地确定简档条目的值时，计算变得更加复杂，并且 需要来自不同用户的更多统计来确定简档条目与简档值之间的关系。当试图确 定传感器或数据的值时，一个或多个附加的复杂层被添加至方程。

每个简档条目基于来自一个或多个DCO或传感器的数据。 如果可以通过只使用一个传感器或DCO来推断条目，则此条目的值可以归属 于所述传感器。一方面，所述值可以至少部分地基于传感器的活动。针对简档 或简档条目的传感器活动必须向简档和条目进行注册或与其相关联以便执行 这种评估。如果多于一个传感器用于进行对简档条目的推断，则必须在传感器 或DCO上对此条目的值进行划分。作为一阶近似，此划分可以以等分的方式 完成。为了更准确的计算，必须确定和量化针对每个DCO的条目的贡献，并 且将其用作针对每个传感器进行条目值划分中的权重。可以通过对来自用于确 定简档条目DCO的数据进行量化来计算这种贡献。数据量化可以基于例如数 据点的数量、千字节的数量、传感器的运行时间、传感器的电池消耗、数据的 频率等。一旦已经对条目的贡献进行了量化，就可以根据其贡献在DCO上对 所述条目的值进行划分。

通过将不同的值贡献添加到每个条目，可以计算每个传感器 或DCO的总值。这个值还可以例如按照数据点的数量、按照千字节的数量、 按照传感器时间的数量等来表示。这可以针对每个DCO来完成，而且还可以 针对所有组合的传感器来完成，从而按照数据点的数量、按照千字节的数量、 按照总组合的传感器时间量等给出总值。

虽然这种讨论示出了如何确定不同DCO和传感器在简档条 目级别的值贡献，但是还可以在完整简档级别完成类似的计算。例如，对于每 个传感器或DCO，可以按照DCO来确定数据点的总数量、千字节的总数量、 传感器的总运行时间、传感器的总电池消耗。在此情况下，‘总’意味着对整 个简档的贡献。然后可以根据此量化的结果将整个简档的值分布在不同DCO 上，这然后给出了DCO的值。

基于以上所讨论的方法，有可能可以确定包括不同传感器简 档和传感器设置的传感器配置的值。这可以针对一个简档条目来完成，或者针 对作为整体的包括多个简档条目的用户简档来完成。可以基于所请求的补偿量 来推导出传感器配置。具有需要更多时间运行的更多传感器的传感器配置或简 档将产生较大的值。因此，大多数情况下，用户感兴趣的是使用尽可能多的传 感器。然而，缺点是更多的传感器意味着更高的处理能力和更多的电池使用。 可以针对可能不同的传感器简档来确定预期值，并且当用户必须对传感器简档 进行设置时可以向他或她指示所述预期值以便说服他或她使用更多传感器。SP 可以基于用户习惯来为用户建议最优传感器简档。例如，对于每晚对电话进行 充电的用户，最优传感器简档是在使电池持续运行直到晚上下一次充电时使用 最大的传感器活动量的那一个。类似推理同样适用于传输数据的潜在成本。例 如，如果用户必须付费将数据传输至SP，则这些传输成本可以在有效值计算 中考虑在内。

还可以以类似的方式根据设备来执行以上执行的用于确定 每个传感器或DCO的值的计算。此信息可以用作市场营销工具。例如，当用 户对购买配备有一个或多个传感器的设备感兴趣时，SP可以能够基于用户简 档和/或来自已经使用所述设备的其他用户的信息来预测值收益。

补偿和货币化选项

一旦用户已经构建了简档，SP就可以使用简档来为用户生成 货币化选项以及其他形式的补偿。如在关于隐私管理的部分所讨论的，SP使 用可交换简档来生成这些选项。顾名思义，货币化选项提供了一种用户获得补 偿的方式，所述补偿以来自他或她的简档的信息作为交换，并且其可以看作对 提供(传感器)数据的一种奖励(图35)。货币化选项可以由用户或SP来发 起。不同选项是可用的，诸如，例如：

“个人化要约”：SP为用户安排商品或服务的个人化要约。 在一个实施例中，使用用户简档作为激励供应商来制作他们的要约的方式，SP 通过供应商之间的拍卖过程或其他适当的协商来“协商”最佳可能的要约(补 偿)。在另一示例中，用户可以与单个供应商或第三方进行交易，但是针对所 提供的补偿来协商所提供的信息。不同实施例的组合也是可能的。要约是个人 的，并且用户需要要约的证明(例如，优惠券)，以便在供应商处兑换要约。 所获得的折扣可以被认为是补偿。SP接收用于协商要约的佣金。

“广告”：这种类型的广告类似于要约，从某种意义上来说， SP联系供应商并向供应商提供用于基于用户简档向用户提出广告的选项。供 应商支付将能够向用户提出广告的费用。在供应商之间的拍卖过程或其他协商 (例如，针对最高费用)可以决定可以提出广告的供应商。与个人要约相反， 广告不是个人的并且在广告中推广的商品或服务以同样的价格可用于公众。供 应商用于广告的费用可以被认为是补偿。

“问卷”：商品和服务的供应商、制造商和提供商可能对用 户关于他们商品和服务的反馈感兴趣。SP可以通过基于用户简档选择适当的 目标用户来为对进行调查感兴趣的各方提供服务。定制调查的一方向用户支付 填写问卷的费用。

在已经创建简档之后，可以生成货币化选项。货币化选项可 以由同样已经创建简档的同一SP来生成。可替代地，可以允许不止一个SP 提供货币化选项(同样参见图15和16)。在这种情况下，简档将被提供给每 个SP。特定SP可以专用于特定领域的货币化选项。在这种情况下，此SP可 以使用调整/简化简档来仅处理此领域的货币化选项。不同SP可以全部是独立 的并且与用户直接联系，或中心SP可以控制这些SP。

还可以基于所提出的补偿来生成简档。例如，基于来自提供 某种补偿来交换某种简档信息的第三方的请求，SP可以采取措施来生成具有 所期望信息的可交换简档。SP可以调整传感器配置以便使得能够生成这种所 期望的信息。在进行所请求的传感器配置变更之前，SP可以从用户那里请求 许可。

SP负责创建包含用于货币化选项以及其他形式补偿的所有 所需信息的供应商和第三方数据库。这些数据库可以包含包括所述第三方的特 性的条目。某个供应商可以提供不止一种类型的货币化选项，并且选择哪个选 项的选择可以取决于用户简档。

在所有的货币化选项中，用户简档用于将关于用户的信息提 供给货币化选项的提供商。如上文所描述的通过变换至少一条简档条目而推导 出的可交换简档可以被传输至第三方并且作为交换而接收补偿。另外，针对供 应商的用户状态可以作为简档的一部分或单独地来提供。从供应商的角度来 看，所感兴趣的是来自用户的基于他或她的简档以及过去购买的物品的预期收 入、以及计算此收入的置信。SP将为与货币化选项的提供商的每次交互提供 这种信息。

现将详细讨论不同的货币化选项。

个人化要约

发起要约——个人化要约可以由用户或者由SP来发起。一 些用户可能更喜欢只有他们自己发起要约时才获得要约，并且可能由于SP所 发起的他们未请求的要约而感到烦恼。用户可以设置关于他或她更喜欢如何接 收要约的偏好。这些偏好可能非常普遍，例如，在他或她更喜欢的较高级别要 约机制上进行选择，或针对每个机制详细地设置偏好。在任何情况下，用户必 须是/感觉完全控制如何获得要约。同样，SP可以基于用户请求来识别适当的 供应商，所述用户请求可以包括所期望的补偿数量。

对于由SP发起的要约，SP可以将在用户简档的一条或多条 简档条目中的条目数据与来自第三方的一个请求或多个请求进行匹配。进一步 地，SP可以分析消费习惯、必需品以及甚至财务数据，以便优化要约。例如， 对于一些用户来说，月末时财务状况可能不允许任何休闲相关的购买，并且因 此应当根据所估计的用户的必需品来生成要约。

手动地提交请求——为获得要约，用户可以向SP启动特定 请求。使用由SP提供的并且在用户的设备(诸如，例如用户的智能电话、平 板电脑或计算机)之一上运行的工具或应用，用户可以指示他或她对购买特定 的商品或服务感兴趣。请求的细节数量取决于用户。例如，如果用户想要购买 新的跑步鞋，则用户可以确切地指定他或她将想要哪双鞋。可替代地，用户可 以仅声明他或她想要新的跑步鞋，并且然后SP(与供应商组合或不与其组合) 可以基于简档(例如，先前拥有的鞋、典型地形、用户的体重和年龄等)中的 可用信息来提出某些类型的跑步鞋。在接收到所述请求后，SP将在SP的供应 商数据中寻找合适的供应商，并且将请求转发给可能潜在地呈现个人化要约的 供应商。

用户可以为请求指定日期或日期范围。在跑步鞋的示例中， 用户可以指定例如用户想要购买新鞋的某个周。SP然后将尝试在所指定的(多 个)日期为用户获得最佳的交易。对于这些日期针对用户作出的要约可以是可 选的，意味着没有要求购买；或者购买可能是强制的，意味着根据用户说明用 户有义务从这些要约的其中之一购买鞋。可以在用户与SP之间实施财务机制 或策略以便用户履行他或她的义务，并且如果没有履行，则可以应用一些形式 的惩罚。这些安排的优点和缺点可以取决于用户的状态，其中，例如，较高状 态可能以较不严格的义务的形式带来更大的灵活性。SP可以聚集来自多个用 户的请求并且可以预测对不同商品和服务的需求。在与第三方的协商中这种信 息可能具有价值并且带来更好的补偿。所述信息以及改善的补偿还可能对不必 对某个日期作出请求的其他用户有益。这些其他用户可以受益的程度可以取决 于用户的状态。

基于在线搜索的要约——SP可以与在线搜索引擎服务建立 合作，以便检测用户是否正在执行对某些产品或服务的在线搜索。在严格意义 上，这就像一个手动请求，但是用户使用在线搜索引擎，而不是直接向SP宣 告请求。在一个实施例中，搜索引擎提供商将请求传送至处理所述请求过程的 SP。所产生的要约可以通过SP通常方法(例如，SP的应用)呈现给用户或可 以传送给负责呈现的搜索引擎提供商。

在可替代实施例中，SP将关于用户的(相关)可交换简档信 息传送给搜索引擎提供商，所述搜索引擎提供商然后进一步处理请求的过程。 用户可以意识到或请求用于将简档信息传送给搜索引擎提供商的许可。

在合作建立中，SP和搜索引擎提供商必须对如何分配从要约 中获得的佣金达成一致。

通过意愿列表进行要约——代替手动提交每个请求，用户还 可以制作用户感兴趣的商品和服务的意愿列表。用户在输入意愿列表上的物品 时可能会收到要约，在这种情况下，所述过程可以与手动提交相同。另外，用 户可以决定他或她想要定期地接收意愿列表上的物品的要约。然而对于用户想 要在短期基础上购买的商品和服务来说，手动地提交是方便的，周期性地要约 允许用户跟踪他或她想要在长期基础上购买的以及想要获得最佳交易可能的 物品的要约。在用户偏好中，用户可以设置他或她想要何时以及如何接收基于 意愿列表的要约。例如，一天一次、一周一次、手动触发、何时开始SP的应 用等。

对于周期性列出要约，其意味着在用户指定的时间段内，SP 将规律地处理用户的请求并且在此时间段内过滤要约以便将选择的提供给用 户。如果请求是手动的或来自意愿列表，则SP可以指定给供应商，因为这将 购买的紧迫性指示给供应商，所述供应商相应地可以或者可以不对要约进行调 整。

通过接近度进行要约——当在供应商或商店附近时，用户可 以接收要约。例如，当用户步行进入购物中心时，他或她可以获得相关要约。 当步行进入购物中心时，用户可以自动地接收这些要约或者用户可以手动地触 发要约。在前一种情况下，SP不断地对用户的位置进行监测来验证是否在附 近存在一些潜在的供应商。在后一种情况下，SP只需要在用户触发要约时检 查用户的位置。根据用户的意愿列表或单纯地基于用户的简档来作出要约。

用户可以设置关于如何触发要约的偏好，并且所述偏好取决 于要约的类型(例如产品的类型、折扣的量……)。用户设置还可以反映用户 何时可能被要约打扰。例如，要约的发送可以取决于用户的活动或取决于可用 时间。如果用户正在开车路过供应商，则不应进行任何要约，但是当用户行走 路过时，可以进行要约。要约还可以取决于用户与供应商之间的距离。关系可 以是动态的，从某种意义上说，为了被考虑，用户与供应商离得越远，要约必 须越能引起兴趣。在这些示例中，由SP进行的用户简档的分析并且由此推断 的用户习惯是非常重要的。

基于活动的要约——要约可以由SP基于对用户的活动和/或 位置的分析来发起。例如，用户可以是在购物中心购物并且光顾同样类型的商 店，例如用于寻找新的跑步鞋。SP可以对光顾同样类型的商店的这种行为进 行分析并且制定与这种类型商店有关的要约。因为用户没有指定请求，所以如 果商店销售各种物品，则要约可能不无法非常具体；在示例中，用户光顾的商 店可能销售鞋和服装。在这种情况下，要约可以是通常所制定的要约，诸如， 例如对任何项物品的10％的折扣。SP可以将商店中的物品与用户的简档进行 比较，并且如果用户近期已经购买了用于跑步的服装，但是他或她的跑步鞋是 相当旧的，则要约可以变成对于鞋更具体。SP可以联系拥有用户已经光顾的 商店的供应商(如果用户订阅了服务)，并且因为很明显用户在场并且想要购 买，所以所提出的折扣可能是一个重要的区别因素。

基于活动的要约可能不只是基于用户已经处于某些类型的 购物模式的活动。要约可以与现在的活动或未来活动的一部分有关。例如，如 果用户刚刚完成了跑步活动，要约可以与在训练后在附件的某处得到关于清凉 饮料的感兴趣的要约有关。在另一示例中，SP可能知道用户正计划去餐馆吃 饭(从习惯或议程)并且可以提供餐馆的感兴趣的要约。

供应商发起的要约——用户可以接收来自SP的要约，其中， 动作由供应商发起。SP可以通过将经变换简档条目与请求匹配来识别第三方、 供应商。

例如，供应商可以推出新产品并且想要为此产品确定目标用 户。供应商可以联系SP并且为产品或供应商设置所期望的或理想的用户简档。 SP可以将在SP数据库中的用户简档与目标简档进行匹配，并且以一定折扣向 这些用户提供新产品。此要约可能是在组级别上‘个人化的’，但是甚至可以 是在所选组内的进一步个人化的(例如居住较远的人可能需要更大的折扣作为 到商店购物的激励)。

当供应商在新位置开商店并且想要接触在所述地区的潜在 客户时，可以应用类似的要约策略。

构造要约——一旦已经手动地或自动地提交请求，SP就在 SP供应商数据库中执行搜索，以便找到可以能够提供所请求物品的一个或多 个供应商(图36)。同样的，可以至少部分地基于所提供的补偿和或请求而从 多个实体中选择第三方。在供应商数据库中的搜索可能受制于某些参数，所述 参数中的一些参数可以由用户进行设置。例如，用户可以设置他或她愿意前往 并且兑换要约的一定距离。这种信息还可以来自对用户习惯的分析。在这种情 况下，用户去专门买东西通常会开车多远？

供应商数据库包含订阅服务的所有供应商，并且对于每个供 应商来说，供应商简档是可用的。供应商简档包含找到正确潜在客户所需的所 有信息，诸如，位置以及供应商提供的商品和服务的类型。要约创建过程可以 是自动的并且SP实际上没有要求人来制定要约。(有可能供应商‘手动地’ 响应，但是这通常需要更多时间)。这意味着供应商还必须提供基于用户的简 档来制定要约所需的所有信息。此信息可以是供应商简档的一部分并且包含根 据用户简档来确定可获得物品的要约价格或折扣的一组规则。例如，如果用户定期地购买物品或在供应商销售的物品的类别上花费很多钱，则供应商可以指 示较高的折扣以吸引用户作为客户。类似地，如果用户具有很多居住在供应商 附近的并且定期购买相关物品的联系人，则供应商可以提出感兴趣的折扣，从 而希望用户能够将一些他的联系人带到商店。换言之，要约可以根据用户的状 态(如关于用户状态的部分所讨论的)进行调整。SP可以向供应商提供反映 基于用户的习惯用户将访问供应商的概率的参数。

SP可以向供应商提供供应商工具以便设置和管理这些规则。 这种供应商工具可以在SP服务器上的云中运行并且可以直接地连接至供应商 数据库并与其集成。供应商然后可以使用例如计算机或智能电话通过类似于网 页的远程访问来改变设置。可替代地，供应商工具可以在供应商的设备之一上 运行，例如，在供应商智能电话或台式计算机上的app。在这种情况下，供应 商工具与供应商数据库进行远程通信以便设置要约参数。

供应商可以是连锁商场或连锁专营店的一部分。在这种情况 下，可能的是，总公司或总部可以设置部分要约参数和规则，并且本地供应商 可以设置不同的参数或规则。某些企业参数可能覆盖本地参数(反之亦然)。

供应商简档的一部分可以由SP创建，并且可能对于供应商 甚至是未知的(或不可改变的)。可以基于过去的要约和销售来自动地构思这 种信息。例如，针对什么样的用户简档制作哪些要约。信息还可以与关于要约、 销售或供应商本身的用户反馈有关。

为了增大订阅服务的供应商的数据库，SP可以联系在相关联 供应商的范围内的非关联的供应商，并且向他们示出由于没有进行关联而潜在 丢失的生意。在这种情况下，供应商简档必须由SP基于关于供应商的可用信 息来创建。

图36示出了所述过程的全局概览。供应商被示出在SP的‘外 部’。在这种情况下，程序和或应用的部分在与SP进行通信的供应商处的系 统上运行。可替代地，作为如上文所解释的完整过程的构造块的所有的部件都 在SP的系统上运行。

第一要约——在接收来自SP的请求后，供应商基于用户简 档和用户状态来制定第一要约。

供应商可以以若干方式获得关于用户的信息。SP可以将相关 用户信息连同要约请求一起发送给供应商(图37)。基于用户的(隐私)设置， SP可以发送完整的可交换简档或以从可交换简档中选择的形式仅发送相关信 息。在后一种情况下，由SP从用户简档中选择相关信息并且将专用和简化的 简档传输给供应商。这种选择可能受用户的隐私设置的影响。选择过程可以遵 循与SP和用户一致的预设规则。可替代地，用户可以决定将哪种信息发送给 哪种类型的供应商。用户状态可以是用户简档的一部分或可以被单独地发送。 如上文所讨论的，用户状态被调整用于供应商的兴趣。

用户简档信息可以由供应商要约模块(VOM)来处理，所述 供应商要约模块接收用户信息以及供应商要约参数和规则作为输入。基于来自 用户的简档和状态信息，供应商规则和参数限定进行什么样的要约、每个类型 的信息有多少折扣量。还可以由SP通过对所执行的购买与用户的简档信息之 间的相关性强度进行分析来学习不同简档条目在折扣中的权重。基于来自双方 的信息，VOM可以提出第一要约。用户可以由供应商仅通过购买ID来识别， 所述购买ID由SP在没有供应商的知识的情况下链接至用户ID。使用用于每 个新请求的购买ID的目的在于供应商不能将多个请求链接至同一用户。

SP可以只发送购买ID，而不是将用户简档与购买请求一起 发送给供应商(图38)。在接收到购买请求之后，供应商可以‘采访’用户简 档来获得相关信息。当响应时，SP可以将购买ID链接至正确的用户ID以及 用户简档。所述采访由请求来自用户简档的某种信息的VOM组成，并且如果 例如所请求的物品看起来与供应商的类别相关，则用户简档将提供信息。如果 所述请求是不相关的，则VOM可以拒绝提供信息。例如，这可以是基于 OpenPDS和SafeAnwser系统(http://openpds.media.mit.edu/)。这些隐私规则 可以由SP和/或用户进行设置。

可以在时间上对用户简档的访问进行限制，其中，时间限制 可以由SP或根据用户的偏好来设置，并且可以取决于请求的类型或其被制定 的方式。

拍卖——将来自不同供应商要约模块的要约输入到要约处 理模块(OPM)，从而使得在包括第三方的自动拍卖过程中根据预设的拍卖规 则来确定用户的补偿，所述拍卖过程通常涉及对用户的可交换简档进行投标的 多个第三方。在文献中存在很多不同类型的自动拍卖和/或协商过程和算法，并 且这里没有打算讨论这些内容。本领域的技术人员将能够应用在文献中引用的 用于确定可交换简档的补偿的方法。以下内容仅仅是可能的实施例的示例，其 绝不是限制性的。在其最简单的实施例中，OPM可以在没有任何动作的情况下将要约传递给用户。OPM还可以仅选择最佳的N个要约，以便不用将过多 要约传递给用户。OPM可以按照相关性、接近度等……对要约进行排序。在 自动拍卖过程中，还可以确定可交换简档的内容。可以根据期望采用其他协商 技术。

OPM还可以包含要约比较模块或拍卖模块(AM)，所述模 块可以对来自不同供应商的价格进行比较并且对拍卖过程进行调节(图39)。 例如，假设AM接收来自供应商1和供应商2的要约。如果供应商1具有比供 应商2更好的第一要约，这可能被供应商2知道，则后者然后可能决定制作比 供应商1的第一要约更好的第二要约。因为这可能是自动的过程，并且实际上 没有任何人参与此拍卖过程，所以拍卖规则必须由供应商预先设置。这些拍卖规则可以是供应商简档的一部分，或者可以单独地存储。

在一个示例中，每个供应商可以具有在供应商之间变化的各 种折扣级别或百分比(例如，5％、10％和15％)。对于所述第一要约，供应商 可以应用最低的折扣级别。然而，另一个供应商可能具有较高的第一折扣级别 或较低的初始销售价格，使得有效要约对于用户更感兴趣。在这种情况下，拍 卖规则对所述第一供应商何时可以应用更高的折扣百分比来获得更好的要约 进行调节。确定何时出价高于另一个供应商的拍卖规则可以取决于例如用户状 态、用户的接近度、相关联系人的数量等。因此，拍卖决定是基于拍卖规则和用户简档的组合做出的。拍卖规则还可以考虑参与拍卖的其他供应商的简档。 拍卖规则还可以考虑要约的时间方面。例如，某些要约可能只在一定的时间内 有价值或者所述要约可能减少用户等待的时间。SP可以根据SP具有的用户的 习惯和日程安排的知识来考虑用户实际前往并且兑换要约的可能性。在AM中 的算法对所有的不同规则、参数以及拍卖过程的方面进行处理并且计算最好的 (多个)要约。用户可以限定他或她希望接收多少(竞争)要约。

还有可能的是，AM算法无法确定对于用户来说什么是最好 的要约。例如，供应商1可能给出比供应商2更好的要约，但是要约是在较短 的时间段内有效的。在这种情况下，这两个要约可能都被呈现给用户，然后所 述用户可以做出决定。这种规则可以甚至包括在用户简档中，但是可能添加了 对一些用户来说太复杂的层。可替代地，还可以使用其他信息来源来解决一些 这类问题。例如，使用用户的议程，SP可以预先知道用户将没有时间来获得 时间限制的要约。但是再次，这可能是用户可能需要做出的决定，因为他或她 的日程安排可能是灵活的。

除了灵活的折扣率，SP佣金或费用也可以是灵活的。类似于 折扣级别，SP佣金也可以具有不同的级别，意味着不同供应商可能为SP提出 不同的佣金。类似策略可以应用于佣金级别(如上文所讨论的折扣级别一样)， 并且在拍卖过程期间SP佣金可能是变化的。例如，如果用户针对SP具有高状 态，如果这使用户获得更好的交易，则在拍卖期间SP可以减少SP的佣金。

可能存在以下情况，其中，竞争供应商的设置导致用户的最 大利润而其他的要约导致SP的最大利润。可以设置规则，从而使得用户的利 润胜过SP的利润(可以设置范围)。

拍卖规则可以是自适应的。这意味着规则可以基于与竞争供 应商的过去拍卖过程而演进。例如，如果供应商总是失去要约竞争，因为供应 商的折扣百分比有点太低，则SP可以通知供应商并且可以能够进行模拟增加 百分比的结果。

递送要约——一旦要约过程模块已经确定最终要约，则这些 要约必须被传输至用户(图40)。这种任务可以由要约传输模块(OTM)来 执行。当接收到来自OPM的要约时，供应商可以由供应商ID号来表示并且用 户通过购买ID号来表示。OTM收集来自供应商和用户数据库的相关信息以便 对应的ID号。供应商信息包含姓名、地址以及其他所需的信息。另外，也可 以添加关于供应商的补充信息(诸如客户评论)。还可能对用户感兴趣的是， 查看来自用户简档的供应商访问用于制定要约的信息。如果需要，则此信息可 以用于调整对用户简档的访问。所用的要约信息和历史可以存储在SP数据库 中以供将来引用。

然后将要约信息传送至用户。例如，这可能借助于电子邮件、 短信服务或由SP设计的专用应用或工具来完成。还可以将为用户制定的要约 传达给供应商，因此，供应商意识到要约已经呈现给用户。当将要约传输给用 户时，对于SP供应商是已知的，但是用户对于SP仍然是匿名的，因为要约可 以使用用户ID来传输。对于个人化要约，供应商可能需要识别用户。对于供 应商来说，与要约有关的购买ID可能是充足的，因为这使供应商能够识别要 约被提出给的用户。一些供应商可能要求或期望知道用户的确切身份。因为 SP不知道此身份，所以用户应用或工具必须将此信息直接传输给供应商，从 而使得用户身份对SP保持未知。此传输的细节可以合并到要约，并且还可以 取决于用户的(隐私)设置。

要约递送的时刻可以取决于请求需求的方法。例如，如果用 户手动地提交请求，要约可能被尽可能快地制定并且递送，因为有很大可能性 用户正在等待要约。另一方面，如果要约是例如通过存在在潜在供应商的预设 范围内自动生成的，递送的时刻可能根据用户的活动和/或位置来选择。在一个 示例中，用户可以在移动设备(诸如，例如智能电话)上接收要约，所述移动 设备运行合并要约传递模块(ODM)的专用应用或工具。ODM接收要约信息， 并且决定根据例如用户的位置和/或活动在适当的时刻使用户意识到。例如，如 果用户正在开车，ODM可以等待直到用户停止开车。通常，应当对app进行 编程以等待活动中的适当暂停。例外可能是当用户正很接近时，并且如果等待 则意味着用户本身正与供应商远离。可以对ODM进行编程以便选择最佳时刻 从而获得尽可能高的潜在转换率，同时考虑到用户的安全。

在可替代实施例中，要约信息可以存储在SP服务器上的 ODM中，等待设备发出要约可以被传送的信号。在这种情况下，应用监测设 备的活动，并且在适当的时刻向ODM发信号以便递送要约。在另一示例中， 如果用户正在线传输他或她的传感器数据，可以在云中决定对适当时刻的分 析。

尽管在最初要约被认为是个人化的，但是供应商可以允许将 要约传送给用户的联系人。例如，如果用户联系中之一具有类似的简档并且可 能对供应商具有类似的兴趣。SP可以负责此传送，在这种情况下，要约变成 对用户的(多个)联系人的个人化。

要约后分析——对于SP和供应商，其可能对知道在要约已 经被接收之后的行为/动作/反应感兴趣。此信息可以用于增加以及改进要约和 服务。

如果用户使用SP的应用或工具访问要约，则可以测量他或 她是否打开了要约信息并且他或她检查每条要约的时长。在最初打开要约后， 也许可能看到用户是否做了任何后续动作(例如，在互联网上)以便寻找较好 的要约。如果用户向SP提供了足够的数据，则可以进行这种分析。

在要约后通过监测用户的动作，SP可以能够验证用户实际上 是否来到供应商的商场，但是可能没有购买物品。在这种情况下，要约可以被 看作广告，并且针对这些情况，可以在SP与供应商之间确定专用费用。

可以在用户可能响应要约(例如，对要约进行评级，或者指 示要约是否感兴趣)时实施系统。此信息可以用于改进未来要约并且调整用户 简档。这种反馈可以如关于货币化选项部分的上文中所提及的那样进行处理， 并且在下文关于问卷部分中更详细的讨论。

兑换要约——当用户接收到他或她想要使用的个人化要约 时，用户应当能够在供应商处兑换要约。

为了兑换个人化要约，当用户前往供应商处时，用户必须证 明他或她具有使用特定要约的权利。在一个示例中，用户可以能够通过示出 QR码或等效物(例如优惠券参考……)来证明要约。可以将QR码与要约一 起立刻发送给用户。可替代地，用户可能需要按下按钮来下载QR码。这对于 监测用户对不同要约的兴趣具有优点。当将要约示出给供应商时，所约定折扣 应当应用于用户想要购买的商品或服务。供应商可能请求识别用户，以便确认 用户具有使用要约的权利。此确认可以通过将用户呈现的要约与通过SP发送 给供应商的要约通知进行比较而发生。此确认可以手动地完成，或可以通过均 由SP提供提供的用户app与供应商工具之间的通信来完成。如果用户使用他 的电话支付，SP app可以负责应用折扣。与供应商(系统)通信的其他装置(诸 如，例如蓝牙、NFC等)同样可以用于兑换要约。

在可替代实施例中，用户最初没有接收到折扣而支付全额价 格。供应商然后将折扣传送给SP，并且SP将折扣传送给用户，从而最小化佣 金费用。SP可以定期(例如，一月一次)向用户进行支付。这种方法具有的 优点是，用户变得更加意识到他或她可以从由SP提供的服务中作为交换数据 而获得的补偿。

除了对用户应用折扣外，当兑换要约时，供应商还必须向SP 传送所约定佣金。此交易可以由供应商工具来完成。佣金可能从供应商的剩余 利润中产生，并且可能从用户的折扣中产生。

可能发生的是，用户正前往供应商处意图购买他或她已经收 到要约的物品。然而，与供应商讨论之后，用户决定购买具有或不具有(类似) 折扣的另一(类似的)物品。对于这些情况，SP和供应商可能关于SP的佣金 达成协议，所述佣金取决于要约和实际购买。进一步，还可能发生的是，用户 购买要约的物品，并且另外购买其他物品。对于发生的这些附加购买，SP和 供应商可能关于SP的佣金达成协议，因为用户是在由SP‘协商’之后才来到商 场的。

在供应商与用户和/或SP之间的附加协商同样可能发生。例 如，可以在传输之前修改可交换简档比如用于改进用于供应商的值。这种修改 可能包括粒度级别的变化。因此，所述修改可以至少部分地基于所述第三方的 特性。同样地，如果用于供应商的值得到改善，则所述可交换的简档的修改与 在所述补偿中的变化有关。

还可以将交易的细节上传至SP并且与用户简档和或供应商 简档一起存储。

售后分析——为了改进用户简档、供应商简档或制定要约， 进行售后分析可能是有用的。所述结果可能对用户、供应商或SP有利。

可以将购买历史提供给SP，以便分析用户是否确切地购买了 要约中的物品、用户是否购买了可替代产品、用户是否不仅仅购买了所推广的 产品……

分析由事件决定的用户的动作也可能是有趣的。为来到供应 商处用户采取了什么动作？用户是专门为供应商而来，或者用户与其他动作组 合？用户以前去看过竞争对手吗？

在销售之后分析用户的动作也可能是有趣的。用户在附近做 了其他事情吗？用户返回商场为了购买或者仅为了看看？

SP的售后工具也可能给出用户提供关于销售反馈的可能性， 或使其他朋友或联系人意识到供应商。此外，用户可以能够追踪回头生意和口 碑影响。例如，SP可以能够分析用户的一些联系人是否来到商店并且购买了 东西。SP可以能够追踪用户第一次使用的新物品并且让用户作出评论。

基于简档的广告

除了上文所讨论的个人化要约之外，基于简档的广告给出用 户其他货币化选项。基于用户的简档和请求，供应商可以能够进行有针对性的 广告。为了管理广告(意味着不是过量向用户投放广告并且最大化用户的补 偿)，SP可以遵循具有个人化要约的类似的拍卖过程(如上文所描述的)。 换言之，为了能够向用户提出广告，供应商将支付较少费用，并且通过拍卖过 程，SP将试图为用户获得最大费用。提出最高费用的供应商将得到提出广告的机会。

类似于个人化要约，供应商愿意支付的广告费用基于预设规 则以及对用户简档和状态的分析。广告是较不个人的，从某种意义上来说，用 户简档用于选择对用户感兴趣的广告，但是广告不是为用户定制的并且任何提 出的要约或折扣都可用于公众。用户可能不需要特定的优惠券或喜好以便能够 购买广告中的商品或服务。

广告的触发或发起类似于个人化要约。呈现给用户的广告数 量可能是自适应的，并且SP可以监测用户对广告的关注，以便针对用户和/或 供应商优化过程。可以由SP针对某个用户或用户组/类别或针对某个供应商或 供应商类别来确定投资回报率(ROI)。ROI可以由SP提供给供应商以便确 定供应商愿意支付的(类似于用户状态)广告费用。

可以在若干不同介质或设备(诸如移动设备(如智能电话)、 台式计算机或甚至电视屏幕)上将广告呈现给用户。可以在很多不同类型的应 用(诸如，例如web浏览器、移动应用、视频查看器或视频流)中使用/集成 广告。

可能仅针对向用户呈现广告来收取广告费用。然而，广告后 分析可能用于跟踪用户由于广告而产生的动作。SP可以跟踪用户是否前往供 应商的商店以及他或她是否购买一些供应商的商品或服务。SP可以根据用户 所采取的措施/动作来向供应商收取附加费用。例如，用户前往商店时收取较少 固定费用，并且如果用户实际上购买了东西，则收取销售的很小百分比。SP 可以基于用户的数据来提供这些动作的认证证明。

基于简档的问卷

上文所讨论的要约和广告选项通常由用户对购买什么感兴 趣来触发。然而，用户的知识和意见也可能是补偿的资源。例如，已经将产品 卖给用户的供应商可能对用户的反馈感兴趣。回答这些问题将需要用户的时 间，为此他或她可能接收补偿或以其他方式(例如关于未来产品的折扣)。如 果问题需要任何动作，则SP可以使用(传感器)数据验证用户是否已经执行 了所需动作。

在另一示例中，第三方可能想要执行关于某些商品或服务的 调查，并且可能带着他们的请求来联系SP。基于调查的类型、问题的类型和/ 或商品或服务的类型，SP可以基于其用户简档来选择潜在的用户。SP然后可 以联系所选用户并且让他们针对所约定补偿来填写问卷，所约定补偿可以取决 于例如问题的类型和数量。SP还可以接收针对问卷的佣金。

基于简档的过滤

基于用户的简档信息还可以用于基于简档信息来过滤外部 数据库。例如，用户可能想要使用服务，并且此服务已经接收了来自用户的评 论或评语(图41)。这种服务可能由帮助人们找到餐馆、宾馆等组成。所述用 户或其他用户的简档信息可以用于过滤所提出服务(例如，餐馆、宾馆……) 的评论或评语以仅获得例如由与用户具有类似简档或生活方式的用户所贡献 的这些结果。

基于简档的过滤可以通过若干方式完成，所述方式现将使用 用户寻找餐馆的示例来解释。在第一种方法中，用户可能限定他或她正寻找的 餐馆的具体类型，并且提供餐馆信息和评论的服务可以根据用户请求和说明来 列出相应的餐馆。所列出餐馆中的每个餐馆都可以具有来自用户的评论或评 语。来自用户的基于简档的信息用于过滤所示出的用户评论，并且简档用于例 如从与简档最匹配的用户的评论开始对评论进行排序(图42)。这里假设足够 数量的评论者具有可用的简档。

在第二种方法中，过滤是在较高级别上完成的。当用户限定 了餐馆的类型，基于用户简档来过滤所选的将被呈现给用户的餐馆。例如，所 示出的餐馆是基于用户具有类似简档而不是用户已经给所述餐馆至少一定评 级的事实(图43)。

在第三种方法中，过滤甚至是在更高级别上完成的。在这种 方法中，用户没有限定他或她寻找的餐馆类型。所呈现的餐馆是基于具有类似 简档的用户给予餐馆至少一定的评级的事实来选择的。

过滤取决于用户寻找的服务的类型并且取决于用户的可用 简档信息。过滤设置可以至少部分地通过列出选项的服务来限定，并且可以至 少部分地由用户来限定。例如，用户可以基于哪些标准(例如，简档条目)来 指示应当过滤的匹配简档。还可以由SP来限定这些标准，或者SP可以基于通 过用户设置的过去的限定来学习这些标准。然后可以向用户提出这些所学偏 好，所述用户可以选择修改他们。

过滤这些类型的服务的评论和推荐的原则还可以与个人化 要约的原则组合。针对每个所列出服务，至少针对向SP订阅的这些服务，可 以安排个人化折扣并且将其在列表中示出。这意味着如果一个折扣是可用的， 则由服务提供的列表还示出基于用户简档的任何个人化折扣。

可替代补偿

SP可以具有使(传感器)数据或简档信息货币化的其他机会。 所述机会还可以向用户(即，数据的提供商)提供货币化选项。例如，SP可 以将具有(传感器)数据的数据库销售给第三方，所述第三方可能想要使用这 些数据来构建模型。这些第三方可以直接为数据支付，或可以向SP提供一份 销售模型的利润中。用户可以获得由SP赚取的货币的一份奖励，其中，用户 的部分可以取决于他或她对被售出的数据库作出的贡献。SP它本身还可以使 用传感器数据来开发模型。如果这些模型被售出，以类似的推理，用户可以接 收一份。

以类似的方式，SP可以能够销售具有简档信息的数据库，例 如出于市场营销的目的。用户奖励将被作为与传感器数据的销售一样处理。

在任何情况下，用户完全控制如何使用他或她的传感器数据 以及简档信息。用户可以在他的偏好中指示他或她如何允许SP来使数据货币 化。

市场调查服务——

作为使SP已经从用户收集的数据和简档信息货币化的示例， SP可以提供市场调查服务。这种服务可以例如提供回答：产品和服务的制造 商或供应商已经关注其客户。例如，考虑某种样式跑步鞋的制造商。此制造商 可能想要知道什么类型的购买者购买这种样式的鞋，并且他们如何使用鞋。SP 可以检查哪些用户已经购买这种样式鞋，并且然后对这些用户进行分析。用户 的特性、习惯等的相关分析可能为鞋制造商提供有价值的信息。这些相关性中 的一些可能是显而易见的，但是一些可能只能使用SP所构建的简档推断算法来推断。可以将找到的相关性以及与用户对应的简档中的信息与制造商打算将 鞋子送给的目标用户进行比较。此外，可以将关于用户如何使用鞋子的信息与 目标使用进行比较。在任何类型的信息中，还可以透露地理依赖性。基于这些 发现，制造商可以例如改变市场营销策略或可以对下一样式的版本提出修改。

对这些类型的调查收取服务费用，并且此费用的一部分可以 被传送至在调查中简档被使用的用户。分布在用户上可以是均匀的，或者可以 根据使用多少简档信息来施加权重。用户的状态还可以用作在补偿分布的计算 中的权重。

基于本体的架构

使用本体——为了基于不同数据类型和来源来创建用户简 档，必须已知或限定简档条目与数据之间的关系。当使用不同的传感器时，必 须知道哪个传感器可以对哪个简档条目或构造块作出贡献。出于这些目的，可 以使用很多不同的架构。

在一个示例实施例中，这种架构可以由本体驱动。本体可以 被限定为“specification of a conceptualization(概念化的规范)”(Tom Gruber) 或“description of things that exist and how they relate to each other(描述存在的 事物以及它们如何彼此相关)”(Chris Welty)。在构造用户简档的应用中， 存在生成数据的DCO，所述数据被转换成简档条目。本体基本上描述所有这 些不同的要素以及他们之间存在的关系。基本思想是：基于本体，存在用于确 定哪个DCO和数据可以用于哪些简档条目以及需要哪些DCO和数据来构建具 体的简档条目的逻辑方式。

本体以及本体的使用在文献中被广泛的描述，并且在这里描 述所有的原则不是我们的目标。下文的示例示出了如何应用本体法则来创建用 户简档。示例不应当被理解为明确的本体定义或语法定义。在本体中，定义通 常以三元组形式给出：主语-谓语-宾语。

考虑以下三元组列表：

杂货店	是一个	建筑
			建筑	具有一个	位置
位置	利用被测量	使用GPS

在此示例中，谓语‘is_a(是一个)’用于将杂货_商店归于 类‘building(建筑)’， 以及谓语‘has_a(具有一个)’用于将性质“location (位置)”归于类“building(建筑)”的 要素中。谓语‘is_measured_with(利 用被测量)’限定使用哪个传感器或DCO可以确定哪个 性质。这些本体三元 组限定杂货店的位置可以使用GPS来测量，或更一般地，任何建筑的位 置都 可以使用GPS来确定。

建筑	具有一个	地址
			地址	利用被测量	使用地址DB

通过添加这些三元组，杂货商(或其他建筑)的地址可以从 查找表‘地址DB’中来 确定。在这种情况下，数据库可以是数据来源。为了 限定在杂货店进行购物并获得用户在 杂货店花费的货币，可以使用以下三元 组。

杂货店	是一个	在商店
			购买	是一个	活动
购买	是处的活动	在商店
			支付	是一部分	购买
支付	利用被测量	信用卡DB

这限定了：用户在杂货店(或其他商店)购买东西，并且支 付的数量可以从代表用户的信用卡状态的DCO‘信用卡DB’中来确定。SP 用于限定关系的谓语可以由SP来限定或可以从其他已有本体导入。

本体应用的基本思想是用于限定：人、物体和事件的可测量 的性质或属性，如何测量这些性质和属性以及使用哪些传感器或DCO。对于 任何可测量的性质或属性，应当总是存在可以直接地或间接地进入到本体中的 一条传感器或DCO条目。如果没有，这意味着所述性能或属性不能被测量并 且这可能指示用户应当进行手动条目。间接地意味着：遵循本体中限定的关系， 可以遵循路径来确定如何测量。谓语或在主语与宾语之间的关系可以由SP来 专门限定以便确定简档条目。然而，谓语应当尽可能地保持基本的和尽可能少， 以便简化过程。

创建构造块——关系的定义可以用于上文所讨论的从传感 器信号中提取特征以及创建构造块。图44示出了用于创建构造块的本体的应 用的示例。在此示例中，接收到GPS数据，并且如果GPS数据指示用户没有 移动，而是处在某个位置处，可以开始特征提取并且构造块构建。GPS测量位 置的事实可以触发位置构造块的创建。本体教导了每个位置都具有地址，并且 这个地址可以在DB中查找到。因为地址有位置性质，所以将所确定位置作为性质添加到位置构造块。地址数据库可以指示地址对应于杂货店，并且所述地 址还可以作为属性添加至构造块。还可以添加到达时间以及离开时间。

一旦已经检测出位置是杂货店，可以遵循本体逻辑进一步推 断杂货店是商店，并且将在商店处的活动限定为购买或购物。活动的检测可以 导致活动构造模块的创建。可以限定每个活动都具有位置，并且可以将从位置 构造模块中继承的位置添加至活动构造模块。因为支付是购买的一部分并且支 付可以根据信用卡记录来测量，系统将检查这种记录是否可用于用户光顾杂货 店的时隙。如果记录可用，则使用对应信息来创建支付构造块。

此示例表明：通过遵循在本体中限定的逻辑路径，可以创建 所有可能的构造块并且确定可测量的性质。换言之，本体帮助确保可以测量的 每个东西被测量，并且没有遗忘任何东西。可以创建最大的构造块并且将已知 在构造块之间的链接。在此示例中，起始点是GPS数据，但是如果来自其他 DCO的数据是可用的，则可以在每个DCO或输入数据处开始这些逻辑路径， 因为不是所有传感器是必然互联的(图45)。

在数据进入时、或者例如在一天结束时、或当所有数据在那 一天可用的晚上期间来创建构造块。某些数据可能是延迟可用的，并且可以稍 后使用时间戳来创建构造块，或者可以稍后添加数据。如果本体正在寻找某种 类型的数据，并且此数据仍不可用，可以开始定期地检查丢失数据的过程。对 于总是延迟可用的数据(诸如，例如信用卡数据)来说，SP可以学习时延并 且调整用于检查数据的过程。

传感器简档——在上文的讨论中，示出了可以如何应用本体 来分析已经测量出的数据。此外，本体的定义和链接还可以用于创建和调整用 户传感器简档。传感器简档定义了哪些传感器是活动的以及所述传感器的设置 是什么。基于本体链接和定义，可以确定传感器或DCO中的哪一个需要获得 所需的信息。在上文的示例中，当用户在杂货店中时可以关闭GPS。因为由于 购物活动而进行预期支付，所以检测支付的检测器必须是激活的(尽管在这种 情况下信用卡的DCO实际上不是传感器)。然而，可以限定支付总是在排队 等待之前。因此，可以决定激活加速度计(和陀螺仪)以确定在付款完成之前 用户静止或慢慢行走多久。在另一示例中，如果检测到用户在网球场，活动监 测传感器(诸如，例如加速计和陀螺仪)可以打开确定当打网球时用户跑步以 及步行多少。如果用户正使用电子球拍，来自球拍的数据的激活和检测还可以 用于激活运动传感器。

传感器简档可以根据位置、活动或任何其他相关的触发选项 而自适应。如果预期可用的数据需要传感器，则系统可能能够打开传感器。如 果不需要传感器，则系统还可以能够关闭传感器以便节约电池或处理能力。在 这种情况下，应当验证(例如，使用OS)系统的任何其他部分都没有使用传 感器。

本体不一定总是提供需要优化传感器简档的所有信息。还可 以通过分析传感器数据来提供附加信息。例如，为确切地知道何时在某个活动 内需要传感器可能不会基于本体被知道。没有限定在购物结束时完成支付的事 实(但是这是可能的)。然而，可以根据对与购物活动的时间相比较的支付时 间的分析来确定这种关系，并且可以相应地调整加速计激活。

简档条目——除了用于特征提取和构造块的创建的本体逻 辑的应用之外，本体可以以类似的方式用于简档条目输入。因为本体用于收集 信息，状态可以被称为本体查询。例如，考虑简档条目与用户的杂货店统计有 关。此条目可以使用本体查询来限定：‘用户正在光顾杂货店’。谓语正在光 顾可以被定义为在主语和宾语的位置中寻找匹配。系统然后对具有位置类杂货 店的位置构造块进行分析。给出具有请求的时间窗口以便仅分析在其窗口内的 构造块。可以设置系统来分析如在本体中所指定的所有性质。此外，系统可以 呈现作为类的总和的结果，以及在本体中所限定的每个可用的子类。这意味着： 对于此示例，系统将被设置以便将给出到杂货店的光顾数量、光顾时间和支付 作为类的总和，但是系统将给出属于类的一部分的每个不同杂货店的相同信息 (例如Safeway、WholeFoods……)。如果存在杂货店类的任何子类，系统将 根据子类(例如，有机或无机)自动执行分析。可以根据在本体中所限定的逻 辑自动地执行所有不同的分析。例如，如果代替杂货店，简档条目与餐馆光顾 有关，则可以通过‘用户正在光顾餐馆’来限定简档条目，并且自动地执行类 似于杂货店分析的所有分析。餐馆可以具有其他性质(诸如，例如噪音水平)， 但是如果在本体中指示了所述其他性质，则这些性质自动地包括在分析和统计 中。

还可以通过将例如子类或性质添加到宾语来限制简档条目。 例如，仅为了获得支付信息，简档条目可以被限定为‘用户正在光顾杂货店(支 付)’，或为限制有机杂货店的子类而被限定为‘用户正在光顾杂货店(有机)’， 或两者的组合而使用‘用户正在光顾杂货店(支付；有机)’来限定。

在另一示例中，简档条目可以与用户的活动以及具体地跑步 有关。活动类可以具有跑步所属的子类“运动”。简档条目定义然后可以是例 如‘用户正在做运动(跑步)’，其中，正在做被限定为与主语正在做的活动 有关。与上文的示例一样，遵循本体中限定的性质，呈现与跑步有关的所有数 据(诸如，例如平均距离、平均速度)。可以针对与地势(例如，柏油路、单 轨、砂石路……)有关的不同子类来分配此数据。

以上示例示出了如何使用本体来概括遵循本体逻辑的所有 相关信息。某些功能或计算还可以应用于所获得的数据。例如，为创建指示用 户每周平均花费多少时间做运动的条目，以下声明可以使用“用户正在做运动 (每周时间)”。在此示例中，首先可以收集用户的所有运动相关的活动，并 且然后应用函数‘每周时间’。此函数由SP限定，并且从由于本体查询而产 生的数据中提取所有时间信息，并且确定每周的平均时间。(注意的是，在所有这些示例中使用或者提出的语法仅为解释原则服务并且仅仅是示例，并且很 多其他语法变化可能获得同样的功能)。

简档条目还可以通过组合不同的本体查询来构建。例如，为 了获得声明用户是否生活健康的简档条目，可以对用户执行的活动、他或她光 顾的餐馆类型或用户使用的杂货店执行查询。然后可以由生成例如健康生活指 数的特定函数或算法来组合所产生信息。

本体和函数/算法还可以被设计用于调查和确定时间相关的 依赖性。这意味着SP应当能够确定某些事件在时间上与其他事件有关。例如， 为了确定用户是否正在乘坐汽车或公共交通工具去工作，必须在用户工作之前 (和之后)确定用户的活动是否正在‘驾驶’(其可以被限定为活动或位置)。

总之，可以使用本体作为用于收集被预处理成例如构造块的 所有可用信息的手段来生成简档条目。函数或算法可以应用于组合或进一步提 取信息。

通过供应商查询简档——当为了货币化选项而向供应商发 送简档信息时，还可以使用本体查询。查询可以由SP成形，并且信息然后将 被发送至供应商，或者供应商可以构建查询并且如果隐私设置允许，SP将用 信息进行响应。当SP向供应商发送信息时，信息可以已经以简档条目的形式 可用。可替代地，SP可以针对供应商限定特定查询并且收集具有货币化选项 的信息。例如，如果用户请求跑步鞋的要约，则SP可以运行查询以便确定用户平均每周进行的英里数或千米数(例如，‘用户正在做运动(跑步(英里每 周)’)，并且使用结果作为信息的一部分连同请求一起发送给供应商。在允 许供应商‘采访’简档的设置中，供应商工具可以被设计用于制定类似请求以 便获得信息。可以使用隐私管理器来验证供应商没有要求不相关的信息。例如， 供应商可能已经被归于一类，并且可以只询问与此类有关的问题。在此示例中， 供应商可以被归于类‘运动’，并且因此问题/查询仅可以与用户的运动活动有 关(例如，‘用户正在做运动’)。许可可以与本体的(类)级别有关。在使 用活动的这种示例中，最高或第一级别是覆盖所有活动的级别，在这种情况下 第二级别是覆盖运动活动的级别，并且第三级别是覆盖跑步活动的级别。如果 用户要求与运动鞋有关的要约，则等效级别的所有信息都可以对供应商可用 (在这种情况下为第三级别)。可以针对这个级别来限定某个折扣百分比，如 果供应商想要得到关于较高级别的信息，则在这种情况下，针对所有运动相关 的活动，供应商可能还必须提高折扣级别(如上文在拍卖部分中所讨论的)。 总之，本体的不同级别也帮助调节对用于供应商的信息的访问以及不同折扣百 分比。

本体演进——本体不是静态的并且可以演进，因为其初始由 SP创建。SP可能不能够限定在物品、性质、活动等之间的所有所需逻辑连接。 本体可以由于用户的添加(例如，通过注释)而演进。例如，可以由用户添加 活动与位置之间的某些链接、或物品与性质之间的链接。SP可以提供注释工 具或专用工具以用于本体的演进。

还可以基于在数据中检测到的关系和相关性来自动地完成 对本体的添加。例如，通过对用户运动数据以及支付数据进行分析，SP可以 能够推断在支付之前用户在一定时间量内总是静止或非常慢地行走。换言之， 此静止时间或等待时间可以被限定为支付过程的一部分。这种逻辑组合的检测 可以作为对本体的必须由SP批准的候选添加而提出。这种自动添加意味着在 新本体条目的这种创建之后，为了将来支付活动，系统将自动地检测等待时间。

尽管已示出和描述了一些实施例，但本领域的技术人员将理 解的是，可以在不改变或脱离这些实施例的范围、意图或功能的情况下对其进 行各种改变和修改。在前述说明中使用的术语和表达已经在本文中用作描述性 而非限制性术语，并且在使用这种术语和表达时，不旨在排除所输出或所描述 的特征或其部分的任何等效物，认识到的是，本公开仅受随后的权利要求书限 定和限制。

Claims (36)

1.一种用于构建用户的具有至少一条简档条目的可交换简档的方法，所述方法包括：

a)使具有包括至少一个传感器的集成传感器组件的第一设备与所述用户相关联；

b)根据第一传感器配置来操作所述集成传感器组件；

c)获得来自所述集成传感器组件的传感器数据；

d)确定可以从所述传感器数据中提取的至少一个特征；

e)对所述传感器数据进行处理以提取所述至少一个特征；

f)确定至少部分地取决于所提取的特征的至少一条简档条目；

g)至少部分地基于所提取的特征来确定所述用户的私密简档所述至少一条简档条目的条目数据；

h)通过合并所确定的条目数据来生成所述私密简档的所述至少一条简档条目，使得所述至少一条简档条目至少部分地基于来自所述集成传感器组件的传感器数据；

i)获得与所述用户相对应的隐私数据；

j)至少部分地基于所述隐私数据来针对所述私密简档的至少一条简档条目建立第一粒度级别；

k)变换所述私密简档的所述至少一条简档条目以匹配所述第一粒度级别；以及

l)生成所述可交换简档，其中所述可交换简档包括所述至少一条经变换的简档条目。

2.如权利要求1所述的方法，进一步包括：确定简档条目所需的至少部分地基于所述条目数据的第二传感器配置；以及根据所述第二传感器配置来操作所述传感器组件。

3.如权利要求1所述的方法，进一步包括：确定所述简档条目的所确定的条目数据的置信因数。

4.如权利要求3所述的方法，进一步包括：随着时间推移调整所述置信因数。

5.如权利要求1所述的方法，进一步包括：获得对所述至少一条简档条目的请求。

6.如权利要求5所述的方法，其中，确定特征是基于所请求的简档条目进行的。

7.如权利要求5所述的方法，其中，所述第一传感器配置至少部分地基于所述请求。

8.如权利要求1所述的方法，进一步包括：输入所述简档条目的条目数据；以及基于所述传感器数据对所输入的条目数据进行验证。

9.如权利要求8所述的方法，进一步包括：至少部分地基于所述验证来确定所输入信息的置信因数。

10.如权利要求1所述的方法，其中，所述用户简档的至少一部分被匿名化。

11.如权利要求1所述的方法，进一步包括：确定所确定的条目数据的传感器活动；以及使所述传感器活动与所述简档条目相关联。

12.如权利要求1所述的方法，其中，所述用户简档包含与所述用户的状态相关的至少一条简档条目。

13.如权利要求1所述的方法，其中，所述用户连接到至少一个第二用户。

14.如权利要求1所述的方法，进一步包括：针对所述简档的至少一条简档条目建立多个粒度级别，其中建立所述第一粒度级别包括至少部分地基于所述隐私数据从所述至少一条简档条目的所述多个粒度级别中选择第一粒度级别。

15.如权利要求14所述的方法，其中，建立所述多个粒度级别包括对多个用户简档进行分析。

16.如权利要求15所述的方法，其中，所述多个用户简档选自用户组，所述从用户组的选择基于对至少一条简档条目的所述条目数据的比较。

17.如权利要求14所述的方法，进一步包括：生成包括所述至少一条经变换简档条目的可交换简档。

18.如权利要求1所述的方法，进一步包括：将所述可交换简档传输到第三方；以及作为交换而接收补偿。

19.如权利要求18所述的方法，其中，所述补偿至少部分地基于所述条目数据的粒度级别。

20.如权利要求18所述的方法，进一步包括：在传输之前对所述可交换简档进行修改。

21.如权利要求20所述的方法，其中，所述修改至少部分地基于所述第三方的特性。

22.如权利要求20所述的方法，其中，对所述可交换简档的修改与所述补偿的变化有关。

23.如权利要求18所述的方法，其中，至少部分地基于关于所期望补偿的用户请求来识别所述第三方。

24.如权利要求18所述的方法，其中，根据预设规则在与所述第三方的自动协商过程中确定所接收到的补偿。

25.如权利要求24所述的方法，其中，在所述自动协商过程中确定所述可交换简档的内容。

26.如权利要求18所述的方法，其中，所述可交换简档包括关于针对所述第三方的所述用户的状态的信息。

27.如权利要求18所述的方法，其中，所述可交换简档包括与连接至所述用户的第二用户有关的至少一条简档条目。

28.如权利要求1所述的方法，进一步包括：建立所述经变换简档条目的值。

29.如权利要求28所述的方法，进一步包括：至少部分地基于与至少一个完成的交换的比较来建立所述经变换简档条目的值。

30.如权利要求28所述的方法，进一步包括：至少部分地基于对所述经变换简档条目的请求来建立所述经变换简档条目的值。

31.如权利要求28所述的方法，进一步包括：通过对多条经变换简档条目的所建立的值进行聚集来确定所述可交换简档的值。

32.如权利要求28所述的方法，进一步包括：通过选择第二粒度级别并且至少部分地基于所述第二粒度级别而更新所述经变换简档条目来调整所述经变换简档条目的所建立的值。

33.如权利要求28所述的方法，进一步包括：使所建立的值与所述第一传感器配置相关。

34.如权利要求33所述的方法，进一步包括：根据第二传感器配置来操作所述传感器组件从而生成具有不同值的可交换简档。

35.一种用于构建用户的可交换简档的设备，所述设备包括传感器组件以及简档模块，所述传感器组件包括与所述设备集成的至少一个传感器，所述简档模块由处理器实施，所述简档模块被配置用于：

a)根据第一传感器配置来操作所述传感器组件；

c)提供来自所述传感器组件的传感器数据；

d)确定可以从所述传感器数据中提取的至少一个特征；

e)对所述传感器数据进行处理以提取所述至少一个特征；

f)确定至少部分地取决于所提取的特征的所述用户的私密简档的至少一条简档条目；

g)至少部分地基于所提取的特征来确定所述私密简档的所述至少一条简档条目的条目数据；

h)通过合并所确定的条目数据来生成所述私密简档的所述至少一条简档条目，使得所述至少一条简档条目至少部分地基于来自所述传感器组件的传感器数据；

i)获得与所述用户相对应的隐私数据；

j)至少部分地基于所述隐私数据来针对所述私密简档的至少一条简档条目建立第一粒度级别；

k)变换所述私密简档的所述至少一条简档条目以匹配所述第一粒度级别；以及

l)生成所述可交换简档，其中所述可交换简档包括所述至少一条经变换的简档条目。

36.一种用于构建用户的可交换简档的服务器，所述服务器包括实施简档模块的处理器，所述简档模块被配置用于：

a)确定至少部分地取决于所提取的特征的所述用户的私密简档的至少一条简档条目，其中，所提取的特征是从自与所述用户相关联的设备处获得的传感器数据中提取的，所述设备具有根据第一传感器配置进行操作的集成传感器组件；

b)至少部分地基于所提取的特征来确定所述私密简档的所述至少一条简档条目的条目数据；

c)通过合并所确定的条目数据来生成所述私密简档的所述至少一条简档条目，使得所述私密简档的所述至少一条简档条目至少部分地基于来自所述集成传感器组件的传感器数据；

d)获得与所述用户相对应的隐私数据；

e)至少部分地基于所述隐私数据来针对所述私密简档的至少一条简档条目建立第一粒度级别；

f)变换所述私密简档的所述至少一条简档条目以匹配所述第一粒度级别；以及

g)生成所述可交换简档，其中所述可交换简档包括所述至少一条经变换的简档条目。

Images