[0001] 本发明涉及电路卡，具体而言，涉及用于保护电路卡上存储的数据的布置和方法。

[0002] 诸如蜂窝电话手机之类的手持设备以及其他形式的移动设备(ME)随着它们功能的不断增多已经成为用于存储和保存大量(个人)数据的流行设备/接口。

[0003] 这些数据可以例如包括私人照片、视频和SMS消息，并且用户一般可以选择将这些数据存储在ME内，或诸如订户身份模块(SIM)卡之类的通用集成电路卡(UICC)的相关部分中，或甚至由网络运营商提供的网络侧存储区域中，或诸如存储器卡之类的其他介质设备上。

[0004] 考虑到将被存储的数据的量和可能的私人/敏感性本质，从终端用户(end-user)的角度，存储区域应该提供足够的存储容量、适当的安全性级别以及易访问性。

[0005] 虽然ME本身可以被认为是提供了适当的安全性程度，但是这样的安全性级别倾向于与特定ME制造商有关，并且存储容量被认为不足够用于所有类型的用户数据(具体讲，多媒体数据)。同样，对数据的可访问性一般也需要特定于制造商的线缆和相关的连接软件。

[0006] 虽然诸如存储器卡之类的设备可以提供大存储容量和易访问性，但不存在已有装置可用于保护用户数据或为用户数据提供适当保护。

[0007] 关于网络侧存储区域，可以实现高度安全性以及足够的存储容量，但是可访问性当然将取决于可能无法保证的网络访问可用性。

[0008] 根据近来发展，例如来源于3GPP/ETSI Rel-7，诸如UICC之类的电路卡包括潜在吸引人的存储位置，支持高密度存储器的UICC是可获得的，并且根据同一规范，建议在UICC和ME之间提供基于USB 2.0/USB Inter-Chip的新接口，这将极大地简化和加速与UICC的数据交换，从而使得能够利用简单的适配器来容易地实现例如到PC的数据获取。

[0009] 引用列表

[0010] 专利文献

[0011] PTL 1：国际专利公开No.WO2008/139615

[0012] PTL 2：美国专利公开No.2008/254834

[0013] PTL 3：美国专利公开No.2008/256629

[0014] PTL 4：美国专利公开No.2008/155830

[0058] 如从以上描述所了解到的，并且根据下面对特定实施例的更具体描述，本发明有利地致力于解决在当前电路卡上存在的限制，例如那些与简单地基于PIN代码来提供数据保护机制有关的限制。如上所述，它们主要与应用(例如GSM/USIM)及其相关的数据(例如IMSI或PLMN列表等等)有关，并且其中不是与任意这样的应用直接链接的数据(例如，用户私人文件、照片、视频、个人消息)落在相同的安全性区段内。

[0059] 本发明限定了一种数据保护机制，如果需要，该机制可被与已有的PIN保护一起使用，以便为存储在电路卡上的所有类型的数据提供更高的安全性级别。

[0060] 而且，在电路卡内的数据存储当前是基于初级文件(Elementary File)，这些初级文件不适应于大量数据的存储。而且，这些文件通常不能用于存储某些类型的数据，例如视频和音乐文件。因此，作为本发明的一部分，建议了一种新的数据存储布置，并且发现这种新布置特别有利于与提高的电路卡安全性相关联的使用。

[0061] 首先参考图1，提供了可以有利地体现本发明的一个电路卡示例的示意图。

[0062] 电路卡包括UICC 10，其包括介于存储区域14和ME接口16之间的处理功能12。

[0063] 如下面将描述的，接口16可以有利地基于USP 2.0/USP Inter-Chip，其简化和加速例如UICC 10与图2的蜂窝电话手机18可以通过简单的电适配器被连接到的PC之间的数据交换。

[0064] 关于图2，提供了一种移动无线电通信设备的示意图，该移动无线电通信设备可以包括任意形式的移动设备(ME)(例如蜂窝电话手机18)，并且其中提供了图1的UICC 10以及相关联的标准存储器22、处理器20和发送/接收功能24，如图所示的。

