用于在智能卡和卡外设备之间进行控制的方法和装置 【技术领域】
本发明涉及智能卡技术。更具体地，本发明涉及智能卡控制卡外设备的方法和装置。
背景技术
近年来，随着电子技术的不断发展，智能卡以其安全、方便、快捷、网络投资小、容量大、多功能等诸多特点越来越受到普遍重视。目前，智能卡已经被广泛应用于商业、医疗、保险、交通、社会公共事业收费等多种领域，而且每年的发卡量上亿。
但是，在如此庞大的智能卡应用中，绝大部分智能卡应用仅仅局限于智能卡本身。换言之，大部分智能卡应用仅仅是利用了智能卡本身的安全性、计算能力及其存储能力，而很少利用智能卡来对卡外设备进行控制。而且，在数量有限的涉及卡外设备控制的智能卡应用中，也还没有提出一种有效并且统一的途径来使得智能卡内的应用程序能够方便地控制卡外设备，并且卡外设备反过来也可以控制智能卡内的应用程序。
在现有技术中，智能卡与卡外设备之间的控制一般只能通过自定义应用协议数据单元(APDU)的方式来实现。APDU是指读卡器和智能卡之间的通信单元，其结构由ISO7816规范定义。APDU可分为两大类，即，APDU命令和APDU应答，前者是由读卡器发送给智能卡的命令，而后者是由智能卡发送给读卡器的状态字以及数据字节。为了实现智能卡对卡外设备的控制，开发人员往往需要在原有APDU的基础上，针对每一个卡外设备，自定义一套扩展的APDU命令，以实现一个专有的用于控制特定卡外设备的应用。图1示出了上述情况的一个例子。如图1所示，智能卡中的每一个应用程序都增加了一套自定义的APDU命令，同时每个卡外设备也相应地具有与之对应的APDU命令处理单元。由此，在图1中，智能卡内的应用程序能够具有控制卡外设备的能力。
然而，在图1所示的方案中，自定义的APDU命令是针对每个应用程序或每个卡外设备而设计的，其固有地缺乏可扩展性和普适性。具体而言，图1所示的解决方案具有如下缺陷：
第一，智能卡中的各个应用程序均需要实现自定义的APDU命令集合，并且对于每一个不同的卡外设备，此APDU命令可能是完全不兼容的；
第二，对于卡外设备的相同的控制内容，例如使卡外设备关闭这种简单的功能，需要在智能卡内的每一个应用程序中都重复实现；
第三，智能卡一旦掩模发卡后，就无法支持新的卡外设备控制。
因此，现有技术中的这种利用自定义APDU命令来实现智能卡对卡外设备控制的方式，还远不能为智能卡和卡外设备之间的控制提供一种统一的、方便的且可扩展的机制。为此，还需要提出一种新的方案来使得智能卡能够方便地控制卡外设备的操作。
【发明内容】
本发明的目的在于提出一种能够使得智能卡方便地控制卡外设备的操作的方法和装置，从而智能卡内的各个应用程序能够控制不同的卡外设备，并且无需重复实现相同的命令。
为此，在本发明一个实施例中，提出了一种智能卡及其方法。该智能卡包括：通信接口，用于与卡外设备进行通信；至少一个应用程序接口(API)函数，用于响应于所述智能卡内至少一个应用程序的调用而生成相应的设备控制接口(DCI)消息，其中所述DCI消息用于控制所述卡外设备进行操作；DCI消息传输单元，用于经由所述通信接口向所述卡外设备传递所述DCI消息。
在本发明另一个实施例中，提出了一种适于与智能卡耦合的电子设备及其方法。该电子设备包括：通信接口，用于与所述智能卡进行通信；DCI消息传输单元，用于经由所述通信接口接收来自所述智能卡的DCI消息，所述DCI消息用于控制所述电子设备执行操作；命令执行单元，用于解释由所述DCI消息传输单元接收到的所述DCI消息，并根据所述DCI消息控制所述电子设备执行相应操作。
【附图说明】
为了使得本发明的上述目的和益处能够更加清楚明了，以下将参照附图、结合具体实施例给出对本发明的详细描述，其中在附图中：
图1示出了现有技术中智能卡与卡外设备之间控制的示意图；
图2示出了根据本发明地一个实施例的利用设备控制接口(DCI)在智能卡与卡外设备之间进行控制的结构框图；
图3A-C是根据本发明的一个实施例的DCI协议的消息格式及实例；
图4示出在本发明的一个实施例中由智能卡内的应用程序控制卡外设备操作的流程图。
图5示出在本发明的一个实施例中由卡外设备控制智能卡内的应用程序的流程图。
在上述所有附图中，相同的附图标记表示相同的或相似的元件或功能。
【具体实施方式】
在本发明的至少一个实施例中提供了一种能够解决智能卡内应用程序与卡外设备之间的控制问题的设备控制接口(DCI)。根据本发明的至少一个实施例的DCI内置于智能卡内，并且通过专用于DCI的应用程序编程接口(API)函数向智能卡内的所有应用程序提供统一的用于卡外设备控制的功能调用。同时，根据本发明至少一个实施例的DCI向不同的卡外设备提供了标准的控制接口，从而即使卡外设备发生变化也无须更新智能卡内的DCI相关程序。
图2示出了如上所述的利用DCI来解决智能卡内应用程序与卡外设备之间的控制问题的一个例子。
如图2所示，智能卡100可以通过例如USB通信接口与一个或多个卡外设备200连接，如卡外设备200-1和200-2。在图2所示的例子中，USB通信接口可用于在智能卡和卡外设备之间传递DCI协议格式的消息。但是，本领域技术人员可以理解的是，智能卡和卡外设备之间还可以采用其他任意的通信接口或通信协议(如TCP/IP)来传递DCI协议格式的消息。
在图2所示的实施例中，智能卡100可以是任何集成有处理器且可以处理数据的卡片，比如银行卡、公交卡以及基于智能卡的SIM卡等等，而卡外设备200、200-1和200-2则可以是任何可以与智能卡100耦合的电子设备，例如读卡器、PDA、笔记本、手机等等。为了便于描述，在以下的实施例中，将以基于智能卡的SIM卡作为智能卡100，且以手机作为卡外设备200为例进行描述，同时，在基于智能卡的SIM卡中可以运行多种应用程序130、130-1和130-2。但是，本领域技术人员可以理解的是，智能卡100和卡外设备200并不限于此。
如图2所示，智能卡100的平台中嵌入有一个DCI消息传输单元110，其用于经由USB通信接口与同样嵌入在卡外设备200的平台中的DCI消息传输单元210交换DCI协议格式的消息。在此实施例中，DCI协议的格式可以如图3A所示。
参照图3A，DCI消息可以包括卡外设备标签、DCI消息长度和DCI消息内容三个部分。其中，卡外设备标签用于识别出将要操作的卡外设备硬件单元，例如卡外设备200中的背光灯、液晶屏、扬声器以及摄像头等。DCI消息长度表示整个DCI消息的字节数，例如8个字节。DCI消息内容可包括一条或多条子消息。例如，在图3A中，DCI消息内容可包括两条子消息。每条子消息具体包括功能标签、子消息长度和子消息值三个部分。其中，功能标签用于标识卡外设备的具体动作，例如背景灯的“开启”或“关闭”、扬声器音量的“设置”等。子消息长度表示该条子消息的字节数目，例如4个字节。子消息值可以包括一些动作参数。例如，背光灯开启的持续时间等等。
如图3A所示的DCI消息进一步又可以分做DCI命令消息和DCI事件消息两大类。图3B和图3C分别示出了这两类DCI消息的具体实例。图3B示出的DCI命令消息M 340是由智能卡100发出的用于控制卡外设备200中的摄像头动作的命令。如图3B所示，在命令消息M340中，卡外设备标签指示为针对“摄像头”的操作；功能标签指示具体动作为“拍摄快照”；而子消息值指示出曝光时间例如为“2s”。图3C示出的DCI事件消息M 350是由卡外设备200发出的用于向智能卡100报告在卡外设备中触发的事件。智能卡100内的应用程序可以对该触发的事件进行处理，从而卡外设备200中发生的动作可以影响到卡内的应用程序。如图3C所示，在消息M350中，卡外设备标签指示为事件是在“呼叫”处理单元内发生的；功能标签指示具体事件为“呼入呼叫”；而子消息值指示出该呼入呼叫的电话号码(来电号码)。关于DCI命令消息和DCI事件消息的处理将在下面结合附图4和图5进行详细描述。
下面回到图2。如图2所示，智能卡100的平台之上还扩展出至少一个专用于DCI的API 120。智能卡100内的一个或多个应用程序130以及应用程序130-2和130-3中的任意一个可直接调用DCI API 120来实现对卡外设备200的控制。响应于应用程序的调用，DCI API 120生成如图3A所示的DCI消息，例如图3B的命令消息。DCI命令消息可经由DCI消息传输单元110传递给卡外设备200。可选地，在图2所示的实施例中，例如应用程序130还可以通过调用DCI服务125的方式来调用DCI API 120，其具体过程将在后面结合图4进行详细描述。
如图2所示，卡外设备200中除了DCI消息传输单元210之外，还包括一个DCI队列220和一个DCI执行单元230。在图2中，DCI消息传输单元210将接收到的DCI消息存储在DCI队列220中。DCI队列220可根据消息的类型或优先级对接收到的DCI消息进行排序。DCI执行单元230则每次从DCI队列220中取出排在首位的DCI消息进行处理。DCI执行单元230可对取出的DCI消息进行解释，并根据DCI消息中的命令驱动卡外设备200中的相应硬件设备进行相应操作。
由此，利用如图2所示的DCI可使得智能卡内的各个应用程序控制卡外设备200。此外，卡外设备200中触发的事件也可以在DCI消息传输单元210、DCI队列220和DCI执行单元230的操作下，反过来通过智能卡100内API对卡内应用程序产生作用。以下将结合两个具体的实施例来详细描述智能卡内的应用程序利用上述DCI控制卡外设备，以及卡外设备通过DCI反过来控制卡内应用程序的过程。
在以下实施例中，假设智能卡100平台是全球平台(Global Platform：GP)，且在GP上专门为DCI扩展的API为GP API。同时，用于调用GPAPI的DCI服务为Global Service(全球服务)。另外，为了便于描述，在以下实施例中，智能卡100内的GP还提供一个卡管理器140和一个注册单元150用于管理智能卡内的应用程序。鉴于卡管理器140和一个注册单元150的操作与现有技术中类似，因而在图2中均未示出。根据具体应用，在图4和图5中涉及卡管理器140和注册单元150的操作可根据实际情况发生变化，甚或省略。
图4示出了本发明一个实施例中智能卡100通过DCI控制卡外设备200的一个流程图。
在图4中，智能卡100内的应用程序130例如希望控制卡外设备——手机中的摄像头拍摄快照。如图4所示，首先，应用程序130向DCI GlobalService 125发出请求，以获得DCI服务(步骤S411)。此时，DCI GlobalService 125需要检查应用程序130是否有权限控制卡外设备(步骤S413)。如果权限检查通过，则DCI Global Service返回给应用程序130一个DCIGlobal Service引用(步骤S415)。应用程序130通过这个Global Service引用可调用用于拍摄快照的DCI API 120，如API函数Camera.TakeSnapShot()(步骤S417)，即发出控制请求。这里，步骤S411～S417是通过调用服务方式来调用DCI API 120的一个例子。可选地，应用程序130还可以直接调用相应的DCI API 120。
响应于应用程序130的调用，DCI API 120首先需要检查调用者(即应用程序130)是否具有使用卡外设备(手机)200的摄像头的权限。具体而言，DCI API 120向卡管理器140请求检查应用程序130的权限(步骤S421)。卡管理器140向注册单元150查询应用程序130的注册表项(步骤S423)，并在得到相应的注册表项后(步骤S425)校验应用程序130的权限(步骤S427)。如果步骤S427中权限校验通过，则卡管理器140反馈给DCIAPI校验通过消息(步骤S429)。这里，根据实际需要，API对应用程序的校验过程也是可以省略的。
在校验通过之后，DCI API 120根据应用程序130在调用API时提供的接口参数，创建符合图3A所示格式的DCI命令消息(例如如图3B所示DCI命令消息M340)，并将所创建的DCI消息发送给DCI消息传输单元110(步骤S430)。继而，智能卡100内的DCI消息传输单元1110将创建的DCI消息M340发送给卡外设备200中的DCI消息传输单元210(步骤S440)。可选地，此时，DCI消息传输单元110还可经由DCI API 120和DCI GlobalService 125向应用程序130反馈表示DCI命令消息已发出的应答消息(步骤S442)。
在卡外设备200中，DCI消息传输单元210将接收到的DCI消息M340存储到DCI队列220中(步骤S450)。DCI队列220在接受新的DCI命令消息M340时会根据类型和优先级对的DCI消息进行排序(步骤S452)。在此实施例中，假设该DCI命令消息M340排在DCI队列220的首位。
DCI执行单元230在空闲时会自动到DCI队列220中取一个DCI消息进行处理(步骤S461)。例如，在此实施例中DCI执行单元230直接取到DCI命令消息M340。继而，DCI执行单元230解释该DCI命令消息M340，并从中提取出DCI命令。例如，在本实施例中，解释出的DCI命令为“控制摄像头拍摄快照”且曝光时间为“2s”。然后，DCI执行单元230根据解释出的DCI命令，调用卡外设备200中的硬件驱动，即摄像头的驱动(步骤S463)。在摄像头驱动的作用下，摄像头执行曝光时间为2s的拍摄操作(步骤S465)，并返回给摄像头一个驱动动作完成信号(步骤S467)。摄像头驱动再根据该完成信号形成驱动应答，返回给DCI执行单元230(步骤S469)。最后，DCI执行单元230在得到来自摄像头驱动的应答消息后，将该DCI消息M340从DCI队列220中的移除，并可继续从DCI队列中取下一个DCI消息(步骤S470)。
按照上述实施例中所述的方法，智能卡内的任意一个应用程序130都可以方便地通过DCI控制卡外设备200的操作。在上述实施例中，为了避免智能卡内的应用程序长时间等待，DCI消息传输单元110在发出DCI消息M340之后立即向应用程序130发送反馈消息。可选地，如果应用程序130期望得到来自卡外设备200的回馈消息，例如应用程序130-1希望查询卡外设备200的音量状态，则DCI消息传输单元110可以在发出DCI消息之后等待来自卡外设备中的DCI消息。
在查询音量状态的例子中，卡外设备200中的DCI执行单元230调用扬声器驱动，以得到当前的扬声器的音量。然后，DCI执行单元230将得到音量信息封装成如图3A所示格式的DCI消息，并通过DCI消息传输单元210将该DCI消息返回给智能卡内的DCI消息传输单元110。这时，智能卡内的DCI消息传输单元110再经由DCI API 120和DCI Global Service125向应用程序130反馈该包含音量状态的DCI消息。
图5示出了本发明一个实施例中卡外设备200通过DCI作用于智能卡100内的应用程序的一个流程图。
在图5的例子中，假设智能卡100内的应用程序130对于卡外设备(如手机)收到呼入呼叫的事件感兴趣，则应用程序130希望能够处理卡外设备中呼入呼叫事件。
在这种情况下，如图5所示，应用程序130可以预先通过DCI API 120注册该呼入呼叫事件。例如，应用程序130可向DCI API 120发送注册呼入呼叫事件的请求(步骤S511)，同时提供该应用程序130自身实现的呼入呼叫处理方法的回调函数。这时，DCI API 120可以先对应用程序130的权限进行鉴别。具体而言，DCI API 120可向卡管理器140请求鉴权(步骤S512)。卡管理器140进而向注册单元150查询应用程序130的注册表项(步骤S513)。在得到注册表项后(步骤S514)，卡管理器140根据注册表项的记录鉴权应用程序130是否有权利监听该呼入呼叫事件(步骤S515)。如果鉴权通过，则卡管理器140返回给DCIAPI 120鉴权成功消息(步骤S516)，同时在注册单元中为应用程序130注册该呼入呼叫事件。继而，DCIAPI 120反馈给应用程序130注册成功消息(步骤S517)。由此，应用程序130可成功地注册了呼入呼叫事件。重复执行步骤S511～S517，其他的应用程序，如应用程序130-1和130-2，也可分别注册其各自感兴趣的事件。在上述步骤中，如果应用程序130被认为是可信的，则可省去鉴权过程。
在注册之后，卡外设备200中一旦产生事件，例如恰好产生了呼入呼叫事件(来电)，则DCI消息传输单元210会从卡外设备的平台获知该事件的发生(步骤S521)，并将该事件存入DCI队列220中(步骤S522)。可选地，在事件存入DCI队列220之后，DCI消息传输单元220可在收到存储完成的确认消息(步骤S523)之后，向卡外设备平台反馈事件处理完成的消息(步骤S524)。重复上述步骤S521～S524，卡外设备中发生的多个事件均可依次存储在DCI队列220中。
在DCI队列220中，存入的事件可根据类型和优先级进行排序(步骤S530)。在图5的实施例中，假设呼入呼叫事件暂时排在队列的首位。继而，卡外设备200中的DCI执行单元230在空闲时会从DCI队列220中提取出待处理的事件(例如呼入呼叫事件)并且将提取出的事件封装成DCI事件消息，例如如图3C所示的DCI事件消息M350(步骤S540)。然后，DCI事件消息M350经由DCI消息传输单元210传送到智能卡100中的DCI消息传输单元110(步骤S550)。
在智能卡100中，根据接收到的DCI事件消息，DCI消息传输单元110通知卡管理器140进行事件发生处理(步骤S560)，以便处理该呼入呼叫事件。卡管理器140遍历注册单元中的各个注册表项(步骤S571)，找到所有注册过该呼入呼叫事件的卡内应用程序，例如应用程序130(步骤S572)。
在找到相应的应用程序130后，卡管理器140通过DCI API 120调用应用程序130在注册时提供的回调函数，即应用程序130实现的呼入呼叫处理方法(步骤S581)。从而，应用程序130可按照自身实现的方法处理来自卡外设备200的呼入呼叫事件(步骤S582)，并在处理之后经由DCI API 120反馈给卡管理器140处理成功与否的应答消息，从而卡管理器140可记录事件处理成败状况(步骤S583)。这时，卡管理器140可重复步骤S581～S583，顺序调用其他注册了该呼入呼叫事件的应用程序，并分别执行各自的呼入呼叫处理。
在所有注册的应用程序均完成了对该呼入呼叫事件的处理之后，卡管理器140经由DCI消息传输单元110向卡外设备200反馈事件处理完毕的应答消息(步骤S590)。在卡外设备200中，DCI执行单元230可经由DCI消息传输单元210得到该事件处理完毕的应答消息(步骤S590)，并由此从DCI队列中移除该呼入呼叫事件(步骤S592)。接下来，DCI执行单元230可处理下一个事件。
在图4和图5所述的实施例中，本领域技术人员可以理解，并非每一个应答消息都是必须的。对于那些不关心处理是否成功的实施例而言，图4和图5中的应答消息或反馈消息可以略去。
另外，在上述实施例中，由于DCI具有标准的消息格式和分层处理结果，DCIAPI 120可以按照多种方式进行设计。例如，一个API函数可以被设计成针对同一个卡外设备的某一种操作，也可以被设计成针对不同卡外设备的相同操作。比如，对于关闭卡外设备的操作可以提供一个通用的API函数Close()，其参数可以包括不同卡外设备的标签。由此，只要在调用API函数Close()时，卡内应用程序在相应的参数中填入所要关闭的卡外设备标签(即，在调用请求中包含相应的卡外设备标签)，则可利用该Close()函数生成相应的DCI命令消息。可选地，DCI API 120还可以是针对不同卡外设备的不同操作的通用控制函数Control()。在这种情况下，应用程序130可以通过为API函数Control()填入不同的卡外设备标签、功能标签等参数来实现各种各样的控制。由此，DCI API可以适应于各种新的卡外设备控制，从而DCI可具有很强的可扩展性。
此外，尽管以上结合附图3A～C描述了本实施例中给出的DCI消息的格式，但是在本发明中DCI消息的格式并不限于图3A～C所示的情况。例如，图3A中的子消息可以包括多个子消息值字段，用于填写卡外设备反馈的状态信息。再比如，图3A中DCI消息长度字段也可以放置在整个消息的开头。关于DCI消息的各种定义或者变形，对于本领域技术人员而言也是显而易见的。
有益效果
在以上实施例中，DCI为智能卡内的各个应用程序提供了统一的接口函数。由此，每个应用程序无需再各自实现自定义的APDU命令，从而节约了资源和成本。同时，DCI也为不同的卡外设备提供了标准的命令消息和事件消息的格式。因而，具有DCI的智能卡可以插入在不同的卡外设备上，且可以利用其内部的DCI API对这些不同的卡外设备进行控制。再者，在上述实施例中，DCI具有标准的消息格式，而且具有传输层和处理层的分层结构，同时，DCI API还可以被设计成通用函数。因而，根据本发明的DCI可以具有良好的可扩展性。即使智能卡在掩模发卡后也可实现新的卡外设备控制。另外，根据本发明的DCI消息可以在各种通信协议上传送，而不再局限于ISO7816标准。
因此，根据本发明的DCI为智能卡和卡外设备之间的控制提供了一种通用的、统一的且可扩展的解决途径。DCI的应用可以支持智能卡对各种各样的卡外设备的控制，从而为智能卡的应用又开辟了广阔的空间。
尽管通过参照示例性实施例对本发明进行了描述，该描述并不旨在被解释为某种限定意义。对所述示例性实施例以及其它实施例的各种修改，对与本发明相关的技术领域的技术人员是显而易见的，并被认为属于本发明的精神和范围内。