相关申请的交叉引用本申请要求2014年2月5日提交的名称为“ProtocolsandSpecificationsforanAccessoryManagementSystem”的美国临时申请61/935,967的优先权，其公开内容据此全文以引用方式并入本文。本申请还要求2015年2月5日提交的名称为“UniformCommunicationProtocolsforCommunicationBetweenControllersandAccessories”的美国专利申请14/614,914的优先权，其公开内容据此全文以引用方式并入本文。
背景技术：本公开整体涉及电子设备之间的通信，具体地，涉及用于在控制器和附件之间进行通信的统一通信协议。电子设备正在很多应用中变得越来越普及。移动电话、平板电脑、家庭娱乐系统等仅仅是用户定期交互的电子设备中的一些。正在变得更普及的另一类电子设备包括各种电子可控设备，诸如恒温器、照明设备、家用电器等。
技术实现要素：当前，用户可能难以管理多个电子可控设备或系统。例如，用户家中可能有恒温器、电子可控照明系统、家庭安全系统等。每个此类系统可能是由不同制造商制造的，并且每个制造商可能提供专用控制器设备(例如，基于IR的遥控设备)或控制器应用，用户可以将该控制器应用安装并运行于通用计算设备上，诸如移动电话、平板电脑或家用计算机系统上。每个控制器设备或应用通常是针对特定制造商的系统定制的，并且可能无法与来自其他制造商的系统，甚至是来自同一制造商的其他系统互操作。此类分件方式不容易扩展。尝试利用可以集中控制或管理的相异系统阵列来创建“智能家庭”环境等的用户面临过多控制器设备和/或控制器应用累积的需求。本发明的某些实施方案涉及一种用于在控制器设备(或“控制器”)和要控制的任意数量的其他电子设备(本文称为“附件设备”或简称为“附件”)之间进行通信的“统一”协议。例如，通过为通用计算设备提供适当的可执行程序代码，控制器可以实现于通用计算设备上，诸如台式计算机、膝上型电脑、平板电脑、移动电话、其他手持或可穿戴计算设备上；或者，控制器可以是专用计算设备。附件可以包括可由控制器控制的任何设备。附件的示例包括灯具、恒温器、门锁、自动开门器(例如，车库开门器)、静物相机或摄像机等。附件和控制器可以经由有线或无线信道使用标准传输协议诸如Wi-Fi、蓝牙、蓝牙LE等来彼此通信。在一些实施方案中，统一附件协议可以定义简单而可扩展的框架，用于将附件定义为服务的集合，其中每项服务被定义为一组特性，每个特性在任意给定时间具有定义的值。特性可以表示附件状态的各种极小基本方面。例如，对于恒温器而言，特性可以包括功率(无论恒温器是开还是关)、当前温度(恒温器测量的实际温度)和目标温度(恒温器尝试保持的可设置温度)。该协议还可以定义可由控制器用于向附件发送命令和控制消息(请求)并由附件发送响应消息的消息格式。请求可以允许控制器询问(例如，读取)附件特性，并且在某些情况下修改(例如，写入)附件特性；例如，控制器能够读取功率特性以确定附件是开还是关，并且能够写入功率特性以关闭或打开附件。因此，任何类型的附件，无论其功能如何，均能够通过发送适当请求而被控制。附件可以向控制器提供附件定义记录。附件定义记录可以包括关于附件的全部可访问特性的完整信息。控制器可以在确定如何与附件交互时使用附件定义记录。例如，来自附件定义记录的信息可以由控制器用于构造用于操作附件的用户界面，以及构造发送到附件的请求消息。在一些实施方案中，该协议还可以定义通知机制，在特性变化时，附件可以使用该通知机制来通知控制器。示例包括被动通知机制以及主动或基于事件的通知机制，在被动通知机制中，控制器可以查询附件以发现是否有任何特性改变；在主动或基于事件的通知机制中，附件可以在特定特性改变时向一个或多个控制器选择性地生成消息。可以同时支持多种通知机制，并且控制器可以选择要用于特定附件、服务或特性的通知机制。在一些实施方案中，该协议可以定义安全措施，该安全措施可用于防止未经授权的控制器操作附件。例如，附件可被配置为以仅接受来自先前已经与该附件建立配对并因此被该附件识别的控制器的请求。建立配对可以包括以安全方式在附件和控制器之间交换长期公共密钥，其中每个设备持久地存储密钥。该协议可以指定配对设置流程，以便减小未经附件所有者/操作者批准便建立配对的风险。例如，在配对设置过程期间，可以要求用户读取由一个设备(例如，附件)呈现的设置代码，并向另一个设备(例如，控制器)中输入设置代码，或将设备放置成彼此物理接近。一旦建立配对，便可以利用该配对来提供端到端消息加密，使得仅配对的控制器和附件能够读取在它们之间交换的消息。例如，当先前建立了配对的附件和控制器重新连接时，它们可以验证先前的配对(例如，通过证明每一个拥有另一个的长期公共密钥)并生成特定于会话的加密密钥。在一些实施方案中，该协议可以定义供控制器在其附近发现并配置兼容附件的程序。此类程序能够简化向由控制器管理的自动化控制系统添加新附件的任务。以下具体实施方式连同附图将提供对本发明的实质和优点的更好理解。附图说明图1示出了根据本发明的一个实施方案的家庭环境。图2A-图2D示出了根据本发明的一个实施方案的附件特性的示例性定义。图2E示出了根据本发明的一个实施方案可针对特性进行定义的属性的实施例。图2F示出了根据本发明的一个实施方案的可定义的扩展特性的实施例。图2G-图2H示出了根据本发明的一个实施方案的附件服务的示例性定义。图2I示出了根据本发明的一个实施方案的可定义的附件信息服务的实施例。图2J示出了根据本发明的一个实施方案的可定义的用于附件信息服务的特性的实施例。图3A-图3C示出了根据本发明的一个实施方案的附件定义记录的实施例。图4是根据本发明的一个实施方案的用于通过控制器发现附件的过程的流程图。图5A-图5K示出了根据本发明的一个实施方案的请求和响应消息的实施例。图6A-图6E示出了根据本发明的一个实施方案的请求和响应消息的附加实施例。图7示出了根据本发明的一个实施方案的被动通知过程的实施例。图8示出了根据本发明的一个实施方案的通告式通知过程的实施例。图9示出了根据本发明的一个实施方案的主动通知过程的实施例。图10示出了根据本发明的一个实施方案的事件通知过程的实施例。图11A示出了根据本发明的一个实施方案订阅通知的请求消息的实施例。图11B示出了根据本发明的一个实施方案的事件消息的实施例。图12示出了根据本发明的一个实施方案的针对附件的配对外形的示例性特性。图13A-图13C示出了根据本发明的一个实施方案基于设置代码的配对设置过程的实施例。图14A-图14C示出了根据本发明的一个实施方案利用认证芯片和安全证书的配对设置过程的实施例。图15A-图15F示出了根据本发明的一个实施方案利用设置代码和安全证书的配对设置过程的实施例。图16示出了根据本发明的一个实施方案的一般化配对设置过程的实施例。图17A-图17C示出了根据本发明的一个实施方案的配对验证过程的实施例。图18A-图18B示出了根据本发明的一个实施方案的配对添加过程的实施例。图19A-图19B示出了根据本发明的一个实施方案的配对移除过程的示例。图20示出了根据本发明的一个实施方案用于门锁定附件的示例性操作环境。图21示出了根据本发明的一个实施方案用于门锁定附件的示例性服务定义。图22示出了根据本发明的一个实施方案将控制器与附件配对的过程的实施例。图23示出了根据本发明的一个实施方案用于对门解锁的过程的实施例。图24示出了根据本发明的一个实施方案针对IP相机附件的操作环境。图25A-图25B示出了根据本发明的一个实施方案用于IP相机附件的示例性服务定义。图26A-图26E示出了根据本发明的一个实施方案用于图25中所示的服务特性的示例性定义。图27A-图27D示出了根据本发明的一个实施方案用于IP相机附件的附件定义记录的实施例。图28示出了根据本发明的一个实施方案用于控制IP相机附件的过程的实施例。图29示出了根据本发明的一个实施方案的启动媒体会话请求的实施例。图30示出了根据本发明的一个实施方案的启动媒体会话响应的实施例。图31示出了根据本发明的一个实施方案的结束媒体会话请求的实施例。图32示出了根据本发明的一个实施方案的结束媒体会话响应的实施例。图33示出了根据本发明的一个实施方案用于IP流服务的示例性服务定义。图34示出了根据本发明的一个实施方案用于图33的IP流服务的特性定义的实施例。图35示出了根据本发明的一个实施方案针对IP流的过程的实施例。图36是根据本发明的一个实施方案的控制器的简化框图。图37是根据本发明的一个实施方案的附件的简化框图。图38是根据本发明的一个实施方案的控制器架构的简化框图。图39是根据本发明的一个实施方案的附件架构的简化框图。具体实施方式本发明的某些实施方案涉及一种用于在控制器设备(或“控制器”)和要控制的任意数量的其他电子设备(本文称为“附件设备”或简称为“附件”)之间进行通信的“统一”协议。例如，通过为通用计算设备提供适当的可执行程序代码，控制器可以实现于通用计算设备上，诸如台式计算机、膝上型电脑、平板电脑、移动电话、其他手持或可穿戴计算设备上；或者，控制器可以是专用计算设备。附件可以包括可由控制器控制的任何设备。附件的示例包括灯具、恒温器、门锁、自动开门器(例如，车库开门器)、静物相机或摄像机等。附件和控制器可以经由有线或无线信道使用标准传输协议诸如Wi-Fi、蓝牙、蓝牙LE等来彼此通信。示例性环境图1示出了根据本发明的一个实施方案的家庭环境100。家庭环境100包括可以与位于环境100中的各种附件设备(也称为附件)进行通信的控制器102。例如，控制器102可以包括台式计算机、膝上型电脑、平板电脑、智能电话、可穿戴计算设备、个人数字助理或能够如本文所述向附件传送命令和控制消息并呈现用户界面以允许用户指示对附件进行期望操作的任何其他计算设备或设备组。在一些实施方案中，可以利用多个分立设备来实现控制器102。例如，可存在与附件通信的基站，其可以安装于环境100中的固定位置，以及一个或多个移动遥控站(例如，手持式或可穿戴设备，诸如移动电话、平板电脑、智能手表、眼镜等)，其提供用户界面并与基站通信以实现对附件的控制。可以控制任何类型的附件设备。附件设备的示例包括门锁104、车库门系统106、灯具108、安全相机110和恒温器112。在一些情况下，控制器102可以与附件直接通信；例如，控制器102被示为与门锁104和车库门系统106直接通信。在其他情况下，控制器102可以经由中间媒介通信。例如，控制器102被示为经由无线网络接入点114与由接入点114提供的无线网络上的附件108,110,112进行通信。如上所述，在一些实施方案中，控制器102可以包括基站，并且基站功能可以集成到接入点114中或集成到要被控制的附件中的至少一个附件(例如，恒温器112)中。可以利用各种通信传输和传输的组合，并且可以将不同的传输用于不同的设备。通信传输的一个示例可以是符合BluetoothSIG,Inc.(http://www.bluetooth.com)定义并发布的通信标准和协议的传输；本文使用的术语“蓝牙”一般是指通信标准和协议，并且本文使用的术语“蓝牙LE”是指智能通信标准和协议。蓝牙协议可以支持在有限范围内的设备之间的直接点对点通信。通信传输的另一个示例可以是符合Wi-Fi(http://www.wi-fi.org)定义并发布的通信标准和协议的传输；本文使用的“Wi-Fi”一般是指标准和协议。Wi-Fi协议可以定义具有中心接入点的无线网络，该中心接入点在网络上的不同设备之间对通信进行路由。网络可以支持包括例如TCP和HTTP的标准互联网协议群(IP)。应当理解，蓝牙和Wi-Fi被用作通信传输和协议的示例；也可以使用其他传输和协议。此外，尽管示出了无线通信传输，但对于一些或所有附件，也可以提供有线传输。例如，灯泡108可以通过有线连接而连接到接入点114，并且控制器102可以通过向接入点114无线地发送消息而与灯泡108通信，接入点114可以充当桥接器，经由有线连接向灯泡108递送消息。有线和无线通信的其他组合也是可能的。此外，尽管示出了一个控制器102，但家庭环境100可以具有多个控制器设备。例如，生活在家中的每个人可以具有一个或多个个人设备(例如，移动电话、平板电脑、膝上型电脑、可穿戴设备)，其可以充当用于附件104-112中的一些或全部的控制器。不同的控制器设备可被配置为与附件的不同子集进行通信；例如，可以阻止儿童的控制器修改恒温器112上的设置，而许可父母的控制器设备修改该设置。例如，可以利用下文描述的配对技术来配置和控制此类许可。本发明的某些实施方案涉及一种统一附件协议，该协议促进控制器诸如控制器102与一个或多个附件诸如附件104-112中的一些或全部进行通信。该协议可以提供简单且可扩展的框架，该框架将附件模型化为服务的集合，其中每项服务被定义为一组特性，每个特性在任意给定时间具有定义的值。特性可以表示附件状态的各种极小基本方面。例如，对于恒温器112而言，特性可以包括功率(无论恒温器是开是关)、恒温器112测量的当前温度以及恒温器112设置到的目标温度。下面描述使用服务和特性的附件模型的示例。该协议可进一步定义可以由控制器(例如控制器102)用于向附件(例如，恒温器112)发送命令和控制消息(请求)的消息格式，以及可以由附件(例如，恒温器112)用于向控制器(例如，控制器102)发送响应消息的消息格式。命令和控制消息可以允许控制器询问(例如，读取)附件特性的当前状态，并且在某些情况下，可以允许修改(例如，写入)附件特性。例如，修改恒温器112的功率特性可以关闭或打开恒温器112。因此，任何类型的附件，无论功能或制造商，均能够通过发送适当消息而被控制。该消息格式可以在控制器和附件之间是统一的；下面描述示例。在一些实施方案中，附件可以向控制器提供附件定义记录。附件定义记录可以包括关于附件的全部可访问特性的完整信息。控制器可以在确定如何与附件交互时使用附件定义记录。例如，控制器可以使用来自附件定义记录的信息来构造用于操作附件的用户界面，以及构造发送至附件的请求消息。该协议可进一步定义通知机制，该通知机制允许附件112(或其他附件)在状态改变时选择性地通知控制器102。示例包括被动通知机制以及主动、通告或基于事件的通知机制，在被动通知机制中，控制器102可以查询附件(例如，附件112)以发现是否有任何特性改变；在主动、通告或基于事件的通知机制中，附件112(或其他附件)可以在特定特性改变时向一个或多个控制器选择性地生成消息和/或广播通告。可以同时支持多种通知机制，并且控制器可以选择要用于特定附件、服务或特性的通知机制。在下文描述了示例。在一些实施方案中，与给定附件的通信可以限于被授权的控制器。该协议可以指定一种或多种机制，用于在如下环境中在控制器102和给定附件(例如，门锁附件104)之间建立“配对”：该环境提供了高置信度，表示用户希望控制器102能够控制附件104，并且已经与特定附件建立配对的控制器可以被视为针对该附件被授权。例如，可以通过利用短期密钥和带外共享秘密建立安全加密框架来建立配对。可以在这个框架内交换用于附件和控制器的长期公共密钥，并且附件和控制器可以持久地存储交换的密钥，由此建立配对。在建立了配对之后，附件104能够验证所接收的通信是来自配对的控制器102还是另一个设备，并且附件104可以拒绝不是来自配对控制器102的任何通信(反之亦然)。例如，在先前建立了配对的附件和控制器重新连接时，它们可以验证先前的配对(例如，通过证明每一个具有另一个的长期公共密钥)并生成特定于会话的加密密钥以用于在配对验证的会话内进行通信。在一些实施方案中，多个控制器可以与同一附件建立配对，并且附件可以接受来自任何其配对控制器的通信并作出响应，同时拒绝或忽略来自未配对控制器的通信。配对流程的示例如下所述。应当理解，家庭环境100是例示性的，并且可能进行变型和修改。本发明的实施方案可以在用户希望使用控制器设备来控制一个或多个附件设备的任何环境中实施，包括但不限于家庭、车辆或其他交通工具、办公楼、具有多个楼宇的园区(例如大学或企业园区)等。控制器可以是用于控制一个或多个其他设备(附件)的任何设备，并且附件可以是允许其一些或所有操作由控制器控制的任何设备。控制器102可以实施或包括本文描述为在控制器中实施或包括的任何或所有特征，并且附件诸如附件104-112可以实施或包括本文描述为在附件中实施或包括的任何或所有特征。在一些实施方案中，控制器102可以从远程位置(例如，世界任何地方)与附件(例如，附件108)通信。例如，当位于远程环境中时，控制器102可以经由广域网(例如，互联网)与服务器通信，服务器能够将消息中继到附件108(例如，通过与位于环境100中的接入点114通信，该接入点可以在本地与附件108通信)。控制器102和附件108之间的通信内容对于服务器可以是不透明的；例如，控制器102和附件108可以建立安全通信会话(例如，本文所述的配对验证会话)，其中消息被加密，并且服务器可以仅仅传递加密数据，同时保持对其内容不可知。因此，可以在本地操作附件(例如，由能够建立与附件的直接通信路径的控制器)，或者远程操作附件(例如，由经由中继服务器等间接通信的控制器)。示例性附件模型在一些实施方案中，统一附件协议能够提供统一框架和语法，用于将任何附件模型化为“服务”的集合。本文使用的“服务”可以指用于完成附件设备的特征、功能或操作(或其某个部分)的数据和相关联行为的集合。每项服务可以被模型化为“特性”的集合，每个特性表示附件的基本数据元素或行为(也称为附件状态的元素)。如下所述，附件可以通过向控制器提供附件定义记录来向控制器描述自身，附件定义记录可以是定义附件的服务和特性的结构化数据对象。结构化数据对象可以各种特定格式表示，例如，使用JSON(JavaScript对象表示法)、蓝牙LE通用属性配置文件(GATT)或用于表示和传送结构化数据的其他技术和格式。如下所述，控制器可以利用附件定义记录来确定如何控制附件。例如，图1的恒温器附件112可以包括执行调节区域(例如，房间或楼宇或楼宇的部分)温度功能的部件，以将温度保持接近某个目标。出于对附件112模型化的目的，可以将温度调节标识为“恒温器”服务。恒温器服务的特性可以包括：恒温器是开还是关；当前设置的目标温度；当前测量的温度；以及恒温器调节的系统当前是处于加热模式(能够打开加热器以朝更高目标温度驱动测量温度)还是冷却模式(能够打开冷却器以朝更低目标温度驱动测量温度)。在更复杂的示例中，恒温器可以是可编程的，例如，以根据一天中的时间和/或一周中的日期来选择不同目标温度，并且在此类情况下，特性可以包括编程特征，诸如一组时间范围和针对每个时间范围的相关联目标温度。在一些情况下，附件可以提供多个服务。例如，车库门附件106可以利用自动车库开门器实现，该自动车库开门器可以打开和关闭门，并且还具有可以控制的灯，例如，以照亮车库内部。因此，车库门附件106的定义可以包括“开门器”服务和“灯泡”服务，该开门器服务完成打开和关闭车库门的功能，该灯泡服务完成打开或关闭灯的(不同)功能。开门器服务的特性可以包括门的当前状态(例如，打开、关闭、处于打开的过程中、处于关闭的过程中)、门是否被锁定(例如，以防止开门器开门)，以及门是否被阻挡(例如，开门器系统中的障碍传感器是否检测到防止门关闭的障碍)。灯泡服务的特性可以包括灯是开还是关，以及当前的亮度水平(如果灯具有可变亮度控制)。应当理解，可以将任何附件模型化为服务的集合，并且相同环境中的不同附件可以包括相同或相似服务中的一些或全部。例如，诸如家庭环境100的环境可以在不同位置具有多个灯泡(例如，每个房间中的灯)、多个门锁(例如，每个外门上的锁，内门上的锁)等等。在一些实施方案中，统一附件协议通过定义名称空间而明确允许此类重叠，使得每个附件和服务可以被唯一地标识，从而允许容易地区分不同附件上的相同服务的实例，或相同附件上的相似服务的多个实例。在一些实施方案中，统一附件协议可以定义一组“核心”特性，其可以包括预期被频繁使用和/或要存在于不同附件类型范围间的特性。可以使该组特性是可扩展的；例如，可以允许附件制造商定义特定于制造商的特性(本文也称为“扩展”特性)。因此，附件不限于核心特性。然而，在适用的时候使用核心特性能够方便系统设计和操作。例如，控制器的系统软件可以包括核心特性的代码定义属性，并且仅使用核心特性的附件能够通过标识其特性及其当前值来向控制器描述自身。图2A-图2D示出了根据本发明的一个实施方案可定义的标准特性201-229的一些示例。每个特性201-229可以具有表示附件(或附件的一部分)的状态的某个方面的值(图2A-图2D中未示出)，该方面提供特性的给定实例所属的服务。在该示例中，每个特性201-229被描述为具有类型、许可和格式。根椐格式，还包括附加信息(例如，最小值、最大值、步长、单位或所枚举的有效值列表)。特性的“类型”可以是分配给该特性的唯一名称或标识符(例如，字符串)。在该示例中，使用反向域名惯例来分配类型，这可以方便附件制造商定义扩展特性。例如，如果包括图2A-图2D中所示特性定义的统一附件协议的发布者是称为“proto.com”的互联网域的所有者，那么所有的核心特性类型均可以从字符串“com.proto.ch.”开始，接着是特性特定名称，诸如“开启”、“亮度”等。可使用其他命名惯例。在一些实施方案中，作为已命名类型的补充或替代，可以为每个特性分配唯一的数字标识符(图2A-图2D中未示出)。例如，唯一的数字标识符可以是由符合互联网工程任务组(IETF)RFC4122的36个十六进制数字构成的UUID(可以通过http://ietf.org/rfc.html访问本文引用的所有“IETFRFC”文档)。统一附件协议可以为所有核心特性定义公共“基础”UUID(例如，最后28个十六进制数字)，并向每个特性分配唯一的“短”UUID(例如，前8个十六进制数字)；可以使用任意编号方案。使用UUID，尤其是与截取UUID的惯例结合，能够允许控制器或附件使用比使用字符串更少量的被传输数据来指定感兴趣特性。例如，在一些实施方案中，截取惯例可以将36位UUID减少到只有两个或三个十六进制数位。特性的“许可”可以指示允许控制器与特性交互的方式(例如，询问或修改特性)。在一些实施方案中，可以将许可表示为字符串的阵列，其中每个字符串对应于特定交互方式。如果存在字符串，则许可其对应的交互方式；如果不存在字符串，则不许可交互。表1中示出了可以定义的许可字符串的一些示例。表1在一些实施方案中，在希望控制器发现附件状态的对应方面时授予对特性的读取许可，并且在希望控制器能够促成附件状态对应方面的改变时授予写入许可。因此，例如，与附件能够直接控制的状况相关的特性(例如，目标温度特性210)可以具有读取和写入许可，而与附件不能直接控制的状况相关的特性(例如，当前温度特性209)可以仅具有读取许可。每个特性201-229可以具有反映附件状态的对应属性或方面的值。图2A-图2D指定了用于每个特性201-229的值的格式。如本文所用，<boolean>格式指示该特性取值为真和假；<int>格式指示该特性取带符号整数值；<float>指示该特性取带符号浮点值；<string>指示该特性取字符串值(例如，使用UTF-8编码)；<date>指示该特性取日期值(例如，ISO8601格式的UTF-8日期字符串)；以及<data>指示该特性可以用于存储数据块(即，协议可能不知道其内容的一块数据)。<enum>格式指示该特性采取表示具体状况的定义的一组值之一，并针对该特性将可能的值列为“有效值”。在一些实施方案中，可以通过向每个有效值分配不同的整数来实施所枚举的值格式。<tlv>格式指示堆积类型长度值数据类型，其中第一字节表示类型，第二字节表示长度(N字节)，并且其余N个字节包含该值。在一些实施方案中，可以使用其他格式；示例包括本文表示为<object>的数据对象格式(还可以使用密钥值格式进一步定义数据对象)和数组格式(可以是任何其他格式的固定长度或可变长度的值数组)。在一些实施方案中，统一附件协议能够指定针对特性的允许格式的闭宇宙，使得以允许的格式之一表示所有特性(包括扩展特性)的值。特性的值可以指示附件状态的属性或方面。可以适于被表示信息的格式指定该值。在一些情况下，特性定义可以指定值的范围。例如，“Max”(或“maxValue”)可以表示上限，“Min”(或“minValue”)可以表示下限，并且“Step”(或“stepSize”)可以表示取离散值的特性的最小增量。“单位”可以定义为指示测量该值的特定单位；这一信息可以方便控制器对值的解释。例如，如果附件通电，“开”特性201可以具有布尔值“真”，并且如果附件断电，则为“假”。例如，可以结合灯泡、灯开关或具有开关状态(并且在其处于关状态时能够与控制器通信)的其他附件使用这一特性。作为另一个示例，可以将“使用中的插座”特性202用于具有电源插座的附件，并且布尔值可以指示电源插头是否连接到电源插座。在这种情况下，假设附件不能物理地插入或取下电源插头，因此，该特性具有只读许可。作为使用附件模型的附件控制的简单示例，假设电源插座附件具有控制开关，其能够开始或停止电力流向插座。可以将电源插座附件模型化为具有“开”特性201和“使用中的插座”特性202的服务。控制器可以读取“使用中的插座”特性202以确定电源插头是否连接到插座，然后写入“开”特性201以根据电源插头是否连接来启用或禁用向插座供电。例如，可以结合提供光源的附件使用亮度特性203、色调特性204和饱和度特性205。亮度特性203可以具有0到100范围内的整数值(如图2A中的“Min，Max，Step”字段中所示)，以将亮度水平指示为附件支持的最大亮度的百分比。像所有以百分比为单位指定的特性那样，应当理解，不需要附件支持设备状态(在这种情况下为亮度)对应方面的恰好一百种不同设置；相反，附件可以将给定百分比值映射到可用的设置。色调特性204可以具有浮点值，其在0到360度范围内指定色调；将以度为单位的值转换成物理色调可以遵循标准色彩建模实践。饱和度特性205可以具有0到100范围内的浮点值，以将期望色彩饱和度定义为最大值的百分比。控制器可以读取这些特性以确定当前设置并写入特性以改变设置。也可以支持其他色彩模型(例如，CIE1931色彩空间、色温等)。在附件响应于用户输入或在附件处检测到的其他事件具有任选的音频反馈(例如，蜂鸣)时，可以使用音频反馈特性206。可以通过向这个特性写入布尔值来启用或禁用音频反馈。可以使用输出音量特性207来读取或设置产生声音的附件上的输出音量；该值可以指示附件能够产生的最大音量的百分比。可以在附件保持活动的带时间戳日志的情况下使用日志特性208。可以由附件制造商来定义日志的结构，或者由统一附件协议的发布者针对特定类型的附件来指定日志的结构。在该实施例中，控制器可以通过读取特性208来获得附件的日志，但不写入特性208，因为更新日志不是控制器的任务。应当理解，附件可以向日志添加控制器交互的记录，作为其例行操作的部分，并且控制器可以接收具有日志其余部分的任何此类记录。图2B示出了涉及恒温器附件的特性的示例，该附件可以包括能够监测环境(例如，房子或房间)内的当前温度并控制加热和/或冷却系统以朝目标温度调节温度的任何附件。可以由控制器读取当前温度特性209以确定由附件测量的当前温度。可以由控制器读取目标温度特性210以确定恒温器附件的目标温度设置，并还可以由控制器写入目标温度特性以改变目标温度设置。在该实施例中，以摄氏度为单位指定温度；可以替换其他标度(例如，华氏度，开尔文)。不论该协议指定什么标度，控制器或附件均能够始终转换到不同的标度，以用于内部使用和/或向用户显示。例如，可以由控制器读取或写入温度单位特性211以指示在向用户显示温度时附件应当使用哪些单位。此外，尽管温度特性209和210指定了允许值的范围，但可以使用其他范围，或者可以不指定范围。一些恒温器可以用于控制加热和冷却两者。因此，可以读取当前加热/冷却状态特性212以确定恒温器当前是在加热(主动朝目标温度加温)、冷却(主动朝目标温度冷却)还是关闭。由于控制器不会决定何时加热或冷却，因此不提供写入许可。可以通过写入目标加热/冷却模式特性213来控制恒温器的操作模式。在该实施例中，模式特性213的有效值包括加热模式(其中恒温器朝目标温度加热环境)、冷却模式(其中恒温器朝目标温度冷却环境)、自动模式(其中恒温器能够根据环境条件来动态选择加热模式或冷却模式)和关闭。在选择自动模式时，可能希望指定用于将恒温器切换成加热或冷却模式的温度阈值。例如，可以由控制器写入冷却阈值温度特性214以设置冷却阈值温度，使得如果当前温度超过冷却阈值温度，恒温器将启用冷却模式，并且可以由控制器写入加热阈值温度特性215，以设置加热阈值温度，使得如果当前温度降低到加热阈值温度以下，恒温器将启用加热模式。如图2B所示，冷却温度阈值特性214和加热温度阈值特性215可以但未必具有彼此不同且与目标温度特性210不同的上下限。图2C示出了涉及开门器(例如，车库开门器或其他打开和/或关闭门的自动机构)和门锁的特性的示例。可以由控制器读取当前门状态特性216以确定门当前是打开、闭合、处于打开或闭合过程，还是停止(例如，未完全打开或完全闭合，但不运动)。可以由控制器写入目标门状态特性217以指示应当打开还是关闭门。如果控制器向目标门状态特性217写入不匹配当前门状态特性216的值，则该附件可以通过致动开门器机构以便改变当前状态以匹配目标来作出响应。例如，如果门是打开的(当前门状态特性216具有“开”值)并且控制器向目标门状态特性217写入“关闭”值，则附件可以致动开门器以关闭门。在致动开门器时，附件可以将当前门状态特性216更新为“正关闭”，并且一旦门完全关闭，附件可以进一步将当前门状态特性216更新为“关闭”，从而与目标状态匹配。控制器可以通过读取目标门状态特性217而在任何时间知道门的当前状态。在一些实施方案中，开门器附件可以向控制器提供附加信息。例如，可以使用运动检测特性218来指示附件是否检测到门附近的运动(例如，敲门)。可以使用障碍检测特性219来指示附件是否检测到可能防止门移动的障碍。控制器可以通过读取这些特性来获得该信息。在一些实施方案中，如果检测到这些特性的改变(例如，如果门被阻碍或如果检测到运动)，附件可以向控制器发送通知。可以与开门或关门分开对待锁门。例如，可以针对控制无弹簧锁闩、磁性锁或能够接合以防止门打开的任何其他物理机构的任何设备来实现“锁门机构”附件。可以由控制器读取锁门机构当前状态特性220以确定锁门机构当前是未固定(解锁)、固定(锁定)、卡住(不能锁定或解锁)还是未知。可以由控制器写入锁门机构目标状态特性221以请求对门锁定或解锁。控制器可以读取锁门机构最后动作特性222以确定对门锁执行的最后已知动作。可以支持不同水平的细节。例如，在一个实施方案中，有效值可以包括：(1)利用物理移动(例如，用户物理地移动无弹簧锁闩杠杆)从内部固定；(2)利用物理移动从外部固定；(3)利用小键盘固定；(4)远程固定(例如，基于来自控制器的请求)；(5)基于超时状况固定；(6)利用物理移动从内部解除固定；(7)利用物理移动从外部解除固定；(8)利用小键盘解除固定；以及(9)远程解除固定。根据所期望信息的粒度，还可以定义有效值的其他组合。附加特性可以与管理门锁机构相关联。例如，可以使用门锁管理自动超时特性223设置超时期间，在此期间之后，附件自动重新锁定门锁。例如，超时期间可以在门锁变成解锁时开始。在一些实施方案中，超时期间的持续时间可以是特性的数值(例如，单位为秒)，并且可以使用值0表示没有超时期间(即，门锁可以保持解锁，直到采取特定动作锁定)。可以使用门锁管理控制点特性224调用与门锁相关的特定功能，例如，通过向标识功能的特性224写入值。可以调用的功能示例包括读取门锁活动日志(可以导致附件为日志特性208返回值)、清空日志、在门锁处设置时间等。作为另一个示例，供应商可能希望允许用户设置关于门锁使用的各种策略，诸如仅在一天的特定小时之间许可远程开锁。在一些实施方案中，控制器可以通过向门锁管理控制点特性224写入来向门锁附件提供这些策略。在一些实施方案中，统一附件协议不指定向门锁管理控制点特性224写入的数据内容，但可以指定以TLV格式或其他格式提供的数据，使得能够使用统一附件协议从控制器向附件可靠地传送数据，并可以由附件以特定于供应商的方式解释数据。图2D示出了核心特性的附加实施例。可以使用旋转方向特性225来控制风扇(或具有旋转元件的任何其他附件)以按照顺时针或逆时针方向旋转。可以使用旋转速度特性226来控制风扇(或其他旋转元件)的旋转速度，其中速度被指示为最大速度的百分比。可以使用名称特性227向附件或服务分配人可读名称。可以将名称表示为字符串(例如，UTF-8格式)。可以使用仅管理员访问特性228将对附件或服务的访问限制到已经针对该附件建立为管理员(即，具有管理员许可)的控制器。下文描述用于将控制器建立为管理员的技术的实施例。在一些实施方案中，仅已经被建立为附件管理员的控制器能够向特性228进行写入。可以使用版本特性229来提供关于附件或服务的版本信息。应当理解，图2A-图2D中所示的特性被提供为示例。可以定义任意数量的核心特性。例如，可以定义涉及室内环境的其他可控方面(例如，相对湿度)的特性。可以根据需要改变定义为统一附件协议的一部分的特性的特定组合。在一些实施方案中，可以由第三方(例如，附件制造商)使用本文所述的技术来将未定义为核心特性的特性定义为扩展特性。在一些实施方案中，该组特性是可扩展的。附件能够通过为特性提供一组属性(或描述符)来定义新特性(也称为“扩展”特性)。图2E示出了根据本发明的一个实施方案的特性的一组可定义属性。对于核心特性而言，可以由协议来定义这些属性(例如，如图2A-图2D中所示)。在一些实施方案中，附件可以重新定义核心特性的属性中的一些属性并由此覆写针对该特性定义的默认属性。在一些实施方案中，可以通过提供附件定义记录内的这些属性来定义扩展特性。在下文描述了实施例。“类型”230可以是例如使用上述反向域名惯例来标识特性类型的字符串。在一些实施方案中，可以使用数字标识符(例如，上述UUID)作为类型标识符，以补充或替代字符串。“许可”231可以是标识控制器许可的访问类型的字符串阵列(例如，上表1中的任何或所有许可)。“通知模式”232可以是用于指示应当如何通知控制器特性的变化的字符串阵列。在一些实施方案中，控制器可以向这一属性写入以订阅特定通知模式。表2列出了可以支持的通知模式的一些示例。下面描述这些通知模式中的每个通知模式的操作。表2在一些实施方案中，无论控制器进行过任何订阅，被动通知均受到所有附件针对所有特性的支持；可以基于控制器进行的订阅请求来选择性地启用其他支持的通知模式。在一些实施方案中，具有“配对读取”许可的所有核心特性还至少支持“事件”通知模式。“格式”233可以是标识特性值的格式的字符串，例如，布尔、字符串、整数、浮点、TLV等。在一些实施方案中，该协议可以定义一组识别的格式，并且可以从定义的组中选择格式233。“值”234可以是特性的当前值。如果需要极限，可以使用“最小值”235和“最大值”236来设置特性的下限和上限。类似地，如果希望有最小增量，可以使用“步长”237指定改变特性值的最小增量。在指定最小值、最大值和步长值的情况下，预期附件会识别范围中的任何有效值并作出响应。然而，如上所述，这并非暗示附件上可用的设置数量必须等于有效值的数量。例如，如果灯泡附件具有亮度特性203，该附件便能够控制亮度(例如，通过调节施加到灯泡的电流)，使得在将亮度特性设置为100时亮度最大，并且在将亮度特性设置为0时亮度为零。预期(尽管并非严格需要)定义了亮度特性的灯泡会具有零和最大亮度之间的至少一个中间等级；如果该附件支持超过或少于100个中间等级，则该附件可以定义亮度特性值到其亮度等级的映射。在一些实施方案中，可以支持枚举的值格式，并且可以使用“有效值”属性238来列出有效值，其中格式233被指定为“枚举”。“单位”属性239可以指示为特性使用的单位(例如，百分比、特定温度标度等)。在一些实施方案中，该协议可以指定优选的单位系统，并且可以在这个系统内选择针对给定特性的单位属性239。“用户描述符”属性240可以提供以人可读方式描述特性或其功能的字符串。例如，用于当前加热/冷却状态特性212的用户描述符可能会指明“指示加热/冷却系统当前是加热、冷却还是关闭”。“所有者”属性241可以标识定义或重新定义特性的组织单位。在一些实施方案中，这能够帮助用户或开发者理解各种特性的定义的来源。可以为特性定义图2E中的任何或所有属性(以及任选地，其他属性)。如上所述，对于核心特性而言，该协议能够指定默认定义，并且在使用核心特性的情况下，不必在附件定义记录中包括特性的所有属性(例如，如下所述)。在一些实施方案中，附件可以通过在附件定义记录中包括要重新定义的那些属性来重新定义核心特性。可以通过在附件定义记录中包括所有其定义属性来定义扩展特性。在一些实施方案中，特性的属性可以被控制器读取并用于确定如何呈现用于控制特性和/或呈现当前值的图形用户界面。例如，对于表示为百分比的亮度特性203(图2A)或任何其他特性而言，控制器可以将控制呈现为0到100％的滑块并以1％的步长移动该滑块。对于表示为布尔值的特性201(图2A)或任何其他特性而言，控制器可以呈现打开/关闭开关。对于温度相关的特性而言，控制器可以基于具有“摄氏度”单位(或其他温度单位)的特性来呈现温度量规等，或者其可以简单地显示数值。在为特性定义用户描述符240时，控制器能够结合用于特性的用户界面控制元件来呈现文本，并且这能够方便用户理解控制元件。因此，附件可以是自我描述的，使得对于给定的附件定义记录，控制器能够动态生成用于控制任何附件的界面而无需针对该附件专门编程。应当理解，图2A-图2D所示的特性和图2E中所示的属性(或描述符)是例示性的，并且可能进行变型和修改。统一附件协议可以定义任意数量的特性及其组合，并且可以利用与图示那些不同组的属性和值来定义特性。例如，可以使用最大字符串长度属性来指定字符串长度的上限，并且可以使用最大数据长度属性来指定包含数据特性的上限(例如，对于数据对象或数据块)。此外，如上所述，该协议可以允许附件制造商为其附件定义定制的或特定于制造商的扩展特性。例如，假设制造商(拥有互联网域名“discoball.com”)生产包括镜球和光源的“迪斯科球”系统，可以控制该镜球以沿不同方向并以不同速度旋转，可以朝向球的表面引导该光源。可以使用来自图2A-图2D的核心特性(例如，“开”特性201和亮度特性203)对光源进行模型化和控制。制造商可能希望定义扩展特性以进一步控制光源和/或镜球。图2F示出了用于这种情形的扩展特性的实施例。闪光灯特性242是用于控制闪光灯效果的示例性特性。在为真时，以闪光灯模式操作灯；在为假时，以稳定模式操作灯。方向特性243是用于控制镜球旋转方向的示例性特性。球可以不在旋转(停止)、顺时针旋转或逆时针旋转。在核心特性包括旋转方向特性225的实施方案中，制造商能够选择是使用核心特性还是定义扩展特性。速度特性244是用于控制镜球的旋转速度的示例性特性。在该实施例中，速度具有两个设置(0用于慢速旋转，1用于快速旋转)。在核心特性包括旋转速度特性226的实施方案中，制造商能够选择是使用核心特性还是定义扩展特性。如上所述，统一附件协议能够将附件模型化为一个或多个服务，其中每个服务被模型化为特性的集合。因此，可以通过标识其构成特性来定义服务，特性可以包括核心特性和/或扩展特性的任意组合。在一些实施方案中，统一附件协议可以定义一组核心服务，其可以包括预期会频繁使用和/或要在不同附件类型范围间发挥作用的服务。可以使该组服务是可扩展的；例如，可以允许附件制造商向核心服务添加特定于制造商的特性或定义附加的“扩展”服务。然而，在适用的时候使用核心服务能够通过允许系统设计者利用预定义的服务和特性来促进系统设计与操作。图2G-图2H示出了根据本发明的一个实施方案可以定义的核心服务251-258的实施例。可以为每个服务251-258分配“类型”，其可以是用于标识服务的唯一名称。在该实施例中，类似于特性类型，使用反向域名惯例来定义类型，以方便附件制造商定义新的服务。因此，图2G-图2H中的核心服务类型以“com.proto.svc”开始(其中，可以使用“svc”指示该类型针对服务而不是特性)。在一些实施方案中，作为类型的补充或替代，可以为每个服务分配唯一的数字服务标识符(图2G-图2H中未示出)。例如，可以向每个服务分配由IETFRFC4122定义的UUID(由36个十六进制数字构成的标识符)。统一附件协议可以为所有服务定义公共“基础”UUID(例如，最后28个十六进制数字)(根据需要，其可以与分配给所有特性的基础UUID相同或不同)，并向每个服务分配唯一的“短”UUID(例如，前8个十六进制数字)；可以使用任意编号方案。使用UUID，尤其是与基于“短”UUID的截取UUID的惯例结合，能够允许控制器或附件使用比使用字符串更少量的被传输数据来指定感兴趣服务。每个服务251-258表示附件能够实施并参考一组所需特性(图2G-图2H中的“RequiredCh.”属性)和一组任选特性(图2G-图2H中的“OptionalCh.”属性)定义的功能。在本文的实施例中，每个服务具有至少一种任选的特性(名称)；在其他实施方案中，该组任选特性对于至少一些服务可以是空白的。在该实施例中，在预期声称要提供该核心服务的任何附属附件会识别和使用“必需”特性来控制附件时，将特性针对给定核心服务定义为“必需”。例如，灯泡服务251包括必需特性“com.proto.ch.on”(图2A的特性201)；这意味着如果附件声称提供“com.proto.svc.lightbulb”服务，那么预期该附件会通过打开(真)或关闭(假)灯来对特性“com.proto.ch.on”的写请求作出响应，并通过返回用于指示灯打开(真)还是关闭(假)的布尔值来对特性“com.proto.ch.on”的读请求作出响应。在一些实施方案中，附件可以仅对来自经授权(或配对)的控制器的请求作出响应；下文将描述授权。在该实施例中，在不需要附件在其服务定义中包括该特性但可以这样做的情况下，将特性针对给定核心服务定义为“任选”。例如，灯泡服务251包括任选特性“com.proto.ch.brightness”(图2A的特性203)。仅有开或关设置的灯泡附件(诸如很多常规荧光灯灯具)不会使用任何亮度控制，并且此类附件不需要支持“com.proto.ch.brightness”特性。具有亮度控制的灯泡附件(例如，可调光灯)可以包括“com.proto.ch.brightness”特性以允许控制器操作调光器。类似地，色调和饱和度可以是灯泡服务251的任选特性。可以类似地定义其他服务252-258，从而指定必需和任选特性的组合。在图2G-图2H中通过类型标识了特性，并且可以如上述图2A-图2D所示那样定义特性。应当指出，特性可能在一个核心服务中是必需的，并且在另一个核心服务中是任选的。例如，锁门机构当前状态和目标状态对于车库开门器服务253是任选特性，但对于锁门机构服务254是必需特性。应当理解，图2G-图2H中的核心服务示例是出于例示的目的提供的。可以定义任意数量的核心服务，并可以根据需要改变与给定核心服务相关联的特定必需和/或任选特性。此外，在支持扩展特性的实施方案中，可以允许制造商通过添加扩展特性来加强核心服务。除此之外或替代地，在一些实施方案中，制造商可以利用核心特性和/或扩展特性的任何组合来定义扩展服务。可以利用“附件信息”服务来描述附件自身，其可以是由协议指定的核心服务。在一些实施方案中，该协议可以指定所有符合协议的附件均在其附件定义记录中包括附件信息服务的实例。图2I示出了根据本发明的一个实施方案的附件信息服务261的定义(与图2G-图2H格式相同)，并且图2J示出了用于附件信息服务261的附加特性271-276的定义(与图2A-图2D格式相同)。可以由控制器写入标识特性271以调用附件的自我标识例程。这种自我标识例程可以包括附件发起用户可观察到的动作。例如，附件可能使灯闪烁，发出声音，振动、移动可移动部件(例如，打开和关闭门)，显示特定消息(例如，“我在这里”)，或执行用户能够观察到的某种其他物理动作。例如，结合确认控制器正在与用户希望控制的附件通信，从控制器调用附件的自我标识例程可能是有用的。在一些实施方案中，控制器可以通过向标识特性271写入“真”来调用附件的自我标识例程。制造商名称特性272、型号名称特性273和序列号特性274可以由控制器读取以获得关于附件的标识信息。在一些实施方案中，值可以是人可读字符串。固件修订特性275、硬件修订特性276和/或软件修订特性277可以由控制器读取以获得关于附件的代系信息，其可以由控制器使用以确定如何与附件交互。在一些实施方案中，可以标准格式表示修订信息，例如<x>.<y>.<z>；<w>，其中<x>是主版本号，<y>是辅版本号，<z>是修订版本号，并且<w>可以包含附加信息。应当理解，上述特性和服务实施例是例示性的并且可能进行变型和修改。统一附件协议可以定义任意数量的核心特性和核心服务及其组合，并且可以从那些示出的不同组特性来定义给出的服务。如上所述，可以利用扩展特性和/或扩展服务(例如，由附件制造商定义)增强核心服务，针对统一通信和控制框架内的不同需求提供了很大程度的灵活性和适应性。在一些实施方案中，核心服务定义的不同版本可以共存。为了便于不同代产品之间的兼容，可以将核心服务定义的稍晚版本限制到添加新的任选特性；保持相容组的必需特性能够便于互操作性。如上所述，在一些实施方案中，附件制造商可以向服务添加扩展特性。例如，如果附件是具有闪光灯选项的灯，制造商可以向核心灯泡服务251添加闪光灯特性(例如，图2F的闪光灯特性242)。制造商也可以定义扩展服务。例如，对于上述迪斯科球而言，制造商能够定义扩展服务“com.discoball.svc.discoball”以控制镜球和灯。这一服务可以包括以下特性：·com.proto.ch.on(特性201，图2A)；·com.proto.ch.brightness(特性203，图2A)；·com.proto.ch.hue(特性204，图2A)；·com.discoball.ch.strobe-on(特性242，图2F)；·com.discoball.ch.rotate-direction(特性243，图2F)；以及·com.discoball.ch.rotate-speed(特性244，图2F)。将附件表示为具有特性的服务集合的附件模型可以作为附件对象被传送到控制器。可以利用JSON或用于表示结构化数据对象的其他表示法(例如，使用嵌套密钥值对)传送附件对象。图3A-图3C示出了根据本发明的一个实施方案的附件对象300的实施例。利用JSON表示附件对象300；可以用其他表示替代。出于例示的目的，使用了具有附带灯的车库开门器，但附件模型不限于任何特定附件。可以将附件对象300表示为服务实例310,320,330的阵列，其中的每个可以表示为特性示例的阵列。因此，服务实例310可以包括特性实例311-315；服务实例320可以包括特性实例321-325；并且服务实例330可以包括特性实例331-332。在该实施例中，服务实例310是图2I的附件信息服务261的实例，服务实例320是图2G的车库开门器服务253的实例，并且服务实例330是图2G的灯泡服务251的实例。(本文可以互换使用术语“服务”和“服务实例”，如术语“特性”和“特性实例”那样。)每个服务实例310,320,330和每个特性实例311-315,321-325,331-332可以包括服务或特性类型，标识作为其实例的服务或特性。在该实施例中，可以使用类型字符串。在一些实施方案中，可以使用UUID或截断的UUID，从而允许通过数字而非字符串来标识服务和特性类型。这样可以减小附件对象300的大小。也为每个服务实例和每个特性实例分配实例标识符。在该实施例中，附件的每个服务实例和特性实例具有唯一的实例标识符，可以顺序地或以任何其他期望方式进行分配。如下所述，这样可以允许附件内的任何服务实例或特性实例通过参考其实例标识符而被寻址。在一些实施方案中，可以实现不同的唯一性规则。例如，每个服务实例可以具有唯一的服务实例标识符，并且每个特性实例可以具有在服务实例内的特性实例间是唯一的特性实例标识符。这样可以允许参考其实例标识符对服务实例寻址，并通过其实例标识符，与其所属的服务实例的实例标识符一起，对特性实例寻址。可以使用其他方案。在图3A中，服务实例310可以是图2I的附件信息服务261的实例。在一些实施方案中，该协议能够指定每个附件具有附件信息服务的单一实例，并且附件信息服务实例具有实例ID1；可以根据需要指定不同的规则。特性实例311-315可以是服务261的必需特性的实例。在图3B中，服务实例320可以是图2G的车库开门器服务253的实例。特性实例321-323可以是服务253的必需特性的实例。在该实施例中，服务实例320还包括任选的特性实例324,325以控制车库开门器的锁门机构。在图3C中，服务实例320可以是图2G的灯泡服务251的实例。特性实例331可以是服务251的必需特性的实例，并且特性实例332可以是任选亮度特性的实例。对于除附件信息服务之外的服务，同一服务的多个实例可以在附件对象内共存。例如，操作多个独立可控灯泡的附件对于每个灯泡可以具有灯泡服务251不同的实例，从而允许独立控制每个灯泡的状态。附件对象300还可以为具有读取许可的每个特性实例提供当前值。例如，车库门当前关闭(当前门状态特性实例321具有值2，其映射到“关闭”)，并且灯是关闭的(特性实例331具有假值)。标识特性实例315具有空值，因为对这个特性的访问是只写。对每个特性实例的许可可以表示为“perms”字符串的阵列。在该实施例中，该阵列可以包括“事件”字符串，以指示该附件支持关于此特性的事件通知。例如，如下所述，控制器可以针对其许可包括“事件”字符串的任何特性实例订阅事件通知。事件通知机制的实施例在下文中有所描述。图3C示出了附件部分重新定义核心特性的实施例。通过指定新的最小值、最大值和步长值来重新定义亮度特性实例332(相对于核心特性203)以减少亮度增量的数量。重新定义仅适用于实例332，并且不会影响附件对象300内定义的任何其他服务实例或给定控制器与其互操作的任何其他附件的亮度特性。应当理解，图3A-图3C的附件对象为例示性的，并且可能进行变型和修改。附件可以包括任意数量的服务实例及其组合，并且附件内的服务实例可以包括任意数量的特性实例及其组合。在附件对象内可以指定给定特性实例的更多或更少属性；例如，可以指定图2E中所示各种属性中的任一种或全部。在附件包括多个服务实例的情况下，服务实例之一(例如，除附件信息服务实例之外的附件对象中列出的第一服务实例)可以被指定为基本服务。此外，尽管图3A-图3C示出了使用JSON的实施，但不要求使用任何特定的表示法或语法。例如，了解本公开的本领域技术人员将理解，可以通过利用蓝牙LE通用属性配置文件(GATT)来表示附件服务和特性，由此便于使用蓝牙LE在控制器和附件之间进行通信。例如，可以由UUID标识服务和特性，使得每个服务和每个特性具有唯一的UUID。此外，在一些实施方案中，控制器可以与单个端点(也称为附件服务器)通信，以与一个或多个附件交互。为了支持这个功能，附件定义记录可以包括一个或多个附件对象的阵列，其中每个附件对象可以通过图3A-图3C所示的方式表示。可以为每个附件对象分配在附件对象阵列内是唯一的附件实例ID。应当理解，给定的附件服务器可以为全部在针对该附件服务器的单个附件定义记录中表示的一个或多个附件对象服务。控制器可以与任意数量的附件服务器通信。在一些实施方案中，可以将控制多个附件(或向另一个附件中继消息)的单个端点称为“桥接器”，并且用于此类接入点的附件定义记录可以包括针对该桥接器的附件对象以及针对由桥接器控制的每个附件的附件对象。针对桥接器的附件对象可以仅包括附件信息服务的单个实例，并且该桥接器的附件对象的存在可以向控制器指示存在桥接器。在操作中，每个附件(或附件服务器)可以在持久存储装置中存储其附件定义记录。附件可以根据请求向控制器提供全部或部分其附件定义记录。如下所述，这可以作为设备发现过程的一部分或在其他时间(例如，在从配对控制器请求时)处发生。在一些实施方案中，控制器可以使用来自附件定义记录的信息，以确定是与附件配对还是通过其他方式连接到附件。如果建立了配对或连接，控制器可以利用附件定义记录来确定如何控制附件。附件定义记录可以是自备式的，表示控制器不需要关于附件的任何其他信息来与其交互。例如，附件定义记录可以包括特定于制造商的特性(例如，“com.discoball.ch.rotate-direction”)和/或特定于制造商的服务(例如，“com.discoball.svc.discoball”)的完整定义，并且该定义可以包括特性和服务的人可读描述符。可以对控制器编程以生成为各种特性呈现人可读描述符和用户可操作控制元件(例如，基于特性的“单位”属性选择)的用户界面，并且用户能够操作控制元件以根据需要控制附件。控制器可以基于用户输入(例如，向特性写入新值)发送控制消息(请求)，从而允许控制附件，而控制器无需特定于附件的软件或其他特定于附件的定制。示例性附件发现过程在控制附件之前，控制器首先与要控制的附件建立通信。本文使用的“附件发现”一般是指控制器可用以定位其要通信的附件的任何过程。在某些情况下，发现可以包括应当在控制器和附件之间进行通信的用户验证。在一些实施方案中，附件发现可以利用现有的便于在无线或其他网络上定位设备和/或服务的服务发现协议，诸如简单服务发现协议(SSDP)，由UPnPForum(http://www.upnp.org)开发的协议，或者由AppleInc.开发的联网技术(发布为IETFRFC6762和IETFRFC6763，并在本文中称为“Bonjour”)。在设备发现服务中，一个设备(例如，附件)可以通告信息，指示其存在、地址以及关于其能力的任选附加信息。其他设备(例如，控制器)能够浏览该通告并基于广播信息来标识感兴趣设备。使用地址，浏览设备能够发起与通告者的通信。根据网络和发现服务，通告可以但未必一定包括向中央储存库(例如，在网络接入点处)实时广播信息(例如，通过多播或信标信号)和/或提供通告信息，其他设备可以从中央储存库检索信息。浏览通告可以包括从中央储存库检测广播通告和/或检索通告信息。图4是根据本发明的一个实施方案用于通过控制器404发现附件402的过程400的流程图。附件402可以是例如图1中的任何附件，并且控制器404可以是例如图1的控制器102。在框410处，附件402可以设置状态比特，以指示其当前未配对(或查找要配对的控制器)。这可以是例如下述状态标记指示符“sf#”中的比特。在框412处，附件402可以通告其作为支持设备发现服务上的统一附件协议(“UAP”)的附件而存在。例如，附件可以使用Bonjour来通告带有名称和服务类型的其自身。名称可以是附件的用户可读名称(例如，“恒温器”)；在某些情况下，通告的名称可以是在附件定义记录的附件信息服务实例中指定的名称。可以为统一附件协议来定义服务类型(例如，服务类型“_uap._tcp”)。通告还可以包括附加的信息。例如，附件可以提供具有表3中所示密钥的BonjourTXT记录。表2本领域的技术人员将认识到，可以使用其他服务发现协议和技术来分配类似的信息。例如，使用SSDP，附件能够使用多播HTTPNOTIFY消息通告名称和服务类型URI，并且URI可以由控制器用于经由发往附件的单播请求来检索附加信息。在框414处，控制器404可以浏览发现未配置的附件。不需要特定的定时，尽管通常仅在如果在控制器浏览时可以检测到附件的通告时，控制器才将发现附件。在框416处，控制器404可以例如通过从框412检测通告而找到附件402。在框418处，控制器404能够基于通告来确定附件402是否为“感兴趣的”或是否是互操作的潜在候选者。例如，控制器404可以检查表2中的发现状态标记“sf#”以确定附件是否已经被配置或与控制器配对。作为另一个示例，控制器404能够检查表2中的协议版本“pv”以确定附件的协议版本是否与控制器的版本兼容。此外，在一些情况下，控制器可能正在特定情景(例如，执行特定应用)中浏览以发现附件，并可以基于通告名称、基本服务标识符、附件型号名称、特征标记或可从附件通告获得的任何其他信息来限制感兴趣的附件。如果控制器404确定不对附件感兴趣，则控制器404可以返回框414并继续浏览。(在一些实施方案中，如果未发现感兴趣的附件，浏览操作可以超时。)在框422处，控制器404可以向用户呈现关于附件的信息，并且在框424处，用户可以提供输入，指示控制器是否应当与附件建立配对。例如，控制器404可以向用户呈现从附件的通告获得的任何或所有信息，并提示用户指示控制器404是否应当连接到附件402。在不需要时，请求用户确认可以帮助避免控制器和附件之间虚假或不希望的配对。在框426处，控制器404能够解释在框424处接收的用户输入并确定其是否应当与附件402配对。如果不配对，控制器404可返回至框414以查找其他附件。如果控制器404和附件402应当配对，那么在框428和430处，控制器404和附件402可以执行配对设置过程。在一些实施方案中，可以使用配对设置过程来建立加密密钥，以便于控制器404和附件402之间的安全通信；下文描述了可以在框428和430处实施的配对设置过程的实施例。在一些实施方案中，用户确认可以被并入配对设置过程中，并且不需要在发起配对设置之前独立进行用户确认。假设配对设置过程成功完成，在框431处，附件402可以通过更新上述状态标记指示符“sf#”来更新其状态以指示现在需要授权以与附件通信和/或附件现在与至少一个控制器配对。在框432处，控制器404可以从附件402获得附件定义记录并进行高速缓存，其可以在框434处根据请求来提供记录。在控制器404高速缓存附件定义记录时，可以使用该信息以方便在附件402中检测状态的改变。在一些实施方案中，控制器404还可以高速缓存来自附件通告的信息(例如，来自上表2的任何或所有信息)，并且也可以使用这一信息例如使用如下所述的状态计数器“s#”来检测附件中的状态改变。在框436和438处，控制器402和附件404可以开始交换命令和控制消息，从而允许控制器404控制附件404。在一些实施方案中，可以使用在配对设置过程中或在如下所述的后续配对验证过程中建立的密钥对这些消息加密。应当理解，本文所述的发现流程是例示性的，并且可能进行变型和修改。可并行执行按顺序描述的步骤，可改变步骤顺序，并且可修改、合并、添加或省略步骤。此外，尽管将Bonjour服务用作设备发现服务的示例，但可以在其他设备发现服务的情景中应用类似的概念。在一些实施方案中，在确定是否与特定附件配对之前，控制器404可以从附件402请求附件定义记录(或其一部分)。例如，控制器404可以向附件发送消息(例如，HTTPGET请求)以请求其附件定义记录。可以由统一附件协议的惯例，或在附件的通告内(例如，在TXT记录中)指定用于HTTPGET请求的URL。根椐配置，附件402可以响应于来自未配对控制器的请求，提供其附件定义记录的全部、一些或一个都不提供。在一些实施方案中，附件402可以提供部分附件定义记录。例如，如上所述，一些特性可以具有用于指定它们只能由配对控制器读取和/或写入的属性，并可能不希望向未配对控制器提供关于此类特性的信息。因此，附件402可以标识“公共”特性，即，许可未配对控制器读取和/或写入的特性，并且向未配对控制器提供的部分附件定义记录可以仅包括具有至少一个公共特性的服务实例并可以仅包括既有公共特性又有非公共特性的服务实例的公共特性实例。在一些实施方案中，在建立配对之前根本不可以访问附件定义记录；在那种情况下，是否配对的决定可以基于附件的通告、控制器的情景和/或用户输入。在一些实施方案中，发现过程400或类似过程可以用于检测状态的改变。例如，如表2中所示，在状态改变时可以递增状态编号“s#”。附件能够通过例如广播更新的TXT记录来通告状态改变，并且先前已经高速缓存过TXT记录(例如，在过程400的框432处)的配对控制器能够通过将“s#”的广播值与其高速缓存的值进行比较来检测改变。在控制器和附件利用TCP/IP通信的情况下，可以在实例中使用图4的过程。在一些实施方案中，作为TCP/IP的补充或替代，统一附件协议可以支持诸如蓝牙LE的其他传输。在是这种情况时，附件能够利用蓝牙LE通告其服务。例如，附件可以在一个或多个蓝牙LE通告信道上进行通告。通告数据可以包括例如以下各项中的任一者或所有：附件的本地名称；唯一附件标识符；指示附件可被发现的标记；用于服务中的至少一些服务的UUID(包括如下所述的配对服务)；附件状态的指示符(类似于表2中的当前状态数量)；以及附件是否执行与至少一个控制器的配对设置的指示。可以在类似于上述过程400的发现过程中使用这一信息。示例性通信在控制器已经与附件建立了配对之后，控制器能够向附件发送命令和控制消息(请求)。这些请求可以用于获得关于附件状态的信息和/或改变附件状态的各方面。在一些实施方案中，命令和控制消息可以是地址指向反映针对特定服务或特性的路径的URL的HTTP请求，如在附件定义记录中定义的那样。在此类实施方案中，附件可以充当HTTP服务器(接收对资源的请求并作出响应)，而控制器可以充当HTTP客户端(生成对服务器/附件的请求并接收响应)。应当指出，一些附件可以实现多个HTTP服务器，例如，用于管理不同界面或域上的通信。在一些实施方案中，附件和控制器可以通过单个TCP连接和/或HTTP流水线(例如，在接收响应之前发送多个HTTP请求)来支持多个HTTP请求。例如，给定图3A-图3C中所示的附件对象300，控制器能够构造图5A的URL500以表示资源，在这种情况下，即图3B中定义的开门器服务实例320的门状态特性实例321。URL500包括协议标识前缀502(“http://”)、用于附件的主机名504(可以通过上述图4的发现过程获得)以及本地路径506。本地路径506可以包括协议关键字508(“proto/”)以指示参考通过统一附件协议暴露的服务、服务实例标识符510(“service/<serviceID>”)以标识特定服务实例，以及特性实例标识符512(“characteristic/<characteristicID>”)以标识服务实例内的特性实例。在图5A中，利用附件对象中定义的实例标识符来替换<serviceID>和<characteristicID>。因此，参考图3A-图3C，具有实例ID7的服务实例是车库开门器服务实例320，并且具有实例ID8的特性实例会是当前状态特性实例321。因此，可以将URL500理解为参考车库开门器的当前门状态。通过类似的方式，可以利用服务和特性的实例ID从附件定义记录生成其他URL。可以通过这种方式来标识任何服务实例的任何特性实例。控制器可以向通过这种方式构造的URL生成HTTPGET(PUT)请求以读取(写入)特性。此外，可以利用URL500的分级结构以允许控制器从单次事务中的多个特性或多个服务读取或向其写入。例如，可以通过省略特性标识符来完成发送GET请求以读取特定服务的所有特性。响应可以是包含特性的JSON对象，格式类似于图3A-图3C。为了确定附件资源的当前状态，控制器能够基于图5A的URL500来发送HTTPGET请求。图5B示出了从图5A的URL500构造的GET请求520的实施例。GET请求520的地址指向URL500的主机504并指定本地路径526(类似于URL500的本地路径506)作为要检索的资源。在该实施例中，本地路径526不指定单个特性；可以将此解释为读取指定服务实例的所有特性的请求。响应于HTTPGET请求520，附件可以发送提供所请求资源的HTTP响应(状态信息)。图5C示出了可以响应于图5B的请求而提供的示例性HTTP响应530的一部分。该响应包括HTTP响应标头532，其标识响应和状态(“200OK”)并指示内容534被格式化为由统一附件协议定义的JSON对象。内容534包括针对所请求的资源的状态信息，其在该实施例中是图3B的开门器服务实例320。服务实例320包括五个特性实例，并且自从读取所有特性的请求之后，所有五个特性的当前状态都被报告。(图5C中仅示出两个特性；应当理解，可以通过类似方式示出其他特性。)可以通过修改路径526以反映期望水平的粒度来构造其他水平粒度的读取请求和响应(例如，单一特性实例或所有服务实例)。类似地，控制器可以通过向适当的URL发送HTTPPUT请求而改变附件的状态信息。图5D示出了从图5A的URL500构造的PUT请求540的实施例。PUT请求540的地址指向URL500的主机504并指定本地路径546(类似于URL500的本地路径506)作为要写入内容542的资源。在该实施例中，PUT请求540向一个特性实例写入，因此路径546包括期望特性实例的实例ID(其对应于图3B的开门器目标状态特性实例322)。内容542指定要写入的值。在图3B的实施例中，特性实例322的类型是“com.proto.ch.door-state.target”，并且如上所述，针对这一特性类型的值1可以映射到“打开”状态。因此，可以由附件将PUT请求540解释为打开车库门的指令。附件可以利用空白HTTP“204无内容”响应来作出响应，并能够例如通过打开门来实现状态更新。(在主动打开门的时候，附件可以将当前门状态特性实例321更新到指示门正在打开的值，然后一旦门完全打开，便更新到指示“打开”的值。)在一些实施方案中，例如，附件响应可以包括如下文参考图5F所述的内容。例如，如果发生错误，附件可以利用HTTP错误响应作出响应。例如，HTTP错误代码400可以指示坏的请求(例如，语法错误或无效特性)，错误代码403可以指示禁止的动作(例如，尝试向控制器没有写入许可的资源写入)，并且错误代码500可以指示附件处的内部错误。在一些情况下，错误响应的内容可以包括具有关于错误的信息的“响应”对象。下文描述响应对象的实施例。在一些实施方案中，可以使用单个PUT请求来写入多个特性。图5E示出了从图5A的URL500构造的PUT请求550的实施例。PUT请求550可以类似于PUT请求540，只是本地路径556处于服务水平的粒度，这样允许写入多个特性。参考图3的附件定义300和图2A中的特性定义，可以将PUT请求550解释为解锁并打开车库门的请求。如该实施例所示，可以使用PUT请求向服务特性的子集写入。该请求可以仅包括要写入的特性；类型和实例ID密钥在每个特性数据对象内的存在能够防止歧义。此外，可以按任何顺序列出要写入的特性。附件可以利用包括每个特性的当前状态的消息作出响应。图5F示出了根据本发明的一个实施方案的示例响应560。响应560是非空白HTTP响应，其内容562包括每个更新特性563,564的当前值。针对每个特性，包括“响应”对象565,566。如图所示，响应对象可以包括“developerMessage”。如果发生错误了，developerMessage可以提供错误的简明语言解释，并任选地提供校正问题的建议。“errorCode”可以是数字代码(例如，可以用于选择要在响应中采取的控制器动作)。“moreInfo”字符串能够提供附加的信息，诸如标识为了帮助解决错误而应参考的协议规范或其他文档的一部分。在图5F所示的实施例中，未发生任何错误，并且每个特性的状态是图5E中请求的状态。如果发生错误，状态可能不匹配所请求的状态。通过类似的方式，可以使用类似于图5E的请求550的PUT请求向服务或向多个服务写入，并且可以生成类似于图5F的请求506的响应。如上所述，控制器能够通过发送PUT请求来请求附件中的状态改变。在一些情况下，状态改变可能涉及调用附件功能(例如，执行命令或操作)，该附件功能可能需要一些时间来完成。为了允许附件在响应时具有灵活性，一些实施方案相对于一些特性或服务支持延迟的响应行为。在控制器使用HTTPPUT向特性写入时，附件可以评估该请求并选择响应选项(例如，基于写入的特定特性)。在一些实施方案中，提供了两个响应选项：“在线结果”和“查询结果”。对于在线结果，附件执行所请求的操作，然后在HTTP响应中返回结果(例如，如上文参考图5E和图5F所述)。可以延迟响应，直到完成操作所需。对于查询结果，附件在执行操作之前返回HTTP响应。在这种情况下，操作前HTTP响应可以包括“事务ID”(由附件分配)，控制器可以稍晚使用事务ID发送HTTPGET请求以获得结果。操作前HTTP响应还可以包括“事务持续时间”(也由附件分配)，其指示在发送GET请求之前控制器应当等待的最小时间。附件可以针对每个请求选择响应选项。作为例示，考虑实施功能以打开配置端口的附件。可以将端口模型化为具有各种特性的服务。图5G示出了控制器能够向其写入布尔值真以请求打开端口的特性实例571。图5H示出了根据本发明的一个实施方案可以由控制器用于请求打开端口的PUT请求572。(应当理解，在具有实例ID22的服务实例内定义特性实例571)。例如，根椐控制器许可或附件的当前状态，附件可以履行或拒绝请求。附件可以选择是否首先根据请求而行动，然后作出响应(在线结果)，或响应然后行动(查询结果)。如果附件选择首先根据请求而行动，那么附件可以发送用于指示结果的在线响应。例如，履行请求可以包括创建套接字并开始在端口上侦听。附件可以在其HTTP响应中传递关于所配置端口的信息。图5I示出了对图5H的请求572的在线HTTP响应573的实施例。内容574可以包括端口标识符和针对请求的状态指示符。如果附件选择首先作出响应，附件能够发送包含信息的事务响应，控制器稍晚可以使用该信息来查询结果。图5J示出了根据本发明的一个实施方案的事务响应575的实施例。事务响应575包括事务ID576和事务持续时间577(例如，以秒为单位)，事务ID576可以是UUID或由附件生成以标识事务的其他标识符。响应575指示控制器应等待5秒，然后查询附件以检索响应。在这个时间期间，附件可以执行动作，并连同事务ID一起存储结果。在经过事务持续时间之后，控制器可以例如通过使用相同URL发送HTTPGET请求作为第一请求来查询附件。图5K示出了根据本发明的一个实施方案可用于事务状态查询的HTTPGET请求578的实施例。GET请求578可以包括来自事务响应575的事务ID。这向附件指示该查询用于其可能已经存储的特定事务结果。该附件可以利用HTTP响应作出响应，HTTP响应包括事务的结果；这一响应可以与图5I的在线响应573相似或相同。可以实施用于访问资源的其他技术。一种另选的具体实施可以使用非分级URL，并采用附件的每个服务实例和特性实例的唯一实例ID，这样可以减小HTTP消息的长度。例如，图6A示出了简化的URL600，可以构造该URL600以允许访问附件的特性和服务。URL600包括协议标识前缀602(“http://”)、主机名604(可以通过上述图4的发现过程提供)以及本地URL606，在这一实施例中为“/characteristics”。可以从附件支持的一组URL选择本地URL606。表4列出了统一附件协议可以根据本发明的一个实施方案定义的URL。表4在该实施例中，控制器能够通过向通过图6A所示的方式构造的URL发送请求来调用附件功能，其中本地URL是基于要调用的功能从表4选择的。可以结合在控制器和附件之间建立和验证配对来使用/pair-setup、/pair-verify和/pairingsURL；下文描述了实施例。配对的控制器可以向附件的/accessoriesURL发送GET请求以获得其附件定义记录。可以将/characteristicsURL用于涉及读取或写入附件特性的所有交互。/identifyURL可以允许未配对控制器例如在附件与任何控制器建立配对之前调用附件的自我标识例程。如果附件未与任何控制器配对，附件可以利用HTTP204“无内容”响应作出响应，并继续调用自我标识例程。如果附件已经与控制器建立配对，该附件可以拒绝该请求(例如，利用HTTP400“坏请求”响应)，指示该URL无效。在一些实施方案中，配对的控制器可以通过向标识特性271写入来调用附件的自我标识例程，这可以包括在图2I和图3A中所示的附件标识服务中。图6B示出了可以利用URL600发送的HTTPGET请求610的实施例，用以读取由图3A-图3C的附件对象300定义的附件的特性。GET请求610地址指向URL600的主机604并指定本地URL606。字符串612是指定要读取的特性实例的URL参数。使用的格式是<accessoryIID>.<characteristicIID(s)>，其中<accessoryIID>是附件实例标识符，并且<characteristicIID(s)>是用于要读取的特性的实例标识符的逗号分隔列表。参考图3B的实例ID，GET请求610可以被理解为读取当前门状态和目标门状态的请求。可以使用其他格式，诸如特性实例标识符的范围(例如，URL参数“？1.8-12”)。在该实施例中，不必指定服务实例标识符，因为附件的每个特性都被分配了唯一的实例标识符。在其他实施方案中，如果需要，可以包括服务实例标识符。图6C示出了可以响应于GET请求610而发送的HTTP响应620的实施例。响应620可以包括HTTP响应标头622，其标识响应和状态(“200OK”)并指示内容624被格式化为用于统一附件协议的JSON对象。内容624可以包括针对每个请求的特性实例的状态信息(值)。在该实施例中，针对每个特性传输的数据仅包括值和实例ID。只要附件的每个特性实例具有唯一实例ID，这一信息便足以对请求作出响应。可以通过这种方式使用单个GET请求和响应来读取附件的任意数量的特性(包括不同服务实例的特性)。此外，如果控制器正与为多个附件对象服务的附件服务器通信，控制器可以发送单个GET请求以例如通过将该特性指定为逗号分隔的列表<accessoryIID>.<characteristicIID(s)>来读取服务器上多个附件的特性。例如，URL参数(“？1.8.9,2.6,7”)可以被附件服务器理解为从具有实例ID1的附件读取特性实例8和9，并从具有实例ID2的附件读取特性实例6和7的请求。可以使用HTTPPUT请求向附件的/characteristicsURL写入特性。图6D示出了可以用于写入附件的任意数量特性的PUT请求630的实施例。对于要写入的每个特性，内容634可以指定附件实例ID、特性实例ID和新的值。在该实施例中，写入了两个特性，但该阵列可以包括任意数量(一个或多个)特性，包括同一附件服务器上不同附件的特性。如果未发生错误，附件可以利用空白HTTP“204无内容”响应作出响应，并可以通过发起适当的动作(例如，触发车库开门器中的电机以移动门)来实施状态更新。如果发生错误，附件可以利用错误消息作出响应。图6E示出了可以响应于PUT请求630而发送的错误消息640的实施例。在该实施例中，内容644标识(同样利用附件实例ID和特性实例ID)标识出写入尝试的每个特性实例。未指示新的值。状态代码646,648用于传达哪些写入失败。在该实施例中，状态代码646(值0)指示具有实例ID8的特性未发生错误。状态代码648(值12345)指示具有实例ID9的特性发生错误。状态代码648的值可以指示错误的类型。例如，可以定义状态代码以指示特权不足(例如，控制器未被授权向特性写入)，不能访问资源(例如，附件被关闭)，资源忙，不支持请求(例如，尝试向只读特性写入)，值无效(例如，对于具有最小和最大值的特性超出范围)，以及期望的其他错误状况。应当理解，这些命令以及图5A-图5K和图6A-图6E的控制消息格式和序列是例示性的，并且可能进行变型和修改。HTTP允许在任何时间请求任何资源；因此，控制器能够按照任何顺序发送HTTP请求，并且附件可以按照接收的顺序对HTTP请求作出响应。附件可以利用标准HTTP响应(包括错误消息)作出响应，并且控制器可以将该HTTP响应作为确认消息处理(或者在错误的情况下当做否认)。在一些实施方案中，附件服务和特性到HTTP资源的映射可以允许在控制器如何检索信息方面有很大灵活性。在一些实施方案中，使用具有更短URL的实例标识符能够导致更短的请求和响应，这可以减少带宽要求。此外，尽管所示的实施方案使用HTTP，但本发明不限于任何特定成帧协议；可以用其他协议替代。例如，在控制器和附件使用蓝牙LE通信的实施方案中，控制器能够通过利用分配给每个服务和特性的蓝牙LEGATT层和UUID从特性读取并向特性写入。在以上实施例中，控制器能够通过例如利用HTTP请求向附件发送命令和控制消息(请求)来发起附件中的状态改变。在其他情况下，附件状态改变可以由除控制器之外的源发起，并且在发生变化时，控制器可以连接到或不连接到附件。例如，不同的控制器可能会在不同时间与同一附件交互，或者用户可以手动操作附件(例如，推动车库中的打开/关闭按钮以激活车库开门器)。因此，附件状态可以改变而控制器不知道。因此，统一附件协议的一些具体实施能够提供用于通知控制器状态改变的机制。可以同时支持多个通知机制，并且控制器能够例如针对每个特性或每个服务确定其优选哪个机制。通知机制的实施例列于上表2中。在一些情况下，附件能够维持内部状态计数器，其可以在附件状态每次改变时递增。可以在附件层级维持单个状态计数器，或者可以根据需要为不同的服务或特性维持不同的状态计数器。各种实施方案可以支持下文描述的任何或全部通知机制。图7示出了根据本发明的一个实施方案的“被动”通知过程700的实施例。过程700涉及控制器读取附件的内部状态计数器以确定是否发生了状态改变。因此，在控制器接下来重新连接时，可以检测到在控制器从附件断开连接时发生改变的情况。在一些实施方案中，默认启用被动通知(例如，每个附件均维持内部状态计数器)，并且不需要任何特定动作(例如，订阅)来启用它。在框706和708处，控制器702和附件704可以建立连接。在各种实施方案中，建立连接可以包括执行过程400和/或下文描述的其他过程(例如，配对验证)。在框712处，附件704可以向控制器702提供其当前内部状态计数器值，控制器702可以在框714处获得并存储该值。在一些实施方案中，控制器702可以向适当的资源发送HTTPGET请求(例如，可以在附件信息服务中定义的可读状态计数器特性)。附件704在框712处的响应可以包含计数器值。控制器702可以存储这一值。在之后的某个点处，控制器702可以从附件704断开连接(框716)。在框718处，在控制器702断开连接之后，可以在附件704中发生状态改变。作为响应，附件704可以在框720处更新其状态计数器。之后，控制器702可以重新连接到附件704(框722)。在框724处，附件704可以向控制器702提供当前内部状态计数器值，控制器702在框726处获得该值。在一些实施方案中，这可以通过控制器702指向适当资源的HTTPGET请求来完成；附件704的响应可以包含计数器值。在框728处，控制器702可以通过例如将在框726处获得的计数器值与先前在框714处获得并存储的计数器值进行比较来检测状态改变。在一些实施方案中，控制器702可以利用新的值重写所存储的旧计数器值。之后，在框730处，附件704可以向控制器702提供更新的状态信息，控制器702在框732处获得该信息。在一些实施方案中，这可以利用控制器702的HTTPGET请求和附件704的响应来完成。控制器可以选择请求附件定义记录或仅请求控制器会对其状态改变感兴趣的特定特性。图8示出了根据本发明的一个实施方案的“通告式”通知过程800的实施例。在过程800中，附件可以使用设备发现服务(例如，如上所述)来通告已经发生状态改变。检测到通告的控制器能够连接到附件并获得更新的状态信息。在框806和808处，控制器802和附件804可以建立连接。在各种实施方案中，建立连接可以包括执行过程400和/或下文描述的配对过程。在框810处，控制器802可以指示订阅通告的通知的期望。例如，如上文参考图2E所述，每个特性可能具有notificationMode属性，并且控制器可以通过向notificationMode属性写入来指定通知模式。在一些实施方案中，除非至少一个控制器订阅了通告的通知，否则附件804不会通告状态改变；这样可以减少网络流量。在框812处，附件804可以向控制器802提供当前内部状态计数器值，控制器802在框814处获得并存储该值。在一些实施方案中，这可以通过控制器802指向适当资源的HTTPGET请求来完成；附件804的响应可以包含计数器值。控制器802可以存储这一值。在之后的某个点处，控制器802可以从附件804断开连接(框816)。在框818处，在控制器802断开连接之后，可以在附件804中发生状态改变。作为响应，附件804可以在框820处更新其内部状态计数器。在框822处，附件804还可以通告更新的状态计数器。例如，如以上表3中所示，附件可以例如在BonjourTXT记录等中通告包括状态编号“s#”的信息。附件可以通过更新字段并广播新的TXT记录来通告状态改变。在框824处，假设控制器802正在侦听广播，控制器802可以检测到更改。例如，控制器802能够从广播提取当前状态计数器，将状态计数器与存储的状态计数器进行比较，并检测指示附件状态已经改变的偏差。在框826处，控制器802可以重新连接到附件804。在框828处，附件804可以向控制器802提供更新的状态信息，控制器802在框830处获得该信息。在一些实施方案中，这可以通过控制器802的HTTPGET请求和附件804的响应来完成。图9示出了根据本发明的一个实施方案的“主动”通知过程900的实施例。在过程900中，在更新状态信息时，附件可以向控制器发起连接以提示控制器。例如，控制器可以向专用于接收状态更新的设备发现服务(例如，Bonjour服务)登记服务记录，并且附件可以使用控制器的服务记录向控制器发起连接。在框906和908处，控制器902和附件904可以建立连接。在各种实施方案中，建立连接可以包括执行过程400和/或下文描述的配对过程。在框910处，控制器902可以指示订阅主动通知的期望。例如，如上所述，每个特性可能具有notificationMode属性，并且控制器可以通过向notificationMode属性写入来指定通知模式。在一些实施方案中，附件904仅在至少一个控制器已订阅主动通知时才执行与主动通知相关的操作；这样可以减少网络流量。在框912处，控制器902可以设置端口以侦听主动通知。在框914处，控制器902可以向设备发现服务登记服务记录。例如，如果使用Bonjour服务，控制器902可以登记唯一的DNSSRV记录。如果SRV记录是唯一的，控制器可以避免诸如探测、通告或提供TXT记录的操作，从而减少网络流量。在一个实施方案中，DNSSRV记录可以具有以下格式：<ID>._guid._tcp.local。<TTL>INSRV<priority><weight><port><target>，其中<ID>是控制器的唯一标识符(例如，小写且去除短划线的GUID，UUID，或其他标识符)；“._guid._tcp”是DNS服务类型；“local”是域名；<TTL>是SRV记录存活时间(例如，可以是120秒)；<priority>是目标主机的优先级(例如，可以是服务中识别的最高优先级)；<weight>是具有相同优先级的记录的相对权重(可以是例如0)；<port>是运行于控制器902上的统一附件协议服务器的TCP端口号(例如，该端口设置于框912处)；并且<target>是可用于获得IP地址以连接到统一附件协议服务器的DNS名称。在框916处，控制器902可以断开连接。在框918处，在控制器902断开连接之后，可以在附件904中发生状态改变。作为响应，在框920处，附件904可以通过例如发送针对服务类型“._guid._tcp”的多播DNSSRV查询来查询设备发现服务以定位登记的服务。(在一些实施方案中，附件904在框920处执行查询，并且仅在至少一个控制器已订阅主动通知时才继续进行动作。)在框922处，控制器904可以利用在框912和914处建立的DNS名称和端口标识符来对查询作出响应。在框924处，附件904可以向端口发送单播查询以解析DNS名称。在一些实施方案中，支持IPv4和IPv6地址版本两者的附件可以利用IPv4和IPv6地址两者发送查询(例如，针对IPv4的DNSA查询和针对IPv6的DNSAAAA查询)；如果附件仅支持一个IP地址版本，它可以发送一个查询。在框926处，控制器902可以发送具有其解析的地址的单播响应。如果附件发送两个查询，根据其支持哪个IP地址版本，控制器可以对任一者或两者作出响应。在框928处，附件904可以利用解析的地址向控制器902发起新连接。在一些实施方案中，如果控制器提供IPv4和IPv6两个地址，可以优选IPv6。在框930处，控制器902可以接受连接。如果连接尝试失败，附件可以重试；在一些实施方案中，可以将重试频率限制到例如每60秒一次。在框932处，附件904可以发送更新的状态信息，并且在框934处，控制器902可以接收更新的状态信息。在一些实施方案中，可能需要在发送更新的状态信息之前验证先前建立的配对(例如，利用下述配对验证过程)。这样可以保证附件向订阅该通知的同一控制器报告状态信息。图10示出了根据本发明的一个实施方案的“事件通知”过程1000的实施例。在过程1000中，附件可以向当前订阅接收针对已改变特性的事件通知的控制器发送主动HTTP响应(本文也称为EVENT消息)。在该实施例中，控制器可以在其连接到附件的任何时候订阅通知，并在从附件断开连接时自动变成不订阅。在框1006和1008处，控制器1002和附件1004可以建立连接。在各种实施方案中，建立连接可以包括执行过程400和/或下文描述的其他配对过程。在框1010处，控制器1002可以指示订阅事件通知的期望。例如，如上所述，每个特性可能具有notification-mode属性，并且控制器可以通过向这一属性写入来指定通知模式。图11A示出了HTTPPUT请求1100订阅针对特性的事件通知的实施例。内容1102(通过附件实例ID和特性实例ID)标识特性并包括针对notificationMode属性的值“ev”。可以在单个订阅请求中列出多个特性，并且在一些实施方案中，可以将订阅请求与向一个或多个特性写入值的请求组合。附件可以将请求1100理解为订阅针对指定特性的事件通知的请求，并可以利用确认(例如，HTTP204“无内容”)或错误响应(例如，如果对于该特性不支持事件通知)作出响应。可以通过控制器使用类似消息通过指定期望的通知方法来订阅其他类型的事件通知(例如，如上所述的主动或通告通知)。在订阅之后，在框1014处，控制器1002可以取消订阅基于事件的通知。在一些实施方案中，如果控制器1002从附件1004断开连接，控制器1002便自动取消订阅。作为补充或替代，控制器1002可以通过向通知模式属性写入新值而不从附件1004断开连接来明确取消订阅。如果控制器1002(自动或明确地)取消订阅，将不再向控制器1002发送任何后续事件通知，过程1000可以在框1016处结束。(当然，取消订阅的控制器1002可以执行过程1000以再次订阅。)自动或明确取消订阅的控制器1002可以帮助减小附件1004的功耗，因为附件1004可以避免生成或尝试向不感兴趣(或未连接)的控制器发送事件消息。在框1018处，附件1004中可以发生状态变化，并且在框1020处，附件1004可以更新其内部状态计数器；更新内部状态计数器可以结合例如如上所述的被动和/或通告的通知使用。此外，如果控制器1002订阅基于事件的通知，附件1004可以向控制器1002生成通知。例如，在框1024处，附件1004能够确定是否有任何控制器(例如，控制器1002)当前订阅了针对受影响特性的状态改变的基于事件的通知。如果当前没有订阅控制器，那么不采取任何进一步动作，并且过程1000可以在框1026处结束。如果至少一个控制器(例如，控制器1002)当前订阅，那么在框1028处，附件1004可以生成包含更新的状态信息的事件消息。图11B示出了根据本发明的一个实施方案的事件消息1120的实施例。事件消息1120可以在结构上类似于HTTP响应；然而，不像HTTP响应那样，不响应于特定HTTP请求来发送事件消息1120。标头部分1122可以将消息1120标识为事件消息，并且可以包括版本信息和状态代码。主体1122可以包括改变的特性的更新值；如在本文的其他实施例中那样，可以由附件标识符和实例标识符来标识特性。应当理解，如果多个特性已经改变，附件可以包括单个事件消息1120中的多个特性；即，事件消息可以是聚合的。也可以使用其他格式。再次参考图10，在框1030处，附件1004可以向控制器1002发送事件消息，并且在框1032处，控制器1002可以接收事件消息。例如，可以修改控制器1002中的HTTP堆栈以识别事件消息1100(例如，基于标头1122)。控制器1002可以从接收的事件消息提取更新的状态信息。应当理解，上述各种通知过程是例示性的，并且可能进行变型和修改。可并行执行按顺序描述的步骤，可改变步骤顺序，并且可修改、合并、添加或省略步骤。此外，根据在状态改变时各控制器已经订阅了哪些通知选项，同一附件可以同时支持任意或全部通知过程，并且同一状态改变可能导致以下各项中的任一种或全部：更新内部状态计数器、通告更新的状态计数器、与一个或多个订阅的控制器发起连接以及/或者向订阅的控制器发送事件消息。除了图7-图10中所示那些之外或作为替代，可以支持其他通知机制和过程。如上所述，控制器可以针对每个特性，例如，通过向特性的notificationMode属性写入来订阅状态改变通知。附件可以基于任何控制器是否订阅了与关注特性相关的每个通知机制来确定执行哪种(哪些)通知机制。在一些实施方案中，被动通知是默认机制，并且内部状态计数器始终被更新，无论任何控制器已经专门请求了什么。因为通告、事件和/或主动通知能够产生网络流量，所以这些机制的使用可以被限于依赖于被动通知会对用户体验造成不利影响的情况。在一些实施方案中，可以施加各种策略以减少由(例如，通过通告、事件和/或主动通知)宣告状态改变而生成的网络流量。例如，状态改变通告可以限于至少一个控制器订阅了通告通知的情况，并且查询服务记录以发起连接可以限于至少一个控制器订阅了主动通知的情况。此外，可以要求附件聚合所有的具有最小延迟期间(例如，1秒)的通告、主动或事件通知，以进一步减少网络流量。作为另一个示例，事件通知和/或附件发起的连接可能在频率方面受限(例如，限制到每30秒)。可以将使网络流量最小化的被动通知作为默认值。此类限制是设计选择的问题，并且可以根据需要改变或消除。在施加限制且附件突破限制的情况下，检测到突破的控制器可以提示用户行为错误和/或终止其与附件的配对。示例性配对过程在一些实施方案中，在附件和控制器之间确保通信可能是有用的。例如，参考图1，控制器102可以例如通过发送如上述的请求消息来用于解锁门104或打开车库106。本领域的技术人员应当理解，此类操作应当限于特定授权的控制器。因此，本发明的一些实施方案提供了诸如认证配对和端到端加密的安全措施。认证配对可以作为建立附件和控制器之间的配对(也称为对设置)的一部分而发生，在此期间，附件和控制器可以建立安全框架(例如，使用密码技术)并能够在该框架内交换长期公共密钥。在一些实施方案中，配对设置可以结合信息的带外交换(例如，设置代码)，并且带外交换可以结合用户输入(或用户动作)以向附件验证其应当与特定控制器配对和/或向控制器验证其应当与特定附件配对。在通过这种方式交换公共密钥之后，控制器和附件可以存储密钥并稍晚使用它们来验证已建立了配对。端到端加密可以包括在附件和控制器两者内生成会话密钥(例如，在验证配对之后)以及使用会话密钥来加密每个消息，之后其离开发送设备，使得如果消息被拦截，拦截者将不能使用它。因此，不必在链路层或传输层保证通信网络的安全。例如，可以在附件和控制器每次重新连接时(例如，使用如下所述的配对验证过程)生成新的会话密钥。此外，可以提供机制用于移除建立的配对(例如，通过移除存储的长期公共密钥)，使得曾经被授权控制特定附件的控制器变得不被授权。在一些实施方案中，可以将密码密钥(包括下文所述的任何或所有密钥)排他地存储于“安全元件”内，诸如专用集成电路芯片中，其能够为设备安全地存储数据(也称为“安全存储元件”)。可以使用安全元件提供所接收的长期公共密钥和/或用于标识已经与其建立配对关系的其他设备的其他信息的持久安全存储。这样能够帮助防止攻击者不通过适当的设置过程便添加配对(这可能导致控制器的非法使用)或不经授权便移除配对(这样可以防止非法使用控制器)。此外，在一些实施方案中，安全元件还可以包括逻辑电路，允许其充当附件主处理器或控制器的协处理器(或“安全计算元件”)。安全元件能够接收各种输入和指令以对输入执行加密操作。安全元件可以执行操作并提供输出。本文描述的任何或所有加密操作(例如，生成密钥，利用秘密密钥签名和涉及密钥的其他操作)均可以被委托给安全计算元件。如本文所用，“安全元件”能够提供安全存储和/或安全计算的任意组合。在一些实施方案中，支持配对的附件可能具有配对概况作为其附件模型的一部分。类似于本文描述的其他服务，可以将配对概况定义为特性的集合。在一些实施方案中，统一附件协议能够指定所有附件均具有配对概况。在其他实施方案中，配对概况可以是任选特征，但该协议能够指定，如果附件具有配对概况，那么可能需要控制器在交换任何命令和控制消息之前与附件配对。也可以对配对要求进行进一步调整。例如，附件的配对概况能够标识需要配对的特定服务实例，允许不经配对便访问附件服务的一些服务。图12示出了根据本发明的一个实施方案的用于配对概况的示例特性1201-1205。该格式大致类似于图2A。如本文描述的其他特性那样，可以由控制器例如使用HTTPGET请求等读取特性1201-1205；例如，可以使用HTTPPUT或HTTPPOST请求等执行写入(在许可时)。可以由控制器写入配对状态请求特性1201以请求配对过程状态的改变(例如，以在下述配对设置、配对验证、配对添加和/或配对去除过程期间发送各种请求)。在一些实施方案中，控制器可以通过向配对URL(例如，如在以上表4中所示)发送HTTPPOST请求而非向特性1201写入来请求配对过程状态的改变。下文结合特定配对过程来描述配对过程状态和请求的实施例。特征标记特性1202可以是定义由附件支持的配对特征的比特掩码。例如，如下所述，各种附件可以支持基于设置代码的配对(这可能需要用户输入设置代码，诸如PIN以确认应当进行配对)、基于证书的配对(这可能使用证书基础结构，可以利用如下所述的认证芯片在任一或两种设备中提供证书基础结构)和/或委托的配对(这可能允许已经配对的控制器验证应当对另一个控制器配对)。在一些实施方案中，特征标记特性1202还可以包括指示附件当前是否处于可以使用配对设置来建立新配对的模式中。控制器可以读取但不写入读取特性1202，并且控制器可以使用该信息来确定如何以及是否执行配对设置。配对当前状态特性1203可以指示配对过程的当前状态，例如，是否发生错误或下文所述的各种其他状态。控制器可以读取但不能写入它。配对列表特性1204可以存储已经与附件建立的所有配对的列表。例如，可以针对每个配对来生成TLV项，该TLV项指示配对控制器的公共密钥(用于基于设置代码的配对)和/或证书(用于基于证书的配对)，以及每个控制器具有哪些许可。这些TLV项可以作为子TLV而堆积在一起(具有分隔体)作为单个顶级TLV。在一些实施方案中，附件对顶级TLV加密，之后向请求控制器发送它。配对ID特性1205可以是用于附件的全局唯一标识符，诸如MAC地址、附件公共密钥的一部分、附件“用户名”(例如，如下所述)等。在一些实施方案中，特性1201-1205可以通过定义对于未配对控制器可见的附件配对服务而暴露于控制器，至少直到附件与至少一个控制器建立了配对为止。例如，在附件使用蓝牙LE作为通信传输的情况下，附件可以经由蓝牙LE通告其配对服务。作为配对服务的补充或替代，附件可以定义控制器访问配对功能而参考的一个或多个URL。例如，参考上述表4，控制器可以向URL/pair-setup发送HTTPPOST请求，以作出请求并在配对设置过程期间提供相关联的信息。控制器可以向URL/pair-verify发送HTTPPOST请求，以作出请求并在配对验证过程期间提供关联的信息。控制器可以向URL/pairings发送HTTPPOST请求，以管理配对，例如发起配对添加和配对去除过程或检索针对附件已建立配对的列表；POST请求可以包括指示特定请求的数据对象。现在将描述用于在附件和控制器之间建立配对的过程的实施例(称为“配对设置”)。例如，可以在图4的过程400的框428和430处实施这些或其他过程的任一个。因此，在下文中，假设附件和控制器已经进行了发现并打开了通信信道，该通信信道可能是不安全的。进一步假设用户已经向控制器确认其应当与特定附件配对。在一些实施方案中，仅在附件处于配对模式中时许可配对设置。使附件处于配对模式可能涉及用户与附件物理接触。例如，可能要求用户向附件上的接收器中插入物理对象(例如，钥匙)，移动附件上的开关到“配对”位置等等。在一些实施方案中，仅在附件未与任何控制器建立配对时才许可配对设置。一旦附件具有一个建立的配对，便可以使用如下所述的配对添加过程(或其他委托配对过程)建立附加的配对。图13A-图13C示出了根据本发明的一个实施方案用于控制器1302和附件1304的基于设置代码的配对设置过程1300。在基于设置代码的配对设置中，可能要求用户在控制器处输入附件的设置代码(其可以是例如，特定于附件且不容易猜到的八位数标识数字)，以提供双向认证。为了安全起见，可以由附件在显示器上显示附件的设置代码或由用户向附件手动提供(例如，通过在附件上设置物理拨号盘或向小键盘中键入数字)，或者可以在附件外壳或封装上或之内某处印刷设置代码(例如，在不显眼表面上的标签上)。附件制造商可以通过不从公共可访问信息(例如，序列号、MAC地址、制造商名称、制造日期等)导出设置代码来增强安全性。在本文的实施例中，配对设置利用了安全远程口令(“SRP”)协议(文档在http://srp.standford.edu)；然而，可以使用其他协议。首先参考图13A，在框1306处，控制器1302可以查找相关联的用户名(“userC”)。该用户名可以包括控制器1302和/或控制器1302的授权用户的任何标识符，可以由附件用于帮助对控制器进行彼此区分。在框1308处，控制器1302可以向适当的URL发送配对设置开始请求，例如，HTTPPOST请求。配对设置开始请求可以包括状态指示符，以指示已经发送了配对设置开始请求(在一些实施方案中，可以由控制器向图12的配对状态请求特性1201写入这一和后续状态指示符)，方法指示符，以指示正在使用基于设置代码的配对方法，以及控制器用户名userC。在框1310处，附件1304可以确定是否抑制配对设置开始请求。例如，为了挫败基于随机猜测的攻击，附件1304可以实施指数抑制，其中在每次不成功配对设置尝试之后，等待下一个开始请求的时间加倍(例如，如果前n次尝试不成功，则第(n+1)次尝试必须等待至少2n-1秒)。可以全局性而非针对每次会话或每个连接应用抑制。可以在不成功的配对设置尝试之后重置抑制时间。因此，在框1310处，如果抑制生效且自从上次尝试之后还未经过抑制时间，附件1304可以在框1312处发送抑制消息。抑制消息可以指示控制器需要在重试之前等待多长时间。在框1314处，如果接收到抑制消息，控制器1302能够确定是否重试(在等待适当时间之后)。如果控制器1302确定重试，过程1300可以返回到框1308，以在适当等待时间之后发送新的配对设置开始请求。如果在框1310处，附件1304未抑制请求，过程1300可以进行到框1316，其中附件1304可以例如通过调用适当的SRP协议功能，诸如SRP_new(SRP6a_server_method())来创建SRP会话；将控制器的用户名设置为接收的值userC(利用SRP_set_username或SRP_set_user_raw)；生成随机盐(例如，至少16个字节)，其可以设置有SRP_set_params；选择并设置其自己的设置代码(例如，利用SRP_set_auth_password或SRP_set_auth_password_raw)；以及生成公共密钥(“pkA”)(例如，利用SRP_gen_pub)。公共密钥pkA可以是短期密钥对的一部分(连同秘密密钥“skA”)，该短期密钥对用于过程1300期间并随后丢弃。附件可以使用各种技术来选择设置代码。例如，设置代码可以在EEPROM中预先编程(以及在用户可以找到的附件或标签等上印刷)。或者，在过程1300之前(或期间)，可以由用户使用附件上或附件中提供的机械或电子输入设备向附件中输入用户选择的设置代码。作为另一选项，附件可以在执行配对设置过程1300的每个实例期间生成随机设置代码，条件是附件有能力通知用户设置代码(例如，通过向用户显示它或通过其他方式发信号通知)。也可以使用其他技术。在框1318处，附件1304可以向控制器1302发送随机盐和公共密钥pkA，控制器1302可以在框1320处接收它们。在框1318处发送随机盐和公共密钥pkA时，附件1304能够更新配对状态以指示已经发送了附件的公共密钥。在框1322处，控制器1302可以从用户获取附件的设置代码。例如，控制器1302可以呈现提示用户输入附件的设置代码的用户界面屏。可以使用其他技术，只要在带外，即经由独立于用于执行配对设置过程的通信信道的通信信道，向控制器1302输送设置代码即可。例如，在一些实施方案中，用户能够操作控制器1302的板上相机以在设置代码出现于附件上时捕获设置代码的图像(图像可以包括人可读的表示或机器可读的表示，诸如条形码或快速响应(QR)代码等)，并且控制器1302可以执行图像处理以提取设置代码。可用于从附件1304向控制器1302提供设置代码的技术的其他实施例包括：在控制器1302被置于或保持物理接近附件1304时，从附件1304到控制器1302的近场通信(NFC)传输；附件1304发出的可由控制器1302检测到的声波或超声波传输；高速光学信令(例如，相机视场或控制器1302的光探测器视场中的附件1304生成的光脉冲序列)；或者将存储设置代码的附件1304或相关联设备物理连接到控制器1302的连接器接口。在框1324处，控制器1302能够例如通过调用适当的SRP协议功能，诸如SRP_new(SRP6a_server_method())来创建SRP会话；设置控制器的用户名(利用SRP_set_username或SRP_set_user_raw)；设置从附件接收的盐(利用SRP_set_params)；生成其自己的公共密钥(“pkC”)(例如，使用SRP_gen_pub)；使用用户输入的设置代码(例如，利用SRP_set_auth_password或SRP_set_auth_password_raw)设置SRP口令；以及计算共享秘密(“inputKey”)(例如，使用SRP_compute_key)。像附件公共密钥pkA那样，公共密钥pkC可以是短期密钥对的一部分(连同秘密密钥“skC”)，该短期密钥对用于过程1300期间并随后丢弃。在框1326处，控制器1302可以生成控制器证据(“proofC”)以证明其自身的身份(例如，利用SRP_respond)。在框1328处，控制器1302可以向附件发送验证请求，包括公共密钥pkC和证据proofC，例如，作为向适当URL发送的HTTPPOST请求。在框1328处发送请求时，控制器1302可以更新配对状态以指示控制器的证据已被发送。在框1330处，附件1304可以验证控制器证据proofC。例如，附件1304可以计算共享秘密(“inputKey”)(例如，使用SRP_compute_key)并使用共享秘密来验证proofC(例如，使用SRP_verify)。如图13B所示，如果在框1332处，框1330处的验证失败，那么在框1334处，附件1304可以向控制器1302发送错误消息。如果在框1336处，控制器1302接收到错误消息，过程1300可以在框1338处结束。在一些实施方案中，控制器可以向用户报告错误。如果在框1332处验证成功，那么在框1340处，控制器1304可以生成附件证据(“proofA”)以证明其自身的身份(例如，利用SRP_respond)。在框1342处，附件1304可以向控制器1302发送附件证据proofA，控制器1302可以在框1344处接收proofA。在框1342处发送proofA时，附件1304可以更新配对状态以指示附件的证据已被发送。在框1346处，控制器1302可以验证proofA(例如，使用SRP_verify)。在框1348处，如果验证失败，过程1300可以退出(框1350)。如果在框1348处验证成功，附件和控制器现在都拥有验证的共享秘密。因此，在框1352处，控制器1302可以从共享秘密inputKey生成新的加密密钥(“密钥”)。例如，控制器1302可以使用基于HMAC的密钥导出函数，其利用inputKey、随机盐和附加信息项(可以预先编程到控制器1302中)作为输入，来实施针对512比特散列的安全散列算法版本2(HMAC-SHA-512，在IETFRFC2104中定义)。在框1354处，控制器1302可以使用Key来加密其长期公共密钥(LTPKC)。长期公共密钥可以是持久存储于控制器上(例如，在上文所述的安全元件中)的密钥，并且与过程1300中更早生成的短期公共密钥pkC不相关。加密可以使用加密和认证算法，诸如ChaCha20-Poly1305(在IETFInternetDraftdraft-agl-tls-chacha20poly1305-03中描述，可以在https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03得到)，以Key作为密钥，LTPKC作为消息，以及当前，以产生加密的数据edataC和认证标签authTagC。在框1356处，控制器1304可以向附件1304发送edataC和authTagC；控制器1302也可以更新配对状态以指示LTPKC已被发送到附件。在框1358处，在接收edataC和authTagC时，附件1302可以使用与控制器1302在框1352处使用的相同方法生成加密密钥(“Key”)。如果到此为止全部正确进行，它应当是相同的Key。在框1360处，附件1302可以验证接收的authTagC。如图13C中所示，如果在框1362处，框1360处的验证失败，那么在框1364处，附件1304可以向控制器1302发送错误消息。如果在框1366处，控制器1302接收到错误消息，过程1300可以在框1368处结束。在一些实施方案中，控制器可以向用户报告错误。如果框1362导致成功，那么在框1370处，附件1304可以对LTPKC解密，并且在框1372处，附件1304可以持久存储LTPKC和控制器的用户名userC作为配对的控制器记录。此类存储可以在如上文所述的安全元件中进行。在框1374处，附件1304可以构建包括附件的长期公共密钥(LTPKA)和与附件相关联的用户名的数据对象。附件的长期公共密钥可以是持久存储(例如，在附件1304的安全元件中)的密钥，并且与过程1300中更早生成的短期公共密钥pkA不相关。像控制器用户名userC那样，附件用户名userA可以包括附件1304和/或附件1304的授权用户的任何标识符，可以由控制器用于帮助对附件进行彼此区分。在框1376处，附件1304可以加密在框1374处生成的数据对象以生成edataA和authTagA。可以使用控制器1302在框1354处使用的相同加密算法。在框1378处，附件1304可以向控制器1302发送edataA和authTagA；附件1304也可以更新配对状态以指示LTPKA已被发送到控制器。在框1380处，在接收edataA和authTagA时，控制器1302可以验证接收的authTagA。如果在框1382处，框1380处的验证失败，那么在框1384处，过程1300可以结束，并且控制器1304可以向用户报告错误。如果验证成功，那么在框1386处，控制器1304可以解密LTPKA并且持久存储LTPKA和附件的用户名userA作为配对的附件记录。此类存储可以在上文描述的安全元件中进行。在框1388处，配对设置完成，并且可以更新配对状态以指示这种情况。应当理解，过程1300是例示性的，并且可能进行变型和修改。可并行执行按顺序描述的步骤，可改变步骤顺序，并且可修改、合并、添加或省略步骤。例如，控制器每次向附件发送消息或反之(例如，在配对过程状态改变时)，可能检测到错误。尽管指示某些错误状况，但应当理解，如果在任何点检测到错误，过程1300可以结束，并且控制器可以通知用户该错误。此外，参考SRP和特定加密和/或认证算法是为了例示的目的，并且可以替换用于在不安全通信信道上进行数据安全交换的其他协议和算法。在一些实施方案中，配对过程可以利用认证基础结构。例如，认证芯片(集成电路器件，或IC)可以并入到附件和/或控制器设备中。认证芯片可以安全地存储用于设备的加密密钥、用于设备的安全证书以及关于可以由其他设备给出的有效或无效安全证书的信息。在一些实施方案中，认证芯片可以实现上文所述的安全元件(或其一部分)。在给定附件包括认证芯片的情况下，认证芯片可用于配对设置过程中。图14A-图14C示出了根据本发明的一个实施方案用于使用认证芯片的控制器1402和附件1404的配对设置过程1400的实施例。假设控制器1402在发起过程1400之前已经确认附件1404具有认证芯片。例如，上述特征标记特性1202可以包括指示附件是否支持基于证书的配对的标记。可以针对具有认证芯片的附件设置这个标记。作为另一个示例，指示附件是否支持基于证书的配对的标记可以是包括在针对附件的服务发现记录的特征标记字段中(例如，表3中BonjourTXT记录的特征标记“ff”字段)，这可能会使得未配对的控制器更容易访问标记。(然而如果没有认证芯片的附件设置这个标记，控制器可以在执行过程1400的正常过程期间检测到不存在认证芯片信息并报告错误。)参考图14A，在框1406处，控制器1402能够例如使用基于椭圆曲线Diffie-Hellman密钥一致协议的Curve25519算法(在http://cr.yp.to/ecdh.html提供文档)来生成公共/秘密密钥对(pkC，skC)。这个密钥对可以是过程1400期间使用的短期密钥对，随后被丢弃。在框1408处，控制器1402可以向附件1404发送配对设置开始请求，例如，作为向适当URL发送的HTTPPOST请求；该请求可以包括公共密钥pkC。配对设置开始请求可以包括状态指示符，以指示已经发送了配对设置开始请求(在一些实施方案中，可以向图12的配对控制点特性1201写入这一和后续的状态指示符)。在框1410处，响应于配对设置开始请求，附件1404可以例如使用Curve25519算法生成公共/秘密密钥对(pkA，skA)。像(pkC，skC)那样，这个密钥对可以是过程1400期间使用的短期密钥对，随后被丢弃。尽管未示出，但可以并入上文参考过程1300所述的抑制行为，并且如果在不成功尝试之后太快接收到它，附件1404能够拒绝配对设置开始请求。在框1412处，附件1404可以使用skA和pkC生成共享秘密(“inputKey”)。在框1414处，附件1404可以通过级联公共密钥pkA和pkC来构造消息，并且在框1416处，附件1404可以使用其认证芯片来签署该消息以生成消息“smsg”。认证芯片可以具有其自己的持久密钥对(独立于pkA和skA)，并能够实施任何期望算法，诸如SHA-1或SHA-2(由U.S.NationalSecurityAgency设计的密码散列函数，在FederalInformationProcessingStandards(联邦信息处理标准)出版物180-4中有记录)。在框1418处，附件1404可以生成对称的密钥(“Key”)。例如，附件1404可以使用inputKey、盐(例如，预定义的字符串)和附加信息作为输入来使用HMAC-SHA-512。在框1420处，附件1404可以使用在框1418处生成的密钥Key对来自框1416的已签名消息smsg进行加密，以生成证据“proofA”。可以使用任何对称的加密算法。在框1422处，附件1404可以向控制器1402发送响应。该响应可以包括公共密钥pkA、附件证据proofA和由认证芯片供应的附件证书。在框1422处发送响应时，附件1404可以更新配对状态以指示附件的证据已被发送。在框1424处，控制器1402可以验证附件证书。例如，控制器1402可以具有其自己的认证芯片或存储标识有效附件证书的信息的其他安全数据存储装置；该信息可以被提供给控制器1402，并且在一些情况下，可以由受信任的证书管理机构更新。控制器1402可以使用这一信息确认接收的附件证书有效。在一些实施方案中，某些证书可能仅对于特定类别的附件有效，并且控制器1402可以使用先前从附件接收的信息(例如，附件定义记录或在如上所述的设备发现期间提供的其他信息)来确定附件类别以及接收的附件证书对于该附件类别是否有效。参考图14B，在框1426处，如果附件证书不是有效的，过程1400可以终止(框1428)，并且控制器1402可以通知用户有错误。如果附件证书是有效的，那么在框1430处，控制器1402可以使用skC和pkA生成共享秘密(“inputKey”)。在框1432处，控制器1402可以生成对称的密钥(“Key”)。例如，附件1404可以使用inputKey、盐(例如，预定义的字符串)和附加信息作为输入来使用HMAC-SHA-512。在框1434处，控制器1404可以使用对称密钥Key以解密从附件接收的proofA，使用附件1404用于对proofA加密的相同算法。因此，控制器1402获得签名的消息smsg。在框1436处，控制器1402可以使用附件证书来验证smsg上的签名。在框1438处，如果签名不是有效的，过程1400可以终止(框1440)，并且控制器1402可以通知用户有错误。参考图14C，如果签名是有效的，那么在框1442处，控制器1402可以利用控制器用户名“userC”和控制器的长期公共密钥LTPKC来构建数据对象(其可以与上文所描述的过程1300相同)。在框1444处，控制器1402可以对数据对象加密以生成edataC和authTagC。框1442处的加密可以使用加密和认证算法，诸如ChaCha20-Poly1305，以Key作为密钥，LTPKC作为消息，以及当前时间，类似于上述过程1300。在框1446处，控制器1402可以向附件1404发送包括edataC和authTagC的交换请求消息；控制器1402也可以更新配对状态以指示LTPKC已被发送到附件。在框1448处，附件1404可以使用其对称密钥Key来验证接收到的authTagC。如果在框1450处，框1448处的验证失败，那么在框1452处，附件1404可以向控制器1402发送错误消息。如果在框1454处，控制器1402接收到错误消息，过程1400可以在框1456处结束。在一些实施方案中，控制器可以向用户报告错误。如果框1450导致成功，那么在框1458处，附件1404可以对LTPKC解密，并且在框1460处，附件1304可以持久存储LTPKC和控制器的用户名userC作为配对的控制器记录。此类存储可以在上文描述的安全元件中进行。在框1462处，附件1404可以构建包括附件的长期公共密钥(LTPKA)和与附件相关联的用户名(userA)的数据对象，其两者都可以与上述过程1300中的相同。附件的长期公共/秘密密钥对可以不同于附件的认证芯片中的密钥对。在框1464处，附件1404可以加密在框1462处生成的数据对象，以生成edataA和authTagA。可以使用控制器1402在框1444处使用的相同加密算法。在框1466处，附件1304可以向控制器1402发送edataA和authTagA；附件1404也可以更新配对状态以指示LTPKA已被发送到控制器。在框1468处，在接收edataA和authTagA时，控制器1402可以使用先前生成的密钥Key来验证接收到的authTagA。如果在框1470处，框1468处的验证失败，那么在框1472处，过程1400可以结束，并且控制器1404可以向用户报告错误。如果验证成功，那么在框1474处，控制器1404可以解密LTPKA并且持久存储LTPKA和附件的用户名userA作为配对的附件记录(此类存储器可以在上述安全元件中)。在框1476处，配对设置完成，并且可以更新配对状态以指示这种情况。应当理解，过程1400是例示性的，并且可能进行变型和修改。可并行执行按顺序描述的步骤，可改变步骤顺序，并且可修改、合并、添加或省略步骤。例如，控制器每次向附件发送消息或反之(例如，在配对过程状态改变时)，可能检测到错误。尽管指示某些错误状况，但应当理解，如果在任何点检测到错误，过程1400都可以结束，并且控制器可以通知用户该错误。此外，参考特定加密和/或认证算法是为了例示的目的，并且可以替换用于在不安全通信信道上进行数据安全交换的其他协议和算法。过程1400是不对称的，因为附件向控制器发送证书进行验证，但控制器不向附件发送对应的证书。在一些实施方案中，可以实现双向证书验证。例如，具有证书的控制器可以实施类似于框1412-1416的处理，以生成控制器证据(“proofC”)，可以连同控制器证书一起将其发送到附件。附件可以实施类似于框1424-1436的处理以验证控制器的证据。在一些实施方案中，认证芯片可以是特定于特定设备的，并且每个设备具有唯一的证书。在其他实施方案中，同一类别中的附件(或控制器)可以具有相同的认证芯片，因此具有相同的证书。在这种情况下，可以减少配对设置期间对中间人攻击的保护；然而，一旦交换了长期公共密钥，便可以将这些密钥可靠地用于后续配对验证期间的双向认证。可以使用其他技术进一步减小中间人攻击或其他利用的风险。例如，如果配对设置过程中的两个设备之一(或两者)具有接近传感器，该传感器能够检测另一个设备有多近(例如，使用蓝牙LE或NFC)，如果另一个设备不非常接近或不保持非常接近(例如，在几英寸内)，那么具有传感器的设备可以中止配对设置过程。这样可以减小中间人攻击的可能性，因为攻击设备会需要物理地接近过程中的预期参与者，用户可能会注意到这种情况。一些实施方案能够向配对设置过程中并入安全证书和基于设置代码的配对。图15A-图15F示出了根据本发明的一个实施方案用于使用安全证书和设置代码的控制器1502和附件1504的配对设置过程1500的实施例。过程1500可以并入上文所描述的过程1300和1400的特征。首先参考图15A，在框1506处，控制器1502可以向附件1504发送启动请求以开始配对设置过程。例如，控制器1502可以向附件1504的/pair-setupURL发送HTTPPOST请求。POST请求可以包括指示期望配对状态(例如，“开始配对设置”)的TLV数据对象和用于指示是否将使用设置代码和/或证书的方法标识符。在框1508处，附件1504可以接收启动请求并可以相应地设置当前配对状态。在框1510处，附件1504可以阻挡可能出现的任何其他控制器，以免其发起配对设置。例如，如果在框1510之后接收到开始配对设置的请求，那么附件可以返回错误响应(例如，HTTP429“请求过多”消息)。附件1504可以继续通过这一方式阻止配对设置请求，直到过程1500完成(或由于错误而终止)。在一些实施方案中，附件1504可以全局性地或针对每个控制器将不成功配对设置尝试的次数限制到最大尝试次数。例如，附件1504可以定义极限(例如，5次尝试，10次尝试，或某些其他极限)并维持不成功尝试的计数器。如果计数器达到或超出极限，那么在框1512处，附件可以拒绝请求，并且过程1500可以在框1514处退出。在一些实施方案中，附件1504可以向控制器1502发送错误响应，指示错误原因(例如，尝试过多)。或者，可以使用抑制技术(例如，如上文参考图13A所述)或其他技术，以防止未经授权的控制器暴力尝试执行配对设置。假设未超过最大尝试次数，在框1516处，附件1504可以开始配对设置。例如，附件1504可以例如通过调用适当的SRP协议功能，诸如SRP_new(SRP6a_server_method())来创建SRP会话；设置针对会话的SRP用户名(例如，利用SRP_set_username，使用固定字符串作为用户名，其可以是一般性的)；生成随机盐(例如，至少16个字节)，其可以被设置有SRP_set_params；并选择(例如，检索)设置代码以设置为SRP口令(例如，使用SRP_set_auth_password或SRP_set_auth_password_raw)。类似于过程1300，附件1504可以使用各种技术选择设置代码，包括从EEPROM读取代码，从用户接收代码，生成随机代码(例如，在执行过程1500期间)等。在框1518处，附件1504可向用户提供设置代码。例如，根椐附件和设置代码，可以在附着于附件1504或其封装的标签上印刷代码，在附件1504的显示器上呈现，等等。在一些情况下，并非向用户呈现设置代码，附件1504可以使用独立于用于配对设置过程1500的信道的通信信道，诸如NFC信道或具有极短范围的(例如小于50cm)其他信令信道，向控制器1502输送代码。在框1520处，附件1504可以(例如，使用SRP_gen_pub)生成公共密钥(“pkA”)。公共密钥pkA可以是短期密钥对的一部分(连同秘密密钥“skA”)，该短期密钥对用于过程1500期间并随后丢弃。在框1522处，附件1504可以例如使用HTTP响应消息来发送启动请求的响应。响应可以包括公共密钥pkA和随机盐。在框1522处发送响应时，附件104可以更新当前配对状态以指示附件的公共密钥已被发送。在框1524处，控制器1502可以接收对启动请求的响应。在框1526处，控制器1502可以从用户获取设置代码。例如，控制器1502可以呈现提示用户输入附件的设置代码的用户界面屏。像上述过程1300的框1322那样，可以使用其他技术，只要在带外，即经由独立于用于执行配对设置过程的通信信道的通信信道，向控制器1502输送设置代码即可。根据使用的特定技术，控制器采集设置代码可以并入某种形式的用户活动(例如，输入代码，保持控制器接近附件，操作控制器的相机等)，并且此类活动可以充当除了提供设备身份的带外确认之外，用户期望在控制器1502和附件1504之间建立配对的确认。参考图15B，在框1528处，控制器1502能够通过例如调用适当的SRP协议功能，诸如SRP_new(SRP6a_server_method())来创建SRP会话；设置SRP用户名(例如，利用SRP_set_username，使用固定字符串作为用户名，其可以是一般性的)；将盐设置成从附件接收的盐(利用SRP_set_params)；生成其自己的公共密钥(“pkC”)(例如，使用SRP_gen_pub)；以及使用在框1526处获取的设置代码来设置SRP口令(例如，使用SRP_set_auth_password或SRP_set_auth_password_raw)。像附件公共密钥pkA那样，公共密钥pkC可以是短期密钥对的一部分(连同秘密密钥“skC”)，该短期密钥对用于过程1500期间并随后丢弃。在框1530处，控制器1502可以计算共享秘密(“inputKey”)(例如，使用SRP_compute_key)。在框1532处，控制器1502可以生成证据(“proofC”)，表示其具有共享秘密inputKey(例如，使用SRP_Respond)。在框1534处，控制器1502可以向附件1504发送验证请求。例如，控制器1502可以向附件1504的/pair-setupURL发送HTTPPOST请求。POST请求可以包括指示期望配对状态(例如，“验证配对设置”)、控制器的公共密钥pkC和控制器证据proofC的TLV数据对象。在框1536处，附件1504可以接收验证请求。在框1538处，附件1504可以计算共享秘密(“inputKey”)(例如，使用SRP_compute_key)；这一共享秘密应当匹配控制器1502在框1530处计算的共享秘密。在框1540处，附件1504可以使用在框1538处计算的共享秘密来验证控制器的证据proofC(例如，使用SRP_verify)。虽然在图15B中未示出，但如果验证失败，附件1504可以终止过程1500并且向控制器1502发送错误消息。(像本文描述的其他配对过程那样，控制器1502可以向用户报告错误。)假设proofC得到验证，在框1542处，附件1504可以生成附件证据(“proofA”)以证实其拥有共享秘密(例如，使用SRP_respond)。在框1544处，附件1504能够从共享的秘密导出会话加密密钥(eKey)。例如，附件1504可以使用基于HKDF的密钥导出函数，其利用inputKey、盐和附加信息作为输入，实施针对512比特散列的安全散列算法版本2(HKDF-SHA-512，在IETFRFC6234中记录)。参考图15C，假设在该实施例中附件1504具有由受信任证书管理机构发出的安全证书。在一些实施方案中，证书可以被并入如上文参考图14A-图14C所述的认证芯片中。在这种情况下，附件1504可以使用其证书进一步向控制器1502认证其身份。在一些实施方案中，控制器1502在框1506处发送的启动请求或控制器1502在框1534处发送的验证请求可以包括附件是否应当利用证书认证的指示。在附件1504利用证书认证的情况下，在框1546处，附件1504能够从在框1538处计算的共享秘密(inputKey)生成要签署的质疑。例如，可以通过应用使用inputKey、盐和附加信息项作为输入的密钥导出函数诸如HKDF-SHA-512来生成质疑。盐和附加信息项可以具有预定义值，可以将预定义值作为其操作系统或固件的一部分编程到附件1504中。在框1548处，附件1504可以利用其证书对质疑进行签署。例如，如果附件1504包括认证芯片，则该认证芯片可以签署质疑。如上所述，认证芯片可以具有其自己的持久密钥对(独立于pkA和skA或LTPKA和LTSKA)，并能够实施任何期望的签名算法，诸如SHA-1。在框1550处，附件1504可以构建包括已签署质疑和附件证书的数据结构，可以从认证芯片检索该数据结构。在框1552处，附件1504能够使用在框1544处生成的加密密钥(eKey)来对在框1550处构建的数据结构加密。可以使用诸如ChaCha20-Poly1305AEAD算法的任何对称加密算法。加密算法可以生成加密的数据结构和标签(authTagA)。在框1554处，附件1504可以向控制器1502发送验证响应。验证响应可以包括在框1542处生成的附件证据proofA，以及在框1550处生成的加密数据结构和authTagA。如上所述，在一些实施方案中，可以选择性地执行或不执行基于证书的认证(例如，根据控制器1502是否请求基于证书的认证)。在不执行基于证书的认证的情况下，验证响应可以省略加密数据结构和authTagA。在框1556处，控制器1502可以从附件1504接收验证响应。在框1558处，控制器1502可以验证附件证据proofA(例如，使用SRP_verify)。如果验证失败，过程1500可以带错误地终止。假设验证成功，在框1560处，控制器1502能够从在框1530处计算的共享秘密(inputKey)导出加密密钥(eKey)。控制器1502可以使用附件1504在框1544处使用的相同的密钥导出算法和输入，使得预期在框1560处导出的eKey匹配附件在框1544处生成的eKey。在框1562处，控制器1502可以验证接收到的authTagA，并且在框1564处，控制器1502可以对接收到的数据结构解密。现在参考图15D，在框1566处，控制器1502可以验证从解密的数据结构提取的附件证书。例如，如上所述，控制器1502可以具有其自己的认证芯片或存储用于标识有效附件证书的信息的其他安全数据存储装置；该信息可以由受信任的证书管理机构提供并且在一些情况下更新。或者，控制器1502能够与受信任的证书管理机构实时通信以验证所接收的证书。控制器1502能够使用来自证书管理机构的信息(无论是在本地高速缓存的还是实时获得的)以确认附件证书是有效的。在一些实施方案中，某些证书可能仅对于特定类别的附件有效，并且控制器1502可以使用先前从附件接收的信息(例如，在如上所述的设备发现期间提供的信息)以确定附件类别以及附件证书对于该附件类别是否有效。如果证书不是有效的，过程1500可以带错误地终止。假设证书是有效的，在框1568处，控制器1502可以从共享秘密inputKey生成质疑。控制器1502可以使用附件1504在框1546处使用的相同算法和输入(例如，带有预定义盐和附加信息项的inputKey)，结果控制器1502和附件1504均应当生成相同的质疑。利用这种技术，控制器1502不必向附件1504通过明文发送质疑。此外，在质疑并入共享秘密inputKey的情况下，冒名顶替者可能难以猜测到质疑。在框1570处，控制器1502可以使用来自附件证书的公共密钥来验证签署的质疑。如果验证失败，过程1500可以带错误地终止。假设验证成功，控制器现在准备好与附件交换长期公共密钥。在框1572处，控制器1502可以生成LTPKC消息，其级联了对共享秘密(例如，具有盐和附加信息项的共享秘密的HDKF-SHA-512，其可以具有编程到控制器1502中的预定义值作为其操作系统或固件的一部分)、控制器的长期公共密钥(LTPKC)和控制器的标识符的表示。在一些实施方案中，控制器具有可在框1572处使用的预定义的(LTPKC，LTSKC)密钥对；在其他实施方案中，可以在框1572处生成(LTPKC，LTSKC)密钥对。在框1574处，控制器1502能够利用其长期秘密密钥(LTSKC)，例如，通过向LTPKC消息应用诸如Ed25519(在http://ed25519.cr.yp.to有文档记录)的签名算法，来签署LTPKC消息。在框1576处，控制器1502可以构建包括来自LTPKC消息的签名、LTPKC和控制器ID的数据结构。(LTPKC消息自身可以从该数据结构省略，因为附件1504将能够重建它。)在框1578处，控制器1502能够使用在框1560处导出的加密密钥eKey对数据结构加密并生成认证标签(authTagC)。在框1580处，控制器1502可以向附件发送密钥交换请求。例如，控制器1502可以向附件1504的/pair-setupURL发送HTTPPOST请求。密钥交换请求可以包括加密的数据结构和在框1578处生成的验证标签。在框1582处，附件1504可以从控制器1502接收密钥交换请求。现在参考图15E，在框1584处，附件1504可以验证接收到的验证标签。在框1586处，附件1504可以对数据结构解密，并且在框1588处，附件1504可以验证包含在数据结构中的签名。如果任何验证均失败，过程1500可以带错误地终止。假设认证标签和签名得到验证，在框1590处，附件1504能够持久存储从数据结构提取的LTPKC和控制器ID作为配对的控制器记录。此类存储可以在如上文所述的安全元件中进行。附件1504可以通过类似方式向控制器1502发送其自己的长期公共密钥(LTPKA)。例如，在框1592处，附件1504可以生成LTPKA消息，其级联了对共享秘密(例如，具有盐和附加信息项的共享秘密的HDKF-SHA-512，其可以具有编程到附件的系统软件或固件中的预定义值)、附件的长期公共密钥(LTPKA)和控制器的标识符的表示。在一些实施方案中，附件具有可在框1592处使用的预定义的(LTPKA，LTSKA)密钥对；在其他实施方案中，可以在框1592处生成(LTPKA，LTSKA)密钥对。在框1594处，附件1504能够利用其长期秘密密钥(LTSKA)，例如，通过向LTPKA消息应用诸如Ed25519的签名算法，来签署LTPKA消息。在框1596处，附件1504可以构建包括来自LTPKA消息的签名、LTPKA和附件ID的数据结构。(LTPKA消息自身可以从这种数据结构省略，因为控制器1502将能够重建它。)在框1598处，附件1504能够使用在框1544处导出的加密密钥eKey对数据结构加密并生成认证标签(authTagB)。在框1501处，附件1504可以向控制器1502发送密钥交换响应。密钥响应可以包括加密的数据结构和在框1598处生成的验证标签。在框1503处，控制器1502可以接收密钥交换响应。现在参考图15F，在框1505处，控制器1502可以验证接收到的验证标签。在框1507处，控制器1502可以对数据结构解密，并且在框1509处，控制器1502可以验证包含在数据结构中的签名。如果任何验证均失败，过程1500可以带错误地终止。假设认证标签和签名得到验证，在框1511处，控制器1502能够持久存储从数据结构提取的LTPKA和附件ID作为配对的附件记录。此类存储可以在如上文所述的安全元件中进行。在框1513处，配对设置完成，并且可以更新配对状态以指示这种情况。应当理解，过程1500是例示性的，并且可能进行变型和修改。可并行执行按顺序描述的步骤，可改变步骤顺序，并且可修改、合并、添加或省略步骤。例如，控制器每次向附件发送消息或反之(例如，在配对过程状态改变时)，可能检测到错误。尽管指示某些错误状况，但应当理解，如果在任何点检测到错误，过程1500都可以结束，并且控制器可以通知用户该错误。此外，参考特定加密和/或认证算法是为了例示的目的，并且可替换用于在不安全通信信道上进行数据安全交换的其他协议和算法。过程1500是不对称的，因为附件向控制器发送证书进行验证，但控制器不向附件发送对应的证书。在一些实施方案中，可以实现双向证书验证。例如，具有证书的控制器可以实施类似于框1546-1552的处理，以生成质疑，并利用控制器证书对其签署，并且可以连同控制器证书一起将签署的质疑发送到附件。附件可以实施类似于框1566-1570的处理以验证控制器的证据。在一些实施方案中，给定附件或控制器能够支持配对设置过程1300,1400,1500(和/或未具体描述的其他过程)中的任一个或全部，并且可以针对每次配对选择要使用的配对设置过程。为了一致起见，控制器可以支持多个配对设置过程(例如，具有和不具有证书)并能够基于附件支持哪个(些)过程来针对给定附件选择过程。过程可以是签署的优选顺序(例如，基于所提供的相对安全性)，并且控制器能够选择给定附件支持的最优选过程。控制器能够通过例如在启动请求消息中包括过程标识符来指定要使用的过程。可以参考图16获得配对设置的更一般视图，图16示出了根据本发明的一个实施方案的控制器1602和附件1604之间的一般化配对设置过程1600。可以由控制器1602在框1606处发起配对设置过程1600。例如，如上所述，控制器1602可以执行过程400(通过框426)以标识应当与其进行配对设置的附件(例如，附件1604)。控制器1602可以向附件1604发送消息(例如，向适当的URL发送POST请求)，使得附件1604也可以在框1608处开始配对设置。在框1610和1612处，附件1604和控制器1602可以建立共享秘密(例如，上文所描述的过程1300,1400和1500中的inputKey)。建立共享秘密可以包括双向信息交换。例如，在过程1300中，附件提供盐和短期公共密钥，并且控制器提供其短期公共密钥。在过程1400和1500中，附件提供其短期公共密钥和证书，并且控制器提供其短期公共密钥。在一些实施方案中，共享的秘密还可以并入被编程到两个设备中(例如，在安全元件内或别处)的其他信息。共享秘密还可以并入带外信息，这可以提供控制器被授权(例如，由用户)与附件互操作的证据。例如，在过程1300和过程1500中，附件的设置代码由控制器和附件用于构造共享秘密。如上所述，附件的设置代码可以在带外被提供给控制器，即，使用除用于发送和接收证据的除信道之外的通信信道。带外信道的示例可以包括用户输入(例如，用户能够在控制器的用户界面处输入附件的设置代码，使用控制器的相机拍摄设置代码的照片)、近场通信信道、光学信令信道、有线电子信令信道、音频(例如，超声波)信道等。在一些情况下，带外信道可以并入用户的介入(例如，输入设置代码，保持控制器近场接近附件，拍照，插入连接器)，并且经由带外信道传送设置代码的事实能够充当用户证实建立配对的指示。在框1614处，控制器1602可以生成并向附件1604发送证据。如本文所用，“证据”或“密码证据”可以包括拥有共享秘密的接收设备(在这种情况下是附件1604)可用于验证发送设备(在这种情况下是控制器1602)也拥有共享秘密的任一条信息。控制器证据的示例包括在过程1300,1400,1500中标记为“proofC”的消息。在框1616处，附件1604能够接收控制器的证据，并且在框1618处，附件1604能够基于其本地生成的共享秘密的副本来验证证据。如果共享秘密不匹配，将不验证控制器的证据，并且过程1600可以带错误地终止。应当指出，在使用设置代码来生成共享秘密时，框1618处的验证还可以充当控制器对附件的认证。假设证据得到验证，在框1620处，附件1604能够生成其自己的证据并向控制器1602发送，以展示附件1604也拥有共享秘密。附件证据可以是例如来自控制器证据的也并入共享秘密(像在过程1300和1500中那样)的不同加密消息。在一些实施方案中，可以并入附件身份的其他证据；例如，在过程1400和1500中，附件可以利用确认附件身份的至少一些方面的证书来签署消息。在框1624处，控制器可以验证接收到的证据。类似于框1618，如果共享秘密不匹配，将不验证附件的证据，并且过程1600可以带错误地终止。应当指出，在使用设置代码来生成共享秘密时，框1624处的验证还可以充当附件对控制器的认证。例如，如果附件证据并入了使用证书签署的消息(像在过程1400和1500中那样)，可以提供进一步认证。假设在框1624处认证了证据，则可以认为两个设备彼此认证，并且可以使用共享秘密交换附加信息，诸如上述长期公共密钥，以建立(持久)配对。例如，在框1626处，控制器1602可以发送其长期公共密钥(LTPKC)。LTPKC可以加密形式发送，例如，利用从共享秘密导出的密钥(像过程1300,1400和1500中那样)。在框1628处，附件1604可以接收并持久存储LTPKC(例如，在如上所述的安全元件中)。在框1630处，附件1604可以发送其长期公共密钥(LTPKA)。LTPKA也可以以加密形式发送，例如，利用从共享秘密导出的密钥(像过程1300,1400和1500中那样)。在框1632处，控制器1602可以接收并持久存储LTPKA(例如，在如上所述的安全元件中)。之后，完成配对设置(框1634)，因为每个设备现在都具有认证过的、持久存储的彼此建立配对的记录。应当理解，过程1600是例示性的，并且可能进行变型和修改。可并行执行按顺序描述的步骤，可改变步骤顺序，并且可修改、合并、添加或省略步骤。例如，可以按照任何顺序(附件优先或控制器优先)交换证据，并且也可以按照任何顺序交换长期公共密钥。应当指出，本文将长期公共密钥称为“公共”，以指示可以向其他设备提供它们，这与私有(或秘密)密钥不同。然而，如过程1300,1400,1500,1600中所示，在利用其他信息(例如，设置代码)建立共享秘密之后，配对设置可以允许设备以加密形式交换长期公共密钥。在一些实施方案中，长期公共密钥的解密和存储可以在接收设备中的安全计算元件内进行，并且这可以进一步保护长期公共密钥不暴露于未经授权的设备。这可以使未经授权的设备伪造配对设置记录更加困难。这一层级的安全性允许如下所述，在设备重新连接时，为更简单的配对验证过程使用配对设置记录。经由上述配对设置过程的任一种建立的配对可以是持久状态，因为附件和控制器可以在持久存储装置(例如，非易失性存储器、磁盘等)中存储它们接收的长期公共密钥；持久存储装置可以在安全元件中。在一些实施方案中，一旦附件与一个控制器执行了配对设置，附件便能够例如通过利用错误消息对任何接收到的发起配对设置的请求作出响应来防止任何其他控制器执行配对设置。可以将执行与附件的配对设置的控制器指定为该附件的“管理员”，并能够允许其指示附件例如使用上述配对添加过程来与其他控制器建立配对。在一些实施方案中，附件可以同时与多个控制器建立配对；可以利用配对设置、配对添加(如下所述)等建立每个配对。例如，附件可以持久存储查找表或其他数据结构，其包括已经建立配对的每个控制器的标识符和相关联的LTPKC。数据结构还可以包括关于控制器的其他信息。例如，可以授权不同的控制器对附件进行不同程度的控制(称为许可)，并且附件维护的数据结构可以包括用于指定每个控制器具有哪些许可的指示符(例如，标记)。可以定义各种许可。可以定义的一种许可是“管理员”许可，并且在一些实施方案中，仅有具有管理员许可的控制器能够向附件添加针对其他控制器的配对记录(例如，利用下述配对添加过程)。在一些实施方案中，可以自动为成功执行配对设置的控制器授予管理员许可。可以在配对添加期间选择性地为其他控制器授予管理员许可(例如，如下所述)。类似地，控制器可以同时与多个附件建立配对。例如，控制器可以执行与多个附件的配对设置，或者在一些情况下，控制器可以经由如下所述的配对添加过程与附件添加附件。控制器可以持久存储查找表或其他数据结构，其包括控制器已经与其建立配对的每个附件的标识符和相关联的LTPKA。该数据结构还可以包括诸如控制器针对该附件具有什么许可的信息。设想已经建立配对的控制器和附件可能之后不会彼此保持持续通信。例如，附件或控制器可能被关闭，或者一个设备可能已经离开另一个的范围。在已经彼此建立配对的控制器和附件返回到通信状态时，并不是再次执行配对设置，该设备可以使用不同的过程(本文称为配对验证)来验证先前建立的配对的存在。配对验证可以使用先前创建和存储的长期公共密钥记录(例如，在配对设置或配对添加期间)。配对验证过程还可以生成新的共享秘密和/或会话密钥，可以用于对后续消息加密，只要设备保持在配对验证状态即可。可以由任一个设备，例如通过删除会话密钥的其自身副本，来终止配对验证状态(本文也称为配对验证会话)，这将使其不能对来自另一设备的将来消息解密。在一些实施方案中，可以在控制器每次尝试打开信道，以与其已经建立配对的附件进行统一附件协议通信时，执行配对验证。图17A-图17C示出了根据本发明的一个实施方案的控制器1702和附件1704之间的配对验证过程1700的实施例。过程1700可以在控制器1702确定配对验证是适当动作时，例如，在控制器1702接收到控制附件1704上的一些操作的用户指示，并且配对验证会话并未同时存在于控制器1702和附件1704之间时，或在控制器1702与附件1704重新连接时开始。参考图17A，在框1706处，控制器1704可以例如利用如上所述的Curve25519算法来生成新的短期密钥对(pkC，skC)。在框1708处，控制器1704可以向附件1704发送配对验证开始请求；该请求能够包括短期公共密钥pkC(和任选的附加信息，诸如在建立配对时向附件1704提供的控制器ID或控制器用户名userC)。在一些实施方案中，可以将配对验证开始请求作为HTTPPOST请求向附件的/pair-verifyURL发送。在一些实施方案中，可以向图12的配对状态请求特性1201写入状态指示符，以指示控制器1704已经请求配对验证开始状态。在框1710处，附件1704可以接收配对验证开始请求并能够在其配对控制器列表中查找长期公共密钥(LTPKC)。在一些实施方案中，可以在安全元件内执行查找，并且附件1704的其他逻辑部件可以仅知道查找是否成功。如上所述，在建立配对时，可以持久存储将控制器ID(或用户名userC)与LTPKC相关联的配对记录，因此框1710能够允许附件1704确定是否已经与控制器1702建立了配对。在框1712处，如果还没有建立与控制器1702的配对，附件1704能够在框1714处发送错误消息。如果在框1716处，控制器1702接收到错误消息，过程1700可以在框1718处结束，并且控制器1702可以向用户报告错误。如果附件1704确定其已经与控制器1702建立了配对，那么在框1720处，附件1704能够例如利用Curve25519算法生成短期公共/秘密密钥对(pkA，skA)。在框1722处，附件1704可以使用skA和pkC生成共享秘密(“inputKey”)。在框1724处，附件1704可以导出对称的密钥(“Key”)。例如，附件1704可以使用inputKey、盐(例如，预定义字符串，可以与配对设置中使用的盐不同)和附加信息作为输入来使用HDKF-SHA-512。在框1726处，附件1704可以生成并签署附件信息消息。例如，附件1704能够级联pkA和pkC，并利用附件的长期秘密密钥(LTSKA)签署该级联。也可以级联附加信息，诸如附件ID。在框1728处，附件1704可以利用对称密钥Key对签署的消息加密，以生成附件证据(proofA)和认证标签(authTagA)。在框1730处，附件1704可以向控制器1702发送配对验证开始响应。该响应可以包括proofA、认证标签和短期公共密钥pkA。也可以包括其他信息，诸如附件标识符或用户名(“userA”，可以是在建立配对时提供给控制器的附件名称)。在框1730处发送响应时，附件1704可以更新配对状态以指示附件的证据已被发送。在框1732处，在接收响应之后，控制器1702可以例如基于附件ID或附件用户名在其配对附件的列表中查找长期公共密钥(LTPKA)。在一些实施方案中，可以在安全元件内进行查找，并且控制器1702的其他逻辑部件可以仅知道查找是否成功。如上所述，在建立配对时，可以持久存储将附件ID(或用户名userA)与LTPKA相关联的配对记录，因此框1732能够允许控制器1702确定是否已经与附件1704建立了配对。参考图17B，在框1734处，如果还没有建立与附件1704的配对，过程1700可以在框1736处结束，并且控制器1702可以向用户报告错误。在一些实施方案中，控制器1702能够在开始过程1700之前确定其是否存储了指示与附件1704建立配对的记录，并且可以省略在框1734处的附加检查。如果控制器1702确定其已经与附件1704建立了配对，那么在框1738处，控制器1702可以使用skC和pkA生成共享秘密(“inputKey”)。在框1740处，控制器1702可以导出对称的密钥(“Key”)。例如，控制器1702可以使用inputKey、盐和附加信息项作为输入来使用HDKF-SHA-512。在一些实施方案中，盐和附加信息项可以具有与配对设置期间使用的预定义值不同的预定义值。如果未发生错误，在框1740处导出的Key应当匹配附件1704在框1724处导出的Key。在框1742处，控制器1702可以使用对称密钥Key解密接收到的proofA，并且还可以验证authTagA。在框1744处，控制器1702可以验证从proofA提取的已签署附件信息消息上的附件的签名。这种验证可以使用来自与附件1704建立配对的所存储LTPKA。如果成功，这一验证确认附件1704是先前提供LTPKA的同一附件(假设没有其他附件具有相同的长期密钥对)。在框1746处，如果未验证authTagA或签名(或如果解密失败)，过程1700可以在框1748处结束，并且控制器1702可以向用户报告错误。参考图17C，如果框1746处的验证成功，那么在框1750处，控制器1702可以生成并签署控制器信息消息。例如，控制器1702可以级联pkC和pkA(在该实施例中，顺序与框1724处的级联相反)，并签署与控制器的长期秘密密钥的级联。也可以级联附加信息，诸如控制器ID。在框1752处，控制器1702可以使用对称密钥Key加密签署的消息以生成控制器证据(proofC)和认证标签(authTagC)。在框1754处，控制器1702可以向附件1704发送验证完成请求。该请求可以包括proofC和authTagC。在框1754处发送请求时，控制器1702可以更新配对状态以指示控制器的证据已被发送。在框1756处，附件1704可以接收验证完成请求并可以使用对称密钥Key和验证authTagC对所接收的proofC解密。在框1758处，附件1704可以验证从proofC提取的已签署控制器信息消息上的控制器签名。这种验证可以使用来自与控制器1702建立配对的所存储LTPKC。如果成功，这一验证确认控制器1702是先前提供LTPKC的同一控制器(假设没有其他控制器具有相同的长期密钥对)。在框1760处，如果未验证authTagC或签名(或如果解密失败)，附件1704可以在框1762处向控制器1702发送错误响应。如果验证成功，附件1704可以在框1764处向控制器1702发送成功响应。在任一种情况下，在发送响应时，附件1704可以更新配对状态以指示适当的响应。在框1766处，控制器1702可以确定接收到哪个响应。如果接收到错误消息1762，过程1700可以在框1768处结束，并且控制器1702可以向用户报告错误。如果接收到成功消息1764，那么在框1770处完成配对验证，并且可以更新配对状态以这样指示。应当理解，过程1700是例示性的，并且可能进行变型和修改。可并行执行按顺序描述的步骤，可改变步骤顺序，并且可修改、合并、添加或省略步骤。例如，控制器每次向附件发送消息或反之(例如，在配对过程状态改变时)，可能检测到错误。尽管指示某些错误状况，但应当理解，如果在任何点检测到错误，过程1700都可以结束，并且控制器可以通知用户该错误。此外，参考特定加密和/或认证算法是为了例示目的，并且可以替换用于进行数据安全交换的其他协议和算法。还应当指出，过程1700与建立配对时交换长期公共密钥的方式无关(例如，使用哪个配对设置或配对添加过程)。附件和控制器可以进行配对验证，只要每个设备具有另一个的长期公共密钥即可，该长期公共密钥可以在所有时间保持存储(例如，在每个设备的安全元件中)。此外，与附件和控制器相关联的用户名(“userA”和“userC”)可以包括允许另一个设备在配对验证期间查找长期公共密钥的任何信息。这可以但不必包括实际用户的名称或其他标识符。在一些实施方案中，用户名可以并入(或者是)特定长期公共密钥所属设备的设备标识符。像上述各种配对设置过程那样，配对验证过程1700可以包括生成新的加密密钥(Key)。在一些实施方案中，可以将这一密钥用作会话密钥以对完成配对验证过程1700之后接着发送的任何或所有消息(例如，上述请求和响应)加密。会话密钥可以一直持续到任一设备对会话密钥的其副本进行删除或使其无效。因此，任一设备能够在任何时间通过对其自己的会话密钥副本进行删除或使其无效来单边切断与另一者的通信。例如，如果控制器移动到附件的接近阈值之外或失去与附件的连接，或者如果在超时期间内未发生任何通信，或者在会话持续时间的固定上限(其可以与附件制造商或程序员选择的一样短或一样长)之后，附件可以删除会话密钥。这样允许附件根据需要限制控制器的访问。在一些实施方案中，仅在过程1700期间使用在配对验证过程1700期间导出的加密密钥。对于配对验证会话内的后续通信，控制器1702和附件1704均可以计算一个或多个新的会话密钥。例如，可以通过向利用控制盐和附加信息项(可以具有预定义的恒定值)的配对验证期间(例如，在过程1700的框1722和1738处)生成的共享秘密(inputKey)应用HKDF-SHA-512(或类似算法)来导出附件到控制器会话密钥(“AC会话密钥”)。可以通过向利用另一个控制盐和附加信息项(其也可以具有预定义的恒定值)的配对验证期间生成的共享秘密(inputKey)应用HKDF-SHA-512(或类似算法)来导出控制器到附件会话密钥(“CA会话密钥”)。在一些实施方案中，可以使用不同的控制盐和/或不同的附加信息项来生成AC会话密钥和CA会话密钥，使得两个会话密钥不必相同。控制器和附件可以均生成AC和CA两个会话密钥。在配对验证会话内的后续通信期间，可以由附件使用AC会话密钥对其向控制器发送的消息加密，并由控制器对其从附件接收的消息解密，而可以由控制器使用CA会话密钥对其向附件发送的消息加密，并由附件对其从控制器接收的消息解密。任一设备均能够通过使其会话密钥无效而结束会话(例如，删除会话密钥或利用错误对任何接收的使用会话密钥加密的消息作出响应)。此外，在一些实施方案中，单个控制器可以定义并使用多个长期密钥对(LTPKC，LTSKC)。例如，具有多个授权用户的控制器(例如，共享计算机)可能针对每个授权的用户具有不同的长期密钥对，使得不同用户能够与附件的不同子集交互。只要控制器具有针对每个密钥对的独立用户名，附件便无需知道控制器具有超过一个密钥对。作为另一个示例，控制器能够使用不同的长期密钥对与不同附件建立配对。使用多个长期密钥对的控制器能够跟踪与其建立配对的每个附件使用哪个(LTPKC，LTSKC)对。类似地，附件可以具有多个长期密钥对(LTPKA，LTSKA)，并能够跟踪与其建立配对的每个控制器使用哪个对。在一些实施方案中，设备可以限制其提供给特定长期公共密钥的其他设备的数量，并且具有多个长期公共密钥能够允许该设备不时切换到不同密钥。在一些实施方案中，可以在配对设置或配对验证之后的任何时间，在可以称为“配对添加”或添加配对的过程中，在设备之间交换长期公共密钥(或在一些情况下，交换证书)。例如，如上所述，附件可以将其自身限制为执行与一个控制器(可以称为针对该附件的“管理员”或“admin”)的配对设置，并可以拒绝第一次成功配对设置之后所有后续配对设置请求(至少直到去除配对，例如，如下所述)。为了允许其他控制器与附件交互，管理员控制器可以执行配对添加过程以在附件和不同控制器之间(或在一些情况下，在附件和同一控制器的不同长期公共密钥之间)建立配对。图18A-图18B示出了根据本发明的一个实施方案的控制器1802(例如，具有管理员许可的控制器)和附件1804之间的配对添加过程1800的实施例。在这个过程中，假设控制器1802先前与附件1804执行过配对设置(并由此获得管理员许可)或者已经经由执行配对添加过程1800的先前实例而被添加为管理员。首先参考图18A，在框1806和1808处，控制器1802和附件1804可以完成配对验证过程(例如，过程1700)以建立共享秘密和会话密钥(例如，如上所述的AC密钥和CA密钥)。在框1810处，控制器1802可以标识长期公共密钥(LTPKN)以与附件1804交换。这可以是例如属于与其建立配对的控制器(本文也称为“新”控制器)的长期公共密钥；这可以是除控制器1802之外的控制器。在一些情况下，可以针对新控制器获得安全证书(其可以包含长期公共密钥)。在框1812处，控制器1802可以生成包含指示数据块涉及添加配对的请求、长期公共密钥LTPKN、新控制器的控制器标识符，以及指示向新控制器授予许可的许可信息(例如标记)的数据块。例如，如上所述，要执行与附件的配对设置的第一控制器可以自动被指定为该附件的管理员。对于经由配对添加过程1800添加的每个新控制器，该许可信息可以指定新控制器是否应当还被指定为管理员。在一些实施方案中，许可针对附件的管理员针对该附件执行配对添加，而不许可不是管理员的控制器执行配对添加。在框1814处，控制器1802可以向附件1804发送配对添加开始请求；该请求可以包括在框1812处生成的数据块。像配对验证会话内的所有通信那样，该请求可以利用适当的会话密钥被加密。在一些实施方案中，配对添加开始请求可以包括用于标识配对添加开始请求的状态指示符(可以向图12的配对状态请求特性1201写入这一状态指示符和后续状态指示符)。在一些实施方案中，可以将配对添加开始请求作为HTTPPOST请求发送到附件1804的/pairingsURL(或其他适当的URL)。在框1816处，附件1804可以接收配对添加开始请求。如在配对验证会话从控制器接收的任何请求那样，附件1804可以通过使用适当的会话密钥对请求解密而开始；如果解密失败，附件1804可以返回错误响应(或根本不作出响应)。在框1818处，附件1804能够确定是否许可控制器1802执行配对添加。例如，如上所述，控制器可以被选择性地授予管理员许可，并且可以将配对添加限制到具有管理员许可的控制器。作为另一个示例，具有用户界面的附件可以提示用户指示是否许可配对添加请求。作为另一个示例，如上所述，在一些情况下，用户可以经由机械操作使附件进入配对模式，并且可以配置一些附件仅在处于配对模式时许可配对添加请求。作为另一个示例，在一些实施方案中，附件1804可以具有能够同时存储的配对数量的上限(例如，16次配对，32次配对或某个其他极限)，并且如果会导致超过这个极限，附件1804可以将配对添加请求作为未许可来处理。其他技术也可以用于确定附件1804是否应该许可特定的配对添加请求。如果请求不被许可，那么附件1804可以在框1820处发送错误消息。参考图18B，如果许可配对添加请求，那么在框1832处，附件1804可以基于所接收的消息(例如，在其安全元件中)持久存储新的配对。例如，附件1804可以存储与接收到的新控制器的控制器标识符和许可相关联的长期公共密钥LTPKN。在一些实施方案中，附件1804不必在过程1800期间向控制器1802提供长期公共密钥(LTPKA)，因为控制器1802会在发起过程1800之前接收到它。然而，在其他实施方案中，可能希望附件1804与不同控制器使用不同的长期公共密钥。在这种情况下，附件1804可以准备包含应当由新控制器使用的长期公共密钥的数据块。例如，在框1834处，附件1804可以标识要由新控制器使用的长期公共密钥；这个公共密钥可以与先前提供给控制器1802的长期公共密钥(LTPKA)相同或不同。在框1836处，附件1804可以生成包含在框1834处标识的长期公共密钥以及要由新控制器使用的附件标识符(可以与先前提供给控制器1802的附件标识符相同或不同)的数据块。在框1838处，附件1804可以向控制器1802发送配对添加响应。如果在框1836处生成数据块，可以将数据块包括在配对添加响应中。像配对验证会话内的所有通信那样，该响应可以利用适当的会话密钥被加密。该配对添加响应可以包括更新状态指示符以指示配对添加响应已被发送。在框1840处，控制器1802可以接收配对添加响应。如在配对验证会话中从附件接收的任何响应那样，控制器1802可以通过使用适当的会话密钥对响应解密而开始；如果解密失败，可以忽略响应，并且过程1800可以带错误地终止。在框1844处，控制器1802可确定响应是否指示成功。否则，过程1800可以在框1846处结束，并且控制器1802可以通知用户有错误。如果响应指示成功，那么在框1848处，控制器1802可以通知新控制器该配对。例如，控制器1802可以向新控制器传送针对附件1804的附件标识符和长期公共密钥LTPKA。在一些实施方案中，控制器1802可以为新控制器提供针对附件1804的先前存储的LTPKA和附件标识符；在其他实施方案中，控制器1802可以为新控制器提供由附件1804在配对添加响应中提供的信息。新控制器可以将接收到的LTPKA和附件标识符作为配对记录持久存储。之后，新控制器可以与附件1804(而不进一步涉及控制器1802)执行配对验证过程(例如，过程1700)，并且可以与附件1804进行交互。应当理解，过程1800是例示性的，并且可能进行变型和修改。可并行执行按顺序描述的步骤，可改变步骤顺序，并且可修改、合并、添加或省略步骤。例如，控制器每次向附件发送消息或反之(例如，在配对过程状态改变时)，可能检测到错误。尽管指示某些错误状况，但应当理解，如果在任何点检测到错误，过程1800都可以结束，并且控制器可以通知用户该错误。此外，参考特定加密和/或认证算法是为了例示目的，并且可以替换用于进行数据安全交换的其他协议和算法。在一些实施方案中，可以将配对添加过程1800用作委托配对的模式，如下所述。如上所述，配对设置和配对添加能够允许通过交换可以由接收设备持久且安全存储的长期公共密钥来建立附件和控制器之间的配对。在一些情况下，可能希望，例如，通过移除来自持久存储器的长期公共密钥来移除建立的配对。因此，本发明的某些实施方案提供配对移除过程。图19A-图19B示出了根据本发明的一个实施方案的控制器1902(例如，具有管理员许可的控制器)和附件1904之间的配对移除过程1900的实施例。过程1900总体上可以类似于过程1800，只是过程1900导致移除现有的配对而不是建立新配对。在这个过程中，假设控制器1902先前与附件1904进行过配对设置(并由此获得管理员许可)或者已经例如经由执行配对添加过程1800而被添加为管理员。参考图19A，在框1906和1908处，控制器1902和附件1904可以完成配对验证过程(例如，过程1700)以建立共享秘密和会话密钥(例如，如上所述的AC密钥和CA密钥)。在框1910处，控制器1902可以获得要移除的控制器的标识符。这可以是附件1804在配对记录中存储的标识符。在一些情况下，这可以是控制器1902自己的标识符(控制器可以移除其自己的配对)；在其他情况下，它可以是另一个控制器的标识符。在一些情况下，框1910可以包括获得除标识符之外被移除的控制器的长期公共密钥。在框1912处，控制器1902可以生成数据块，该数据块包含该数据块涉及移除配对的请求的指示，以及要移除其配对的控制器的标识符。在一些实施方案中，该数据块可以包括诸如要移除的控制器的长期公共密钥的其他信息。在框1914处，控制器1902可以向附件1904发送配对移除开始请求；该请求可以包括在框1912处生成的数据块。像配对验证会话内的所有通信那样，该请求可以利用适当的会话密钥被加密。在一些实施方案中，配对移除开始请求可以包括状态指示符，以指示该配对移除开始请求已被发送(这个和后续状态指示符可以被写入到图12的配对状态请求特性1201中)。在一些实施方案中，可以将配对移除开始请求作为HTTPPOST请求发送到附件1904的/pairingsURL(或其他适当的URL)。在框1916处，附件1904可以接收配对移除开始请求。如在配对验证会话中从控制器接收的任何请求那样，附件1904可以通过使用适当的会话密钥对请求解密而开始；如果解密失败，附件1904可以返回错误响应(或根本不作出响应)。在框1918处，附件1904可以确定是否许可控制器1902执行配对移除。例如，如上所述，可以选择性地授予控制器管理员许可，并且可以将配对移除限制到具有管理员许可的控制器。作为另一个示例，具有用户界面的附件可以提示用户指示是否许可配对移除请求。作为另一个示例，如上所述，在一些情况下，用户可以经由机械操作使附件进入配对模式，并且一些附件可被配置为仅在处于配对模式时许可配对移除请求。其他技术也可以用于确定附件1904是否应该许可特定的配对移除请求。如果请求不被许可，那么附件1904可以在框1920处发送错误消息。参考图19B，如果配对移除请求被许可，那么在框1932处，附件1904可以从其建立的配对列表移除与所接收数据块中指定的控制器的配对(例如，通过从安全存储元件删除配对记录)。在一些实施方案中，附件1904不必提供相反指示以在过程1900期间移除长期公共密钥(LTPKA)。在附件1904移除配对记录之后，移除的控制器将不能执行与附件1904的配对验证，并且这样可以防止移除的控制器与附件1904交互，不论移除的控制器是否还移除其配对记录。然而，在其他实施方案中，可能希望附件1904指定要移除的配对。在这种情况下，附件1904可以准备包含应当由新移除的控制器移除的长期公共密钥和附件标识符的数据块。例如，在框1934处，附件1904能够标识应当从新移除的控制器移除的长期公共密钥；例如，这可以是在添加控制器时在过程1800的框1834处标识的密钥。在框1936处，附件1904可以生成数据块，该数据块包含在框1934处标识的长期公共密钥和与该长期公共密钥相关联的附件标识符。在框1938处，附件1904可以向控制器1902发送配对移除响应。如果在框1936处生成数据块，可以将数据块包括在配对移除响应中。像配对验证会话中的所有其他通信那样，该响应可以利用适当的会话密钥被加密。该配对移除响应可以包括更新状态指示符以指示配对移除响应已被发送。在框1940处，控制器1902可以接收配对移除响应。像在配对验证会话中从附件接收的任何响应那样，控制器1902可以通过使用适当的会话密钥对响应解密而开始；如果解密失败，可以忽略响应，并且过程1900可以带错误地终止。在框1944处，控制器1902可确定响应是否指示成功。否则，过程1900可以在框1946处结束，并且控制器1902可以通知用户该错误。如果响应指示成功，那么在框1948处，控制器1902可以通知移除的控制器其配对已被移除。在一些实施方案中，控制器1902还可以向移除的控制器传送附件1904的附件标识符和/或长期公共密钥LTPKA。之后，移除的控制器不再能够与附件1904执行配对验证过程，这可能导致移除的控制器不能与附件1904交互。已经经由过程1900移除的控制器能够例如经由配对添加过程1800在稍晚时间被再次添加。一些实施方案可以为附件1904提供选项以将移除的控制器“加入黑名单”，这样可以防止移除的控制器与附件1904重新建立配对。例如，来自控制器1902的配对移除请求可以包括是否应当将移除的控制器加入黑名单的指示，并且附件1904能够持久存储加入黑名单的控制器列表。在配对设置或配对添加期间，附件1904可以检查黑名单，并且如果控制器在黑名单上，则返回错误。应当理解，过程1900是例示性的，并且可能进行变型和修改。可并行执行按顺序描述的步骤，可改变步骤顺序，并且可修改、合并、添加或省略步骤。例如，控制器每次向附件发送消息或反之(例如，在配对过程状态改变时)，可能检测到错误。尽管指示某些错误状况，但应当理解，如果在任何点检测到错误，过程1900都可以结束，并且控制器可以通知用户该错误。此外，参考特定加密和/或认证算法是为了例示目的，可以替换用于进行数据安全交换的其他口令协议和算法。如下所述，在一些实施方案中，可以结合委托的配对来使用配对移除过程1900。上文描述的实施方案允许附件和控制器创建(设置)、验证、添加和移除配对，其中配对可以包括配对中的每个伙伴设备持久存储另一伙伴设备的长期公共密钥和/或证书。在一些实施方案中，可能有用的是用户获得与给定附件配对的控制器列表，或者与给定控制器配对的附件列表。在后一种情况下(与控制器配对的附件)，控制器上执行的程序(例如，操作系统或应用程序)能够通过读取控制器存储的配对信息来生成列表，并能够在控制器自己的用户界面上向用户呈现该列表。为了提供与给定附件配对的控制器列表，特定实施方案允许控制器从附件检索所有配对控制器的列表；然后控制器可以向用户呈现该列表。例如，如图12中所示，附件可以具有作为其配对概况的一部分的配对列表特性1204。特性1204可以包括关于已经与附件建立配对的每个控制器的信息(例如，控制器ID等)，但不需要包括任何控制器的长期公共密钥。在一些实施方案中，控制器能够例如利用HTTPGET请求等如任何其他特性那样读取配对列表特性1204。在一些实施方案中，控制器可以通过向附件的/pairingsURL(或其他适当的URL)发送HTTPPOST请求来获得附件的配对列表；POST请求可以包括用于指示正在请求配对列表的项目。在一些实施方案中，可以允许控制器仅在配对验证的会话内读取配对列表1204，使得可以对附件响应加密。此外，在一些实施方案中，可以将配对列表1204的读取限制到具有管理员许可的控制器。在一些实施方案中，附件一次仅能够与一个控制器建立配对，并且仅许可建立配对的控制器稍晚移除该配对。这样可以增强安全性。然而，对于某些应用而言，这可能是不方便的限制。例如，在家庭环境100(图1)的情况下，如果多个人生活在家中，可能希望每个人都具有能够打开门锁104的控制器102(例如，移动电话)。因此，本发明的某些实施方案能够允许附件同时与多个控制器保持配对。例如，每个控制器可以使用上文描述的配对设置过程来单独建立配对。然而，允许控制器独立建立配对可能对于一些应用而言不够安全。例如，对于家庭前门的门锁而言，房主可能希望防止任何别人不经房主的明确许可而建立配对。为了能够管理配对，某些实施方案能够提供“委托”配对过程。在委托配对过程中，第一(“admin”或“主”)控制器能够例如使用上述配对设置来与附件建立配对，并由此获得管理员许可。之后，可能需要管理员控制器参与针对任何后续(“委托”)控制器的配对设置过程。一种类型的委托配对可以是“直接”委托。在直接委托中，主控制器可以使用图18A-图18B的配对添加过程1800或类似过程，以向附件递送针对委托控制器的控制器公共密钥(和控制器用户名)。对于直接委托而言，主控制器能够与委托控制器通信以获得委托控制器的长期公共密钥。另一类型委托配对可以是“外部的”或“转发的”委托。在外部委托中，附件可被配置为向“授权者”设备委托配对设置和配对验证，授权者设备可以被并入主控制器中或能够与主控制器通信的某个其他设备中。授权者设备能够如上所述执行与附件的配对设置，并且在配对设置之后，授权者能够维持(或使用配对验证来重新建立)通往附件的安全信道。如果附件接收配对设置或配对验证请求，附件可以经由安全信道向授权者转发请求。授权者能够执行操作和/或向附件指示是否应当允许操作。第三种类型的委托配对可以是“基于证书的”委托。在基于证书的委托中，主控制器能够为附件配置信任证书链。例如，主控制器能够使用图18A-图18B的配对添加过程1800或类似过程向附件安全地递送信任证书链。例如，可以定义“设置证书链请求”消息供控制器向附件发送(这可以是，例如，发往为接收证书链而定义的特性或URL的HTTPPUT请求)。这一请求消息的内容可以包括TLV项或TLV项的系列，包含证书链，例如，按照从根到最深的子管理机构的顺序。可以利用在配对验证期间建立并利用主控制器的长期公共密钥LTSKC数字地签名的对称密钥对TLV项加密。该附件能够使用存储的LTPKC来验证签名并利用对称密钥对加密的TLV项解密，以提取证书链。在一些实施方案中，可以在附件的安全存储元件中存储证书链。附件可以发送用于指示成功或失败的响应消息。在另一个控制器尝试执行与附件的配对设置时，可能要求该控制器提供证书，作为其长期公共密钥的补充或替代。该附件能够确定该证书是否被先前接收的信任证书链签署，并能够部分地基于证书是否被这样签署而接受或拒绝配对设置。被委托控制器可以通过经由某个其他信道(例如，从主控制器，受信任证书管理机构等)获得适当签署的证书并向附件呈现它来针对该附件变成被授权的。本领域的技术人员应当理解，本文所述的配对过程和架构是例示性的，并且可能进行变型和修改。可以替换不同的加密算法、密钥和协议，并且可以在给定操作环境中同时支持多种不同的算法、密钥和协议。示例性附件：门锁为了进一步示出可以在本发明实施方案中给出的各个方面和特征，现在将描述具体的附件实施例。第一实施例是门锁附件，其可以包括联接到可以安装在门上的门锁的电子锁定单元。在一些实施方案中，门锁自身可以是机械锁(例如，无弹簧锁闩型)，并且电子锁定单元能够操作机电致动器以在锁定位置和解锁位置之间移动机械锁。还可以提供位置传感器等以允许电子锁定单元确定机械锁当前处于锁定位置还是解锁位置。在其他实施方案中，可以使用其他类型的门锁，例如磁性锁、电子锁和通过供应电子控制信号和/或施加机械力而锁定和解锁的任何其他类型的锁。电子锁定单元可以容纳或连接到逻辑电路，以实现上文所述的统一附件协议，以及通信电路，以与一个或多个控制器通信。电子锁定单元能够生成电子信号(例如，一条或多条导线上的电压或电流水平)以例如经由机电致动器等来操作门锁。在一些实施方案中，电子锁定单元和门锁可以物理地位于公共外壳内，诸如附接到门的模块内，或者在门或门框内部。在其他实施方案中，电子锁定单元和门锁可以在单独的外壳中。例如，门锁可以在门内部，而电子锁定单元安装在附近墙壁上。可以提供门锁中的致动器和电子锁定单元之间的有线连接。也可以使用无线连接而不脱离本发明的范围，但本领域的技术人员应当理解，本情景中的无线连接可能增加附加安全性问题。参考图20，示出了根据本发明的一个实施方案用于门锁附件2004的操作环境2000。操作环境2000可以实现于例如办公楼、家、公寓或宾馆楼宇或具有至少一个内门或外门2006的任何其他结构中。出于例示的目的，假设希望为多个个人提供锁定和解锁门2006的能力。进一步假设，门2006具有“所有者”(即，合法地或通过协议授权确定应当或不应当允许谁通过门2006的某个人或实体)。例如，如果在办公楼中实施环境2000，则楼宇的所有者(或在所有者的授权下行事的租客)可以是门2006的所有者。如果环境2000实现于家中，所有者可以是房主、户主或由住户指定的其他个人。在该实施例中，门锁附件2004可以被配置为与一个或多个用户操作的控制器2012(示出了三个，但可以使用任意数量)无线通信。例如，门锁附件2004可以提供传感器2020，可以通过物理接近控制器2012之一来触发该传感器以发起通信。门锁附件2004也可以与主控制器2018(也称为管理员)通信。在该实施例中，通过无线连接与主控制器2018通信，但也可以使用有线连接。主控制器2018可以是门2006的所有者所拥有或操作的计算设备，包括台式计算机、膝上型计算机、移动电话、平板电脑等。对于办公楼而言，操作主控制器2018的人可以是指定的安全代理。主控制器2018可以在物理上位于相对于门2006的任何地方。例如，主控制器2018可以在从门2006进入的房间中，位于楼中别处的安全办公室中，或完全在另一栋楼中。在一些实施方案中，主控制器2018也可以充当用户设备(例如，移动电话)。在安装门锁附件2004之后，主控制器2018可以执行如上所述的配对设置过程以将自身确立为主控制器；例如，作为执行配对设置的结果，主控制器2018可以获得管理员许可(例如，如上所述)。之后，委托的配对技术(例如，上述的配对添加)可以用于在门锁附件2004和每个用户设备2012之间建立配对。或者，门锁附件2004可以被配置为使得仅能够在特定物理条件下(例如，钥匙被物理地插入附件2004中)执行配对设置，并且门锁附件2004可以在获得用于配对的物理条件时执行与用户设备2012中的每个用户设备的配对设置。在一些实施方案中，用于门锁附件2004的附件模型可以包括锁定机构服务，其提供锁门和开门的能力(例如，图2G的锁定机构服务254的实例)。用于门锁附件2004的附件模型还可以包括锁定管理服务(例如，图2H的锁定管理服务255的实例)，并且锁定管理服务能够支持其他与锁相关的功能，诸如记录锁定日志，该日志具有用于指示谁以及何时锁门或开门的条目。例如，可以由主控制器2018访问该锁定日志。图21示出了根据本发明的一个实施方案的用于门锁附件2004的附件对象2100的实施例。对象2100被示为扁平形状，但也可以表示为类似于图3A-图3C的JSON对象。如图所示，门锁附件2004可以包括附件标识服务实例2102、锁定机构服务实例2104和锁定管理服务实例2106。每个服务实例可以包括如图所示的特性；可以根据图2A-图2D和图2J定义该特性。例如，可以由控制器读取当前状态特性2110以确定门当前是锁定还是解锁(或卡住等)，并且可以由控制器写入目标状态特性2112以请求门的锁定或解锁。锁定日志特性2116可以包含锁定日志事件记录的阵列，每个事件记录可以是数据对象。在该实施例中，每个锁定日志事件记录可以包括触及门锁2004的实体(人或设备)的标识符、发生触及的时间以及执行的操作(例如，锁定或解锁，读取锁定日志，清空锁定日志)。可以提供任选的字符串元素以提供关于触及的附加特定于供应商的信息。在一些实施方案中，控制器可以读取特性2116以访问锁定日志。例如，可以使用锁定管理控制点特性2114发送请求以读取或清空锁定日志。例如，控制器可以发送请求以向特性2114写入数据对象，并且可以将该数据对象解释为特定请求。在该实施例中，支持的请求可以包括读取锁定日志(从数据对象中指定的开始时间开始)，清空锁定日志(这样可以从锁定日志删除所有条目或数据对象中指定的指定范围条目)，以及设置当前时间，门锁附件2004能够使用当前时间作为记录将来锁定日志条目的依据(设置该时间可能对于例如考虑日光节省等是有用的)。如上文参考图5G-图5K所述，在一些实施方案中，门锁附件2004可以选择在线还是通过查询结果机制来对发往控制点特性2114的写入请求作出响应。决策可以针对每个请求。图21中示出的其他特性可以如上文参考图2A-图2D和图2J所述的那样操作。应当理解，图21中示出的服务和特性是例示性的，并且可能进行变型和修改。根据锁的功能，可以针对锁附件来定义服务和特性的其他集合和子集。为了进一步例示，现在将描述特定实施情形。在这种情形中，门2006的所有者可以购买并在门2006上安装门锁附件2004。(门锁附件2004可以作为门2006的一部分或作为售后升级而被销售。)门2006的所有者可以配置主控制器2018以与门锁附件2004通信。例如，主控制器2018可以是台式或便携式(例如，膝上型、手持式、移动、可穿戴)计算机系统，其可以执行程序(例如，操作系统程序或用户安装的应用程序)以发送和接收符合上述统一附件协议的消息并生成图形用户界面(或其他类型的用户界面)，其允许门2006的所有者与门锁附件2004交互。完成这一安装之后，门2006的所有者可以将主控制器2018与门锁附件2004配对。图22是根据本发明的一个实施方案，诸如门2006的所有者的用户能够将主控制器2018与门锁附件2004(或任何其他控制器与任何其他附件)配对的过程的流程图。在框2202处，门锁附件2004(或任何其他附件)可以进入配对模式。在一些实施方案中，用户可以将附件置于配对模式中。在一些实施方案中，每个附件制造商可以定义特定用户动作以将其附件置于配对模式中。例如，对于门锁附件2004而言，附件制造商可以在附件外壳中某处提供物理钥匙孔或钥匙插槽，用户可以向其中插入由附件制造商提供的钥匙。作为另一个示例，门锁附件2004可以在其外壳上或内部具有机械开关，以启用或禁用配对模式；可以放置这个开关，使得在门2006关闭时不能触及该开关。通常，将附件置于配对模式可能涉及各种动作以向附件指示授权的用户存在并在尝试将控制器与附件配对；然而，不要求使用任何特定技术将附件置于配对模式中。另外，在一些实施方案中，在第一次安装门锁附件并上电时，或者在其未与任何控制器建立配对的任何时候，门锁附件2004可以自动进入配对模式。在框2204处，控制器可以发现附件。例如，对于门锁附件2004和主控制器2018而言，附件2004在被置于配对模式中时，可以例如使用上述设备发现服务开始通告其可以进行配对。主控制器2018可以例如通过执行图4的附件发现过程400直到框422，来执行可以定位门锁附件2004的统一控制器程序(或其他程序代码)。作为另一个示例，一些控制器可被配置为自动搜索附件(定期地或响应于诸如进入区域的事件)或响应于用户输入，诸如致动由控制器提供的“FIND”控件来搜索附件。在框2206处，用户可以指示控制器与在框2204处发现的附件配对。例如，如上所述，附件发现过程400可以包括控制器向用户呈现关于附件的信息并提示用户指示是否应当进行配对。作为另一个示例，执行附件发现的控制器可以向用户呈现发现的所有附件的列表，并且用户可以从该列表选择要配对的附件。用户指令可以采取各种形式。在一些情况下，用户指令可以包括输入门锁附件2004的设置代码；在其他情况下，设置代码的输入可以是独立的用户动作。在框2208处，响应于用户指令，控制器可以与在框2204处发现的附件发起配对设置过程。例如，在框2208处，可以发起以上描述的任何配对设置过程(过程1300,1400,1500,1600)。在框2210处，在配对设置过程期间的某个点处，用户能够向附件提供验证，指示应当与发起配对设置的特定控制器进行配对。可以由附件制造商确定是否需要以及需要什么验证。在一些实施方案中，附件不需要超过其处于配对模式并且控制器正尝试配对这一事实的任何附加验证。此外，在一些实施方案中，框2206处的用户输入(其可以包括附件设置代码)也可以充当框2210处的验证。在附件不需要验证的情况下，例如，可以通过在配对设置过程中包括用户执行某个可以由附件检测到的动作的要求来实施此类验证，如果未正确执行该动作，附件对控制器产生错误响应。例如，配对过程1300和1500包括对附件的验证，形式为控制器具有附件的设置代码的证据。如上所述，控制器可以从用户获得附件的设置代码并在生成共享秘密时使用该设置代码；控制器正确生成共享秘密的事实可以向附件验证控制器具有设置代码。作为另一个示例，如果控制器和附件都装备了近场通信(NFC)技术(例如，符合由NFC论坛(http://nfc-forum.org)发布的标准的通信技术)，附件可以要求用户将控制器带入NFC通信范围中并可以与控制器交换信息以确认NFC信道上的控制器是在另一信道上执行配对设置的同一控制器。例如，可能要求控制器经由NFC信道和配对设置信道两者提供其共享秘密的证据(proofC)。可以替换其他验证操作，并且单个用户动作可以提供在框2206处配对的指令和在框2210处验证的指令。在框2212处，可以完成配对设置过程，并且(假设未发生错误)可以通知用户(例如，由控制器)已经建立与附件的配对。之后，在框2214处，附件可以退出配对模式。在一些实施方案中，退出配对模式可以包括用户动作以从配对模式移除附件。此类用户动作可以是在框2202处将附件置于配对模式中的用户动作的反动作，诸如取下物理钥匙，将配对开关翻转到其禁用位置等。在一些实施方案中，附件可以在一完成配对设置时便自动退出配对模式。参考图20，在环境2000中，可以针对门2006的所有者希望与门锁附件2004配对的每个控制器2012重复过程2200。然而，在一些环境下，逐个配对每个控制器2012可能不方便。例如，如果配对需要物理上非常接近，则必须要使每个控制器2012都这样接近并依次配对。如果要对大量控制器2012配对(例如，如果门2006是具有很多居住者的大型楼宇的前门)，这可能变得相当耗时。此外，在一些实施方案中，在第一控制器已成功建立配对之后，门锁附件2004可能不许可第二控制器执行配对设置。因此，在一些实施方案中，过程2200可以用于在门锁2004和一个控制器(例如，主控制器2018)之间建立配对。之后，主控制器2018可以使用委托的配对过程(例如，配对添加过程1800或上文描述的其他委托配对过程)以建立门锁2004和附加控制器2012的配对。例如，如果主控制器2018具有针对特定控制器2012的长期公共密钥(或安全证书)，主控制器2018可以使用配对添加过程1800向门锁附件2004提供密钥(或证书)。作为另一个示例，主控制器2018能够向门锁附件2004提供信任证书链(例如，如上所述)，并且每个控制器2012可以具有由信任证书链签署的证书，可以使用其以允许给定控制器2012建立配对并访问门锁附件2004。如上所述，在一些实施方案中，主控制器2018可以向任何添加的控制器2012选择性地授予管理员许可，并且具有管理员许可的控制器2012可以执行配对添加以在附件2004和附加控制器2012之间建立配对。此外，被授权访问门2006的该组用户可能随时间变化。例如，在办公楼中，雇员可能会辞掉工作，因此应当终止她进入楼宇的权利。在家中，同住的人可能会迁出。主控制器2018(或具有管理员许可的其他控制器)可以例如通过利用上述配对移除过程1900进行此类更新，以移除门锁附件2004与应当不再许可访问的任何控制器2012的配对。在一些实施方案中，主控制器2018(或针对门锁附件2004具有管理员许可的其他控制器2012)上执行的统一控制器程序可以提供各种用户界面以方便管理对门2006的访问。例如，所有者或安全代理可以能够查看授权控制器的列表，例如，使用如上所述的配对请求列表(在一些实施方案中，该列表还可以包括用于标识授权控制器的用户)；标识要添加到授权列表的新控制器；和/或选择要从授权列表移除的授权控制器。因此，可以改善组织或多用户环境中的安全操作。一旦特定控制器2012已经与门锁附件2004(例如，使用上述任何技术，包括直接或委托配对)建立配对，便可以使用该控制器2012访问门2006。例如，可以为控制器2012提供程序代码(例如，操作系统或应用代码)，其使得控制器2012能够发送和接收符合上述统一附件协议的消息。程序也可以定义图形用户界面(或其他类型的用户界面)以允许控制器2012的用户与附件进行交互。图23是根据本发明的一个实施方案用于打开门锁的过程2300的流程图。例如，可以在任何控制器2012(或控制器2018)和图20的门锁附件2004之间执行过程2300。在控制器2012确定门2006应当解锁时，过程2300可以在框2302处开始。例如，携带便携式控制器2012的用户可能进入门锁附件2004的范围内。可以将“范围内”根据需要定义为在无线通信范围内或更窄范围内。例如，为了避免无意中打开门锁，控制器2012和门锁附件2004可以配置有接近感测能力(例如，使用蓝牙LE、NFC等)，并且控制器2012可以被配置为定义尝试打开门锁的最大范围(例如，几英寸、2英尺、6英尺内或某种其他范围)。在一些实施方案中，在控制器2012检测到门锁附件2004处于范围内时，控制器2012能够与用户交互以确认用户希望打开门2006。例如，用户能够启动或以其他方式激活应用或系统级程序(或其一部分)以在进入范围内时打开门锁。在其他实施方案中，控制器2012可以执行过程2300的部分作为背景过程，以扫描发现其已经与其建立配对的门锁附件；在检测到范围中的此类附件时，控制器2012能够向用户生成提示。此外，在控制器2012提示用户确认应当打开门锁时，控制器2012能够要求用户提供认证凭据(例如，口令或生物测定凭据，诸如指纹)，以验证控制器2012正在被授权用户携带着。在其他实施方案中，控制器2012可以被配置为只要控制器2012进入门锁附件2004的范围内，无需用户输入，便自动尝试打开门锁2006。其他具体实施也是可能的。特定实施可能取决于特定门锁附件2004期望的安全水平，因此同一控制器根据用户接近哪个门而可能有不同行为。此外，可以使用其他技术确定应当打开门锁，并且不需要控制器2012和门锁附件2004之间物理接近。例如，用户可能能够通过操作控制器2012上的用户界面以选择门并指示应当开锁来远程打开门2006(例如，从另一个房间或完全从另一个位置)。在一些实施方案中，在执行远程解锁之前，控制器2012能够要求用户提供认证凭据(例如，口令或生物测定凭据，诸如指纹)，以验证控制器2012正在被授权用户操作。在框2306和2308处，控制器2012和门锁附件2004可以执行配对验证操作(例如，上文所描述的过程1700)。这一操作可以验证先前在两个设备之间建立了配对。在框2310处，如果配对验证过程不成功，过程2300可以在框2312处结束，控制器2012可以提示用户有错误。在一些实施方案中，可以提示用户重试。可能在控制器2012每次尝试打开门锁附件2004时都需要配对验证。如果配对验证过程不成功，那么在框2314处，控制器2012可以向门锁附件2004发送加密的请求以打开门。例如，如上文参考图5A-图5D所述，控制器2012可以发送HTTPPUT请求，以向门锁附件2004的锁定状态特性2102写入布尔值“真”(打开)值。如配对验证会话中的所有通信那样，可以利用配对验证期间(或之后)建立的会话密钥对请求加密。在一些实施方案中，尽管并非必需的，但可以利用控制器2012的长期秘密密钥签署该请求。在框2316处，门锁附件2004可以接收加密的请求。在框2318处，门锁附件2004可以对该请求进行验证和解密。像配对验证会话内的所有通信那样，如果该请求未利用正确的会话密钥加密，附件可以忽略该请求。此外，如果利用控制器的长期秘密密钥签署该请求，附件可以使用控制器长期公共密钥的其副本(其可以针对建立的配对而持久存储)以验证签名并因此验证控制器的身份。附件2004也可以验证许可控制器2012打开门锁。例如，在一些实施方案中，可以将特定时间的访问限制到具有管理员许可的控制器。可以通过具有管理员特权的控制器向仅管理员访问的特性2122(图21)写入来设置或移除这一限制，该特性可以是图2D的特性228的实例。也可以应用其他规则或决策标准。在框2320处，如果请求有效(例如，如果其被正确加密且来自许可的控制器)，门锁附件2004可以在框2322处继续打开门锁。在一些实施方案中，门锁附件2004可以向控制器2012报告解锁(例如，通过发送HTTP200OK响应)。如果需要，控制器2012和/或门锁附件2004还可以提供用于指示成功的用户可察觉输出。例如，任一个或两个设备可以蜂鸣或发出滴答声，闪烁绿灯等。在一些实施方案中，可以通过在锁定服务实例2106的定义中包括适当特性，诸如音频反馈特性206(图2A)或其他希望的特性，来使得附件的反馈行为可以定制。在框2302处，如果请求不是有效的，那么在框2324处，门锁附件2004可以向控制器2012(例如，通过发送HTTP错误响应)发送错误消息。在一些实施方案中，控制器2012可以通知用户错误和/或提示用户再次尝试。如果需要，控制器2012和/或门锁附件2004还可以提供用于指示开锁尝试失败的用户可察觉输出。例如，任一或两个设备都可能发出错误声音(例如，与成功声音不同的蜂鸣声)、闪烁红灯等。应当理解，过程2300是例示性的，并且可能进行变型和修改。可并行执行按顺序描述的步骤，可改变步骤顺序，并且可修改、合并、添加或省略步骤。应当指出，过程2300依赖于先前建立的配对的存在，但可能与建立配对的方式(例如，基于证书或基于设置代码，直接或委托)无关。因此，该实施例中的附件和控制器会需要知道它们已经建立了配对，但无需知道配对是如何或何时建立的。此外，尽管过程2300示出了在锁定门的特定情景中控制器和附件之间的交互，但了解本公开的本领域技术人员将认识到，可以实施类似的过程以控制任何附件的任何操作。在一些实施方案中，门锁附件2004可以保持门2006解锁，直到接收到锁门的明确指令(例如，经由类似于过程2300的过程)。在其他实施方案中，门锁附件2004能够应用自动重新锁定间隔。例如，在框2322处解锁门2006之后，附件2004可以等待固定一段时间(例如，十秒)，然后重新锁定。也可以实施其他安全措施，诸如如果用户在框2322处解锁之后未立即(例如，在五秒内)打开门，则自动重新锁定门2006。例如，可以通过向自动超时特性实例2124(图21)写入非零值来实施自动重新锁定行为。在一些实施方案中，门锁附件2004在打开门锁之前可能需要附加的条件或用户动作。例如，如上所述，门锁附件2004能够并入NFC收发器，并且门锁附件2004能够要求控制器2012在解锁之前被代入NFC范围中。或者，门锁附件2004能够具有传感器，以检测用户何时触摸门，并且如果在附件确定解锁请求无效之后门未被适当触摸(例如，在两秒或五秒内)，可以拒绝解锁。作为另一个示例，在一些实施方案中，门锁(或任何其他附件)的制造商或供应商可以通过使用控制器和附件之间交换的“数据块”而选择并入特定于制造商的行为。如本文所用，“数据块”是指可以由控制器存储(例如，图20的控制器2012和主设备2018中的每一者可以存储数据块)并作为发往附件的任何请求的一部分而被发送到该附件或与特定请求(例如，写入特定特性的请求)一起选择性地发送的一块数据。从控制器的角度来讲，数据块可以是不透明的；接收数据块的附件可以特定于附件的方式解释其内容。作为例示，对于门锁附件2004而言，制造商可能需要门锁附件2004的用户登记为锁的授权用户。例如，制造商可以提供服务器，该服务器支持网站，其中用户能够获得该锁的授权代码(例如，通过在服务器上创建账户)。可以由服务器生成授权块(可以是包含授权代码和附件制造商期望的任何附加信息的数据对象)并递送到用户的控制器2012。控制器2012可以将授权块存储为与附件2004相关联的数据块。在控制器2012接下来向附件2004发送请求时，控制器2012可以在请求中包括存储的数据块。在一些实施方案中，发送数据块可能取决于请求的性质。例如，附件定义记录能够定义包括控制器相对于该特性具有的许可的特性(例如，如图3A-图3C所示)。在一些实施方案中，可以定义许可字符串(例如，“BlobRequired”)以指示需要数据块来访问特性；并且附件制造商可以在针对制造商希望为其接收数据块的任何特性的许可的定义中包括这一字符串。在向特定特性生成请求时，控制器2012可以从附件定义记录(它可以高速缓存的)查阅许可，以确定是否需要数据块；如果需要，控制器2012可以将数据块附加到请求。在其他实施方案中，可以在每个附件的层次上作出是否发送数据块的决定(例如，如果控制器存储了针对特定附件的数据块，控制器可以向其向附件发送的每个请求附加数据块)。示例性附件：IP相机可以根据本发明的各种实施方案控制的附件的第二实施例是IP相机附件。IP相机附件可以包括能够捕获视频图像(有或没有音频)并向其他设备流传输所捕获媒体(音频和/或视频)的相机。在一些情况下，IP相机也可以提供其他功能，诸如记录和/或回放先前记录的内容。像本文所述使用统一附件协议的任何其他附件那样，可以将这些功能模型化为服务并通过读取和写入各个服务的特性实例来进行控制。在以上描述的统一附件协议的实施方案中，控制器和附件之间的通信可以使用HTTP请求和响应进行。就IP相机而言，可以使用HTTP请求和响应来设置相机并控制其行为(例如，瞄准相机，开始和停止记录等)；然而，HTTP可能不太适合设备之间的媒体内容的实时流传输。因此，在本文描述的IP相机实施方案中，IP相机和控制器能够使用不同的协议，诸如RTP协议(例如，如IETFRFC3550中定义)，并使用SRTP协议(例如，如IETFRFC3711中定义的)实现媒体安全。将显而易见的是，可以替换其他媒体流传输协议。统一附件协议可以定义可用于建立流传输会话的特性，该流传输会话支持流传输协议(可以与根据统一附件协议定义的配对验证会话不同)，并可以经由流传输会话进行流传输内容的递送。参考图24，示出了根据本发明的一个实施方案用于IP相机附件2404的操作环境2400。在该实施例中，IP相机附件2404可以例如经由无线接入点2406与控制器2402通信。也可以支持直接通信。IP相机附件2404可以是持久地或可拆卸地安装在某区域中的固定装置(例如，安装在房间、走廊或楼宇入口中的安保或监视相机)，或者可以是可用于在多种不同设置中捕获视频的便携式相机。控制器2402可以是要控制IP相机2404的任何设备。例如，如果将IP相机2404用作楼宇的安保相机，控制器2402可以实施于楼宇中的安保站处。作为另一个示例，可以将IP相机2404设置于儿童房中，例如作为婴儿监视器，并且控制器2402可以是父母的移动电话、平板电脑或父母通常携带的其他设备。作为另一个示例，用户可以带着IP相机2404去公园或野生动物保护区，并在不引人注目的地方设置它，然后撤回远方位置以利用控制器2402控制IP相机2404，由此增大获得野生动物等的高质量视频的可能性。因此，IP相机2404的使用并不限于任何特定环境或任何特定控制器。像本文描述的其他附件那样，IP相机附件2402可以被模型化为服务的集合。图25A-图25B示出了根据本发明的一个实施方案可以包括在针对IP相机附件2402的附件模型中的服务2501-2505的示例性定义。类似于以上图2G-图2H中所示的服务定义示例，服务定义2501-2505可以指定所需和/或任选的特性。图26A-图26E示出了针对图25A-图25B的服务特性的示例性定义。未在图26A-图26E中提供的针对图25A-图25B中所列特性的示例性定义可以在图2A-图2D中找到。可以将这些服务和/或特性中的任一个定义为核心服务和特性，或者，如果不这样定义，可以定义为扩展服务和特性。参考图25A，IP相机流传输服务2501可以描述用于管理媒体会话的实时通信服务。例如，IP相机流传输服务2501可以包括促进例如如下所述在控制器2402和IP相机附件2404之间设置和控制媒体流的特性。记录服务2502可以描述用于控制记录设备，例如开始、停止或安排记录的服务。类似地，回放服务2503可以描述用于控制附件回放所存储媒体，例如，开始和暂停回放的服务。尽管在该实施例中未示出，但本领域的技术人员将认识到，可以定义附加的特性，以用于选择要播放的所存储媒体项，作为回放服务2503的一部分或作为独立的内容选择服务。参考图25B，相机服务2504可以提供相机设置控制，诸如打开或关闭相机。在一些实施方案中，可以在这一服务中包括与相机设置相关的其他特性，作为任选特性，诸如相机取向特性(例如，摇摄、倾斜、缩放、旋转)。其他任选特性可以包括图像处理特性，诸如夜视(开或关)和镜像模式(启用或禁用所捕获图像的镜像)。特定相机附件提供的任何用户可选择设置可以具有在相机服务2504中定义和包括的对应特性。麦克风服务2505可以提供对麦克风的控制，麦克风用于记录声音。服务2505可以包括在针对具有麦克风输入的任何相机附件的定义中并对于没有麦克风输入的任何相机被省略。扬声器服务2506可以提供对扬声器的控制，该扬声器能够用于输出声音。服务2506可以包括在针对具有扬声器输出的任何相机附件的定义中并对于没有扬声器输出的任何相机被省略。参考图26A-图26B，可用于IP相机管理的特性可以包括会话开始特性2601、会话结束特性2602和附加特性2603-2615。可以由控制器写入会话开始特性2601和会话结束特性2602(图26A所示)以开始和结束流传输会话。可以由控制器读取附加的特性2603-2615以获得关于IP相机的视频和/或音频流传输的属性的信息。会话开始特性2601可以具有控制器能够写入的数据对象(例如，TLV格式或其他密钥值格式)作为值，以提供IP相机附件可用于开始流传输会话的信息。图26C示出了可以在会话开始特性2601中包括的数据元的实施例。会话ID2631可以是针对要开始的流传输会话的UUID。控制器IP地址2632和控制器端口2633可以标识流传输数据应当发送到的目的地(例如，使用IPv4或IPv6格式)。控制器SRTP主密钥2634和控制器SRTP主盐2635可以提供盐和主加密密钥，以用于对会话内的流传输的媒体加密。视频最大带宽2636和音频最大带宽2637可以指示流传输数据带宽的上限(例如，单位为每秒千比特(kbps))。再次参考图26A，会话结束特性2602可以具有提供要结束会话的会话标识符的数据对象(例如，TLV格式或其他密钥值格式)作为值。在一些实施方案中，不需要其他信息来结束会话。视频编解码器名称2603可以提供用于表示IP相机服务实例的视频编解码器提供的媒体类型的字符串。在一些实施方案中，可以定义一组用于该字符串的有效值(例如，由IANA(互联网数字分配机构，可以经由http://www.iana.org访问)定义的该组编解码器名称)。在一些实施方案中，IP相机服务2501的给定实例支持一个编解码器(例如，如IETFRFC6184中定义的H.264编解码器)，并且支持多个编解码器的IP相机附件可以定义IP相机服务2501的多个实例。控制器可以通过向IP相机服务2501的对应实例的会话开始特性写入来选择期望的编解码器。视频编解码器参数2604可以提供用于视频编解码器的附加参数。包括的特定参数可以取决于视频编解码器名称2603并可以密钥值格式表示。例如，对于H.264编解码器而言，视频编解码器参数2604可以包括用于指定子概况和H.264编解码器等级的概况级ID，以及用于指定编解码器是支持单个NAL单元模式还是非交织模式的分包模式。可以根椐服务实例支持的特定视频编解码器来定义其他参数。视频属性特性2605可以提供服务等级的属性(例如，SDP属性)。示例包括图像属性和方向属性(例如，仅发送，仅接收，或双向(发送和接收))。在一些实施方案中，如果不指定方向，可以假定“仅发送”为默认的。RTP视频有效载荷类型特性2606能够提供7比特的整数有效载荷类型，例如，如针对RTP所指定的。RTP协议特性2607能够提供用于标识正在使用的特定基于RTP的概况的字符串。例如，“RTP/SAVP”可以指IETFRFC3550中定义的概况，而“RTP/SAVPF”可以指IETFRFC5104中定义的概况。也可以定义其他概况和字符串。RTP扩展特性2608可以提供列出由IP相机服务2501的该实例支持的RTP扩展的字符串阵列。RTP扩展的示例可以包括图片损失指示、时空折衷请求、临时最大媒体流传输比特率等。SRTP密码套件特性2609可以提供用于标识要用于安全RTP流传输的密码套件的字符串。在一些实施方案中，该字符串可以与密码套件的IANA登记名称相符。在一些实施方案中，SRTP密码套件特性2609可以允许“无”值指示未使用SRTP(例如，流传输的视频数据未加密)。参考图26B，音频编解码器名称特性2610可以提供用于表示由音频编解码器提供的媒体类型的字符串。在一些实施方案中，可以定义一组用于该字符串的有效值(例如，由IANA(互联网数字分配机构)定义的该组编解码器名称)。在一些实施方案中，IP相机服务2501的给定实例可以支持音频和视频编解码器的一种组合，并且IP相机附件可以通过定义IP相机服务2501的多个实例来支持编解码器的多种组合。控制器可以通过向IP相机服务2501的对应实例的会话开始特性写入来选择针对会话的期望的音频和视频编解码器。音频编解码器参数2611可以提供用于音频编解码器的附加参数。包括的特定参数可以取决于音频编解码器名称2610并可以密钥值格式表示。例如，对于Opus编解码器而言，音频编解码器参数2604可以包括关于是启用恒定比特率还是可变比特率的指示符。可以根椐特定音频编解码器来定义其他参数。音频属性参数2613可以提供媒体等级的属性(例如，SDP属性)。示例包括方向属性(例如，仅发送，仅接收，或双向(发送和接收))。在一些实施方案中，如果不指定方向，可以假定“仅发送”为默认的。RTP音频时钟率特性2614可以提供用于音频的RTP时钟率，例如，如针对RTP所指定的。RTP音频有效载荷类型特性2615能够提供7比特的整数有效载荷时间，例如，如针对RTP所指定的。在各种实施方案中，也可以针对流传输媒体来定义其他特性和服务。在一些实施方案中，并非在每个服务实例中都使用所有特性。例如，用于不接收或流传输音频的IP相机附件的附件模型可以省略特性2610-2615。图26D示出了根据本发明的一个实施方案用于相机服务2503的各个特性2651-2656的示例定义。如果相机服务支持对应行为，可以定义这些特性(其可以是任选的)。控制器可以写入这些特性以控制相机取向和成像行为。例如，夜视特性2651可以具有布尔值，其可用于启用或禁用夜视成像模式。摇摄特性2652可以用于控制相机的摇摄。例如，相机可以在水平平面中旋转。可以将摇摄的量指定为例如相机相对于中心位置的最大水平旋转的百分比。可以将中心位置定义为具有零摇摄值，其中摇摄特性2652的正值表示向右摇摄，并且摇摄特性2652的负值表示向左摇摄。可以使用诸如度的其他单位。类似地，可以使用倾斜特性2653来控制相机的倾斜角(例如，光轴相对于水平的角度)。可以将倾斜的量指定为例如相机相对于中心位置的最大倾斜的百分比。可以将中心位置定义为具有零倾斜值，其中倾斜特性2653的正值表示向上倾斜，并且倾斜特性2652的负值表示负倾斜。可以使用诸如度的其他单位。可以使用旋转特性2654来控制相机关于其光轴的旋转角。例如，可以以度为单位指定旋转量。在一些实施方案中，可以使用枚举的值(例如，支持向右90度、向左90度、180度和不旋转的旋转设置)。可以使用缩放特性2655来指定针对相机的缩放(或放大)因子。镜像特性2656可以是用于指示是否在显示、流传输或存储图像之前对图像进行镜像变换(例如，关于垂直轴的镜像)的布尔值。图26E示出了可以包括在图25A的记录服务2502和回放服务2503中的附加特性的定义。可以由控制器写入记录控制特性2661以开始或停止记录。该值可以是数据对象(例如，TLV格式或其他密钥值格式)，该数据对象可以包括要执行的操作(例如，开始记录，停止记录，安排记录)的标识符和适合该操作的附加参数(例如，记录的持续时间，所安排记录的开始和/或停止时间等)。记录状态特性2662可以由控制器读取以确定记录服务是否在记录。该值可以是数据对象(例如，TLV格式或其他密钥值格式)，该数据对象可以包括相机当前是否在记录的指示；还可以包括其他信息(例如，为记录安排的结束时间，关于所安排的将来记录的信息，用于记录的可用和/或已用存储空间的量等)。可以由控制器写入回放控制特性2663以控制所存储媒体内容(例如，先前记录的内容)的回放。该值可以是数据对象(例如，TLV格式或其他密钥值格式)，该数据对象可以包括要执行的操作的标识符(例如，开始回放，暂停回放，结束回放等)。还可以包括附加参数，诸如要播放的内容项的标识符。回放状态特性2664可以由控制器读取以确定当前回放状态。该值可以是数据对象(例如，TLV格式或其他密钥值格式)，该数据对象可以包括回放是否在进行中的指示；还可以包括其他信息(例如，被播放内容项的标识符，内容项的持续时间，回放位置等)。可以使用回放速度特性2665控制回放速度，其中该值指示相对于正常回放速度1.0的加速因子。在一些实施方案中，可以将用于回放速度特性2665的有效值限制到回放服务2502的特定实例支持的速度。本文描述的服务和特性是出于例示的目的。还可以定义其他服务和特性。例如，为了便于标识要回放的特定内容项，可能希望使控制器能够对可用内容项的数据库或其他列表进行导航(例如，浏览或搜索)。可以定义附加的特性以方便控制器对数据库进行导航。根据需要，这些特性可以包括在回放服务2502或不同服务(例如，内容浏览服务)中。图27A-图27D共同示出了根据本发明的一个实施方案用于IP相机附件2402的附件对象2700。在该实施例中，附件对象2700是以JSON表示的，并且结构类似于图3A-图3C的附件对象300。也可以使用其他格式和语言。图27A中示出的附件信息服务实例2702可以与上文定义的附件信息服务261相似或相同。在该实施例中，附件对象2700包括三个其他服务的实例：图27B-图27C中所示的IP相机流传输服务2704(符合图25A的服务定义2501)，图27D中所示的相机服务2706(符合图25B的服务定义2503)，以及图27D中所示的麦克风服务2708(符合图25B的服务定义2504)。在该实施例中，IP相机附件2402没有扬声器，也没有本地记录或回放能力，因此未定义这些服务的实例。(阅读本公开的本领域技术人员将能够为那些服务的实例构造适当的附件对象。)在该实施例中，在附件对象2700中指定每个特性实例的当前值；为只写特性指定空值。用户与IP相机附件2404和图24的控制器2402的交互可以类似于上述交互。例如，用户能够操作控制器2402以指示期望的行为，并且控制器2402能够向附件2404发送请求(例如，HTTP请求)以执行期望的行为。图28是根据本发明的一个实施方案的显示交互场景的过程2800的流程图。在框2802处，用户可以设置IP相机附件2404。例如，用户可以将相机放置或安装在期望的操作位置和取向中，连接电缆，将附件2404置于配对模式(如果附件2404未自动进入配对模式)等等。在框2804处，控制器2402可以发现IP相机附件2404。例如，如上所述，控制器2402可以执行应用程序，该应用程序能够实施图4的过程400的控制器可执行部分。可以响应于明确的用户指令或作为背景过程执行应用程序，并且可以提示用户确认已经发现期望的附件或从可用于配对的附件列表选择附件2404。在框2806处，控制器2402和IP相机附件2404可以建立配对验证的会话。例如，控制器2402和IP相机附件2404可以执行上述配对设置过程中的任一种，接着进行如上所述的配对验证过程。可以根据需要应用配对设置期间的验证要求；例如，可以使用上文参考门锁附件2004描述的任何选项。特定验证要求可能取决于特定IP相机附件的性质或预期用途。例如，楼宇安保相机可能需要多个形式的验证，而消费者“网络摄像头”类型的相机可能仅需要相机处于配对模式并且用户输入相机标签上印刷的设置代码。在框2808处，用户可以使用配对的控制器2402，例如通过发送向IP相机流传输服务2704的“开”特性(实例ID8)写入“真”值的请求，来为IP相机附件2404上电。在该实施例中，IP相机附件2404可以具有更低功率模式，其中其收发器能够从配对的控制器接收信号，但其他服务(例如，附件对象2700中列出的服务)被关闭。如图25A-图25B所示，服务2501-2505中的不同服务可以各自具有独立的“开”特性。这样能够允许控制器通过在要使用服务实例时使它们选择性地上电来管理功耗。在一些实施方案中，改变一个服务的“开”特性可能影响其他服务。例如，关闭IP相机流传输服务2501可能导致停止传输所有视频流，但不需要停止麦克风服务2505或扬声器服务2506的操作。IP相机流传输服务2501可以上电，而其他服务保持关闭，但如果媒体流活动，与该流相关联的任何服务实例都应当保持上电或可以停止流传输。而且，在一些实施方案中，如果与针对新会话的流之一相关联的服务实例被关闭，IP相机流传输服务2501不允许开始新会话。关闭IP相机服务2501能够终止所有媒体会话，并自动关闭其他相关服务实例(例如，麦克风服务2506，扬声器服务2506)。打开IP相机服务2501可能导致打开所有相关服务实例(如果不使用，它们能够被相继关闭)，但不需要恢复任何先前的媒体会话。还可以实施其他功率管理规则。在框2810处，用户可以例如通过与控制器2402的用户界面交互来指示控制器2402开始从IP相机附件2404流传输视频。例如，用户可以指示相机要向控制器2402流传输视频(在一些实施方案中，用户可以指定不同的目的地设备)。作为响应，在框2812处，控制器2402可以生成并向IP相机附件2404发送请求以开始媒体会话。在一些实施方案中，可以将开始媒体会话请求作为HTTPPUT请求向IP相机附件2404的/characteristicsURL发送。图29中针对图27A-图27D的使用附件对象2700的实施方案示出了实施例。请求消息2900可以具有消息主体2902。消息主体2902可以包括要写入的实例的实例标识符2904(实例ID9对应于针对IP相机服务实例2704(图27B)的会话开始特性)。值2906可以包括可以由IP相机附件2404用于与控制器2402建立流传输会话的信息，诸如会话ID、IP地址和用于控制器2402(或其他目的地设备)的端口，以及要用于SRTP流传输数据的加密密钥和盐。在框2814处，IP相机附件2404可以发送对开始媒体会话请求的响应。在一些实施方案中，响应可以作为HTTP响应发送。图30针对开始媒体会话请求如图29所示的实施方案示出了实施例。响应消息3000可以具有消息主体3002。消息主体3002可以包括值3004。值3004可以包括错误代码3002，其可以具有用于指示成功完成(例如错误代码0)或发生特定错误(例如，无效参数、资源忙、拒绝访问等)的值。假设没有错误，值3004可以提供可以由控制器2402用于连接到与IP相机附件2404的流传输会话的附加信息，诸如附件的IP地址和端口，以及附件的SRTP加密参数。在该实施例中，SRTP加密参数可以包括在开始会话请求和响应中。应当理解，这些参数不需要明文发送。在控制器2402和附件2404之间的配对验证会话内交换请求2900和响应3000的实施方案中，以加密的形式发送参数(利用配对验证会话的会话密钥)，从而针对未授权者得到保护。也可以实施请求和响应的另选实施方案。在以上描述的示例性服务定义中，IP相机流传输服务2501的给定实例具有相关联的编解码器、属性、有效载荷等；这些可以是服务实例的固定特性，并且可以将不同组的特性定义为服务的不同实例。在其他实施方案中，可使用不同的具体实施。例如，根据期望的安全性，流传输会话开始请求可以利用SDP来配置可以使用RTP或SRTP递送的媒体流。如本文所用，“媒体流”可以由一个或多个“媒体流动”构成，其中每个媒体流动都是音频或视频数据在一个方向上的传输。例如，“单向视频”流可以包含从IP相机附件2404到控制器2402的一个视频流动。“单向音频”流可以包含从IP相机附件2404到控制器2402的一个音频流动。“单向音频和视频”流可以包含从IP相机附件2404到控制器2402的一个音频流动和一个视频流动；两个流动可以是同步的。“单向视频和双向音频”流可以包含从控制器2402到IP相机附件2404的一个音频流动以及从IP相机附件2404到控制器2402的两个媒体流动(一个视频、一个音频)；后两个流动可以是同步的。SDP可以提供用于描述媒体会话，包括媒体能力和传输参数的术语和语法。例如，SDP支持描述以下信息：媒体类型(例如，音频、视频)；媒体编解码器(例如，LPCM音频、H.264视频)；网络传输(例如，接收IP地址和端口)；流属性(例如，仅接收、仅发送、发送和接收)；以及媒体安全(例如，是否使用SRTP)。SDP还可以提供用于在控制器和相机附件之间协商媒体会话的方便模型，其中设备会聚于相互可接受的媒体设置，诸如媒体类型、媒体编解码器等。因此，在IP相机流传输服务的一些另选具体实施中，控制器(例如，控制器2402)可以包括开始媒体会话请求内(例如，请求2900中包括的数据对象内)的SDP提议。接受该请求的附件(例如，IP相机附件2404)可以在其对开始媒体会话的请求内(例如，在响应3000中包括的数据对象内)包括SDP响应，作为对媒体会话请求的响应的一部分。再次参考图28，一旦已经建立了流传输会话，在框2816处，IP相机附件2404便可以开始向控制器2404(或在开始媒体会话请求中指定的其他目的地设备)流传输媒体。流传输的特定媒体和流传输格式可以取决于附件的IP流传输服务的特性；例如，流传输可以包括视频和/或音频。此外，在一些情况下，流传输服务可以支持相反方向的流动，并且该流动可以在同一时间开始。控制器2402(或其他目的地设备)能够向用户呈现所接收的媒体和/或存储所接收的媒体供稍后呈现。媒体内容的流传输可以无限期地继续。在某个点处，用户能够指示控制器2402在框2818处例如通过操作用户界面的“停止”控件来停止媒体流传输。作为响应，在框2820处，控制器2402可以生成并向IP相机附件2404发送结束媒体会话请求。图31示出了针对交换请求2900和响应3000的实施方案的结束媒体会话请求消息3100的实施例。像开始媒体会话请求2900那样，结束媒体会话请求3000可以是HTTPPUT请求。请求消息3100可以具有消息主体3102。消息主体3102可以包括要写入的实例的实例标识符3104(实例ID10对应于针对IP相机服务实例2704(图27B)的会话结束特性)。值3106可以包括可以由IP相机附件2404用于终止与控制器2402的流传输会话的信息；在该实施例中，会话标识符足够。再次参见图28，在框2822处，附件2404可向请求发送响应。图32示出了附件2404能够响应于图31的请求3100而生成的结束媒体会话响应3200的实施例。响应消息3200可以具有消息主体3202。消息主体3202可以包括值3204。值3204可以包括用于指示是否发生了错误的错误代码。可以类似于用于对媒体会话开始请求作出响应的错误代码来定义该错误代码。在框2824处，IP相机附件2404可以停止向控制器2402流传输媒体。(如果定义的流包括相反方向的流动，该流动可以在相同时间结束。)在框2824之后，控制器2402和附件2404可以保持在配对验证会话中，控制器2402可以再次发起流传输和/或在配对验证会话内调用控制器2402的其他功能。应当理解，过程2800是例示性的，并且可能进行变型和修改。可并行执行按顺序描述的步骤，可改变步骤顺序，并且可修改、合并、添加或省略步骤。在不同的情景中，用户可以使用过程2800的适当部分来与IP相机附件2404交互。在一些实施方案中，可能需要在执行诸如开始或终止媒体会话的特定动作之前进行配对验证，或者配对验证可能是与IP相机流传输服务进行任何交互的前提条件。在配对验证会话内，可以对全部请求和响应加密。此外，尽管出于例示的目的使用了诸如SDP、RTP和SRTP的特定媒体相关协议，但可以替换其他协议。可以将过程2800理解为可以由操作控制器的用户执行以控制配对附件的广泛范围交互控制操作的示例，包括但不限于媒体捕获操作。可以利用类似于本文所述那些的过程来控制附件能够执行的任何类型的功能或操作。实施例：流传输界面一些附件可以支持它们自己和控制器之间的IP流传输。像在以上IP相机实施例中那样，实时媒体流传输是一种选项，但也可以支持其他类型的数据流传输。例如，可以支持TCP或UDP流传输。在一些实施方案中，可能要求附件以加密形式来流传输所有数据。例如，对于TCP流而言，可以使用TLS-PSK(ChaCha20/Poly1305)，而对于UDP流而言，可以使用DTLS-PSK(ChaCha20/Poly1305)。在一些实施方案中，IP流传输的具体实施可以类似于以上描述的IP相机服务实施例。另选的具体实施也是可能的。现在将描述实施例。图33示出了根据本发明的一个实施方案针对IP流传输服务3301的示例性服务定义。在图34中将该特性定义为流传输能力特性3401、流传输控制输入特性3402和流传输控制结果3403。这些特性中的每个特性可以是数据对象，其密钥和值可能如所指示那样。任选的“protocol-info”密钥(其值为对象)包括在每个特性3401-3403中，并且可以将此用于提供特定于附加的协议的元数据。在该实施例中，控制器可以向流传输控制输入特性3402写入以打开或关闭流，并可以通过读取流传输控制结果特性3403来获得流传输的状态。例如，如上所述，配对的控制器能够订阅针对流传输控制结果特性3403的事件通知，并且附件能够在流传输控制结果特性3403的值改变的任何时候向控制器发送主动事件响应。此外，配对的控制器还可以(例如，使用如上所述的HTTPGET请求)读取流传输控制结果特性3403。在一些实施方案中，附件可以具有选项来针对每个请求确定是否利用在线结果或查询结果作出响应。上文参考图5G-图5K描述了在线和查询结果的实施例，并可以在这种情景中应用。在该实施例中，“开”未被示为IP流传输服务3301的特性；如果需要，可以将其包括在定义中。支持IP流传输的附件可以在其附件模型中包括IP流传输服务。阅读本公开的本领域技术人员将能够以JSON或其他描述语言或表示法撰写适当的表示。图35是根据本发明的一个实施方案可以通过控制器执行的用于IP流传输的过程3500的流程图。在框3502处，控制器能够与具有如图33和图34中定义的IP流传输服务的附件配对。例如，可以使用上文描述的配对设置和配对验证过程，并且控制器可以读取附件定义记录以确定附件具有IP流传输服务。在框3504处，控制器可以例如通过发送指向流传输能力特性3401的HTTPGET的请求来从附件读取流传输能力特性3401。可以根据以上所述的实施例构造这一请求。在框3506处，控制器可以生成流标识符；可以使用用于生成标识符(例如，UUID)的常规技术。在框3508处，控制器3508可以例如通过向流传输控制输入特性3402发送HTTPPUT请求而向附件发送“打开流”请求，其中请求类型为1，并且流id设置为在框3506处生成的流标识符。例如，在protocol-info对象中可以包括其他信息，诸如针对流传输会话的要使用的IP地址和端口。可以根据以上所述的实施例来构造该请求。在框3510处，控制器可以从附件接收响应。在一些实施方案中，该响应可以是建立事务id的在线结果响应(例如，类似于图5I的响应573)或查询结果响应中的任一种，接着由控制器读取流传输控制结果特性3403并参考所建立的事务id(例如，类似于图5J的响应574和图5K的后续请求578)。在任一种情况下，该响应可以包括端口标识符和控制器可用于连接到流传输会话的任何其他信息。在框3512处，控制器可以使用响应中提供的信息连接到流传输会话。在框3514处，控制器可以设置用于数据流的加密。例如，可以从配对设置或配对验证期间(在框3502)生成的共享秘密和流ID(在框3506生成的)导出用于TLS或DTLS加密的密钥(传输层安全或数据包传输层安全，例如，如IETFRFC4279或IETFInternetDraftdraft-keoh-lwig-dtls-iot-01所记录的，可在https://tools.ietf.org/html/draft-keoho-lwig-dtls-iot-01获得)。附件可以从同一信息导出密钥。在框3516处，设备可以对加密数据进行流传输。数据可以根据需要在任一个或两个方向(从控制器到附件和/或从附件到控制器)上流动。在控制器决定中止流时，在框3518处，控制器可以例如通过向流传输输入点特性3402发送HTTPPUT请求而发送“关闭流”请求，其中请求类型为2，并且流id设置为在框3506处生成的流标识符。也可以根据以上所述的实施例构造这一请求。在框3520处，控制器可以接收用于确认附件已关闭端口的响应。可以与框3510处的响应以相同方式提供这一操作。应当理解，过程3500是例示性的，并且可能进行变型和修改。可并行执行按顺序描述的步骤，可改变步骤顺序，并且可修改、合并、添加或省略步骤。流传输服务可以提供一般IP流传输界面，用于在附件和控制器之间在任一方向上安全地流传输任何类型的数据。在所示的实施例中，TCP和UDP不是实时协议。其他实施方案可以提供实时流传输，例如，使用上文所述的IP相机流传输服务或类似服务。在一些实施方案中，控制器可以订阅通知，以允许附件在状态改变的情况下(例如，如果在流传输期间发生错误)提示控制器。例如，参考图34，控制器可以订阅针对流传输控制结果特性3403的事件通知(或可以支持的其他类型的通知)。如果流传输状态在附件端处改变，附件可以更新该状态代码并向控制器生成通知(例如，如上所述的主动事件消息)。示例性设备本文描述的实施方案可以实现于电子设备中，该电子设备可以是一般常规设计，并适于符合统一附件协议，以支持命令和控制操作，控制器(第一电子设备)通过命令和控制操作能够控制附件(第二电子设备)的操作。图36是根据本发明的一个实施方案的控制器3600的简化框图。控制器3600可以实施本文所述的控制器功能、行为和能力中的任一种或全部，以及未明确描述的其他功能、行为和能力。控制器3600可以包括处理子系统3610、存储设备3612、用户界面3614、通信接口3616、安全元件3618和密码逻辑模块3620。控制器3600还可以包括其他部件(未明确示出)，诸如电池、电力控制器和用于提供各种增强能力的其他部件。在各种实施方案中，控制器3600可以实现于台式计算机、膝上型计算机、平板电脑、智能电话、可穿戴计算设备或具有任何期望形状因数的其他系统中。此外，如上所述，控制器3600可以部分地实现于基站中，并且部分地实现于与基站通信且提供用户界面的移动单元中。存储设备3612可以例如使用磁盘、闪存存储器或任何其他非暂态存储介质或介质组合来实现，并且可以包括易失性和/或非易失性介质。在一些实施方案中，存储设备3612可以存储要由处理子系统3610执行的一个或多个应用和/或操作系统程序，包括实施由控制器执行的本文所述任何或全部操作的程序。例如，存储设备3612可以存储统一控制器应用，其能够读取附件定义记录，并生成图形用户界面，以用于基于其中的信息来控制附件。在一些实施方案中，可以在操作系统程序而非应用中实施本文所述控制器功能的部分(或全部)。在一些实施方案中，存储设备3612还可以存储为特定附件或特定类别附件设计的应用(例如，管理IP相机附件的IP相机应用或与门锁附件交互的安全应用)。用户界面3614可包括输入设备诸如触控板、触摸屏、滚轮、点击轮、拨号盘、按钮、开关、小键盘、麦克风等；以及输出设备诸如视频屏幕、指示灯、扬声器、耳机接口等，连同支持性电子器件(例如，数模转换器或模数转换器、信号处理器等)。用户可操作用户界面3614的输入设备以调用控制器3600的功能，并且可经由用户界面3614的输出设备来查看和/或收听来自控制器3600的输出。处理子系统3610可被实现为一个或多个集成电路，例如一个或多个单核或多核微处理器或微控制器，这些微处理器或微控制器的实施例在本领域中是已知的。在操作中，处理系统3610可以控制控制器3600的操作。在各种实施方案中，处理子系统3610可响应于程序代码来执行各种程序，并且可维护多个同时执行的程序或过程。在任何给定时间，待执行的一些或全部程序代码可以驻留在处理子系统3610和/或诸如存储设备3612的存储介质中。通过合适的编程，处理子系统3610可以为控制器3600提供各种功能。例如，在一些实施方案中，处理子系统3610可以实施由控制器实施的上述各种过程(或其部分)。处理子系统3610还可以执行其他程序来控制控制器3600的其他功能，包括可存储在存储设备3612中的程序。在一些实施方案中，这些程序可通过例如生成待发送至附件的消息和/或通过从附件接收消息来与附件进行交互。此类消息可以符合上述统一附件协议。通信接口3616可为控制器3600提供语音和/或数据通信能力。在一些实施方案中，通信接口3616可以包括：用于访问无线语音和/或数据网络(例如，使用蜂窝电话技术、数据网络技术诸如3G、4G/LTE、Wi-Fi(IEEE802.11系列标准)或其他移动通信技术，或它们的任意组合)的射频(RF)收发器部件、用于短范围无线通信(例如，使用蓝牙和/或蓝牙LE标准、NFC等)的部件和/或其他部件。在一些实施方案中，除了或代替无线接口，通信接口3616可以提供有线网络连接性(例如以太网)。通信接口3616可使用硬件(例如，驱动电路、天线、调制器/解调器、编码器/解码器，以及其他模拟和/或数字信号处理电路)与软件部件的组合来实现。在一些实施方案中，通信接口3616可以使用同一传输或不同传输同时支持多个通信信道。安全存储模块3618可以是可以安全存储用于控制器3600的密码信息的集成电路等。可以在安全存储模块3618内存储的信息示例包括控制器的长期公共和秘密密钥3622(如上所述的LTPKC，LTSKC)，以及配对附件3627的列表(例如，为已经完成上述配对设置或配对添加过程的附件，将附件ID映射到附件长期公共密钥LTPKA的查找表)。在一些实施方案中，可以在与安全存储模块3618通信的密码逻辑模块3620中实施密码操作。在物理上，密码逻辑模块3620可以实现于与安全存储模块3618相同的集成电路中或不同的集成电路(例如，处理子系统3610中的处理器)中。密码逻辑模块3620可以包括实现或支持控制器3600的密码操作的各种逻辑电路(根据需要固定的或可编程的)，该密码操作包括上述任何或全部密码操作。安全存储模块3618和/或密码逻辑模块3620可以对于控制器3600的其余部分呈现为“黑盒子”。因此，例如，通信接口3616可以接收加密形式的消息，其不能对该加密形式解密，并且仅仅能够将消息递送到处理子系统3610。处理子系统3610也可能无法对消息解密，但其能够将消息识别为加密的并将其递送到密码逻辑模块3620。密码逻辑模块3620可以对消息解密(例如，利用从安全存储模块3618提取的信息)并确定要向处理子系统3610返回什么信息。结果，特定信息可能仅在安全存储模块3618和密码逻辑模块3620内可用。如果安全存储模块3618和密码逻辑模块3620实现于仅执行来自内部安全储存库的代码的单个集成电路上，这可能会使得提取信息极其困难，这样能够实现高度的安全性。其他具体实施也是可能的。图37是根据本发明的一个实施方案的附件3700的简化框图。附件3700可以实施本文所述的附件功能、行为和能力中的任一种或全部，以及未明确描述的其他功能、行为和能力。附件3700可以包括存储设备3728、处理子系统3730、用户界面3732、特定于附件的硬件3734、通信接口3736、安全元件3738和密码逻辑模块3740。附件3700还可以包括其他部件(未明确示出)，诸如电池、电力控制器和用于提供各种增强能力的其他部件。附件3700表示可通过控制器诸如控制器3600进行操作的一大类附件，并且此类附件在能力、复杂性和形状因数方面可能有很大不同。各种附件可包括图37中未明确示出的部件，包括但不限于具有固定或可移除存储介质的存储设备(磁盘、闪存存储器等)；视频屏幕、扬声器或用于连接到外部音频/视频设备的端口；相机部件，诸如镜头、图像传感器和用于该图像传感器的控件(例如，孔径，缩放，曝光时间、帧速率等)；用于记录音频的麦克风(单独地或与视频录制结合)等。存储设备3728可以例如使用磁盘、闪存存储器或任何其他非暂态存储介质或介质组合来实现，并且可以包括易失性和/或非易失性介质。在一些实施方案中，存储设备3728可以存储将由处理子系统3730执行的一个或多个程序，包括实施由附件执行的上述各种操作的程序，以及与特定附件行为相关的操作。存储设备3728还可以存储例如可以如上所述提供给控制器设备的附件对象或附件定义记录(例如，如上所述)。存储设备3728也可以存储附件状态信息以及可在附件3700操作期间使用的任何其他数据。处理子系统3730可包括例如执行程序代码以便执行与附件3700相关联的各种功能的一个或多个单核或多核微处理器和/或微控制器。处理子系统3730可以例如通过执行存储设备3728中存储的程序代码来由附件实施的本文所述的任何或全部操作。处理子系统3730也可以执行其他程序以控制附件3730的其他功能。在某些情况下，由处理子系统3730执行的程序可以例如通过生成要发送到控制器的消息和/或从控制器接收消息来与控制器(例如，控制器3600)交互。此类消息可以符合上述统一附件协议。用户界面3732可包括用户可操作的输入设备诸如触摸板、触摸屏、滚轮、点击轮、拨号盘、按钮、开关、小键盘、麦克风等；以及输出设备诸如视频屏幕、指示灯、扬声器、耳机插孔等，连同支持性电子器件(例如，数模转换器或模数转换器、信号处理器等)。根据特定附件3700的实现，用户可操作用户界面3732的输入设备以调用附件3700的功能，并且可经由用户界面3734的输出设备来查看和/或收听来自附件3700的输出。一些附件可以提供最少的用户界面或不提供用户界面。特定于附件的硬件3734可包括可存在于附件3700中以启用或支持其功能的任何其他部件。例如，在各种实施方案中，特定于附件的硬件3734可包括使用固定或可移除存储介质的一个或多个存储设备；GPS接收器；电源和/或电源管理电路；相机；麦克风；一个或多个致动器；环境传感器(例如，温度传感器、压力传感器、加速度计、化学传感器等)等等。应当理解，可通过提供合适的特定于附件的硬件3734来支持任何类型的附件功能。通信接口3736可为附件3700提供语音和/或数据通信能力。在一些实施方案中，通信接口3736可以包括：用于访问无线语音和/或数据网络(例如，使用蜂窝电话技术、数据网络技术诸如3G、4G/LTE、Wi-Fi(IEEE802.11系列标准)或其他移动通信技术，或它们的任何组合)的射频(RF)收发器部件、用于短范围无线通信(例如，使用蓝牙和/或蓝牙LE标准、NFC等)的部件，和/或其他部件。在一些实施方案中，除了或代替无线接口，通信接口3736可以提供有线网络连接性(例如以太网)。通信接口3736可使用硬件部件(例如，驱动电路、天线、调制器/解调器、编码器/解码器，以及其他模拟和/或数字信号处理电路)与软件部件的组合来实现。在一些实施方案中，通信接口3736可以使用同一传输或不同传输同时支持多个通信信道。安全存储模块3738可以是可以安全存储用于附件3700的密码信息的集成电路等。可以在安全存储模块3738内存储的信息示例包括附件的长期公共和秘密密钥3742(如上所述的LTPKA、LTSKA)，以及配对控制器3744的列表(例如，为已经完成上述配对设置或配对添加过程的控制器，将控制器ID映射到控制器长期公共密钥LTPKC的查找表)。在一些实施方案中，可以在与安全存储模块3738通信的密码逻辑模块3740中实施密码操作。在物理上，根据需要，密码逻辑模块3740可以实现于与安全存储模块3738相同的集成电路中或不同的集成电路(例如，处理子系统3730中的处理器)中。密码逻辑模块3740可以包括实现或支持附件3700的密码操作的各种逻辑电路(根据需要固定的或可编程的)，该密码操作包括上述任何或全部密码操作。安全存储模块3738和/或密码逻辑模块3740可以对于附件3700的其余部分呈现为“黑盒子”。因此，例如，通信接口3736可以接收加密形式的消息，其不能对该加密形式解密，并且仅仅能够将消息传输到处理子系统3730。处理子系统3730也可能无法对消息解密，但其能够将消息识别为加密的并将其递送到密码逻辑模块3740。密码逻辑模块3740可以对消息解密(例如，利用从安全存储模块3738提取的信息)并确定要向处理子系统3730返回什么信息。结果，特定信息可能仅在安全存储模块3738和密码逻辑模块3740内可用。如果安全存储模块3738和密码逻辑模块3740实现于仅执行来自内部安全储存库的代码的单个集成电路上，这可能会使得提取信息极其困难，这样能够实现高度的安全性。其他具体实施也是可能的。附件3700可为与控制器诸如控制器3600进行交互的任何电子装置。在一些实施方案中，控制器3600可通过上述附件3700的操作来提供远程控制。例如，控制器3600可以为附件3700提供远程用户界面，其可以既包括输入控件又包括输出控件(例如，显示从附件3700获得的当前状态信息的显示屏，以及允许改变状态信息的输入控件，诸如触摸屏覆层)。在各种实施方案中，控制器3600可以控制附件3700的任何功能并且还可以从附件3700接收数据。图38示出了根据本发明的一个实施方案的针对控制器3800的控制器架构的实施例。控制器架构被示为一组交互的子系统，其中每个子系统包括一个或多个模块。应当理解，可以利用一个或多个可编程处理器上和/或在一个或多个固定功能处理器上执行的程序代码来实现每个模块，并且处理器可以包括控制其他硬件设备(例如，致动器、显示器等)的输出信令和/或从其他硬件设备接收信号的输入信令(例如，键盘、触摸屏、来自致动器的反馈或状态信号、电动机或传感器等)。一些子系统可以包括持久数据存储装置，其可以使用任何类型的非易失性存储设备来实现(例如，半导体闪存存储器、EEPROM、磁盘或光盘等)。尽管未示出，但一些或全部子系统可以包括诸如显示器、键盘、触摸屏、麦克风、扬声器、传感器等附加的硬件元件。安全子系统3802可以包括安全存储元件3804、配对设置模块3806、配对验证模块3808、配对添加模块3810、配对移除模块3812和密码逻辑模块3814。安全存储元件3804可以与安全存储元件3618或上文描述的其他安全存储元件相似或相同。在一些实施方案中，安全存储元件3804用于安全地存储用于控制器3800的长期公共/秘密密钥对(例如，上述LTPKC，LTSKC)以及用于控制器3800已经与其建立配对的每个附件的配对记录。如上所述，每个配对记录可以包括配对附件的标识符、配对附件的长期公共密钥以及任选的其他信息，诸如用于控制器3800与配对附件交互的许可设置(例如，控制器3800是否具有管理员许可)。在控制器3800结合不同附件使用不同长期公共密钥的实施方案中，每个配对记录还可以包括要与配对附件一起使用的长期公共密钥的指示符。如果需要，可以包括其他信息。配对设置模块3806可以实施配对设置过程的控制器部分。配对设置过程可以是控制器3800和附件用以安全交换长期公共密钥的任何过程，每个设备接下来可以使用长期公共密钥来验证另一设备的身份。在一些实施方案中，配对设置过程可以包括信息项在控制器3800和附件之间的带外交换(例如，设置代码、附件的安全证书的确认)，以验证附件的身份。可以使用上述任何配对设置过程(例如，过程1300,1400,1500和/或1600)或其他过程。在一些实施方案中，配对设置模块3806可以与附件交互子系统3850进行交互(下文描述的)以实现在配对设置期间与附件通信。在一些实施方案中，配对设置模块3806可以调用密码逻辑模块3814的功能以结合配对设置过程来执行密码操作。配对验证模块3808可以实施配对验证过程的控制器部分。配对验证过程可以是控制器3800和附件用以使用先前存储的长期公共密钥来验证另一设备身份的任何过程。可以使用上述任意配对验证过程(例如，过程1700)或其他过程。在一些实施方案中，配对验证模块3808可以与附件交互子系统3850进行交互(下文描述的)以实现在配对验证期间与附件通信。在一些实施方案中，配对验证模块3808可以调用密码逻辑模块3814的功能以结合配对验证过程来执行密码操作。配对添加模块3810可以实施配对添加过程的控制器部分。配对添加过程可以是在与附件建立配对之后，控制器3800用以向附件提供用于附件要与其建立配对的“新”控制器的长期公共密钥的任何过程；该新控制器可以是与控制器3800不同的设备。可以使用上述任意配对添加过程(例如，过程1800)或其他过程。在一些实施方案中，配对添加模块3810可以与附件交互子系统3850进行交互(下文描述的)以实现在配对添加期间与附件通信。在一些实施方案中，配对添加模块3810也可以与另一个控制器或密钥信息的其他外部来源通信以获得用于要添加的新控制器的长期公共密钥(或证书)。在一些实施方案中，配对添加模块3810可以调用密码逻辑模块3814的功能以结合配对验证过程来执行密码操作。配对移除模块3812可以实施配对移除过程的控制器部分。配对移除过程可以是在与附件建立配对之后，控制器3800用以向附件提供附件要移除与其配对的控制器的标识符的任何过程；移除的控制器可以是与控制器3800不同的设备。可以使用上述任意配对移除过程(例如，过程1900)或其他过程。在一些实施方案中，配对移除模块3812可以与附件交互子系统3850进行交互(下文描述的)以实现在配对移除期间与附件通信。在一些实施方案中，配对移除模块3812还可以与另一个控制器或信息的其他外部来源通信，以获得要移除的控制器的标识信息。在一些实施方案中，配对移除模块3808可以调用密码逻辑模块3812的功能以结合配对移除过程来执行密码操作。密码逻辑模块3814可以实施可以由控制器3800使用的密码算法。示例包括：密钥生成算法；在SRP中使用的算法和函数；散列算法；诸如ChaCha20-Poly1305、Curve25519、Ed25519的基于密钥的加密/解密算法，和/或其他算法。在一些实施方案中，密码逻辑模块3814可以提供API(应用程序接口)，该API可以由控制器3800的其他模块用于调用密码算法和相关的服务。可以支持任意数量的密码算法和相关服务及其组合。用户交互子系统3830可以管理与控制器3800的用户的交互。例如，用户界面生成模块3832可以生成要在例如显示设备上向用户呈现的用户界面。该用户界面可以包括可以由用户操作以与附件进行交互的控制元件。例如，如上所述，控制器3800可以基于附件对象中提供的信息呈现图形用户界面。用户输入接收器模块3834可以从用户界面接收输入并处理该输入以确定要响应于输入而采取的动作(例如，生成要向附件发送的消息)。在一些实施方案中，用户输入接收器模块3834可以响应于用户输入来调用控制器3800的其他模块的功能。附件交互子系统3850可以支持在控制器3800和附件之间的交互。可以使用易失性或非易失性存储介质(例如，半导体闪存存储器、EEPROM、DRAM、SRAM、磁盘或光盘等)实现附件对象存储元件3852。在一些实施方案中，附件对象存储元件3852可以用于存储控制器3800具有其信息的每个附件的表示。例如，如上所述，在与附件建立配对之后，诸如控制器3800的控制器可以从附件获得附件定义记录，其可以包括一个或多个附件对象。控制器3800可以在附件对象存储元件3852中存储这样获得的附件对象。可以通过若干方式使用存储的附件对象，包括生成用户界面(例如，由用户界面生成模块3832)，解释用户输入(例如，由用户输入接收器模块3834)，向附件生成请求，和/或从附件接收响应或通知。附件发现模块3854可以执行与发现附件相关的操作，例如，侦听广播，确定是否与发现的附件配对等等。例如，附件发现模块3854可以实施上文参考图4所述的控制器操作。请求生成模块3856可以生成并向附件发送请求。例如，响应于来自用户输入接收器模块3834的指令(例如，打开门锁)，请求生成模块3856可以向附件生成适当的请求消息(例如，如上所述写入锁定状态特性)。请求消息的实施例在上文中有所描述。在一些实施方案中，生成消息可以包括对消息加密，并且请求生成模块3856可以调用密码逻辑模块3814结合生成请求所支持的功能。在一些实施方案中，请求生成模块3856可以与安全子系统3802交互，以在配对设置、配对验证、配对添加或配对移除操作期间生成并向附件发送请求(例如，上文参考图13-图19所述的任何请求)。响应处理模块3858可以接收并处理对可能从附件接收的请求消息的任何响应。例如，在请求生成模块3856向附件发送请求消息(例如，向上述锁定状态特性写入)之后，响应处理模块3858可以从附件接收响应消息并可以解释消息。在一些实施方案中，可以加密形式接收响应消息，并且响应处理模块3858可以调用密码逻辑模块3814结合解释该响应所支持的功能。响应处理模块3858还可以基于响应向用户界面子系统3830提供信息(例如，状态代码，是否发生错误等)，并且用户界面子系统3830可以基于这一信息向用户生成反馈。在一些实施方案中，响应处理模块3858也可以基于响应消息中包括的信息来更新附件对象存储元件3852。在一些实施方案中，响应处理模块3858可以与安全子系统3802交互，以在配对设置、配对验证、配对添加或配对移除操作期间接收并处理从附件接收的响应(例如，上文参考图13-图19所述的任何响应)。通知处理模块3860可以接收并处理可从附件接收的通知消息。如上所述，可以支持各种通知机制，并且通知处理模块3860可以支持这些通知机制中的任一种或全部(例如，上述过程700,800,900,1000中的任一种或全部)。例如，对于被动通知而言，通知处理模块3860可以将附件报告的状态计数器值与存储的状态计数器值(例如，在附件对象存储元件3852中)进行比较并可以检测偏差。在一些实施方案中，在检测到偏差时，通知处理模块3860可以指示请求生成模块3856以生成并向附件发送请求，以获得附加状态信息(例如，更新的附件定义记录或其部分)。对于通告的通知而言，通知处理模块3860可以处理经由附件发现模块3854接收的通告，以检测状态改变的已知附件(例如，基于附件存储元件3852中存储的附件对象的状态计数器)。对于事件通知而言，可以由响应处理模块3858接收主动响应消息，其可以将消息识别为主动响应(例如，上述EVENT消息)，并可以向通知模块3860提供该消息以进一步处理。不论特定通知机制是什么，通知模块3860都可以确定改变的状态信息的性质，并向用户交互子系统3830提供适当的信息。在一些实施方案中，通知模块3860也可以更新附件对象存储元件3852中存储的附件对象。通信接口模块3870可以提供服务以支持与包括附件的其他设备通信。在一些实施方案中，通信接口模块3870可以实施蓝牙LE协议栈3872和/或HTTP/IP协议栈3874。蓝牙LE协议栈3872可以根据蓝牙LE传输协议提供传出消息的格式化以及所接收消息的解释。HTTP/IP协议栈3874可以根据HTTP和IP传输协议提供传出消息的格式化以及所接收消息的解释。尽管使用蓝牙LE和HTTP/IP作为示例，但应当理解，在通信接口模块3870内可以支持传输协议的任意组合，并且控制器3800的给定实例可以支持一种或多种传输协议。如上所述，控制器3800可以充当设备交互的客户端/服务器模型中的客户端设备，并且蓝牙LE协议栈3872和/或HTTP/IP协议栈3874可以被配置为支持客户端行为。在一些实施方案中，可以修改通信接口模块3870内的协议栈以识别某些不标准消息。例如，如上所述，HTTP/IP协议栈3874可以被配置为识别来自附件的主动“事件”消息(例如，上述图11B的事件消息1120)。在一些实施方案中，通信接口模块3870可以提供可以由其他模块用来向外部设备发送和/或接收消息的API。该API可以被设计成传输无意识的，并且可以相对于控制器3800内的其他模块透明地在通信接口模块3870内作出针对特定消息的传输选择。可以基于端口配置向蓝牙LE栈3872或HTTP/IP栈3874发送在控制器3800的通信端口(未示出)处接收的消息，并且蓝牙LE栈3872和HTTP/IP栈3874中的每一者可以向适当配置的通信端口发送传出消息。图39示出了根据本发明的一个实施方案针对附件3900的附件架构的实施例。附件架构被示为一组交互的子系统，其中每个子系统包括一个或多个模块。应当理解，可以利用一个或多个可编程处理器上和/或在一个或多个固定功能处理器中执行的程序代码实现每个模块，并且处理器可以包括控制其他硬件设备(例如，致动器、显示器等)的输出信令和/或从其他硬件设备接收信号的输入信令(例如，键盘、触摸屏、来自致动器的反馈或状态信号、电动机或传感器等)。一些子系统可以包括持久数据存储装置，其可以使用任何类型的非易失性存储设备来实现(例如，半导体闪存存储器、EEPROM、磁盘或光盘等)。尽管未示出，但一些或全部子系统可以包括诸如显示器、键盘、触摸屏、麦克风、扬声器、电动机、致动器、传感器等附加的硬件元件。安全子系统3902可以包括安全存储元件3904、配对设置模块3906、配对验证模块3908、配对添加模块3910、配对移除模块3912和密码逻辑模块3914。安全存储元件3904可以与安全存储元件3738或上文描述的其他安全存储元件相似或相同。在一些实施方案中，安全存储元件3904用于安全地存储用于附件3900的长期公共/秘密密钥对(例如，上述LTPKA，LTSKA)以及用于附件3900已经与其建立配对的每个控制器的配对记录。如上所述，每个配对记录可以包括配对控制器的标识符、配对控制器的长期公共密钥以及任选的其他信息，诸如用于配对控制器与附件3900交互的许可设置(例如，特定配对控制器是否具有管理员许可)和/或配对控制器的订阅设置(例如，控制器是否订阅除被动模式之外的特定通知模式的指示符)。在附件3900结合不同控制器使用不同长期公共密钥的实施方案中，每个配对记录还可以包括要与配对控制器一起使用的长期公共密钥的指示符。如果需要，可以包括其他信息。配对设置模块3906可以实施配对设置过程的附件部分。配对设置过程可以是附件3900和控制器用以安全交换长期公共密钥的任何过程，每个设备随后可以使用长期公共密钥来验证另一设备的身份。在一些实施方案中，配对设置过程可以包括信息项在附件3900和控制器之间的带外交换(例如，设置代码、附件的安全证书的确认)，以验证附件3900的身份。可以使用上述任何配对设置过程(例如，过程1300,1400,1500和/或1600)或其他过程。在一些实施方案中，配对设置模块3806可以与控制器交互子系统3950进行交互(下文描述的)以实现在配对设置期间与控制器通信。在一些实施方案中，配对设置模块3906可以调用密码逻辑模块3914的功能以结合配对设置过程来执行密码操作。配对验证模块3908可以实施配对验证过程的附件部分。配对验证过程可以是附件3900和控制器用以使用先前存储的长期公共密钥来验证另一设备身份的任何过程。可以使用上述任意配对验证过程(例如，过程1700)或其他过程。在一些实施方案中，配对验证模块3908可以与控制器交互子系统3950进行交互(下文描述的)以实现在配对验证期间与附件通信。在一些实施方案中，配对验证模块3908可以调用密码逻辑模块3914的功能以结合配对验证过程执行密码操作。配对添加模块3910可以实施配对添加过程的附件部分。配对添加过程可以是已经与附件3900建立配对的控制器用以向附件3900提供用于附件3900要与其建立配对的“新”控制器的长期公共密钥的任何过程。可以使用上述任意配对添加过程(例如，过程1800)或其他过程。在一些实施方案中，配对添加模块3910可以与控制器交互子系统3950进行交互(下文描述的)以实现在配对添加期间与先前配对的控制器通信。在一些实施方案中，配对添加模块3910也可以与密钥信息的外部来源通信以获得用于要添加的新控制器的长期公共密钥(或证书)。在一些实施方案中，配对添加模块3910可以调用密码逻辑模块3914的功能以结合配对验证过程执行密码操作。配对移除模块3912可以实施配对移除过程的附件部分。配对移除过程可以是与附件3900建立配对的控制器用以向附件3900提供附件3900要移除与其配对的控制器的标识符的任何过程；移除的控制器可以是与调用配对移除过程的控制器不同的设备。可以使用上述任意配对移除过程(例如，过程1900)或其他过程。在一些实施方案中，配对移除模块3912可以与附件交互子系统3950进行交互(下文描述的)以实现在配对移除期间与附件通信。在一些实施方案中，配对移除模块3912还可以与另一个控制器或信息的其他外部来源通信，以获得要移除的用于控制器的标识信息。在一些实施方案中，配对移除模块3908可以调用密码逻辑模块3912的功能以结合配对移除过程执行密码操作。密码逻辑模块3914可以实施可以由附件3900使用的密码算法。示例包括：密钥生成算法；在SRP中使用的算法和函数；散列算法；诸如ChaCha20-Poly1305、Curve25519、Ed25519的基于密钥的加密/解密算法，和/或其他算法。在一些实施方案中，密码逻辑模块3914可以提供API(应用程序接口)，该API可以由附件3900的其他模块用于调用密码算法和相关的服务。可以支持任意数量的密码算法和相关服务及其组合。例如，响应于经由控制器交互子系统3950从控制器接收的请求，附件动作子系统3930可以管理附件3900的硬件和/或软件部件的各种操作。例如，附件3900可以并入能够采取特定动作(例如，打开或关闭门，操作相机等)的各种操作部件3932(或与其通信)。操作部件3932可以包括硬件和/或软件部件，并且给定操作部件3932可以对从效应器模块3934接收的控制信号(例如，数字或模拟形式的电信号)作出响应和/或向反馈模块3936生成反馈信号(例如，数字或模拟形式的电信号)。效应器模块3934可以向操作部件3932生成控制信号，例如，执行或实施由用户请求的操作。特定信号可以取决于被寻址的特定操作部件3932。作为例示，操作部件3932可以包括打开或关闭电源的开关电路，并且效应器模块3932能够向开关电路生成信号以打开或关闭电源。作为另一个示例，操作部件3932可以包括能够响应于电控制信号产生物理对象的运动(例如，无弹簧锁闩的锁定或解锁，门的打开或关闭)的机电致动器，并且效应器模块3932能够向致动器生成信号。作为另一个示例，操作部件3932可以包括用于控制数字相机的API(根据具体实施，相机自身可以是或不是操作部件)，并且效应器模块3932能够调用API调用以控制数字相机。在各种实施方案中，效应器模块3934可以响应于经由控制器接口子系统3950从控制器所接收的请求和/或在附件3900的用户界面处所接收的输入而操作。反馈模块3936可以从操作部件3932接收反馈信号。特定信号可以取决于特定操作部件3932。例如，开关电路可以用于提供指示开关当前状态的反馈信号。机电致动器可以提供用于指示当前状态的反馈信号(例如，物理对象的位置和/或运动)。API可以提供错误或状态代码(例如，在从API调用返回时)。作为另一个示例，操作部件3932可以包括用于各种环境条件的一个或多个传感器(例如，运动传感器、位置传感器、温度传感器、障碍传感器等)，并且反馈模块3936可以从传感器接收传感器数据信号。在一些实施方案中，反馈模块3936可以基于所接收的反馈信号向控制器交互子系统3950提供反馈信息。控制器交互子系统3950可以支持附件3900和控制器之间的交互。可以使用易失性或非易失性存储介质(例如，半导体闪存存储器、EEPROM、DRAM、SRAM、磁盘或光盘等)实现附件对象存储元件3952。在一些实施方案中，附件对象存储元件3852可以用于存储可以由控制器用于与附件3900交互的一个或多个附件对象的表示。可以应请求(例如，在与控制器执行配对验证过程之后)向控制器供应所存储的附件对象，并且可以在附件状态改变时更新所存储的附件对象。例如，反馈模块3936可以基于从操作部件3932所接收的反馈信号来更新存储的附件对象。发现模块3954可以执行与使得附件3900可被控制器发现相关的操作，诸如广播通告，从未建立配对的控制器接收用于执行配对设置的请求等等。例如，发现模块3954可以实施上文参考图4所述的附件操作。请求处理模块3956可以接收并处理来自控制器的请求消息。例如，响应于接收到的请求消息(例如，如上所述向锁定状态特性写入)，请求处理模块3956可以确定是否许可请求(例如，是否存在与控制器的配对验证状态，消息是否利用有效会话密钥加密，以及控制器是否具有执行所请求动作的许可)。假设请求是有效的，请求处理模块3956可以向效应器模块3934生成指令(例如，以致动锁定机构)。在一些实施方案中，确定是否许可请求可以包括对消息解密，并且请求处理模块3956可以调用密码逻辑模块3914结合处理请求所支持的功能。在一些实施方案中，请求处理模块3956可以与安全子系统3902交互，以在配对设置、配对验证、配对添加或配对移除操作期间用于接收并处理从控制器接收的请求(例如，上文参考图13-图19所述的任何请求)。响应生成模块3958可以生成并发送对请求消息的响应，并向控制器发送响应消息。例如，如果请求处理模块3956接收到请求并确定不许可它，请求处理模块3956可以这样通知响应生成模块3958，并且响应生成模块3958可以生成错误响应。另一方面，如果请求处理模块3956接收到请求并确定许可它，请求处理模块3956可以通知响应生成模块3958被许可的请求已被接收并正在由效应器模块3934处理。在一些实施方案中，响应模块3958可以等待从反馈模块3936接收反馈信息，然后生成并入了反馈信息的响应消息。例如，如果响应生成模块3958接收到用于读取传感器或开锁的请求，响应生成模块3958可以等待从反馈模块3936接收传感器读数或开锁确认，然后生成适当的响应消息。在一些实施方案中，可以在发送之前对响应消息进行加密，并且响应生成模块3958可以调用密码逻辑模块3914结合对消息加密而支持的功能。在一些实施方案中，响应生成模块3958可以与安全子系统3902进行交互以在配对设置、配对验证、配对添加或配对移除操作期间生成并向控制器发送响应(例如，上文参考图13-图19所述的任何响应)。通知生成模块3960可以从反馈模块3936接收信息(例如，只要更新附件对象存储元件3952中存储的附件对象的时候)，并且可以基于该信息向控制器生成通知消息。如上所述，可以支持各种通知机制，并且通知生成模块3960可以支持这些通知机制的任一种或全部(例如，上述过程700,800,900,1000中的任一种或全部)。例如，对于被动通知而言，通知处理模块3960可以仅仅更新附件对象存储元件3952中维持的内部状态计数器。对于通告通知而言，通知生成模块3960能够更新状态计数器并指示发现模块3954生成包括更新的状态计数器值的通告。对于事件通知而言，通知模块3960可以指示响应生成模块3958生成主动响应(例如，上述EVENT消息)以向上述订阅控制器发送。在一些实施方案中，通知模块3960可以维持针对各种通知机制和/或各种特性的订阅控制器列表，并能够根据是否订阅任何控制器来发起一种或多种机制。在一些实施方案中，可以在附件对象存储元件3952中维持订阅信息。通信接口模块3970可以提供服务以支持与包括控制器的其他设备通信。在一些实施方案中，通信接口模块3970可以实施蓝牙LE协议栈3972和/或HTTP/IP协议栈3974。蓝牙LE协议栈3972可以根据蓝牙LE传输协议提供传出消息的格式化以及所接收消息的解释。HTTP/IP协议栈3974可以根据HTTP和IP传输协议提供传出消息的格式化以及所接收消息的解释。尽管使用蓝牙LE和HTTP/IP作为示例，但应当理解，在通信接口模块3970内可以支持传输协议的任意组合，并且控制器3900的给定实例可以支持一种或多种传输协议。如上所述，附件3900可以充当设备交互的客户端/服务器模型中的服务器设备，并且蓝牙LE协议栈3872和/或HTTP/IP协议栈3874可以被配置为支持服务器行为。在一些实施方案中，可以修改通信接口模块3970内的协议栈以生成某些不标准消息。例如，如上所述，HTTP/IP协议栈3974可以被配置为生成来自附件的主动“事件”消息(例如，上述图11B的事件消息1120)。在一些实施方案中，通信接口模块3970可以提供可以由其他模块用来向外部设备发送和/或接收消息的API。该API可以被设计成传输无意识的，并且可以相对于附件3900内的其他模块透明地在通信接口模块3970内作出针对特定消息的传输选择。可以基于端口配置向蓝牙LE栈3972或HTTP/IP栈3974发送在附件3900的通信端口(未示出)处接收的消息，并且蓝牙LE栈3972和HTTP/IP栈3974中的每一者可以向适当配置的通信端口发送传出消息。应当理解，本文所述的系统配置和部件是例示性的，并且可能进行变型和修改。应当理解，控制器3600(或控制器3800)的具体实施能够执行由控制器执行的上述任何或所有操作，并且附件3700(或附件3800)的实施能够执行由附件执行的上述任何或所有操作；结合不同附图使用不同附图标记并非有其他暗示。控制器和/或附件可能具有本文并未明确描述的其他能力(例如，移动电话、全球定位系统(GPS)、宽带数据通信、互联网连接等)。根据具体实施，这些设备可以进行互操作，以便提供由任一(或两个)设备支持的任何功能或提供在每个设备中部分地实现的功能。在一些实施方案中，特定附件可以具有经由特定控制器不能访问或调用但可以经由另一个控制器或通过直接与附件交互而访问的一些功能。此外，尽管本文参考特定块描述了控制器和附件，但应当理解，定义这些块是为了描述的方便，而并非旨在暗示部件部分的特定物理布置。此外，块不必对应于物理上不同的部件。块可以被配置为执行各种操作，例如通过对处理器编程或提供适当的控制电路，并且根据初始配置是如何获得的，各个块是可以可重新配置的或不可重新配置的。可以在包括利用电路和软件的任何组合实现的电子设备在内的各种装置中实现本发明的实施方案。可以支持很多操作和交互。例如，在一些实施方案中，附件可以广播关于设备发现服务的通告，指示其可用于与控制器配对。控制器可以例如通过检测通告而发现附件，并能够通过安全地交换长期密钥和带外信息项，诸如设置代码或安全证书，来发起配对设置过程(例如，上文参考图13-图16所述的任意过程)以建立配对。一旦完成配对设置过程，附件便能够使自身不能与任何附加控制器进行配对设置(例如，通过忽略或响应于任何配对设置开始请求返回错误)，并可以授予执行过配对设置的控制器管理员许可。具有管理员许可的控制器能够指示附件通过执行配对添加过程(例如，如上文参考图18所述)或使用其他上述委托配对过程(例如，向附件供应信任证书链)来与一个或多个附加控制器建立配对。具有管理员许可的控制器还可以指示附件通过执行配对移除过程(例如，如上文参考图19A-图19B所述)来移除与一个或多个其他控制器(或与具有管理员许可的控制器)建立的配对。这样，控制器和附件的用户能够维持对哪些其他控制器与附件配对的控制，因为可以要求用户的控制器参与建立任何附加配对。在一些实施方案中，用户能够例如通过指示附件向一个或多个附加控制器授予管理员许可来与其他设备共享控制。具有管理员许可的控制器的用户还可以指示附件移除建立的配对，包括不再希望有的任何配对。已经与附件建立配对的控制器(也称为“配对控制器”)可以行使对附件的控制，而不必保持与附件的持续连接。例如，在配对控制器重新连接到附件时，控制器可以发起配对验证过程(例如，如上文参考图17所述)，允许附件和控制器验证它们之间存在已经建立的配对。配对验证过程还可以提供可用于保证可能在附件和控制器保持连接时发送的任何后续消息安全的一个或多个会话密钥；可以将这种状况称为“配对验证会话”。在连接时，控制器可以向附件发送命令和控制消息(或请求消息)。使用适当的请求消息，控制器可以确定附件的当前状态，并且在一些情况下，可以指示附件改变其当前状态的一方面。例如，附件可以维持将其状态描述为特性和服务集合的附件模型(例如，作为附件对象)。控制器可以通过读取或通过其他方式查询特性中的一个或多个特性(可以包括所有特性或其任意子集)来确定附件当前状态的各方面，并可以通过写入或通过其他方式修改特性中的一个或多个特性来指示附件改变其当前状态的一方面。如果附件要求在配对验证会话内将所有此类请求作为加密消息发送，那么可以将附件的操作限制到被授权的控制器。附件可以是自定义的。例如，在建立配对之后，配对的控制器可以从附件请求附件定义记录。附件定义记录可以为可经由控制器已与其配对的附件控制的每个附件定义附件对象。在一些实施方案中，可以在附件建立任何配对之前使控制器可获得附件定义记录的全部或部分，允许在决定是否建立配对时使用来自附件定义记录的信息。在其他实施方案中，控制器可以基于附件通告(例如，上述TXT记录)中包括的信息确定是否建立配对，并且可以仅在建立配对之后使控制器可获得附件定义记录。配对的控制器可以使用附件定义记录以生成用于询问和/或修改特性的请求，由此能够控制附件。根据需要，控制器可以响应于用户输入或自动(例如，基于控制器检测到各种状况)生成此类请求。在一些实施方案中，控制器可以能够动态地生成用于控制附件的用户界面，其中该用户界面基于在附件定义记录中提供的信息。在一些实施方案中，附件可以通知任何配对的控制器其状态的改变。例如，可以支持被动通知过程(例如，如图7所示)、通告通知过程(例如，如图8所示)、主动通知过程(例如，如图9所示)和/或事件消息通知过程(例如，如图10所示)的任意组合。在一些实施方案中，配对的控制器可以向附件发送用于订阅相对于特定特性的特定通知方法的请求(例如，通告、主动和/或事件消息)。附件可以维持针对各种控制器的订阅状态信息并可以基于当前订阅状态生成特定类型的通知。其他实施方案虽然已相对于具体实施方案对本发明进行了描述，但本领域的技术人员将认识到许多修改是可能的。单个控制器可以使用本文描述的过程以与任意数量的附件建立配对，并且在不同的时间选择性地与不同附件通信。类似地，单个附件可以由(例如，使用上述的配对设置和配对添加)已经与其建立配对的多个控制器控制。附件的任何功能可以通过将该功能模型化为具有一个或多个特性的服务并允许控制器与服务和/或其特性交互(例如，读取，修改，接收更新)来被控制。因此，本文描述的协议和通信过程可以是“统一的”，这意味着可以在具有一个或多个控制器以及一个或多个附件的任何情景中应用它们，不论附件功能或控制器形状因子或特定界面如何。此外，以上一些实施例特别参考了HTTP，这是一种可在支持标准网际协议(IP传输栈(例如，TCP/IP))的局域网和广域网上使用的协议。然而，也可以使用其他传输协议。例如，蓝牙LE协议栈包括允许一个设备询问并修改另一个设备的属性的一般属性(GATT)层。在一些实施方案中，可以将附件特性的实例暴露于控制器，作为基于GATT模型的属性。因此，控制器也可以使用蓝牙LE询问(例如，读取)和修改(例如，写入)附件特性。在一些实施方案中，特定附件可以支持IP和/或蓝牙LE传输协议中的任一种或两种，并且根据附件的能力和控制器建立的优先级，控制器可以与使用IP的一些附件以及使用蓝牙LE的其他附件交互。本文所述的各种特征部诸如方法、装置、计算机可读介质等，可使用专用部件和/或可编程处理器和/或其他可编程设备的任意组合来实现。本文所述的各种过程可以任何组合方式在同一处理器或不同处理器上实现。在部件被描述为被配置为执行某些操作的情况下，可以例如通过设计电子电路以执行操作、通过对可编程电子电路(诸如微处理器)进行编程以执行操作或它们的任何组合来实现这种配置。另外，尽管上述实施方案可能参考了具体硬件部件和软件部件，但本领域的技术人员应当理解，也可使用硬件部件和/或软件部件的不同组合，并且被描述为在硬件中实现的特定操作也可能在软件中实现，或反之亦然。结合本文所述的各种特征的计算机程序可被编码并存储在各种计算机可读存储介质上；合适的介质包括磁盘或磁带、光学存储介质诸如光盘(CD)或DVD(数字多功能光盘)、闪存存储器以及其他非暂态介质。可将利用程序代码编码的计算机可读介质与兼容的电子设备封装在一起，或者该程序代码可独立于电子设备提供(例如，经由互联网下载或作为单独封装的计算机可读存储介质)。因此，尽管已相对于具体实施方案描述了本发明，但应当理解，本发明旨在覆盖以下权利要求范围内的所有修改形式和等同形式。