[0065] 如上所述，并且下面将进一步论述，在蜂窝电话手机18能够提供的各种存储选项之中，UICC 10可以基于域安全性元件和密码安全性元件的组合来提供非常安全的、容易访问的、并且适当大的存储位置。

[0066] 与本发明的当前描述和定义有关，应该意识到，“密码”独立地保护对文件/目录/分区的访问，一旦密码被检查就将允许对这些文件/目录/分区的操作。相反，域定义(domain define)服务于一特定实体可以对文件/目录/分区执行的不同的操作。

[0067] 因此，在一个特定示例中，每个数据元素(例如文件、目录或甚至分区)可以与一个域相关联，并且可能受密码保护(在相关联的域需要密码的情况下)。可以提供各种域，这些域具有对它们各自的允许操作的定义，并且一般以标准化方式提供，以允许互操作性。

[0068] 作为示例，可能的域可以如下：

[0069] “私人”：其中只有所有者(创建该文件/目录/分区的实体)可以具有访问权限。一旦密码被成功验证就授予所有权限。

[0070] “受限读写”：其中读写访问权限被授予任意成功通过密码检查的实体。

[0071] “受限读”：其中读访问权限被授予任意成功通过密码检查的实体。

[0072] “只读”：其无需密码而可以被任意实体读取。

[0073] “公开”：其中无需密码读写访问权限被授予任意实体。

[0074] 任意实体，例如特定用户和/或能够访问UICC中的数据的其他设备/装备，被与一称之为“entity_id”的唯一标识符相关联。该标识符优选地由UICC基于来自ME的请求而分配，并且“请求/结果”结构可以如下：

[0075] 从ME到UICC：Generate_Entity_Id_Req(entity_name)

[0076] 从UICC到ME：Generate_Entity_Id_Res(result，entity_name，entity_id)[0077] “entity_name”是能够访问UICC中的数据的实体的公开可获得的名称。

[0078] 该特定图示示例建议：至少如下具有它们各自的entity_name的公开实体被定义：

[0079] -用户(USER)

[0080] -ME(ME)

[0081] -远程服务器(REMOTE_SERVER)

[0082] -ME内的第三方应用(ME_THIRD_PARTY)

[0083] 当然应该意识到，该列表不是穷尽的，因此可以包括其他实体。

[0084] “entity_id”是由UICC分配的针对给定“entity_name”的私人标识符。

[0085] “entity_name，entity_id”对将被保存在ME的存储器中，并且ME将确保这些对的机密性。

[0086] 有利的是，ME负责准确地识别发出请求的实体(希望访问UICC中的数据的实体)，例如，如果请求来自ME应用，则ME将在该文档中所定义的接口功能中使用与ME相关联的entity_id。

[0087] ME识别不同请求实体的简单方式可以通过使用由ME操作系统分配的它们各自的线程或进程标识符。

[0088] UICC可以依赖于如下事实：由ME通过的“entity_id”是准确的，因为某些操作直接依赖于该entity_id。因此，从ME向UICC提供这样的准确的“entity_id”用于提高在本建议中所限定的安全性机制。

[0089] 当文件/目录/分区被创建时，UICC可以针对所创建的元素关联“所有者”的概念。出于这个目的，UICC简单地采用在创建请求功能中所通过的“entity_id”并将其存储为所创建的元素的所有者entity_id。

[0090] 该所有权的概念可以证明很重要，因为很多操作都仅仅允许文件/目录/分区的所有者(例如，在上述“私人”域中所定义的元素只允许其所有者访问)。

[0091] 各种安全性接口功能可以被采用。首先，可采用设置密码功能，其中实体可以仅针对其自身的文件/目录/分区使用该功能。如果UICC在接收到请求时意识到所接收的entity_id与所有者entity_id不匹配，则丢弃该请求，并且“请求/结果”结构可以如下：

[0092] 从ME到UICC：Set_Password_Req(entity_id，pathname，password)[0093] 从UICC到ME：Set_Password_Res(result，entity_id，pathname)[0094] entity_id被提供，以使得有利地只有文件/目录/分区的所有者被允许执行请求。路径名(pathname)包含包括文件/目录/分区的名称的路径，并且密码(password)包括为该文件/目录/分区设置的密码。最终结果将是成功或失败。

