具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
现有的NFC通信过程交换的设备标识是一个随机数,造成NFC通信应用的局限性。本发明实施例为NFC设备设置了设备类型,并支持NFC设备间交换设备类型或搜索设备类型的功能。
一般而言,可以将NFC设备划分为两个功能实体,DH(DeviceHost,主机)和NFCC(NFCcontroller)。DH负责管理NFC设备和外设(包括NFCC)的运行环境,如初始化、配置、电源管理等。NFCC负责在NFC射频接口上传送数据。NFCC可以通过单独的芯片实现,DH可以通过执行相应指令的处理器实现。DH和NFCC之间的逻辑接口称为NCI(NFCControllerInterface)。
图1是本发明一个实施例的近场通信方法的流程图。图1的方法由NFC设备执行。
101,第一设备发送第一请求消息。第一请求消息携带第一DT(DeviceType,设备类型)信息和/或第二DT信息,第一DT信息用于指示第一设备支持的设备类型,第二DT信息用于指示第一设备要搜索的设备类型。
第一设备是近场通信过程中的主设备,产生自己的射频场,并通过射频场向外部发送第一请求消息。
102,第一设备接收第二设备根据第一请求消息发送的第一响应消息。第一响应消息携带第三DT信息。第三DT信息用于指示第二设备支持的设备类型。
第二设备为近场通信过程中的目标设备,可以按照主动或被动的模式工作。例如,目标设备在接收到第一请求消息之后,可对该第一请求消息作出响应,通过第一响应消息将目标设备支持的设备类型通知给主设备。
可选地,作为另一实施例,第一请求消息可以用来携带第一设备能力信息和/或第二设备能力信息,所述第一设备能力信息用于指示所述第一设备支持的设备能力,所述第二设备能力信息用于指示所述第一设备要搜索的设备能力;所述第一响应消息可以携带第三设备能力信息,所述第三设备能力信息用于指示所述第二设备支持的设备类型或设备能力。
本发明实施例为NFC设备设置了设备类型参数,并且由NFC设备发送携带设备类型信息的请求消息,从而使得NFC设备能够交换或搜索设备类型,增强了NFC设备的能力。
本发明实施例对第一请求消息和第一响应消息的具体形式不作限制。可选地,作为另一实施例,第一请求消息为设备类型请求消息(例如下面将描述的DT_REQ、DTA_REQ或DTF_REQ),第一响应消息为设备类型响应消息(例如下面将描述的DT_RES、DTA_RES或DTF_RES),其中设备类型请求消息和设备类型响应消息是新增的专用消息。
可选地,作为另一实施例,也可以通过扩展现有的消息来携带设备类型参数。例如,第一请求消息为扩展的选择请求消息(如SEL_REQ),第一响应消息为扩展的选择响应消息(如SEL_RES)。或者,第一请求消息为扩展的单设备检测请求消息(如SDD_REQ),第一响应消息为扩展的单设备检测响应消息(如SDD_RES)。或者,第一请求消息为扩展的探测请求消息(如SENS_REQ、SENSF_REQ或ATR_REQ),第一响应消息为扩展的探测响应消息(如SENS_RES、SENSF_RES或ATR_RES)。上述消息为现有的初始化过程中传输的消息。作为另一实施例,第一请求消息和第一响应消息可以是扩展的SNEP(SimpleNFCdataexchangeformatExchangeProtocol,简单近场通信数据交换格式交换协议)消息。SNEP是现有的数据交换过程中传输的消息。
可选地,作为另一实施例,第一请求消息为设备能力请求消息,第一响应消息为设备能力响应消息,其中设备能力请求消息和设备能力响应消息是新增的专用消息或通过扩展现有的消息来携带设备能力参数。
下面还将结合具体例子,更加详细地描述第一请求消息和第一响应消息的实现方式。
可选地,作为另一实施例,第一请求消息还携带类型命令信息。类型命令信息用于指示第一请求消息为用于交换设备类型的第一请求消息或者为用于搜索设备类型的第一请求消息。这里,用于交换设备类型的第一请求消息携带第一DT信息,用于搜索设备类型的第一请求消息携带第二DT信息。如果第一请求消息携带第一DT信息和第二DT信息这两者,则第一请求消息可以同时用于设备类型的交换和搜索。这是一种显式的指示方式,便于目标设备识别和解析第一请求消息。
可选地,作为另一实施例,第一请求消息携带的类型命令信息还可以用于指示第一请求消息为用于交换设备能力的第一请求消息或者为用于搜索设备能力的第一请求消息。
在本发明实施例中,可以将用于交换设备类型的第一请求消息称为“第二请求消息”,将用于搜索设备类型的第一请求消息称为“第三请求消息”。
类型命令信息还可以实现其他指示作用。可选地,作为另一实施例,类型命令信息还用于指示第一请求消息为用于设置第二设备的状态的第一请求消息,以使得第二设备进入第一状态。其中在第一状态下,第二设备不再响应第一设备发送的用于搜索设备类型的第一请求消息。换句话说,如果目标设备进入第一状态,主设备即使再发送用于搜索设备类型的第一请求消息,目标设备也不再响应,这样有利于搜索过程中的冲突解决。例如,主设备的NFCC可以在多个目标设备发送的响应消息产生时隙冲突的情况下,向未发生冲突的目标设备发送用于交换设备类型的第一请求消息,指示目标设备进入第一状态。这样,主设备的NFCC再次发送用于搜索设备类型的第一请求消息时,该未发生冲突的目标设备不再响应,仅仅由发生冲突的目标设备进行响应,逐步实现冲突解决。在本发明实施例中,可以将用于设置设备状态的第一请求消息称为“第四请求消息”。
可选地,作为另一实施例,用于交换设备类型的第一请求消息还可以携带第二设备的标识。由于第二设备的标识可以有多种类型,例如在NFC-A方式下,NFCID1分为4字节、7字节和10字节这几种。此时,可通过类型命令信息指示目标设备的标识的类型。
可选地,作为另一实施例,第一请求消息也可以通过隐式的方式来指示第一请求消息的作用。例如,在第一请求消息携带第一DT信息和第二DT信息这两者的情况下,当第二DT信息为有效值时,表示第一请求消息为用于搜索设备类型的第一请求消息;当第二DT信息为无效值时,表示第一请求消息为用于交换设备类型的第一请求消息。“有效值”和“无效值”可以是规定的值,例如如果值为“0”,则认为该值是无效的;如果为其他非零值,则认为该值是有效的。或者,“有效值”可以是符合特定格式的值,“无效值”是不符合该特定格式的值,例如如果值的前3个比特为“0”,则认为该值是有效的,否则认为该值是无效的。本发明实施例对“有效值”和“无效值”的定义方式不作限制。
可选地,作为另一实施例,在步骤101中,第一设备的DH可以向第一设备的NFCC发送射频发现命令,第一设备的NFCC根据该射频发现命令,在NFCC的射频接口上发送第一请求消息。因此,可通过DH的射频发现命令触发NFCC发送第一请求消息。但本发明实施例对第一设备发送第一请求消息的原因不做限制。例如,第一设备可以在预定事件发生时发送第一请求消息,或者可以按照预定周期发送第一请求消息。或者,也可以通过DH的其他命令触发NFCC发送第一请求消息。这些修改均落入本发明实施例的范围内。
例如,如果射频发现命令携带第二DT信息,则表示DH命令NFCC启动设备类型搜索操作。从而,NFCC发送用于搜索设备类型的第一请求消息。换句话说,NFCC发送携带第二DT信息的第一请求消息。
可选地,作为另一实施例,如果第一设备接收到第二设备根据用于搜索设备类型的第一请求消息发送的第一响应消息之后,则确定该第二设备与要搜索的设备类型相匹配。此时,第一设备可以向第二设备发送用于交换设备类型的第一请求消息,以使得第二设备进入第一状态。。在第一状态下,第二设备不再响应第一设备发送的用于搜索设备类型的第一请求消息。例如,主设备的NFCC可以在多个目标设备发送的响应消息产生时隙冲突的情况下,向未发生冲突的目标设备发送用于交换设备类型的第一请求消息,指示目标设备进入第一状态。这样,NFCC再次发送用于搜索设备类型的第一请求消息时,该未发生冲突的目标设备不再响应,仅仅由发生冲突的目标设备进行响应,逐步实现冲突解决。
可选地,作为另一实施例,第一响应消息还可以携带第二设备的标识。
可选地,作为另一实施例,在步骤101之前,第一设备的DH还可以向第一设备的NFCC发送配置命令CORE_SET_CONFIG_CMD。配置命令CORE_SET_CONFIG_CMD携带第一DT信息。这样可以实现设备类型的配置。例如,在初始设置过程中,或者如果主设备支持的设备类型发生变化,则DH可以通过配置命令CORE_SET_CONFIG_CMD向NFCC通知这样的变化。但本发明实施例对NFC设备确定第一DT信息的方式不作限制。例如,NFCC可以预先存储第一DT信息,如在生产过程中写入第一DT信息,或者在初始安装到NFC设备上之后写入第一DT信息。第一DT信息可以是DH根据系统参数自动产生的,也可以由用户或厂商进行设置。DH也可以通过除了CORE_SET_CONFIG_CMD之外的其他命令将第一DT信息通知给NFCC。这些修改均落入本发明实施例的范围内。
可选地,作为另一实施例,在第一设备接收第二设备根据第一请求消息发送的第一响应消息之后,第一设备可以存储第三DT信息。例如,第一设备的NFCC可以向第一设备的DH发送第三DT信息。这样,主设备的DH能够根据目标设备的设备类型,进行相应的功能处理,增强用户的应用体验。例如,DH可启动与该设备类型匹配的应用程序,如当目标设备(如手机)靠近打印机时,手机的文件传输服务立刻启动;或者,当主设备(如手机)靠近汽车驾驶室的NFC模块(目标设备),立刻启动蓝牙耳机的配对,或者立刻启动收集汽车参数的应用程序。
应注意,本发明实施例对“存储”操作的具体形式不作限制,可以是长期的静态存储,也可以是短期存储,如缓存等。
另外,通过已启动的应用程序来搜索匹配的设备,可以过滤掉无关设备。例如,如果主设备(如手机)开启了音乐播放器,则只有具有扬声器功能的目标设备才会对设备进行响应。或者,如果主设备(如手机)开启了打印应用程序,只有具有打印功能的目标设备才能响应。
上面的例子仅仅是为了帮助本领域技术人员理解本发明实施例的可能的应用场景,而本发明实施例对设备类型的具体应用方式不作限制。
图2是本发明另一实施例的近场通信方法的流程图。图2的方法由NFC设备执行。图2的方法与图1的方法相对应,因此将适当省略重复的描述。
201,第二设备接收第一设备发送的用于交换设备类型的第二请求消息。第二请求消息携带第一DT信息,第一DT信息用于指示第一设备支持的设备类型。
202,第二设备存储第一DT信息,并向第一设备发送第二响应消息,第二响应消息携带第三DT信息,第三DT信息用于指示第二设备支持的设备类型。
第一设备是近场通信过程中的主设备,第二设备是近场通信过程中的目标设备。本发明实施例为NFC设备设置了设备类型参数,并且由NFC设备发送携带设备类型信息的请求消息,从而使得NFC设备能够交换设备类型,增强了NFC设备的能力。
应注意,本发明实施例对“存储”操作的具体形式不作限制,可以是长期的静态存储,也可以是短期存储,如缓存等。
可选地,作为一个实施例,第二请求消息为设备类型请求消息(例如下面将描述的DT_REQ、DTA_REQ或DTF_REQ),第二响应消息为设备类型响应消息(例如下面将描述的DT_RES、DTA_RES或DTF_RES);或者,第二请求消息为扩展的选择请求消息(如SEL_REQ),第二响应消息为扩展的选择响应消息(如SEL_RES);或者,第二请求消息为扩展的单设备检测请求消息(如SDD_REQ),第二响应消息为扩展的单设备检测响应消息(如SDD_RES);或者,第二请求消息为扩展的探测请求消息(如SENS_REQ、SENSF_REQ或ATR_REQ),第二响应消息为扩展的探测响应消息(如SENS_RES、SENSF_RES或ATR_RES);或者,第二请求消息和第二响应消息为扩展的SNEP消息。
可选地,作为另一实施例,第二请求消息还携带类型命令信息,类型命令信息用于指示第二请求消息用于交换设备类型。这样可以显式地指示第二请求消息的作用。
或者,第二请求消息还携带第二DT信息,第二DT信息用于指示第一设备要搜索的设备类型,第二DT信息为无效值。这样可以隐式地指示第二请求消息用于交换设备类型。
类型命令信息还可以实现其他指示作用。可选地,作为另一实施例,类型命令信息还用于指示第二设备的标识的类型。例如在NFC-A方式下,NFCID1分为4字节、7字节和10字节这几种。此时,可通过类型命令信息指示目标设备的标识的类型。
可选地,作为另一实施例,第二请求消息或第二响应消息还可以携带第二设备的标识。
可选地,作为另一实施例,在第二设备向第一设备发送第二响应消息之前,第二设备的NFCC还可以从第二设备的主机接收配置命令CORE_SET_CONFIG_CMD,配置命令CORE_SET_CONFIG_CMD携带第三DT信息。例如,在初始设置过程中,或者如果目标设备支持的设备类型发生变化,则目标设备的DH可以通过配置命令CORE_SET_CONFIG_CMD向NFCC通知这样的变化。但本发明实施例对NFC设备确定第三DT信息的方式不作限制。例如,NFCC可以预先存储第第三DT信息,如在生产过程中写入第三DT信息,或者在初始安装到NFC设备上之后写入第三DT信息。第三DT信息可以是DH根据系统参数自动产生的,也可以由用户或厂商进行设置。DH也可以通过除了CORE_SET_CONFIG_CMD之外的其他命令将第三DT信息通知给NFCC。这些修改均落入本发明实施例的范围内。
这样,目标设备的DH能够根据主设备的设备类型,进行相应的功能处理,增强用户的应用体验。本发明实施例对设备类型的具体应用方式不作限制
图3是本发明另一实施例的近场通信方法的流程图。图3由NFC设备执行。图3的方法与图1的方法相对应,因此将适当省略重复的描述。
301,第二设备接收第一设备发送的用于搜索设备类型的第三请求消息,第三请求消息携带第二DT信息,第二DT信息用于指示第一设备要搜索的设备类型。
302,在第三DT信息匹配第二DT信息的情况下,第二设备向第一设备发送第三响应消息,第三响应消息携带第三DT信息,第三DT信息用于指示第二设备支持的设备类型。
第一设备是近场通信过程中的主设备,第二设备是近场通信过程中的目标设备。本发明实施例为NFC设备设置了设备类型参数,并且由NFC设备发送携带设备类型信息的请求消息,从而使得NFC设备能够搜索设备类型,增强了NFC设备的能力。
这里,第三DT信息匹配第二DT信息,是指第二设备支持的设备类型涵盖了第一设备想要搜索的设备类型。例如,如果DT信息使用集合的方式来表示,则第二DT信息是第三DT信息的子集或者与第三DT信息相同。
另外,在第三DT信息不匹配第二DT信息的情况下,第二设备不对第三请求消息作出响应。可选地,作为一个实施例,第二设备还可进入第二状态,其中在第二状态下,第二设备不再响应第一设备发送的单设备请求消息(SDD_REQ)和选择请求消息(SEL_RES)。
可选地,作为另一实施例,第三响应消息还可以携带第二设备的标识。
可选地,作为另一实施例,在步骤303之后,第二设备在接收到第一设备发送的用于交换设备类型的第二请求消息或接收到第一设备发送的用于设置第二设备的状态的第四请求消息时,可进入第一状态,其中在第一状态下,第二设备不再响应第一设备发送的其他第三请求消息。
可选地,作为另一实施例,第三请求消息为设备类型请求消息(例如下面将描述的DT_REQ、DTA_REQ或DTF_REQ),第三响应消息为设备类型响应消息(例如下面将描述的DT_RES、DTA_RES或DTF_RES);或者,第三请求消息为扩展的选择请求消息(如SEL_REQ),第三响应消息为扩展的选择响应消息(如SEL_RES);或者,第三请求消息为扩展的单设备检测请求消息(如SDD_REQ),第三响应消息为扩展的单设备检测响应消息(如SDD_RES);或者,第三请求消息为扩展的探测请求消息(如SENS_REQ、SENSF_REQ或ATR_REQ),第三响应消息为扩展的探测响应消息(如SENS_RES、SENSF_RES或ATR_RES)。
可选地,作为另一实施例,第三请求消息还携带第一DT信息,第一DT信息用于指示第一设备支持的设备类型。此时,第二设备还可以存储第一DT信息。
可选地,作为另一实施例,第三请求消息还携带类型命令信息,类型命令信息用于指示第三请求消息用于搜索设备类型。另外,第三请求消息也可以通过隐式的方式指示第三请求消息的作用。
可选地,作为另一实施例,在步骤302中,第二设备的NFCC可接收第二设备的DH的配置命令CORE_SET_CONFIG_CMD,配置命令携带第三DT信息。但本发明实施例对NFC设备确定第三DT信息的方式不作限制。例如,NFCC可以预先存储第三DT信息,如在生产过程中写入第三DT信息,或者在初始安装到NFC设备上之后写入第三DT信息。第三DT信息可以是DH根据系统参数自动产生的,也可以由用户或厂商进行设置。DH也可以通过除了CORE_SET_CONFIG_CMD之外的其他命令将第三DT信息通知给NFCC。这些修改均落入本发明实施例的范围内。
图4是本发明一个实施例的信息配置方法的流程图。图4的方法由NFC设备执行,例如可以由NFC通信过程中的主设备或目标设备执行。
41,NFC设备的DH向NFC设备的NFCC发送配置命令,配置命令携带NFC设备支持的设备类型的信息。
例如,可以通过扩展现有的CORE_SET_CONFIG_CMD实现上述配置命令。也可以新增一个专用的配置命令。本发明实施例对此不作限制。
42,NFC设备的NFCC存储设备类型的信息。
这样,能够实现NFC设备中设备类型信息的配置。例如,图4的方法可以在初始设置过程中执行,或者在改变了设备类型的情况下执行。
可选地,作为另一实施例,第一请求消息、第二请求消息、第三请求消息、第一响应消息、第二响应消息及第三响应消息中所携带的除了设备类型信息外还可以是设备能力信息。表0为设备能力描述的一个例子。一个NFC设备可以属于多个分类,即可以同时支持多种设备能力。
表0设备能力的例子
设备能力 |
描述 |
WIFI |
支持WIFI |
蓝牙 |
支持蓝牙 |
音频播放 |
支持音频播放 |
打印 |
支持打印 |
传真 |
支持传真 |
。。。 |
|
下面结合具体例子,更加详细地描述本发明的实施例。应注意,以下实施例仅仅是为了帮助本领域技术人员更好地理解本发明,而非限制本发明的范围。
表1为设备类型的描述的一个例子。一个NFC设备可以属于多个分类,即可以同时支持多种设备类型。
表1设备类型的例子
设备分类 |
描述 |
收银机 |
支付相关 |
音频 |
播放音频格式的数据 |
视频 |
播放视频格式的数据 |
显示 |
显示设备,用于显示静态图片等 |
打印 |
打印机设备 |
传真 |
传真机设备 |
。。。 |
|
表2是本发明实施例的设备类型数据格式的例子。本发明实施例增加了设备类型参数“DEVICE_TYPE”,具体定义如表2所示,长度为2字节(byte)。但是本发明实施例对设备类型参数的具体长度不作限制。
表2设备类型参数“DEVICE_TYPE”的例子
表3是本发明一个实施例的设备类型参数“DEVICE_TYPE”的格式的一个例子,其中h表示十六进制。在表3的例子中,设备类型参数“DEVICE_TYPE”使用位图(bitmap)的编码格式,但本发明实施例对设备类型参数的格式不作限制。应注意,在本发明实施例的各个表中,按照倒序的方式排列各个字节的各个比特。
表3设备类型参数的编码格式的例子
如表3所示,一个NFC设备可以支持多个设备类型。如设备具有视频、显示的功能,那么在第一个字节的b2和b3设置为1。表3中“x”表示预留比特。
图5是本发明一个实施例的近场通信过程的示意流程图。图5的实施例中,相同的步骤使用相同的附图标记。图5的实施例是用于交换设备类型的过程中配置设备类型和上报设备类型的方法。
501:DH向NFCC发送配置命令CORE_SET_CONFIG_CMD,该命令用于配置NFCC的相关参数。
与现有的配置命令不同的是,本发明实施例的配置命令CORE_SET_CONFIG_CMD包含了要配置的设备类型。
例如,步骤401可以在初始设置过程中执行,或者在改变了设备类型的情况下执行。
502:NFCC收到配置命令后,向DH反馈响应消息CORE_SET_CONFIG_RSP,用于指示配置是否成功。
步骤501和502是配置设备类型的过程。该过程不必再每次启动发现过程之前均需执行,而只需在初始设置时执行即可,或者在设备类型的配置发生变化时执行。因此,步骤501和502是可选的过程。
503:DH向NFCC发送RF_DISCOVER_CMD命令,触发NFCC启动设备的发现过程。
504:NFCC向DH反馈响应消息,用于指示设备发现过程正在进行;
505:主设备和目标设备之间执行用于交换设备类型的发现过程。
506:当主设备的NFCC发现周围的目标设备后,会向DH发送射频发现通知消息RF_DISCOVER_NTF,用于通告发现结果。与现有的射频发现通知消息不同,本发明实施例的射频发现通知消息RF_DISCOVER_NTF包括该目标设备的设备类型。
同样的,当目标设备的NFCC发现周围的主设备后,会向DH发送射频发现通知消息RF_DISCOVER_NTF,用于通告发现结果。与现有的射频发现通知消息不同,本发明实施例的射频发现通知消息RF_DISCOVER_NTF包括主设备的设备类型。
例如,可以在RF_DISCOVER_NTF消息中增加“DeviceType”(设备类型)字段,携带表3所示的设备类型参数。
图6是本发明一个实施例的近场通信过程的示意流程图。图6的实施例中,相同的步骤使用相同的附图标记。图6的实施例是用于搜索设备类型的过程中配置设备类型和上报设备类型的方法。
应注意,在图6的实施例中,在搜索设备类型的同时,也执行设备类型的交换,但本发明实施例不限于此。例如,在不执行设备类型的交换的情况下,目标设备的步骤606可以省略。
步骤601-602和图5的步骤501-502相同,因此省略重复的描述。
603:DH向NFCC发送RF_DISCOVER_CMD命令,其中包括要搜索的设备类型,触发NFCC启动设备的发现过程。
604:NFCC向DH反馈响应消息,用于指示设备发现过程正在进行。
605:主设备和目标设备之间执行用于搜索设备类型的发现过程。
步骤606和图5的步骤506相同,因此省略重复的描述。
下面结合图7-图11,描述在NFC-A被动通信模式下,新增专用消息DTA_REQ和DTA_RES用于交换及搜索特定设备类型的实施例。
在NFC-A被动通信下,增加了DTA_REQ/DTA_RES帧用于交换及搜索特定设备类型的目标设备。根据DTA_REQ帧中的DTA_CMD(即类型命令信息的一个例子,如表4所示)编码格式的不同,DTA_REQ的组成如表5和表6所示。表中“Bytei”表示第i个字节,i为正整数。
表4:DTA_CMD的编码格式的例子
当DTA_CMD=10h、20h或30h(h表示十六进制)时,DTA_REQ用于交换设备类型,帧格式如表5所示。
表5:DTA_REQ交换设备类型
其中,NFCID1为目标设备的NFCID。DT1是上述第一DT信息的例子,用于标识主设备支持的设备类型。
当DTA_CMD=01h时,DTA_REQ用于搜索特定设备类型的目标设备,帧格式如表6所示。
表6:DTA_REQ搜索设备类型
其中,DT1标识主设备支持的设备类型。DT2是上述第二DT信息的例子,用于标识主设备要搜索的设备类型。表6的例子中,DTA_REQ消息既携带DT2,也携带DT1,在搜索设备类型的同时实现设备类型的交换,但本发明实施例不限于此。DTA_REQ消息可以仅仅携带DT2而不携带DT1。
在下文中,为了简洁,以用于搜索的请求消息携带DT1和DT2这两者的情况为例进行描述,但本领域技术人员容易理解,这种情况下的DT1是可选的,这样的实施方式也落入本发明实施例的范围内。
目标设备收到DTA_REQ消息后,将会响应DTA_RES消息,帧格式如表7所示。
表7:DTA_RES帧格式
其中,NFCID1t为目标设备的NFCID。DTt是上述第三DT信息的例子,用于标识目标设备支持的设备类型。
图7是本发明一个实施例的交换设备类型的过程的流程图。图7的方法由主设备执行。
701:主设备向目标设备发送SENS_REQ,用于探测周围目标设备。
702:目标设备收到SENS_REQ后,将会向主设备反馈SENS_RES消息。
703:主设备启动单设备检测过程。
704:主设备获取所有目标设备的NFCID1。
705:主设备向目标设备发送DTA_REQ消息,其中DTA_CMD可以是10h、20h或30h(根据目标设备NFCID1的长度),用于标识该消息用于交换设备类型。
706:主设备收到该NFCID1的目标设备的DTA_RES响应消息。
707:主设备判断DTA_RES消息中的NFCID1值是否与DTA_REQ中的一致,如果一致执行步骤708,如果不一致重新执行步骤705。
708:主设备检测DTA_RES消息中的设备类型,如果设备类型有效,执行709,如果无效,则执行步骤710。
709:主设备的NFCC向主设备的DH通告发现目标设备,并携带该目标设备的设备类型。
710,将该设备类型设置为“未知”,然后执行步骤709。
711:主设备判断是否继续检测,如果继续执行步骤703,否则结束。
这样,能够实现设备类型的交换。
图8是图7的实施例中主设备和目标设备的消息交互的示意图。图8中各个消息的定义可参照图5-图7的实施例,因此不再重复描述。
图9是搜索特定设备类型的过程的示意流程图。图9的方法由主设备执行。
901:主设备向目标设备发送SENS_REQ,用于探测周围目标设备。
902:主设备接收从目标设备反馈回来的SENS_RES消息。
903:主设备发送DTA_REQ,其中DTA_CMD=01h,表示DTA_REQ用于搜索特定设备类型的目标设备。
904:主设备接收从目标设备反馈回来的DTA_RES消息。
905:如果主设备检测到冲突,执行步骤906,否则执行步骤910。
906:主设备执行基于该设备类型的冲突检测过程。
907:主设备获取目标设备的NFCID1。
908:主设备向该目标设备发送DTA_REQ消息,其中DTA_CMD可以是10h、20h或30h,用于标识DTA_REQ用于交换设备类型。
909:主设备接收DTA_RES。
910:主设备检测DTA_RES中的设备类型是否有效,如果有效执行步骤911,无效则执行步骤912。
911:主设备的NFCC向DH通告目标设备的设备类型。
912,设置该设备类型为“未知”,然后执行步骤911。
913:主设备判断是否继续进行目标设备的解析,如果是,执行步骤906,否则结束。
这样,能够实现设备类型的搜索。
图10是搜索特定设备类型的过程中目标设备的状态示意图。图10的框表示各个状态。箭头表示状态的转换,并描绘了触发状态转换的消息。
目标设备收到SENS_REQ后,从状态IDLE(空闲)进入状态READYA,该状态在NFC协议中表示目标设备可以接收级联等级1的单设备检测请求帧。如果各个级联等级检测正确,则会依次进入READYA’和READYA”,或者进入状态ACTIVEA。这些状态均为现有状态。
本发明实施例中增加了READYDTA状态,作为上述第二状态的例子。
具体地,目标设备收到DTA_REQ,其中DTA_CMD=01h,表示DTA_REQ消息用于搜索特定设备类型的目标设备。然后目标设备检查DTA_REQ中的DT2是否与自己的设备类型匹配,如果匹配则向主设备发送DTA_RES消息。如果不匹配,则进入READYDTA状态。在READYDTA状态下,目标设备将不会响应SDD_REQ及SEL_REQ消息。当目标设备收到其它消息(除了SDD_REQ/SEL_REQ)后,将会返回READYA状态。
图11是图9和图10的实施例中主设备和目标设备的消息交互的示意图。图11中各个消息的定义可参照图5-6以及图9-10的实施例,因此不再重复描述。
下面结合图12-图17,描述在NFC-F被动通信模式下,新增专用消息DTF_REQ和DTF_RES用于交换及搜索特定设备类型的实施例。
在NFC-F被动通信下,增加了DTF_REQ/DTF_RES帧用于交换及搜索设备类型。根据DTF_REQ帧中的DTF_CMD(即类型命令信息的一个例子,如表8所示)编码格式的不同,DTF_REQ的组成如表9和表10所示。表中“Bytei”表示第i个字节,i为正整数。
表8:DTF_CMD编码格式的例子
当DTF_CMD=x0h(“x”表示预留比特,可以为任意值),DTF_REQ用于交换设备类型,帧格式如表9所示。
表9:交换设备类型DTF_REQ帧格式
其中NFCID2t表示目标设备的NFCID,DT1为主设备的设备类型,TSN表示时隙数目。
当DTF_CMD=x1h,DTF_REQ用于搜索设备类型,帧格式如表10所示。
表10:搜索设备类型DTF_REQ帧格式
其中DT1表示主设备支持的设备类型,DT2表示主设备要搜索的设备类型。
目标设备收到DTF_REQ消息后,将会响应DTF_RES消息,帧格式如表11所示。
表11:DTF_RES帧格式
图12是本发明一个实施例的交换设备类型的过程的流程图。图12的方法由主设备执行。
1201:主设备向目标设备发送SENSF_REQ,用于探测周围目标设备。
1202:主设备接收从目标设备反馈回来的SENSF_RES消息。
1203:主设备执行单设备检测。
1204:主设备获取目标设备的NFCID2。
1205:主设备向目标设备发送DTF_REQ消息,其中DTF_CMD=x0h,表示DTF_REQ用于交换设备类型,同时设置TSN=0,表示收到该请求消息的目标设备在第一个时隙上发送响应消息。
1206:主设备收到目标设备反馈的DTF_RES消息。
1207,主设备检查NFCID2值与DTF_RES中的设备标识是否一致,执行步骤1208,否则执行步骤1205。
1208:主设备检测DTF_RES中的设备类型是否有效,如果有效执行步骤1209,无效则执行步骤1210。
1209:主设备的NFCC向DH通告目标设备的设备类型。
1210:设置该设备类型为“未知”,然后执行步骤1209。
1211:主设备判断是否继续进行目标设备的解析,如果是,执行步骤1203,否则结束。
这样,能够实现设备类型的交换。
图13是图12的实施例中主设备和目标设备的消息交互的示意图。图13中各个消息的定义可参照图5-6以及图12的实施例,因此不再重复描述。
图14是搜索特定设备类型的过程的示意流程图。图14的方法由主设备执行。
1401:主设备向目标设备发送DTF_REQ,其中DTF_CMD=x1h,表示DTF_REQ用于搜索特定设备类型的目标设备。TSN=0Fh,表示收到DTF_REQ消息的目标设备,可以在16个时隙中任意选择一个时隙发送响应消息。
1402:主设备接收从目标设备反馈回来的DTF_RES消息。
1403:如果响应消息发生冲突执行步骤1404,否则执行步骤1407。
1404:主设备获取所有未发生冲突的目标设备NFCID2。
1405:主设备向已检测出的目标设备发送DTF_REQ消息,其中DTF_CMD=x0h,表示DTQ_REQ用于交换设备类型,同时设置TSN=0,表示收到该请求消息的目标设备在第一个时隙上发送响应消息。
1406:主设备收到目标设备反馈的DTF_RES消息,并判断是否向所有的目标设备发送完成,如果已发送完成,执行步骤1405,否则执行步骤1401。
1407:主设备检测DTF_RES中的设备类型是否有效,如果有效执行步骤1408,无效则执行步骤1409。
1408:主设备的NFCC向DH通告目标设备的设备类型。
1409:设置该设备类型为“未知”,然后执行步骤1408。
1410:主设备判断是否继续进行目标设备的解析,如果是,执行步骤1403,否则结束。
这样,能够实现设备类型的搜索。
图15是搜索特定设备类型的过程中目标设备的状态示意图。图15的框表示各个状态。箭头表示状态的转换,并描绘了触发状态转换的消息。本发明实施例中增加了READYDTF状态,作为上述第一状态的例子。
目标设备收到DTF_REQ消息,其中DTF_CMD=x1h,表示DTF_REQ消息用于搜索特定设备类型的目标设备。如果设备类型匹配,目标设备进入READYF状态,该状态在NFC协议中表示NFC设备已经被唤醒,可以接收ATR_REQ消息。
然后,目标设备接收DTF_REQ消息,其中DTF_CMD=x0h,TSN=00h表示DTQ_REQ用于交换设备类型,要求目标设备在第一个时隙上发送响应消息。
如果NFCID2相匹配,目标设备进入READYDTF状态,在该状态下,目标设备将不会响应DTA_CMD=x1h的DTF_REQ消息。
图16是图14和图15的实施例中主设备和目标设备的消息交互的示意图。图16中各个消息的定义可参照图5-6以及图14-15的实施例,因此不再重复描述。
图17是NFC-F被动模式下的搜索特定设备类型的目标设备的一个例子的示意流程图。
假设有四个NFC设备,其中一个主设备,三个目标设备1-3。
1701,主设备发送DTF_REQ消息(DTF_CMD=x1h,TSN=0Fh)。
1702,,三个目标设备1-3收到后检查设备类型发现匹配,因此随机选定时隙数回应DTF_RES。其中目标设备1和目标设备2同时在时隙1上响应,产生冲突。而目标设备3在时隙2上响应,没有冲突。
1703,由于目标设备3的响应没有冲突,因此主设备检测出目标设备3的NFCID2,向目标设备3发送DTF_REQ消息(DTF_CMD=x0h),使得目标设备3进入READYDTF的状态。该状态下,目标设备3不会对DTF_CMD=x1h的DTF_REQ消息进行响应。
1704,主设备继续发送DTF_REQ(DTF_CMD=x1h)消息。
1705,目标设备1和目标设备2重新随机选择时隙进行响应。假设目标设备1和目标设备2此次选择不同的时隙进行响应,则主设备获取到所有的目标设备。
这样,能够解决搜索设备类型过程中目标设备响应的冲突问题。
下面结合图18-图21,描述在主动通信模式下,新增专用消息DT_REQ和DT_RES用于交换及搜索特定设备类型的实施例。
根据DT_REQ帧中的OPT(即类型命令信息的一个例子,如表12所示)编码格式的不同,DT_REQ的组成如表13和表14所示。表中“Bytei”表示第i个字节,i为正整数。
表12:OPT编码格式
当OPT=x1h,DT_REQ用于交换设备类型,帧格式如表13所示。
表13:交换设备类型DT_REQ帧格式
其中CMD1=D4h,CMD2=0Ch,用于标识DT_REQ消息。DIDi用于主动通信模式下唯一标识目标设备的标识符。DT1表示主设备的设备类型。
当OPT=x0h,DT_REQ用于搜索设备类型,帧格式如表14所示。
表14:搜索设备类型DT_REQ帧格式
其中CMD1=D4h,CMD2=0Ch,用于标识DT_REQ消息。DT1表示主设备的设备类型。DT2表示要搜索的设备类型。
当目标设备收到DT_REQ消息后,会响应DT_RES消息,帧格式如表15所示。
表15:DT_RES帧格式
其中CMD1=D5h,CMD2=0Dh,用于标识DT_RES消息。DIDi标识目标设备。DTt表示目标设备的设备类型。
图18是本发明另一实施例的交换设备类型的过程的流程图。图18的方法由主设备执行。
1801:主设备向目标设备发送ATR_REQ,用于探测周围目标设备并请求获取目标设备参数。
1802:主设备接收从目标设备反馈回来的ATR_RES消息。
1803:主设备判断是否获取所有目标设备响应,如果是,则执行步骤1804。否则执行步骤1801。
1804:主设备获取目标设备的DID。
1805:主设备向目标设备发送DT_REQ消息,其中OPT=x1h,表示DT_REQ用于交换设备类型。
1806:主设备收到目标设备反馈的DT_RES消息。
1807:主设备检测DT_RES中的设备类型是否有效,如果有效执行步骤1808,无效则执行步骤1809。
1808:主设备的NFCC向DH通告目标设备的设备类型。
1809:设置该设备类型为“未知”,然后执行步骤1808。
1810:主设备判断是否继续进行目标设备的解析,如果是,执行步骤1804,否则结束。
这样,能够实现设备类型的交换。
图19是图18的实施例中主设备和目标设备的消息交互的示意图。图19中各个消息的定义可参照图5-6以及图18的实施例,因此不再重复描述。
图20是本发明另一实施例的搜索设备类型的过程的流程图。图20的方法由主设备执行。
2001:主设备向目标设备发送ATR_REQ,用于探测周围目标设备并请求获取目标设备参数。
2002:主设备接收从目标设备反馈回来的ATR_RES消息。
2003:主设备向目标设备发送DT_REQ消息,其中OPT=x0h,表示DT_REQ用于搜索特定设备类型的目标设备。
2004:主设备收到目标设备反馈的DT_RES消息。
2005:主设备检测DT_RES中的设备类型是否有效,如果有效执行步骤6,无效则执行步骤2007。
2006:主设备的NFCC向DH通告目标设备的设备类型。
2007:设置该设备类型为“未知”,然后执行步骤2006。
2008:主设备判断是否继续进行目标设备的解析,如果是,执行步骤2004,否则结束。
这样,能够实现设备类型的搜索。
图21是图20的实施例中主设备和目标设备的消息交互的示意图。图21中各个消息的定义可参照图5-6以及图20的实施例,因此不再重复描述。
上面描述了新增专用消息实现设备类型的交换或搜索的实施例。下面描述扩展现有消息实现设备类型的交换或搜索的实施例。
下面结合图22-图23,描述在NFC-A被动通信模式下,扩展现有消息SEL_REQ、SDD_REQ和SEL_RES用于交换及搜索特定设备类型的实施例。
交换设备类型帧格式如表16所示,SEL_REQ消息扩展了SEL_CMD编码格式及增加了字节8和字节9用于表示主设备的设备类型。
表16:SEL_REQ的扩展
搜索特定设备类型目标设备的帧格式如表17所示,SDD_REQ消息扩展了字节3和字节4用于表示主设备的设备类型,字节5和6用于表示要搜索的设备类型。
表17:SDD_REQ的扩展
其中SEL_CMD(上述类型命令信息的一个例子)的编码中加入了00h,用于表示搜索设备类型,如表18所示。
表18:SEL_CMD编码格式
响应消息帧格式如表19所示,在原有的SEL_RES消息后追加了DTt,用于表示目标设备的设备类型。
表19:响应消息
图22是本发明另一实施例的交换设备类型的过程的示意流程图。图22的方法由主设备执行。
2201:主设备向目标设备发送SENS_REQ,用于探测周围目标设备。
2202:目标设备收到SENS_REQ后,将会向主设备反馈SENS_RES消息。
2203:主设备启动单设备检测过程。
2204:主设备获取目标设备的4字节NFCID值。
2205:主设备向目标设备发送SEL_REQ消息,其中SEL_CMD=93h,95h或者97h,用于选择该目标设备。DT1为主设备的设备类型。
2206:目标设备收SEL_REQ消息后,进行NFCID1的比较,如果匹配将会响应SEL_RES消息,其中DTt为目标设备的设备类型。
2207:主设备收到SEL_RES响应消息后,判断NFCID1是否完整,如果完整则执行步骤2208。如果不完整,则执行步骤2209。
2208:主设备检测SEL_RES消息中的设备类型,如果设备类型有效,执行步骤2210,如果无效,则执行步骤2211。
2209:增加级联等级,然后执行步骤2203。
2210:主设备的NFCC向主设备的DH通告发现目标设备,并携带该目标设备的设备类型。
2211:将该设备类型设置为“未知”,执行步骤2210。
2212:主设备判断是否继续检测,如果继续执行步骤2203,否则结束。
这样,实现了设备类型的交换。
图23是搜索特定设备类型的过程的示意流程图。图23的方法由主设备执行。
2301:主设备向目标设备发送SENS_REQ,用于探测周围目标设备。
2302:主设备接收从目标设备反馈回来的SENS_RES消息。
2303:主设备发送SDD_REQ,其中DT1为主设备设备类型,DT2用于搜索设备类型。
2304:主设备检测NFCID的有效比特。
2305:主设备检测是否发生响应冲突,如果是,则执行步骤2303,否则执行步骤2306。
2306:主设备发送SEL_REQ消息选择目标设备。
2307:主设备检测NFCID是否完整,如果完整执行步骤2308,否则执行2307。
2308:主设备检测SEL_RES中的设备类型是否有效,如果有效执行步骤2310,无效则执行步骤2311。
2309:增加级联等级,然后执行步骤2303。
2310:主设备的NFCC向DH通告目标设备的设备类型。
2311:设置该设备类型为“未知”,然后执行步骤2310。
2312:主设备判断是否继续进行目标设备的解析,如果是,执行步骤2303,否则结束。
这样,实现了设备类型的搜索。
下面结合图24-图28,描述在NFC-A被动通信模式下,扩展现有消息SENSF_REQ/SENSF_RES用于交换及搜索特定设备类型的实施例。
在NFC-F被动通信下,扩展了SENSF_REQ/SENSF_RES帧用于交换及搜索设备类型。增加了DTF_CMD字节,根据DTF_CMD的取值不同,SENSF_REQ消息有不同的帧格式。DTF_CMD编码格式如表20所示。
表20:DTF_CMD编码格式
DTF_CMD=x0h,用于交换设备类型,帧格式如表21所示,在原有SENSF_REQ的帧格式上扩展了字节6的DTF_CMD及字节7到8的DT1。其中DT1用于设置主设备的设备类型。
表21:交换设备类型帧格式
DTF_CMD=x1h,用于搜索设备类型,帧格式如表22所示。在原有SENSF_REQ的帧格式上扩展了字节6的DTF_CMD,字节7到8的DT1和字节9到10的DT2。其中DT1用于设置主设备的设备类型,DT2用于搜索设备类型。
表22:搜索设备类型帧格式
DTF_CMD=x2h,用于设置目标设备的状态,帧格式如表23所示。在原有SENSF_REQ的帧格式上扩展了字节6的DTF_CMD,字节7到14的NFCID2t。其中NFCID2t为指定的目标设备。
表23:设置目标设备的状态
响应消息在原有SENSF_RES的格式上扩展了字节20到21的DTt,用于标识目标设备类型,如表24所示。
表24:SENSF_RES的扩展
图24是本发明另一实施例的交换设备类型的过程的示意流程图。图24的方法由主设备执行。
2401:主设备向目标设备发送SENSF_REQ,用于探测周围目标设备,其中DTF_CMD=x0h,TSN=0Fh,表示交换设备类型的请求消息,目标设备收到该请求消息后,在16个时隙中选择一个进行响应。
2402:主设备接收从目标设备反馈回来的SENS_RES消息。
2403:如果发生冲突,主设备执行步骤2401。否则执行步骤2404。
2404:主设备检测SENSF_RES中的设备类型是否有效,如果有效执行步骤2405,无效则执行步骤2406。
2405:主设备的NFCC向DH通告目标设备的设备类型。
2406:设置该设备类型为“未知”,然后执行步骤2405。
这样,实现了设备类型的交换。
图25是图24的实施例中主设备和目标设备的消息交互的示意图。图25中各个消息的定义可参照图5-6以及图24的实施例,因此不再重复描述。
图26是本发明另一实施例的搜索特定设备类型的过程的示意流程图。图26的方法由主设备执行。
2601:主设备向目标设备发送SENSF_REQ,用于探测周围目标设备,其中DTF_CMD=x1h,TSN=0Fh,表示交换设备类型的请求消息,目标设备收到该请求消息后,在16个时隙中选择一个进行响应,DT2设置为要搜索的设备类型。
2602:主设备接收从目标设备反馈回来的SENSF_RES消息。
2603:主设备检测是否有冲突发生,如果有,执行步骤2604。否则执行步骤2607。
2604:主设备获取所有未产生冲突的目标设备的NFCID2;
2605:主设备向目标设备发送SENSF_REQ消息,其中TSN=00h,DTF_CMD=x2h,表示交用于设置目标设备的状态的请求消息,目标设备收到该请求消息后,在第一个时隙进行响应。
2606:主设备重复步骤2605,直到给所有的未发生冲突的目标设备发送完毕。
主设备重复执行步骤2601-2606,直到没有冲突发生。
2607:主设备检测SENSF_RES中的设备类型是否有效,如果有效执行步骤2608,无效则执行步骤2609。
2608:主设备的NFCC向DH通告目标设备的设备类型。
2609:设置该设备类型为“未知”,然后执行步骤2608。
这样,实现了设备类型的搜索。
图27是搜索特定设备类型的过程中目标设备的状态示意图。图27的框表示各个状态。箭头表示状态的转换,并描绘了触发状态转换的消息。本发明实施例中增加了READYDTF状态,作为上述第一状态的例子。
目标设备收到SENSF_REQ消息,其中DTF_CMD=x1h或者x0h,表示该请求消息用于交换设备类型或搜索特定设备类型的目标设备。如果设备类型匹配,目标设备进入READYF状态,该状态在NFC协议中表示NFC设备已经被唤醒,可以接收ATR_REQ消息。
然后,目标设备接收SENSF_REQ消息,其中DTF_CMD=x2h。如果NFCID2相匹配,则目标设备进入READYDTF状态,在该状态下,目标设备不会响应DTA_CMD=x1h的SENSF_REQ消息。
图28是NFC-F被动模式下的搜索特定设备类型的目标设备的一个例子的示意流程图。
假设有四个NFC设备,其中一个主设备,三个目标设备1-3。
2801,主设备发送SENSF_REQ消息(DTF_CMD=x1h,TSN=0Fh)。
2802,三个目标设备收到后检查设备类型发现匹配,因此随机选定时隙数回应SENSF_RES。其中目标设备1和目标设备2同时在时隙1上回应,产生冲突。而目标设备3在时隙2上回应,没有冲突。
2803,由于目标设备3的响应没有冲突,因此主设备检测出目标设备3的NFCID,向目标设备3发送SENSF_REQ消息(DTF_CMD=x2h),使得目标设备3进入READYDTF的状态,该状态下,目标设备3不会对DTF_CMD=x1h的SENSF_REQ消息进行响应。
2804,主设备继续发送SENSF_REQ(DTF_CMD=x1h)消息。
2805,目标设备1和目标设备2重新随机选择时隙进行响应。假设目标设备1和目标设备2此次选择不同的时隙进行响应,则主设备获取到所有的目标设备。
这样,能够解决搜索设备类型过程中目标设备响应的冲突问题。
下面结合图29-图32,描述在主动通信模式下,扩展ATR_REQ/ATR_RES帧用于交换及搜索设备类型的实施例
本发明实施例在ATR_REQ帧格式的基础上,在PPt与Gi0-Gin之间加入了DT1和DT2,即字节17-20。其中DT1表示主设备的设备类型,DT2表示要搜索的设备类型。当DT2为特定值(如0)时,ATR_REQ表示交换设备类型。DT2不为0时,ATR_REQ表示为搜索特定设备类型的目标设备。具体帧格式如表25所示。
表25:ATR_REQ的扩展格式
在ATR_RES帧格式的基础上,在PPt与Gi0-Gin之间加入了DTt,即字节18-19,用于表示目标设备的设备类型,如表26所示。
表26:ATR_RES的扩展格式
图29是本发明另一实施例的交换设备类型的过程的示意流程图。图29的方法由主设备执行。
2901:主设备发送ATR_REQ消息,其中DT2=0,表示ATR_REQ用于交换设备类型请求。
2902:主设备接收从目标设备响应的ATR_RES消息。
2903:主设备检测ATR_RES中的设备类型是否有效,如果有效执行步骤2904,无效则执行步骤2905。
2904:主设备的NFCC向DH通告目标设备的设备类型。
2905:设置该设备类型为“未知”,然后执行步骤2904。
2906:主设备判断是否继续检测,如果继续执行步骤2901,否则结束。
这样,实现了设备类型的交换。
图30是图29的实施例中主设备和目标设备的消息交互的示意图。图30中各个消息的定义可参照图5-6以及图29的实施例,因此不再重复描述。
图31是本发明另一实施例的搜索特定设备类型的过程的示意流程图。图31的方法由主设备执行。
3101:主设备发送ATR_REQ消息,其中DT2设置为要搜索的设备类型,表示该请求用于搜索特定设备类型目标设备的请求。
3102:主设备接收从目标设备响应的ATR_RES消息。
3103:主设备检测ATR_RES中的设备类型是否有效,如果有效执行步骤3104,无效则执行步骤3105。
3104:主设备的NFCC向DH通告目标设备的设备类型。
3105:设置该设备类型为“未知”,然后执行步骤3104。
3106:主设备判断是否继续检测,如果继续执行步骤3101,否则结束。
这样,实现了设备类型的搜索。
图32是图31的实施例中主设备和目标设备的消息交互的示意图。图32中各个消息的定义可参照图5-6以及图31的实施例,因此不再重复描述。
上面的实施例描述了在初始化阶段交换和搜索设备类型的实施例。下面结合图33,描述在数据交换过程中交换设备类型的实施例。
图33的实施例中,扩展了SNEP请求和SNEP响应。
具体地,在SNEP请求消息中增加了设备类型请求码,定义如表27所示。
表27设备类型请求码的例子
代码 |
03h |
名称 |
DT |
描述 |
用于请求目标设备的设备类型 |
另外,增加了设备类型记录,用于在SNEP消息中携带设备类型值。设备类型记录组成格式如表28所示。
表28:设备类型记录
设备类型记录由URI记录和TEXT记录组成。其中URI记录用于存放设备类型编码,格式如表29所示。
表29:URI设备类型标识符
其中TEXT记录为可选,用于描述设备类型。
图33是本发明另一实施例的交换设备类型的过程的示意流程图。
3301:主设备发送SNEP请求消息,SNEP请求消息的请求代码为”03h”,表示请求获取目标设备的设备类型,SNEP请求消息中包含主设备的设备类型,存放在设备类型的记录中。
3302:目标设备收到SNEP请求消息后,检查出请求代码为03h,读取消息中主设备的设备的类型,并组建SNEP响应消息,将设备类型存入到设备类型记录中。
主设备收到SNEP响应消息后,从设备类型记录中读取目标设备的设备类型。
这样,能够实现设备类型的交换。
可选地,作为另一实施例,当第一请求消息、第二请求消息、第三请求消息、第一响应消息、第二响应消息及第三响应消息中所携带的是设备能力信息时,交换或搜索设备能力的方法流程与交换或搜索设备类型的方法流程基本相同,在此不再重复描述。
下面,描述本发明实施例的NFC设备的实施例。
图34是本发明一个实施例的NFC设备的框图。图34的NFC设备340包括发送单元341和接收单元342。例如,发送单元341和接收单元342可通过接口(如NFCC的射频接口)实现。
发送单元341发送第一请求消息,第一请求消息携带第一DT信息和/或第二DT信息,第一DT信息用于指示NFC设备340支持的设备类型,第二DT信息用于指示NFC设备340要搜索的设备类型。
接收单元342接收第二设备根据第一请求消息发送的第一响应消息,第一响应消息携带第三DT信息,第三DT信息用于指示第二设备支持的设备类型。
可选地,作为另一实施例,第一请求消息可以用来携带第一设备能力信息和/或第二设备能力信息,所述第一设备能力信息用于指示所述第一设备支持的设备能力,所述第二设备能力信息用于指示所述第一设备要搜索的设备能力;所述第一响应消息可以携带第三设备能力信息,所述第三设备能力信息用于指示所述第二设备支持的设备类型或设备能力。
本发明实施例为NFC设备设置了设备类型参数,并且由NFC设备发送携带设备类型信息的请求消息,从而使得NFC设备能够交换或搜索设备类型,增强了NFC设备的能力。
NFC设备340可执行上述方法实施例中有关主设备的各个过程,实现设备类型的交换或搜索。为避免重复,不再详细描述。
可选地,作为一个实施例,第一请求消息为设备类型请求消息,第一响应消息为设备类型响应消息;或者,第一请求消息为扩展的选择请求消息,第一响应消息为扩展的选择响应消息;或者,第一请求消息为扩展的单设备检测请求消息,第一响应消息为扩展的单设备检测响应消息;或者,第一请求消息为扩展的探测请求消息,第一响应消息为扩展的探测响应消息;或者,第一请求消息和第一响应消息为扩展的SNEP消息。
可选地,作为另一实施例,第一请求消息还携带类型命令信息,类型命令信息用于指示第一请求消息为用于交换设备类型的第一请求消息或者为用于搜索设备类型的第一请求消息,其中用于交换设备类型的第一请求消息携带第一DT信息,用于搜索设备类型的第一请求消息携带第二DT信息。这样可以显式地指示第一请求消息的类型。
可选地,作为另一实施例,类型命令信息还用于指示第一请求消息为用于设置第二设备的状态的第一请求消息,以使得第二设备进入第一状态,其中在第一状态下,第二设备不再响应NFC设备340发送的用于搜索设备类型的第一请求消息。
可选地,作为另一实施例,用于交换设备类型的第一请求消息还携带第二设备的标识,类型命令信息还用于指示第二设备的标识的类型。
可选地,作为另一实施例,在第一请求消息携带第一DT信息和第二DT信息的情况下,当第二DT信息为有效值时,表示第一请求消息为用于搜索设备类型的第一请求消息;当第二DT信息为无效值时,表示第一请求消息为用于交换设备类型的第一请求消息。这样可以隐式地指示第一请求消息的类型。
可选地,作为另一实施例,第一响应消息还携带第二设备的标识。
图35是本发明另一实施例的NFC设备的框图。图35的NFC设备350包括接收单元351和发送单元352。例如,接收单元351和发送单元352可通过接口(如NFCC的射频接口)实现。
接收单元351接收第一设备发送的用于交换设备类型的第二请求消息,第二请求消息携带第一DT信息,第一DT信息用于指示第一设备支持的设备类型。
发送单元352向第一设备发送第二响应消息,第二响应消息携带第三DT信息,第三DT信息用于指示NFC设备350支持的设备类型。
本发明实施例为NFC设备设置了设备类型参数,并且由NFC设备发送携带设备类型信息的请求消息,从而使得NFC设备能够交换设备类型,增强了NFC设备的能力。
NFC设备350可执行上述方法实施例中有关目标设备的各个过程,实现设备类型的交换。为避免重复,不再详细描述。
可选地,作为一个实施例,第二请求消息为设备类型请求消息,第二响应消息为设备类型响应消息;或者,第二请求消息为扩展的选择请求消息,第二响应消息为扩展的选择响应消息;或者,第二请求消息为扩展的单设备检测请求消息,第二响应消息为扩展的单设备检测响应消息;或者,第二请求消息为扩展的探测请求消息,第二响应消息为扩展的探测响应消息;或者,第二请求消息和第二响应消息为扩展的SNEP消息。
可选地,作为另一实施例,第二请求消息还携带类型命令信息,类型命令信息用于指示第二请求消息用于交换设备类型;或者,第二请求消息还携带第二DT信息,第二DT信息用于指示第一设备要搜索的设备类型,第二DT信息为无效值。
可选地,作为另一实施例,类型命令信息还用于指示NFC设备350的标识的类型。
可选地,作为另一实施例,第二请求消息或第二响应消息还携带NFC设备350的标识。
图36是本发明另一实施例的NFC设备的框图。图36的NFC设备360包括接收单元361和发送单元362。例如,接收单元361和发送单元362可通过接口(如NFCC的射频接口)实现。
接收单元361接收第一设备发送的用于搜索设备类型的第三请求消息,第三请求消息携带第二设备类型DT信息,第二DT信息用于指示第一设备要搜索的设备类型。
发送单元362在第三DT信息匹配第二DT信息的情况下,向第一设备发送第三响应消息,第三响应消息携带第三DT信息,第三DT信息用于指示NFC设备360支持的设备类型。
本发明实施例为NFC设备设置了设备类型参数,并且由NFC设备发送携带设备类型信息的请求消息,从而使得NFC设备能够搜索设备类型,增强了NFC设备的能力。
NFC设备360可执行上述方法实施例中有关目标设备的各个过程,实现设备类型的搜索。为避免重复,不再详细描述。
可选地,作为一个实施例,NFC设备360还可以包括控制单元363。控制单元363可通过处理器(如DH的处理器或NFCC的处理器)实现。控制单元363可以在第三DT信息不匹配第二DT信息的情况下,使得NFC设备360进入第二状态,其中在第二状态下,NFC设备360不再响应第一设备发送的单设备请求消息和选择请求消息。
可选地,作为另一实施例,NFC设备360还可以包括控制单元363。控制单元363可通过处理器(如DH的处理器或NFCC的处理器)实现。控制单元363可以在接收单元361接收到第一设备发送的用于交换设备类型的第二请求消息或接收到第一设备发送的用于设置NFC设备360的状态的第四请求消息时,使得NFC设备360进入第一状态,其中在第一状态下,NFC设备360不再响应第一设备发送的第三请求消息。
可选地,作为另一实施例,第三请求消息为设备类型请求消息,第三响应消息为设备类型响应消息;或者,第三请求消息为扩展的选择请求消息,第三响应消息为扩展的选择响应消息;或者,第三请求消息为扩展的单设备检测请求消息,第三响应消息为扩展的单设备检测响应消息;或者,第三请求消息为扩展的探测请求消息,第三响应消息为扩展的探测响应消息。
可选地,作为另一实施例,第三请求消息还携带第一DT信息,第一DT信息用于指示第一设备支持的设备类型。
可选地,作为另一实施例,第三请求消息还携带类型命令信息,类型命令信息用于指示第三请求消息用于搜索设备类型。
可选地,作为另一实施例,所述第三响应消息还携带所述第二设备的标识。
图37是本发明另一实施例的NFC设备的框图。图37的NFC设备370包括DH371和NFCC372。
DH371向NFCC372发送配置命令,配置命令携带NFC设备370支持的设备类型的信息。
NFCC372存储NFC设备370支持的设备类型的信息。
这样,NFCC能够确定NFC设备支持的设备类型,从而可以在设备类型的交换或搜索过程中使用该设备类型的信息,增强了NFC设备的能力。
NFC设备370可执行上述方法实施例中有关配置设备类型的过程,为避免重复,不再详细描述。
图38是本发明另一实施例的NFC设备的框图。图38的NFC设备380包括NFCC383。NFCC383包括发射电路3831、接收电路3832和天线3833。
NFCC383的发射电路3831通过天线3833发送第一请求消息,第一请求消息携带第一DT信息和/或第二DT信息,第一DT信息用于指示NFC设备380支持的设备类型,第二DT信息用于指示NFC设备380要搜索的设备类型。
NFCC383的接收电路3832通过天线3833接收第二设备根据第一请求消息发送的第一响应消息,第一响应消息携带第三DT信息,第三DT信息用于指示第二设备支持的设备类型。
本发明实施例为NFC设备设置了设备类型参数,并且由NFC设备发送携带设备类型信息的请求消息,从而使得NFC设备能够交换或搜索设备类型,增强了NFC设备的能力。
如图38所示,NFC设备380还包括处理器381和存储器382。存储器382存储使得处理器381实现对NFCC383的控制的指令。这样,NFCC383在处理器381的控制之下实现上述功能。换句话说,处理器381实现NFC设备380中的主机(DH)的功能。
NFC设备380的处理器381、存储器382和NFCC383通过总线系统389耦合在一起,其中总线系统389除包括数据总线之外,还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见,在图中将各种总线都标为总线系统389。DH和NFCC之间的逻辑接口NCI可通过总线系统389实现。
处理器381从总体上控制NFC设备380的操作,处理器381可以是CPU(CentralProcessingUnit,中央处理单元)。处理器381还可以是其他通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
存储器382可以包括只读存储器和随机存取存储器,并向处理器381提供指令和数据。存储器382的一部分还可以包括非易失性随机存取存储器。例如,存储器382还可以存储设备类型的信息。
NFCC383可以实现为单独的芯片,发射电路3831、接收电路3832和天线3833实现NFCC383的射频接口。发射电路3831和接收电路3832通过内部连接3839耦合到天线3833。本发明实施例对内部连接3839的形式不作限制,可以是内部总线或内部电路等。
可选地,在一个实施例中,发射电路3831和接收电路3832可以由一套电路实现,通过双工模式实现发射和接收功能。
可选地,NFCC383可以具有自己的处理器3834和存储器3835。这样NFCC383可以实现一定的处理能力,分担处理器381的工作负荷。例如,上述第一请求消息可以由处理器381生成,也可以由处理器3834生成。或者,上述第一响应消息可以由处理器381处理,也可以由处理器3834处理。
在实现过程中,上述方法的各步骤可以通过处理器381或3834中的硬件的集成逻辑电路或者软件形式的指令完成。结合本发明实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器382或3835,处理器381或3834读取存储器382或3835中的信息,结合其硬件完成上述方法的步骤。为避免重复,这里不再详细描述。
可选地,作为一个实施例,第一请求消息为设备类型请求消息,第一响应消息为设备类型响应消息;或者,第一请求消息为扩展的选择请求消息,第一响应消息为扩展的选择响应消息;或者,第一请求消息为扩展的单设备检测请求消息,第一响应消息为扩展的单设备检测响应消息;或者,第一请求消息为扩展的探测请求消息,第一响应消息为扩展的探测响应消息;或者,第一请求消息和第一响应消息为扩展的SNEP消息。
可选地,作为另一实施例,第一请求消息还携带类型命令信息,类型命令信息用于指示第一请求消息为用于交换设备类型的第一请求消息或者为用于搜索设备类型的第一请求消息,其中用于交换设备类型的第一请求消息携带第一DT信息,用于搜索设备类型的第一请求消息携带第二DT信息。这样可以显式地指示第一请求消息的类型。
可选地,作为另一实施例,类型命令信息还用于指示第一请求消息为用于设置第二设备的状态的第一请求消息,以使得第二设备进入第一状态,其中在第一状态下,第二设备不再响应NFC设备340发送的用于搜索设备类型的第一请求消息。
可选地,作为另一实施例,用于交换设备类型的第一请求消息还携带第二设备的标识,类型命令信息还用于指示第二设备的标识的类型。
可选地,作为另一实施例,在第一请求消息携带第一DT信息和第二DT信息的情况下,当第二DT信息为有效值时,表示第一请求消息为用于搜索设备类型的第一请求消息;当第二DT信息为无效值时,表示第一请求消息为用于交换设备类型的第一请求消息。这样可以隐式地指示第一请求消息的类型。
可选地,作为另一实施例,第一响应消息还携带第二设备的标识。
可选地,作为另一实施例,处理器381向NFCC383的处理器3834发送射频发现命令。NFCC383的处理器3834根据该射频发现命令,控制发射电路3831发送上述第一请求消息。
可选地,作为另一实施例,处理器381向NFCC383的处理器3834发送配置命令,配置命令携带上述第一DT信息。
可选地,作为另一实施例,NFCC383的处理器3834在得到第三DT信息之后,可以向处理器381发送第三DT信息,以便处理器381将第三DT信息存储在存储器382中。这样,便于NFC设备380使用第三DT信息,增强了NFC设备380的应用能力。
图39是本发明另一实施例的NFC设备的框图。图39的NFC设备390包括NFCC393。NFCC393包括发射电路3931、接收电路3932和天线3933。
接收电路3932通过天线3933接收第一设备发送的用于交换设备类型的第二请求消息,第二请求消息携带第一DT信息,第一DT信息用于指示第一设备支持的设备类型。
发射电路3931通过天线3933向第一设备发送第二响应消息,第二响应消息携带第三DT信息,第三DT信息用于指示NFC设备390支持的设备类型。
本发明实施例为NFC设备设置了设备类型参数,并且由NFC设备发送携带设备类型信息的请求消息,从而使得NFC设备能够交换设备类型,增强了NFC设备的能力。
如图39所示,NFC设备390还包括处理器391和存储器392。存储器392存储使得处理器391实现对NFCC393的控制的指令。这样,NFCC393在处理器391的控制之下实现上述功能。换句话说,处理器391实现NFC设备390中的主机(DH)的功能。
NFC设备390的处理器391、存储器392和NFCC393通过总线系统399耦合在一起,其中总线系统399除包括数据总线之外,还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见,在图中将各种总线都标为总线系统399。DH和NFCC之间的逻辑接口NCI可通过总线系统399实现。
处理器391从总体上控制NFC设备390的操作,处理器391可以是CPU(CentralProcessingUnit,中央处理单元)。处理器391还可以是其他通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
存储器392可以包括只读存储器和随机存取存储器,并向处理器391提供指令和数据。存储器392的一部分还可以包括非易失性随机存取存储器。例如,存储器392还可以存储设备类型的信息。
NFCC393可以实现为单独的芯片,发射电路3931、接收电路3932和天线3933实现NFCC393的射频接口。发射电路3931和接收电路3932通过内部连接3939耦合到天线3933。本发明实施例对内部连接3939的形式不作限制,可以是内部总线或内部电路等。
可选地,在一个实施例中,发射电路3931和接收电路3932可以由一套电路实现,通过双工模式实现发射和接收功能。
可选地,NFCC393可以具有自己的处理器3934和存储器3935。这样NFCC393可以实现一定的处理能力,分担处理器391的工作负荷。例如,上述第二响应消息可以由处理器391生成,也可以由处理器3934生成。或者,上述第二请求消息可以由处理器391处理,也可以由处理器3934处理。
在实现过程中,上述方法的各步骤可以通过处理器391或3934中的硬件的集成逻辑电路或者软件形式的指令完成。结合本发明实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器392或3935,处理器391或3934读取存储器392或3935中的信息,结合其硬件完成上述方法的步骤。为避免重复,这里不再详细描述。
可选地,作为一个实施例,第二请求消息为设备类型请求消息,第二响应消息为设备类型响应消息;或者,第二请求消息为扩展的选择请求消息,第二响应消息为扩展的选择响应消息;或者,第二请求消息为扩展的单设备检测请求消息,第二响应消息为扩展的单设备检测响应消息;或者,第二请求消息为扩展的探测请求消息,第二响应消息为扩展的探测响应消息;或者,第二请求消息和第二响应消息为扩展的SNEP消息。
可选地,作为另一实施例,第二请求消息还携带类型命令信息,类型命令信息用于指示第二请求消息用于交换设备类型;或者,第二请求消息还携带第二DT信息,第二DT信息用于指示第一设备要搜索的设备类型,第二DT信息为无效值。
可选地,作为另一实施例,类型命令信息还用于指示NFC设备390的标识的类型。
可选地,作为另一实施例,第二请求消息或第二响应消息还携带NFC设备390的标识。
可选地,作为另一实施例,NFCC393的处理器3934从处理器391接收配置命令,配置命令携带第三DT信息。
图40是本发明另一实施例的NFC设备的框图。图40的NFC设备400包括NFCC403。NFCC403包括发射电路4031、接收电路4032和天线4033。
接收电路4032通过天线4033接收第一设备发送的用于搜索设备类型的第三请求消息,第三请求消息携带第二设备类型DT信息,第二DT信息用于指示第一设备要搜索的设备类型。
在第三DT信息匹配第二DT信息的情况下,发射电路4031通过天线4033向第一设备发送第三响应消息,第三响应消息携带第三DT信息,第三DT信息用于指示NFC设备400支持的设备类型。
本发明实施例为NFC设备设置了设备类型参数,并且由NFC设备发送携带设备类型信息的请求消息,从而使得NFC设备能够搜索设备类型,增强了NFC设备的能力。
如图40所示,NFC设备400还包括处理器401和存储器402。存储器402存储使得处理器401实现对NFCC403的控制的指令。这样,NFCC403在处理器401的控制之下实现上述功能。换句话说,处理器401实现NFC设备400中的主机(DH)的功能。
可选地,作为一个实施例,NFCC403的处理器4034和存储器4035的功能也可以分别由处理器401和存储器402实现,即存储器402存储使得处理器401确定第三DT信息的指令。这种情况下,NFCC403可以不包括处理器4034和存储器4035。上述第三响应消息可以由处理器401生成,也可以由处理器4034生成。或者,上述第三请求消息可以由处理器401处理,也可以由处理器4034处理。
NFC设备400的处理器401、存储器402和NFCC403通过总线系统409耦合在一起,其中总线系统409除包括数据总线之外,还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见,在图中将各种总线都标为总线系统409。DH和NFCC之间的逻辑接口NCI可通过总线系统409实现。
处理器401从总体上控制NFC设备400的操作,处理器401可以是CPU(CentralProcessingUnit,中央处理单元)。处理器401还可以是其他通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
存储器402可以包括只读存储器和随机存取存储器,并向处理器401提供指令和数据。存储器402的一部分还可以包括非易失性随机存取存储器。例如,存储器402还可以存储设备类型的信息。
NFCC403可以实现为单独的芯片,发射电路4031、接收电路4032和天线4033实现NFCC403的射频接口。发射电路4031和接收电路4032通过内部连接4039耦合到天线4033。本发明实施例对内部连接4039的形式不作限制,可以是内部总线或内部电路等。
可选地,在一个实施例中,发射电路4031和接收电路4032可以由一套电路实现,通过双工模式实现发射和接收功能。
可选地,NFCC403可以具有自己的处理器4034和存储器4035。这样NFCC403可以实现一定的处理能力,分担处理器401的工作负荷。例如,上述第三响应消息可以由处理器401生成,也可以由处理器4034生成。或者,上述第三请求消息可以由处理器401处理,也可以由处理器4034处理。
在实现过程中,上述方法的各步骤可以通过处理器401或4034中的硬件的集成逻辑电路或者软件形式的指令完成。结合本发明实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器402或4035,处理器401或4034读取存储器402或4035中的信息,结合其硬件完成上述方法的步骤。为避免重复,这里不再详细描述。
可选地,作为一个实施例,处理器4034或401还可以在第三DT信息不匹配第二DT信息的情况下,使得NFC设备360进入第二状态,其中在第二状态下,NFC设备360不再响应第一设备发送的单设备请求消息和选择请求消息。
可选地,作为另一实施例,处理器4034或401还可以在接收电路4032接收到第一设备发送的用于交换设备类型的第二请求消息或接收到第一设备发送的用于设置NFC设备400的状态的第四请求消息时,使得NFC设备400进入第一状态,其中在第一状态下,NFC设备400不再响应第一设备发送的第三请求消息。
可选地,作为另一实施例,第三请求消息为设备类型请求消息,第三响应消息为设备类型响应消息;或者,第三请求消息为扩展的选择请求消息,第三响应消息为扩展的选择响应消息;或者,第三请求消息为扩展的单设备检测请求消息,第三响应消息为扩展的单设备检测响应消息;或者,第三请求消息为扩展的探测请求消息,第三响应消息为扩展的探测响应消息。
可选地,作为另一实施例,第三请求消息还携带第一DT信息,第一DT信息用于指示第一设备支持的设备类型。
可选地,作为另一实施例,第三请求消息还携带类型命令信息,类型命令信息用于指示第三请求消息用于搜索设备类型。
可选地,作为另一实施例,存储器4035或存储器402可存储第一DT信息。
可选地,作为另一实施例,NFCC403的处理器4034可接收处理器401的配置命令,配置命令携带第三DT信息。
可选地,作为另一实施例,第三响应消息还可以携带NFC设备400的标识。
本发明实施例对上述NFC设备340-400的具体实现形式不作限制,打印机、电视、音箱、手机、照相机等,或者是其他能够实现NFC功能的设备。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-OnlyMemory)、随机存取存储器(RAM,RandomAccessMemory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应所述以权利要求的保护范围为准。