[0095] 改变密码功能可以被实体使用，但是仅针对其自身的文件/目录/分区。

[0096] 如果UICC在接收到请求时意识到所接收的entity_id与所有者entity_id不匹配，则丢弃该请求，并且“请求/结果”结构可以如下：

[0097] 从ME到UICC：Change_Password_Req(entity_id，pathname，old_password，new_password)

[0098] 从UICC到ME：Change_Password_Res(result，entity_id，pathname)[0099] 除了与上述类似的参数，还采用old_password和new_password，old_password包含文件/目录/分区的当前密码，new_password包含将被设置给文件/目录/分区的新密码。

[0100] 用于核实密码功能的请求/结果结构可以如下：

[0101] 从ME到UICC：Verify_Password_Req(entity_id，pathname，password)[0102] 从UICC到ME：Verify_Password_Res(result，entity_id，pathname)[0103] 在一种布置中，每个实体对一个给定的受保护元素(文件或目录或分区)的密码核实的“尝试”次数可以被限制为三次。在三次失败的尝试之后，该元素不能再被作出这些尝试的实体所访问，直到针对该元素的访问条件改变为止(例如，该元素的所有者改变或删除密码)。

[0104] 可以如下布置：一实体可以仅对其自身的文件/目录/分区使用“设置域”功能。如果UICC在接收到请求时意识到所接收的entity_id与所有者entity_id不匹配，则丢弃该请求，并且“请求/结果”结构可以如下：

[0105] 从ME到UICC：Set_Domain_Req(entity_id，pathname，domain)

[0106] 从UICC到ME：Set_Domain_Res(result，entity_id，pathname)

[0107] 还可以提供获得域功能，其具有如下“请求/结果”结构：

[0108] 从ME到UICC：Get_Domain_Req(entity_id，pathname)

[0109] 从UICC到ME：Get_Domain_Res(result，entity_id，pathname，domain)[0110] 此外，可以提供访问条件通知功能，其具有如下相应结构：

[0111] 从 UICC 到 ME：Access_Condition_Notification(entity_id，pathname，condition)

[0112] 与上述类似的参数被采用，另外还包括condition(条件)参数，该参数包括针对由pathname所指定的元素需要核实的条件(例如，需要密码)。

[0113] 一个实体标识符创建功能可以被提供，其具有如下“请求/结果”结构：

[0114] 从ME到UICC：Generate_Entity_Id_Req(entity_name)

[0115] 从UICC到ME：Generate_Entity_Id_Res(result，entity_name，entity_id)[0116] 对于相关参数，entity_name还是包括实体的公开名称，并且entity_id包括由UICC为每个entity_name分配的唯一标识符。

[0117] 作为对本发明的该方面的一个示例的进一步图示，下面是与上述可能的域相关的本发明的实现方式的示例。

[0118] 首先，用户拍摄一照片并将图像文件存储在“/partition1/directory1/image1.jpg”中。Partition1域被定义为“受限读写”。“directory1”和“image1.jpg”不受密码保护。

[0119] 用户或任意其他实体希望访问“image1.jpg”文件，并且唯一条件是它们需要知道“partition1”的密码。

[0120] 作为第二示例，用户拍摄一照片，并将图像文件存储在“/partition1/directory1/image1.jpg”中。“partition1”和“directory1”域被定义为“公开”(因此没有密码)。“image1.jpg”受密码保护(域“受限读”)。

[0121] 用户或任意其他实体希望读取“image1.jpg”文件，并且唯一条件是它们需要知道“image1.jpg”的密码。

[0122] 在第三示例中，用户拍摄一照片并将图像文件存储在“/partition1/directory1/image1.jpg”中。“partition1”域被定义为“私人”。“directory1”和“image1.jpg”不受密码保护。

[0123] 用户或任意其他实体希望访问“image1.jpg”文件。但是，只有用户在成功的密码核实之后才能够访问该文件。任意其他实体即使具有正确的密码也不能访问该文件(因为它的entity_id与所有者的entity_id不匹配)。

[0124] 对于第四示例，用户拍摄一照片并将图像文件存储在“/partition1/directory1/image1.jpg”中。“partition1”、“directory1”和“image1.jpg”域被定义为“只读”。

[0125] 对于该示例的第一操作，用户或任意其他实体希望读取“image1.jpg”文件，并且文件数据可直接访问，因为不需要密码来读取文件。

[0126] 但是，对于第二操作，用户或任意其他实体希望更新“image1.jpg”文件，但是只有所有者(用户)将能够在成功的密码核实之后访问该文件。

[0127] 将会意识到的，本发明可以容易地考虑到如下事实：未来的UICC-ME大数据操作将主要通过USB接口实现。因此，图示示例针对基于USB的ME-UICC接口上的实现方式并且支持EEM(以太网仿真模式)接口类。但是，该解决方案的原理也可在其他USB接口类上应用，例如智能卡CCID(集成电路卡接口设备)。

[0128] 鉴于此，应该意识到，USB分组具有如下格式：其中EEM分组包含USB分组的有效载荷。EEM分组本身具有被定义为EEM Data(EEM数据)或EEM Command(EEM命令)格式的格式。

[0129] EEM Command分组被用于本地USB链路管理，因此不能超出USB设备驱动器层。因此，该图示示例所定义的所有接口功能都将被封装在EEM Data类分组的有效载荷部分中。

[0130] 如上所述，本发明还包括用来允许改进的数据存储的特征，以便增强对大尺寸/多媒体数据的支持，对于大尺寸/多媒体数据，当前基于初级文件的文件系统具有某些限制。本发明的这方面建议用标准文件格式文件系统替代大多数已有的初级文件文件系统。

[0131] 为此，特定的ME-UICC接口功能被定义，以便允许ME创建和管理UICC中的文件/目录/分区。

[0132] 这种ME-UICC功能的示例如下所述。

[0133] 用来创建文件/目录/分区的Creation(创建)功能可以与如下“请求/结果”结构相关联。

[0134] 从 ME 到 UICC：Create_Element_Req(entity_id，element_type，pathname，element_parameters)

[0135] 从UICC到ME：Create_Element_Res(result，entity_id，pathname，additional_info)

[0136] 这里所采用的参数可以被定义如下。

[0137] -entity_id：指示发送创建请求的实体

[0138] -element_type：分区或目录或文件

[0139] -pathname：包含将被创建的元素的“路径+名称”，例如，

[0140] “/partition/global_directory/directory1/image1.jpg”

[0141] -element_parameters：特定于给定元素类型的参数(例如，在分区情况下的大小，在文件情况下的文件类型，等等)

[0142] -result：包含请求执行结果(成功、失败、带修改的成功…)

[0143] -additional_info：当UICC发送比简单的执行结果更多的信息时，这些附加数据项被包括在该参数中(例如，在UICC所创建的分区的大小与所请求的大小不同的情况下)[0144] 用来读取分区或目录或文件的Read(读取)功能可以与如下“请求/结果”结构相关联。

[0145] 从ME到UICC：Read_Element_Req(entity_id，pathname)

[0146] 从UICC到ME：Read_Element_Res(result，entity_id，pathname，data)[0147] 这里，参数可以被定义如下：

[0148] -entity_id：指示发送读取请求的实体

[0149] -pathname：包含将被读取的元素的“路径+名称”

[0150] -result：元素读取结果(成功或失败)

[0151] -data：包含读取的元素的数据(例如，位于一读取的分区/目录下的目录和文件的列表或在文件的情况下其自身内容)

[0152] 可以提供Update(更新)功能，但是仅针对文件定义，并且与如下“请求/结果”结构相关联。

[0153] 从ME到UICC：Update_File_Req(entity_id，pathname，data_type，data)[0154] 从UICC到ME：Update_File_Res(result，entity_id，pathname)

[0155] 这里，参数包含：

[0156] -entity_id：指示发送更新请求的实体

[0157] -pathname：包含将被更新的文件的“路径+名称”，例如

[0158] “/partition/global_directory/directory1/image1.jpg”

[0159] -data_type：指示文件中的数据的类型，例如，jpg、mpeg、txt等等[0160] -data：文件的内容

[0161] -result：文件更新结果(成功或失败)

[0162] Rename(重命名)功能可以与如下“请求/结果”结构相关。

[0163] 从ME到UICC：Rename_Element_Req(entity_id，old_pathname，new_name)[0164] 从UICC到ME：Rename_Element_Res(result，entity_id，new_pathname)[0165] 并且，参数可被定义为：

[0166] -entity_id：指示发送重命名请求的实体

[0167] -old_pathname：包含将被重命名的元素的旧“路径+名称”

[0168] -new_name：仅包含将被重命名的元素的新名称(没有路径)

[0169] -result：重命名执行结果(成功或失败)

[0170] -new_pathname：包含已经被重命名的元素的“路径+新名称”

[0171] Move(移动)功能可以被体现为：

[0172] 从ME到UICC：Move_Element_Req(entity_id，old_pathname，new_pathname)[0173] 从UICC到ME：Move_Element_Res(result，entity_id，new_pathname)[0174] 并且，参数定义如下：

[0175] -entity_id：指示发送移动请求的实体

[0176] -old_pathname：包含将被移动的元素的旧“路径+名称”

[0177] -new_pathname：包含已经被被移动的元素的新“路径+名称”

[0178] -result：移动执行结果(成功或失败)

[0179] Delete(删除)功能可以同样提供，并且根据如下请求/结果结构。

[0180] 从ME到UICC：Delete_Element_Req(entity_id，pathname)

[0181] 从UICC到ME：Delete_Element_Res(result，entity_id，pathname)[0182] 参数定义可以如下：

[0183] -entity_id：指示发送删除请求的实体

[0184] -pathname：包含将被删除的元素的“路径+名称”

[0185] -result：删除执行结果(成功或失败)

[0186] 应该注意，如果pathname包含某些受保护的父目录，则对于这些目录的访问条件必须在处理该请求之前被首先满足。

[0187] 还可以提供Cleaning(清除)功能，用于在所有者已经丢失/忘记相关联的密码(并因此不能访问该分区/目录/文件中的任何数据)的情况下删除分区/目录/文件。

[0188] 只有分区/目录/文件的所有者可以执行该操作。

[0189] UICC必须检查所通过的entity_id对应于所有者entity_id，并且相关的“请求/结果”结构如下。

[0190] 从ME到UICC：Clean_Element_Req(entity_id，pathname)

[0191] 从UICC到ME：Clean_Element_Res(result，entity_id，pathname)[0192] 参数定义如下：

[0193] -entity_id：只有所有者将能够实现该请求

[0194] -pathname：包含将被清除(即，删除)的元素的“路径+名称”

[0195] -result：清除执行结果(成功或失败)

[0196] 此外，还可以提供例如与调整分区大小相关的功能，其“请求/结果”结构如下。

[0197] a)调整分区大小

[0198] 从ME到UICC：Resize_Partition_Req(entity_id，name，new_size)[0199] 从UICC到ME：Resize_Partition_Res(result，entity_id，new_allocated_size)[0200] 相关的参数可以定义如下：

[0201] -entity_id：指示发送调整大小请求的实体

[0202] -name：分区的名称

[0203] -new_size：包含该分区的新的所需存储器大小

[0204] -result：调整分区大小结果(成功、失败、带修改的成功(例如，[0205] 在所分配的大小与所请求的大小不同的情况下))

[0206] -new_allocated_size：代表由UICC分配的分区的真实存储器大小[0207] 当然应该意识到，这些接口功能可以根据需要组合提供。

[0208] 现在参考图3，提供了与在图1的UICC 10的存储器存储区域中创建目录所引起的信号序列相关的信令时序图。

[0209] 该信号序列是发生在终端用户26、ME 28(例如蜂窝电话手机)和UICC 30(例如图1的UICC 10)之间的信号序列。

[0210] 图3所示序列开始于来自用户26的要在现有的分区/目录中创建目录的请求32，因此，适当的请求操作34被发送到ME 28，并且可以包含密码名称、域和密码。

[0211] 如果要求域是“公开的”，用户26则不为目录设置密码，因此“password”参数将为空字串。

[0212] ME 28随后向UICC 30传递Create_Element_Request 36，其包括entity_id、element_type、pathname和element_parameters。

[0213] 在本示例中应该注意，为了创建目录，“element_type”被设置为“目录”，并且“element_parameters”具有空值。

[0214] 随后通过的信令包括密码核实序列38，其与父目录相关，但是如果父目录不受密码保护则不需要该序列。但是，如果存在若干受保护的目录级别，则必须随后核实每个目录的密码。

[0215] 密码核实序列38开始于access_condition_notification信号40，其包括parent_directory_path并且还确认需要密码的条件。

[0216] 表示需要密码的通知42被从ME 28传递到ME用户26，ME用户26进而向ME 28提供回密码44，ME 28进而向UICC 30传递verify_password_request信号46。UICC 30进而向ME 28提供verify_password_result信号48，并且随后在UICC 30和ME 28之间发生信令交换，该信令交换包括create_element_result信号50、set_domain_request信号52、set_domain_result信号54、set_password_request信号56和set_password_result信号58，但是应该意识到，这样的设置密码功能如果密码值为空则不会发生。

[0217] 该序列以从ME 28传递到用户26的创建目录结果信号60结束。

[0218] 作为比较，参考图4示出本发明的本实施例的特性的更多细节，图4图示出与文件的创建相关的信号序列。

[0219] 再次地，与用户26、ME 28和UICC 30相关的信令被示出。

[0220] 在本示例中，假设终端用户使用ME的照相机功能拍摄一照片，并决定将照片保存在现有的分区/目录中。在62，作出将照片保存在现有的分区/目录中的决定，因此用户26向移动设备28提供创建文件请求64，并且创建文件请求64包括与相关数据有关的路径名、域、密码和数据类型。

[0221] 随后，create_element_request 66被从ME 28传递到UICC 30，并且为了创建文件，element_type被设置为“文件”，element_parameters包含诸如JPG或MP3之类的文件类型和数据，即文件本身的内容。

[0222] 如果在68发现在到达要创建文件的位置之前存在受密码保护的目录，则每个目录的密码都应该被核实，并且可以将诸如图3所示序列之类的核实序列38与图4的序列一起采用。

[0223] 就是说，create_element_result 70被从UICC 30传递到ME 28，并且作为回复，set_domain_request信号72被传递到UICC 30，UICC 30进而发起set_domain_results信号74。假设密码没有被设置为“空”，则set_password_request 76被从ME 28传递到UICC30，并且作为响应，set_password_result 78被从UICC 30传递到ME 28。在完成ME 28和UICC 30之间的信令交换70-78之后，创建文件结果指示80被ME 28提供到终端用户26。

[0224] 最后参考图5和6，这里作为比较提供了在采用正确密码的实例(图5)中以及在访问条件没有得到满足的实例(图6)中与尝试读取受保护文件相关的信令图。

[0225] 因此，首先参考图5，适当的实体26在82通过向ME 28提供读取文件84来提供该实体希望读取在“受限读”域中定义的文件的指示。在读取文件指示84中的路径名包括到将被读取的文件的特定路径，例如“/partition I/directory I/picture 1.jpg”。

[0226] read_element_request 86随后被从ME 28发送到UICC 30。

[0227] 如图5所示，密码核实序列88被应用到文件本身以及在前的目录，其可以受密码保护，在此情况下，提供例如如图5所示的包含信令和指示90-98的密码核实序列。

[0228] 最初，access_condition_notification信号90被从UICC 30传递到ME28，然后，需要密码指示92被从ME 28提供到实体26，实体26返回核实密码尝试94，该核实密码尝试94进而发起从ME 28到UICC 30的verify_password_request 96。

[0229] verify_password_result 98然后被从UICC 30返回到ME 28，以便完成密码核实序列88。

[0230] 在已经核实密码的情况下，包括所需数据的读取元素结果100被从UICC 30传递到ME 28，以使得包括所需数据的读取文件结果可以被进而传递(102)到请求实体26。

[0231] 现在参考图6，所示序列与如下过程相关：在104，一实体尝试读取由另一不同实体定义在“私人”域中的文件，并且读取文件指示106被提供到ME 28。

[0232] read_element_request 108随后被从ME 28传递到UICC 30，其中，应该意识到，entity_id不同于文件所有者的entity_id。

[0233] UICC 30意识到该文件的域包含“私人”域并因此只有文件的所有者可以访问它。由于接收到的entity_id与所有者的entity_id不匹配，因此在从UICC 30传递到ME 28的read_element_result 110中读取请求被拒绝。

[0234] 读取文件结果指示112随后被从ME 28提供到请求实体26，并且结果指示读取失败，从而其中的数据参数为空。

[0235] 当然应该意识到，本发明并不局限于上述实施例的细节。

[0236] 虽然没有明确描述用于运行在USB智能卡ICCD接口类上的应用的实现方式(其将涉及创建支持与该文档中所描述的相同特征的新APDU命令)，但是如上所述的相同原理可以被应用到这样的ICCD类。

[0237] 而且，对于涉及支持USB大容量存储接口类的UICC的情形，如果由实体(例如ME)在这样的UICC中保存的数据元素可无需密码核实被访问，即，数据元素本身不需要密码，其父数据元素也不需要密码，那么该数据元素在被配置为并且表现为类似USB大容量存储设备的UICC被连接到诸如PC的设备时应该也可以被访问。

[0238] 受密码保护的数据元素必须在UICC被配置为USB大容量存储设备并被连接到不支持密码核实过程的设备时保持无法被访问。

[0239] 因此，更详细地，对于被体现为被配置为USB大容量存储设备并被连接到诸如PC之类的远程设备的UICC，该UICC可以表现为简单的USB记忆棒的形式。然后，在UICC上由ME或任意其他设备已经保存的无需密码的(即，在上述“公开”域中的)数据元素应该保持可在PC上访问。

[0240] 但是，对于受密码保护的数据元素，它们在表现为记忆棒的形式的UICC被连接到PC时保持无法被访问。

[0241] 例如，用户使用ME的照相机拍摄照片并将其无密码地保存在UICC中。当用户随后将UICC通过电适配器插入PC时，UICC将表现得像USB记忆棒，并且照片将可以在PC上被访问。但是，如果用户保存照片时设置了密码，该照片在UICC被插入PC时则将不可见。

[0242] <通过引用并入>

[0243] 本申请基于2009年1月16日递交的英国专利申请No.0900664.4并要求其优先权权益，该在先申请的公开内容通过引用被整体上结合于此。

[0244] 标号列表

[0245] 10UICC

[0246] 12处理功能

[0247] 14存储区域

[0248] 16接口

[0249] 20处理器

[0250] 22标准存储器

[0251] 24发送/接收功能

[0252] 26用户

[0253] 28ME

[0254] 30UICC

[0255] 32请求

[0256] 34适当的请求操作

[0257] 36Create_Element_Request(创建元素请求)

[0258] 38密码核实序列

[0259] 40access_condition_notification(访问条件通知)信号

[0260] 46verify_password_request(核实密码请求)信号

[0261] 48verify_password_result(核实密码结果)信号

[0262] 50create_element_result(创建元素结果)信号

[0263] 52set_domain_request(设置域请求)信号

[0264] 54set_domain_result(设置域结果)信号

[0265] 56set_password_request(设置密码请求)信号

[0266] 60create_directory_result(创建目录结果)信号

[0267] 64create_file_request(创建文件请求)

[0268] 66create_element_request(创建元素请求)

[0269] 70create_element_result(创建元素结果)

[0270] 72set_domain_request(设置域请求)信号

[0271] 74set_domain_result(设置域结果)信号

[0272] 76set_password_request(设置密码请求)

[0273] 78set_password_result(设置密码结果)

[0274] 80文件结果指示

[0275] 82指示

[0276] 84读取文件指示

[0277] 86read_element_request(读取元素请求)

[0278] 90access_condition_notification(访问条件通知)信号

[0279] 92需要密码指示

[0280] 94核实密码尝试

[0281] 96verify_password_request(核实密码请求)

[0282] 98verify_password_result(核实密码结果)

[0283] 100读取元素结果

[0284] 102传递

[0285] 106读取文件指示

[0286] 108read_element_request(读取元素请求)

[0287] 110read_element_result(读取元素结果)

[0288] 112读取文件结果指示