CN1675879A - 数据处理***、数据处理装置及其方法和计算机程序 - Google Patents

数据处理***、数据处理装置及其方法和计算机程序 Download PDF

Info

Publication number
CN1675879A
CN1675879A CN03818944.5A CN03818944A CN1675879A CN 1675879 A CN1675879 A CN 1675879A CN 03818944 A CN03818944 A CN 03818944A CN 1675879 A CN1675879 A CN 1675879A
Authority
CN
China
Prior art keywords
group
attribute certificate
certificate
checking
data processing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN03818944.5A
Other languages
English (en)
Inventor
间杉円
岛田升
�冈诚
川口贵义
石桥义人
阿部博
丰岛信隆
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from JP2002167358A external-priority patent/JP3786055B2/ja
Priority claimed from JP2002167260A external-priority patent/JP2004015507A/ja
Priority claimed from JP2002167148A external-priority patent/JP2004015495A/ja
Application filed by Sony Corp filed Critical Sony Corp
Publication of CN1675879A publication Critical patent/CN1675879A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种权限管理***，该***能够有效地执行权限管理，比如业务接收权限检查处理。相应于由特定装置或者特定用户组成的组设置的组属性证书被作为存储信息，并且加上发放者的数字签名的组属性证书被发送给业务接收实体。当提供业务时，检查所展示的组属性证书的签名以判断该证书是否被篡改，并且使用组信息数据库检查组属性证书以判断该组是否为一个业务允许组。因此，可以对各种用户集合或者装置集合执行统一的权限检查，忽略个别的权限信息管理，从而能够实现有效的权限管理。

Description

数据处理***、数据处理装置及其方法和计算机程序
技术领域
本发明涉及数据处理***、数据处理装置及其方法和计算机程序。特别是，本发明涉及数据处理***、数据处理装置及其方法和计算机程序，从而以有效和安全方式对例如需要确认内容使用的用户执行业务接收权限管理，或者执行业务使用处理等，并且根据用户或装置的访问权限确认执行数据处理。
背景技术
近来，出现了大量伴随终端之间通信的业务提供处理，比如经由通信网如互联网或者可分配的存储媒介如DVD、CD、存储卡和类似物来分配各种类型软件数据如音乐数据、图像数据、游戏程序等(以下称之为内容)，以及出现了伴随终端之间数据传送/接收的付款。例如，在室内或者室外与业务供应商的业务供应装置进行连接以便在装置之间交换数据或者接收内容或业务的用户每天都在出现增加，这些用户具有各类用户装置，比如PC、便携通信终端、便携装置、存储卡等。
各种业务使用的特殊实例包括：使用PC或者便携终端或类似装置访问内容分配业务，以下载各种类型的内容，比如音乐、活动图像、游戏程序等；使用具有存储个人信息、银行账户信息、购物限制货币量信息的内置IC芯片的存储卡等，购物或者转账；以及用来替代列车车票或者公交车车票。
尽管经由通信网或媒介来分配内容和业务等变得日益普遍，但是另一方面，也出现了内容或业务的未授权使用的问题，即，业务被没有合适权限的用户使用，因此需要开发一种***，使内容或业务确实被仅仅提供给具有适当使用权限的用户，从而消除业务的未授权使用。
例如，对于许多软件内容，如音乐、图像数据、游戏程序等，创作者或者出售商通常持有对其分配的权利；并且对于这种内容的分配，使用了考虑安全性的***，由此在某些使用限制条件(即仅仅对于授权用户)下准许软件的使用，从而使未经许可的复制不能执行。
实现接收业务的装置或用户的使用限制的一种方法是加密处理。例如，存在一个安排，其中在例如向装置或者用户提供内容或者业务信息的时候，加密内容或者业务信息然后提供，并且提供能够由被分配所述信息的授权的装置或用户使用的解密密钥，从而启动内容或业务的使用。通过利用解密密钥的解密处理，可以把加密的数据返回到解密的数据(明文)。
尽管存在利用加密密钥和解密密钥的各种数据加密/解密方法和安排，但是一个实例是称为共享密钥加密方法的方法。共享密钥加密方法是，供数据加密处理使用的加密密钥和供数据解密处理使用的解密密钥是共享的，并且向用户提供用于加密处理和解密处理的共享密钥，从而消除没有该密钥的未授权用户对数据的访问。该方法的代表性方法是DES(数据加密标准)。
此外，利用用于加密的加密密钥进行处理和利用用于解密的解密密钥进行处理的方法是所谓的公共密钥加密方法。公共密钥加密方法是使用未指定用户可以使用的公共密钥的方法，其中指定个体的加密文件被使用该特定个体生成的公共密钥进行加密处理。公共密钥加密的文件只可以被对应于用于加密处理的公共密钥的秘密密钥来解密。只有生成公共密钥的个体才拥有秘密密钥，所以只有拥有秘密密钥的个体才能解密用公共密钥解密的文件。公共密钥加密方法的代表性方法是椭圆曲线加密，或者RSA(Rivest-Shamir-Adleman)加密。使用这样的加密方法使得在一个***中，只有授权用户才能够解密被加密的内容。
对于上述的内容或业务使用管理安排，存在用于确定是否为授权用户的已知方法，即，在提供已加密的数据如内容或业务信息等之前，或者在提供解密密钥之前，通过在提供内容或者业务的业务供应商与用户装置如PC、便携终端、存储卡等之间执行验证处理，确认用户是否为授权用户。在普通的验证处理中，确认另一方，并且生成仅对那个通信有效的会话密钥，并且在建立验证的情况下，利用所生成的会话密钥，通过加密内容数据或者解密密钥，执行通信。
发明内容
尽管存在执行用户权限确认的技术，即在提供业务的业务供应商与用户之间通过一对一地执行验证处理，如同上述的确认用户权限的***那样，来执行用户权限确认，但是考虑到在用户终端上可以执行的各种业务如内容提供业务、其它信息使用业务、付款业务的增加，人们希望开发一种能够以有效和安全方式执行各个用户或用户终端的业务使用权限的有/无的实施。
本发明是鉴于上述问题做出的，所以本发明的目的是提供数据处理***、数据处理装置、及其方法以及计算机程序，由此在执行数据通信所伴随的数据处理的数据处理***中，可以对正在进行通信的每个装置或者用户是否具有适当数据处理执行权限或者业务接收权限做出精确确定，从而实现准确无误的数据处理。
例如，本发明的目的是提供一种装置和方法，用于根据属性证书检查一个访问是否来来自被记录在将被访问的通信处理装置上的用户或者通信装置，并且仅允许来自具有访问权限的用户或者装置的访问，从而消除其它装置的访问。
本发明的第一方面是管理用户装置的业务接收权限的权限管理***；
其中作为业务接收实体的用户装置保存组属性证书，该组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；
其中，是业务供应实体的业务供应商具有一个配置，用于借助签名验证执行从用户装置展示的组属性证书是否存在篡改的验证，根据存储在该组属性证书中的组标识信息执行这是否是业务准许组的检查，并且根据该检查执行关于是否可以提供业务的确定。
此外，对于本发明的权限管理***的安排，组属性证书是在组属性证书发放实体与用户装置之间建立相互认证的条件下，向对应于装置或者用户的用户装置发放的证书，并且被发给证书的装置或者用户遵循业务供应商准许的发放策略。
此外，对于本发明的权限管理***的安排，新的组属性证书的发放处理是在组属性证书发放实体处建立关于用户装置已经持有的已经发放的组属性证书的验证的条件下，执行的配置的处理。
此外，对于本发明的权限管理***的安排，业务供应商的配置具有组信息数据库，其中组标识符和属于该组的成员的准许业务信息被相互关联，其中根据用户装置展示的组属性证书中所存储的组标识信息，搜索组信息数据库，执行关于是否可以提供业务的确定处理。
此外，对于本发明的权限管理***的安排，业务供应商具有一个配置，其中根据用户装置展示的多个不同的组定义，对于从多个组属性证书获得的不同组标识信息的多个集合的每一个执行关于是否为业务准许对象的检查，并且在所有组标识集合都是业务准许对象的条件下，执行关于是否可以提供业务的确定处理。
此外，对于本发明的权限管理***的安排，业务供应商具有一个配置，其中根据来自其中装置是组成员的用户装置的组定义，对于从第一组属性证书获得的第一组标识信息执行关于是否为业务准许对象的检查，并且根据来自其中装置是组成员的用户装置的组定义，对于从第二组属性证书获得的第二组标识信息执行关于是否为业务准许对象的检查，并且在所有组标识集合都是业务准许对象的条件下，执行关于是否可以提供业务的确定处理。
对于本发明的权限管理***的安排，用户装置具有一个配置，包括：作为执行与业务供应商通信的装置的终端实体，以及作为各个标识装置的用户标识装置；其中组属性证书被单独地发放给终端实体和用户标识装置的每一个，该发放处理是在组属性证书发放实体与终端实体或者用户标识装置之间已经建立相互认证的条件下执行的。
此外，本发明的权限管理***的安排具有一个配置，其中组属性证书是属性管理机构发放的属性证书，组标识符被存储在被归档于属性证书内的属性信息中。
此外，对于本发明的权限管理***的安排，组属性证书具有存储关于对应于组属性证书的公共密钥证书的链接信息的配置；其中业务供应商具有一个配置，其中在执行组属性证书的验证的时候还执行通过链接信息获得的公共密钥证书的验证。
此外，本发明的第二方面是一个信息处理装置，用于执行作为业务供应处理的数据处理，包括：
接收组属性证书的数据接收单元，该组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名，以作为应用于来自业务供应装置的业务使用权限确认处理的属性证书；
组属性证书验证处理单元，用于借助签名验证执行组属性证书是否存在篡改的验证，根据存储在该组属性证书中的组标识信息执行关于是否是业务准许组的检查，并且根据该检查执行关于是否可以提供业务的确定。
此外，本发明的信息处理装置的安排具有一个包括组信息数据库的配置，其中组标识符和属于该组的成员的准许业务信息被相互关联；其中组属性证书验证处理单元根据用户装置展示的组属性证书中所存储的组标识信息，搜索组信息数据库，并执行关于是否可以提供业务的确定处理。
此外，对于本发明的信息处理装置的安排，组属性证书验证处理单元具有一个配置，其中根据用户装置展示的多个不同的组定义，对于从多个组属性证书获得的不同组标识信息的多个集合的每一个执行关于是否为业务准许对象的检查，并且根据该检查执行关于是否可以提供业务的确定处理。
此外，本发明的第三方面是管理用户装置的业务接收权限的权限管理方法，包括：
在位于是业务接收实体的用户装置处的执行步骤，用于向是业务供应商实体的业务供应商发送组属性证书，该组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；以及
在业务供应商处的执行步骤，用于借助签名验证执行从用户装置展示的组属性证书是否存在篡改的验证，根据存储在组属性证书中的组标识信息执行关于是否是业务准许组的检查，并且根据该检查执行关于是否可以提供业务的确定。
此外，本发明的权限管理方法的安排还包括组属性证书发放处理步骤，用于向对应于装置或用户的用户装置发放组属性证书；其中组属性证书发放处理步骤是，在组属性证书发放实体与用户装置之间建立相互认证的条件下，向对应于装置或者用户的用户装置发放组属性证书的处理步骤，并且被发给证书的装置或者用户遵循业务供应商准许的发放策略。
此外，对于本发明的权限管理方法的安排，组属性证书发放步骤包括关于用户装置已经持有的已经发放的组属性证书的验证处理步骤，其中在建立验证的条件下执行组属性证书的发放。
此外，对于本发明的权限管理方法的安排，业务供应商的配置具有组信息数据库，其中组标识符和属于该组的成员的准许业务信息被相互关联，其中根据用户装置展示的组属性证书中所存储的组标识信息，搜索组信息数据库，并执行关于是否可以提供业务的确定处理。
此外，对于本发明的权限管理方法的安排，业务供应商具有一个配置，其中根据用户装置展示的多个不同的组定义，对于从多个组属性证书获得的不同组标识信息的多个集合的每一个执行关于是否为业务准许对象的检查，并且在所有组标识集合都是业务准许对象的条件下，执行关于是否可以提供业务的确定处理。
此外，对于本发明的权限管理方法的安排，在业务供应商处，根据来自其中装置是组成员的用户装置的组定义，对于从第一组属性证书获得的第一组标识信息执行关于是否为业务准许对象的检查，并且根据来自其中装置是组成员的用户装置的组定义，对于从第二组属性证书获得的第二组标识信息执行关于是否为业务准许对象的检查，并且在所有组标识集合都是业务准许对象的条件下，执行关于是否可以提供业务的确定处理。
此外，对于本发明的权限管理方法的安排，组属性证书具有存储关于与组属性证书对应的公共密钥证书的链接信息的配置；并且业务供应商具有一个配置，其中在执行组属性证书的验证的时候还执行通过链接信息获得的公共密钥证书的验证。
此外，本发明的第四方面是信息处理装置的信息处理方法，用于执行作为业务供应处理的数据处理，该方法包括：
从业务供应装置接收组属性证书的证书接收步骤，所述组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名以作为应用于业务使用权限确认处理的属性证书；以及
组属性证书验证处理步骤，借助组属性证书的签名验证执行关于是否存在篡改的验证，并且根据存储在组属性证书中的组标识信息执行关于是否是业务准许组的检查，以及根据该检查执行关于是否可以提供业务的确定。
此外，对于本发明的信息处理方法的安排，信息处理装置还包括组信息数据库，其中组标识符和属于该组的成员的准许业务信息被相互关联；其中组属性证书验证处理步骤包括根据用户装置展示的组属性证书中所存储的组标识信息，搜索组信息数据库的步骤，并执行关于是否可以提供业务的确定处理。
此外，对于本发明的信息处理方法的安排，组属性证书验证处理步骤包括执行检查的步骤，即根据用户装置展示的多个不同的组定义，对于从多个组属性证书获得的不同组标识信息的多个集合的每一个执行关于是否为业务准许对象的检查的步骤，并且在所有组标识集合都是业务准许对象的条件下，执行关于是否可以提供业务的确定处理。
此外，本发明的第五方面是实现管理用户装置的业务接收权限的权限管理处理的执行的计算机程序，该程序包括：
从业务供应装置接收组属性证书的证书接收步骤，所述组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名以作为应用于业务使用权限确认处理的属性证书；以及
组属性证书验证处理步骤，借助组属性证书的签名签证，执行关于是否存在篡改的验证，并且根据存储在组属性证书中的组标识信息执行关于是否是业务准许组的检查，以及根据该检查执行关于是否可以提供业务的确定。
此外，本发明的第六方面是一种访问权限管理***，用于在具有通信功能的通信装置之间执行访问限制；
其中访问请求装置在存储装置中存储一个组属性证书，所述组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；
其中来自访问请求装置的访问请求对象的被访问请求的装置，借助访问请求装置展示的组属性证书的签名验证，执行关于是否存在篡改的验证，并且根据存储在组属性证书中的组标识信息执行关于访问请求装置是否是属于访问准许组的装置的检查，以及根据该检查执行关于是否准许访问的确定。
此外，对于本发明的访问权限管理***的安排，被访问请求的装置具有一个执行检查的配置，用于根据发放给是构成访问请求装置的访问执行装置的终端实体的组属性证书，检查访问请求装置是否为属于访问准许组的终端实体，并根据该检查确定是否准许访问。
此外，对于本发明的访问权限管理***，被访问请求的装置具有一个执行检查的配置，用于根据发放给是构成访问请求装置的个体标识装置的用户标识装置的组属性证书，检查访问请求装置是否为属于访问准许组的用户所拥有的装置，并根据该检查确定是否准许访问。
此外，本发明的访问权限管理***的安排具有一个配置，其中访问请求装置和被访问请求的装置具有安全芯片，该芯片具有反篡改配置，由此在相互的安全芯片之间执行相互认证，其中，在建立互认证的条件下，被访问请求的装置执行访问请求装置所展示的组属性证书的签名验证，以及该装置是否属于访问准许组的检查。
此外，本发明的访问权限管理***具有一个配置，其中被访问请求的装置从一个装置接收证明该装置是访问准许组成员的组属性证书的发放请求；以及在装置之间的相互认证已经被建立以及组属性证书发放请求装置正在遵循由被访问请求的装置准许的发放策略的条件下，向对应于装置或者用户的装置发放组属性证书，以证明该装置是访问准许组成员。
此外，本发明的访问权限管理***的安排具有一个配置，其中被访问请求的装置从一个装置接收证明该装置是访问准许组成员的组属性证书的发放请求；以及在装置间的相互认证已经被建立，以及对于由组属性证书发放请求装置已经拥有的、已经发放的组属性证书建立了验证和检查的条件下，向对应于装置或者用户的装置发放组属性证书，以证明该装置是访问准许组成员。
此外，对于本发明的访问权限管理***的安排，组属性证书具有存储关于对应于组属性证书的公共密钥证书的链接信息的配置；访问请求装置具有一个配置，其中在执行组属性证书验证的时候还执行对通过链接信息获得的公共密钥证书的验证。
此外，本发明的第七方面是执行访问限制处理的通信处理装置，包括：
接收单元，用于从访问请求装置接收组属性证书，所述组属性证书具有作为被存储信息的、对应于某些通信装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；以及
访问权限确定处理单元，用于执行组属性证书验证处理功能，它借助从访问请求装置接收的组属性证书的签名验证执行关于是否存在篡改的验证，并根据存储在组属性证书中的组标识信息执行访问请求装置是否为属于访问准许组的装置的检查，并且根据该检查确定是否准许访问。
此外，对于本发明的通信处理装置的安排，访问权限确定处理单元具有执行检查的配置，根据发放给作为在访问请求装置上的访问执行装置的终端实体的组属性证书，执行关于访问请求装置是否为属于访问准许组的终端实体的检查，并且根据所述检查确定是否准许访问。
此外，对于本发明的通信处理装置的安排，访问权限确定处理单元具有执行检查的配置，根据被发放给是构成所述访问请求装置的个体标识装置的用户标识装置的组属性证书，执行所述访问请求装置是否为属于访问准许组的用户所拥有的装置的检查，并且根据所述检查，执行关于是否可准许访问的确定。
此外，本发明的通信处理装置的安排包括与访问请求装置执行相互认证的加密处理单元；其中，访问权限确定处理单元具有一个配置，用于在已经建立相互认证的条件下，对访问请求装置展示的组属性证书执行签名验证，并且检查该装置是否属于访问准许组。
此外，本发明的通信处理装置的安排还包括：一个用于生成组属性证书的属性证书生成单元，所述组属性证书具有作为被存储的信息的、对应于某些通信装置或者某些用户的集合的组的组标识信息，并且附有发放者的电子签名。
此外，对于本发明的通信处理装置的安排，组属性证书具有存储关于对应于组属性证书的公共密钥证书的链接信息的配置；访问权限确定处理单元具有一个配置，其中在执行组属性证书验证的时候还执行对通过链接信息获得的公共密钥证书的验证。
此外，本发明的第八方面是在具有通信功能的通信装置之间执行访问限制的访问权限管理方法，该方法包括：
访问请求装置向作为访问请求对象的被访问请求的装置发送组属性证书的步骤，所述组属性证书具有作为存储信息的、对应于某些通信装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；
被访问请求的装置接收由访问请求装置展示的组属性证书的步骤；
检查步骤，借助访问请求装置展示的组属性证书的签名验证，执行关于是否存在篡改的验证，并且根据存储在组属性证书中的组标识信息执行关于访问请求装置是否是属于访问准许组的装置的检查；以及
根据该检查步骤的检查结果，执行关于是否可以准许访问的确定的步骤。
此外，对于本发明的访问权限管理方法的安排，被访问请求的装置根据发放给在访问请求装置上的访问执行装置的终端实体的组属性证书，检查访问请求装置是否为属于访问准许组的终端实体，并根据该检查确定是否准许访问。
此外，对于本发明的访问权限管理方法的安排，被访问请求的装置根据发放给在访问请求装置上的个体标识装置的用户标识装置的组属性证书，检查访问请求装置是否为属于访问准许组的用户所拥有的装置，并根据该检查确定是否准许访问。
此外，本发明的访问权限管理方法的安排还包括：在访问请求装置和被访问请求的装置的具有反篡改配置的安全芯片之间的相互认证执行步骤；其中，在建立相互认证的条件下，被访问请求的装置执行访问请求装置所展示的组属性证书的签名验证，以及检查该装置是否属于访问准许组。
此外，本发明的访问权限管理方法还包括：被访问请求的装置从一个装置接收证明该装置是访问准许组成员的组属性证书的发放请求的步骤；以及在已经建立装置间的相互认证以及组属性证书发放请求装置正在遵循由被访问请求的装置准许的发放策略的条件下，向对应于装置或者用户的装置发放组属性证书的步骤。
此外，本发明的访问权限管理方法的安排还包括，在已经建立装置间的相互认证，以及对于由组属性证书发放请求装置已经拥有的已经发放的组属性证书建立了验证和检查的条件下，执行向对应于装置或者用户的装置发放组属性证书，以证明该装置是访问准许组成员的处理的步骤，以作为被访问请求的装置响应来自一个装置的证明该装置是访问准许组成员的组属性证书的发放请求的执行步骤。
此外，对于本发明的访问权限管理方法的安排，组属性证书具有存储关于对应于组属性证书的公共密钥证书的链接信息的配置；访问请求装置具有一个配置，其中在执行组属性证书验证的时候还执行对通过链接信息获得的公共密钥证书的验证。
此外，本发明的第九方面是用于执行访问限制处理的通信处理装置的通信管理方法，该方法包括：
接收步骤，用于从访问请求装置接收组属性证书，所述组属性证书具有作为被存储信息的、对应于某些通信装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；以及
访问权限确定处理步骤，用于借助从访问请求装置接收的组属性证书的签名验证执行关于是否存在篡改的验证，并根据存储在组属性证书中的组标识信息执行访问请求装置是否为属于访问准许组的装置的检查；以及
访问准许/不准许确定步骤，根据访问权限确定处理结果，确定是否能够准许访问。
此外，对于本发明的通信管理方法的安排，访问权限确定处理步骤包括执行检查的步骤，根据发放给在访问请求装置中的访问执行装置的终端实体的组属性证书，检查访问请求装置是否为属于访问准许组的终端实体。
此外，对于本发明的通信管理方法的安排，访问权限确定处理步骤包括：根据发放给是构成访问请求装置的个体标识装置的用户标识装置的组属性证书，检查访问请求装置是否为属于访问准许组的用户所拥有的装置的步骤。
此外，本发明的通信管理方法的安排还包括执行与访问请求装置相互认证的认证处理步骤；其中，在访问权限确定处理步骤中，在建立了相互认证条件下，执行对访问请求装置展示的组属性证书的签名验证，并且检查所述装置是否属于访问准许组。
此外，对于本发明的通信管理方法的安排，组属性证书具有存储关于对应于组属性证书的公共密钥证书的链接信息的配置；并且，在访问权限确定处理步骤中，在执行组属性证书验证的时候还执行对通过链接信息获得的公共密钥证书的验证。
此外，本发明的第十方面是对于执行访问限制处理的通信处理装置实现通信管理方法的执行的计算机程序，该程序包括：
接收步骤，用于从访问请求装置接收组属性证书，所述组属性证书具有作为被存储信息的、对应于某些通信装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；以及
访问权限确定处理步骤，用于借助从访问请求装置接收的组属性证书的签名验证执行关于是否存在篡改的验证，并根据存储在组属性证书中的组标识信息执行访问请求装置是否为属于访问准许组的装置的检查；以及
访问准许/不准许确定步骤，根据访问权限确定处理结果，确定是否能够准许访问。
此外，本发明的第十一方面是一种数据处理***，在多个能够相互通信的装置之间执行伴随数据通信处理的数据处理，其中在多个所述装置之中，向与其进行通信的其它装置请求数据处理的数据处理请求装置持有组属性证书，所述组属性证书具有作为被存储信息的、对应于某些通信装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名，并且所述数据处理请求装置在数据处理请求处理的时候，向数据处理被请求装置发送组属性证书；
并且其中数据处理被请求装置执行被接收的组属性证书的验证处理，根据该验证确定数据处理请求装置是否具有数据处理请求权限，并且根据权限的确定执行数据处理。
此外，对于本发明的数据处理***的安排，存储在数据处理请求装置中的组属性证书把数据处理被请求装置作为其发放者，并且附有数据处理被请求装置的电子签名；其中，数据处理被请求装置具有应用自己的公共密钥执行电子签名验证处理的配置，所述电子签名验证处理作为所接收的组属性证书的验证处理。
此外，对于本发明的数据处理***的安排，所有的多个可相互通信的装置都是相互请求与其正在通信的其它装置的数据处理的装置，每个这样的装置都具有存储由通信对象装置发放的组属性证书的配置，并且在与其正在通信的其它装置的数据处理请求的时候，发送自己存储的组属性证书，并且在接收装置建立的验证的条件下，相互执行对应于数据处理请求的处理。
此外，对于本发明的数据处理***的安排，所有的多个可相互通信的装置都具有带反篡改配置的安全芯片，在与其正在通信的其它装置的数据处理请求的时候，在相互的安全芯片(mutual security ship)之间执行相互认证，其中，在建立相互认证的条件下，执行在装置之间的组属性证书的发送，以及执行被发送的组属性证书的验证。
此外，对于本发明的数据处理***的安排，存储在数据处理请求装置中的组属性证书把数据处理被请求装置作为其发放者；并且在数据处理请求装置与数据处理被请求装置之间建立相互认证的条件下，执行发放处理。
此外，对于本发明的数据处理***的安排，在互通信的多个装置之中，至少一个或多个装置包括：作为装置配置的一个终端实体，用于执行与其它装置的通信处理以及数据处理；一个用户标识装置，具有能够与终端实体交换数据的个体标识功能；并且在组属性证书被发放到构成某个用户组的成员的情况下，在用户标识装置与组属性证书发放处理执行装置之间建立相互认证的条件下，执行发放处理。
此外，对于本发明的数据处理***的安排，在互通信的多个装置之中，一个装置是执行诸多装置的维护处理的维护执行装置，而其它装置是接收来自维护执行装置的维护业务的业务接收装置；其中，业务接收装置存储业务属性证书，该业务属性证书是由维护执行装置发放的组属性证书；维护执行装置存储控制属性证书，该控制属性证书是由业务接收装置发放的组属性证书；业务属性证书适用于在维护执行装置上验证业务接收装置属于具有维护业务接收权限的一组装置或用户；并且，控制属性证书适用于在业务接收装置上验证维护执行装置属于具有维护业务执行权限的一组装置或用户。
此外，对于本发明的数据处理***的安排，业务接收装置上执行的维护程序被发送给业务接收装置或存储到业务接收装置作为加密维护程序；并且业务接收装置具有一个解密的配置，对具有反篡改配置的安全芯片内的加密维护程序进行解密，然后在业务接收装置上运行该程序。
此外，对于本发明的数据处理***的安排，根据从维护执行装置发送到业务接收装置的命令执行在业务接收装置上执行的维护处理；并且业务接收装置向维护执行装置发送关于命令的执行结果的答复，并且维护执行装置根据所发送的答复向业务接收装置发送新命令。
此外，本发明的第十二方面是一种根据来自数据处理请求装置的数据处理请求执行数据处理的数据处理装置，该数据处理装置包括：
数据接收单元，用于从数据处理请求装置接收组属性证书，所述组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；
权限确定处理单元，用于执行被接收组属性证书的验证处理，根据该验证确定数据处理请求装置是否具有数据处理请求权限；和
数据处理单元，用于根据权限的确定执行数据处理。
此外，对于本发明的数据处理装置的安排，权限确定处理单元具有应用自己的公共密钥执行电子签名验证处理的配置，该电子签名验证处理作为被接收的组属性验证的验证处理。
此外，对于本发明的数据处理装置的安排，数据处理装置具有一个安全芯片，该安全芯片带有反篡改配置并且包括一个加密处理单元；以及加密处理单元具有一个配置，其中响应来自数据处理请求装置的数据处理请求，与数据处理请求装置一起执行相互认证；其中，权限确定处理单元具有一个在建立了相互认证的条件下执行组属性证书的验证的配置。
此外，对于本发明的数据处理装置的安排，数据处理装置具有包括属性证书生成处理单元的配置，该单元具有生成组属性证书的功能，所述组属性证书具有作为被存储信息的、对应于某些装置或某些用户的集合的组的组标识信息，并且还附有电子签名。
此外，本发明的第十三方面是一种数据处理方法，用于执行在多个能够相互通信的装置之间执行伴随数据通信处理的数据处理，其中在多个所述装置之中，向与其进行通信的其它装置请求数据处理的数据处理请求装置，执行在数据处理请求处理的时候向正在进行通信的其它装置发送组属性证书的发送步骤，所述组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；
其中，数据处理被请求装置执行：
用于被接收的组属性证书的验证处理步骤；
根据该验证，确定数据处理请求装置是否具有数据处理请求权限的步骤；和
根据权限的确定执行数据处理的步骤。
此外，对于本发明的数据处理方法的安排，数据处理请求装置中存储的组属性证书把数据处理被请求装置作为其发放者，并且还附有数据处理被请求装置的电子签名；并且，在数据处理被请求装置上的验证处理步骤中，应用自己的公共密钥执行电子签名验证处理，以作为被接收的组属性证书的验证处理。
此外，对于本发明的数据处理方法的安排，所有可相互通信的多个装置都是相互请求与其进行通信的其它装置的数据处理的装置，并且每个装置具有一个配置，用于存储由通信对方装置发放的组属性证书，并且在正在实施通信的其它装置的数据处理请求的时候，发送自身存储的组属性证书，以及在接收装置上建立的验证条件下，相互执行对应于数据处理请求的处理。
此外，对于本发明的数据处理方法的安排，所有相互通信的多个装置都有具有反篡改配置的安全芯片，由此在与其进行通信的其它装置的数据处理请求的时候，在相互的安全芯片之间执行相互认证，并且在建立相互认证的条件下，执行装置之间的组属性证书的传送以及被传送的组属性证书的验证。
此外，本发明的数据处理方法的安排还包括：用于在数据处理请求装置中存储的组属性证书的发放处理步骤；在数据处理请求装置与数据处理被请求装置之间已经建立相互认证的条件下，执行发放处理步骤。
此外，本发明的数据处理方法的安排还包括：用于在数据处理请求装置中存储的组属性证书的发放处理步骤；其中，在向构成某个用户组的成员发放组属性证书的情况中，在与由数据处理请求装置构成的具有个体标识功能的用户标识装置建立相互认证的条件下，执行发放处理步骤。
此外，对于本发明的数据处理方法的安排，在互通信的多个装置之中，一个装置是执行装置的维护处理的维护执行装置，而其中其它装置是从维护执行装置接收维护业务的业务接收装置，该方法包括：业务接收装置向维护执行装置发送业务属性证书的步骤，所述业务属性证书是由维护执行装置发放的组属性证书；维护执行装置执行被接收的业务属性证书的验证的业务属性证书验证步骤；维护执行装置向业务接收装置发送控制属性证书的步骤，所述控制属性证书是业务接收装置发放的组属性证书；业务接收装置执行控制属性证书的验证的控制属性证书验证步骤；以及在已经建立业务属性证书验证和控制属性证书验证的条件下，执行维护处理的维护处理步骤。
此外，对于本发明的数据处理方法的安排，业务接收装置上执行的维护程序被发送到或者被存储在业务接收装置中，以作为被加密的维护程序；业务接收装置具有一个配置，用于解密具有反窜改配置的安全芯片之内的被加密维护程序，然后在业务接收装置上执行该程序。
此外，对于本发明的数据处理方法的安排，根据从维护执行装置发送到业务接收装置的命令，执行在业务接收装置上执行的维护处理；业务接收装置向维护执行装置发送关于命令的执行结果的答复，并且维护执行装置根据所发送的答复向业务接收装置发送新命令。
此外，本发明的第十四方面是根据来自数据处理请求装置的数据处理请求，执行数据处理的数据处理方法，该方法包括：
从数据处理请求装置接收组属性证书的数据接收步骤，所述组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且附有发放者的电子签名；
权限确定处理步骤，用于执行被接收的组属性证书的验证处理，并根据验证，确定数据处理请求装置是否具有数据处理请求权限；
数据处理步骤，用于根据权限确定，执行数据处理。
此外，对于本发明的数据处理方法的安排，权限确定处理步骤包括应用自己的公共密钥执行电子签名验证处理的步骤，作为被接收的组属性证书的验证处理。
此外，本发明的数据处理方法的安排还包括：响应来自数据处理请求装置的数据处理请求，执行与数据处理请求装置的相互认证的步骤；并且在已经建立相互认证的条件下，执行组属性证书的验证的权限确定处理步骤。
此外，本发明的第十五方面是根据来自数据处理请求装置的数据处理请求，实施数据处理的执行的计算机程序，该程序包括：
从数据处理请求装置接收组属性证书的数据接收步骤，所述组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且附有发放者的电子签名；
权限确定处理步骤，用于执行被接收的组属性证书的验证处理，并根据验证，确定数据处理请求装置是否具有数据处理请求权限；
数据处理步骤，用于根据权限确定，执行数据处理。
根据本发明的配置，向业务接收实体发放具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且附有发放者的电子签名的组属性证书，并且借助用户装置展示的组属性证书的签名验证，执行关于是否存在篡改的验证，根据组属性证书中存储的组标识信息，执行关于是否是业务准许组的检查，以及根据该检查确定是否能够提供业务；因此可以进行对应于各个用户集合或者装置集合的集中式权限确认，所以可以省略个体权限信息的管理，从而能够实现有效权限管理。
此外，根据本发明的配置，应用其中组标识符和属于该组的成员的准许业务信息被相互关联的组信息数据库，能够实现是否能够提供业务的确定处理，从而能够实现每组的设置权限的具体区别。
此外，根据本发明的配置，基于用户装置展示的多个不同组定义，对于从多个组属性证书获得的不同组标识信息的多个集合的每个集合，执行关于是否为业务准许对象的检查，并且在所述组标识集合都是业务准许对象的条件下，可以执行关于是否能够提供业务的确定处理，从而能够实现权限设置的各种安排，比如基于多个条件如对应于装置组集合和用户的组集合等提供业务。
此外，根据本发明的配置，基于存储在组属性证书中的组属性信息，执行访问请求装置是否为属于访问准许组的装置的检查，并且根据该检查做出是否准许访问的确定，从而只允许对访问请求通信处理装置组进行访问，其中所述组属性证书具有作为被存储信息的、对应于某些通信装置或某些用户的集合的组的组标识信息，并附有发放者的电子签名，所述访问请求通信处理装置组是由具有通信处理装置的用户任意设置的组的成员的用户或用户装置。
此外，根据本发明的配置，基于向构成访问请求装置的个体标识装置的用户标识装置发放的组属性证书，执行关于访问请求装置是否为属于访问准许组的用户所拥有的装置的检查，并且基于该检查，做出是否能够准许访问的确定，所以即使在通信处理装置已经被改变的情况下，也能够在检查中根据发放给个体标识装置的用户标识装置的组属性证书来准许访问，并且可以避免由于通信装置的改变而禁止访问的情况。
此外，根据本发明的配置，向与其进行通信的其它装置请求数据处理的数据处理请求装置把组属性证书(具有作为被存储信息的、对应于某些通信装置或某些用户的集合的组的组标识信息，并附有发放者的电子签名)发送给数据处理被请求装置，在数据处理被请求装置上执行被接收的组属性证书的验证处理，根据验证做出数据处理请求装置是否具有数据处理请求权限的确定，并且根据权限的确定执行数据处理，所以避免了由错误的装置或用户执行处理的情况，并且执行基于有效权限的适当数据处理。
此外，根据本发明的配置，利用多个数据处理装置请求正在进行通信的其它装置的数据处理从而协作执行数据的安排，使每个装置在与其进行通信的其它装置的数据处理请求的时候，发送自身存储的组属性证书；并且在接收装置建立的验证条件下，相互地执行相应于数据处理请求的处理，因而能够实现多个数据处理装置之间的伴随通信的合适的协作数据处理。
此外，根据本发明的配置，维护执行装置和维护业务接收装置分别存储控制属性证书和业务属性证书，由此在执行维护业务的时候交换属性证书，并在每个装置上相互认证和检查，其中在已经建立验证的条件下，执行维护处理，所以可以在每个集合权限范围之内以确定的方式实现维护处理。
需要注意的是，本发明的计算机程序是可以提供给能够执行各种计算机代码的计算机***的程序码，例如通过存储媒介或者通信媒介提供计算机可读格式的程序码，存储媒介比如是CD、FD、MO或类似物，通信媒介比如是网络或类似物。提供这样的计算机可读格式的程序能够在计算机***上实现对应于程序的处理。
从基于在下面描述的本发明实施例以及附图的详细说明中，将会使本发明的其它目的、特征和优点变得清楚。请注意，本说明书中的术语“***”是指多个装置的逻辑组配置，不局限于位于单个外壳内的组件装置。
附图说明
图1是说明权限管理***中的公共密钥基础结构和权限管理基础结构的示意图；
图2是图示公共密钥证书的格式的示意图；
图3是图示公共密钥证书的格式的示意图；
图4是图示公共密钥证书的格式的示意图；
图5是图示作为权限信息证书的属性证书的格式的示意图；
图6是图示组属性证书(组AC)的发放者、持有者、验证者和属性信息的配置实例的示意图；
图7是图示组属性证书的发放策略表的示意图；
图8是图示信托(trust)模型的示意图，用于说明并入权限管理***中的实体的信托关系配置；
图9是图示在作为用户装置的终端实体(EE)和用户标识装置(UID)上配置的安全芯片的配置实例的示意图；
图10是图示用户装置的安全芯片的被存储数据的实例的示意图；
图11是说明组属性证书的发放申请、发放处理和使用处理的示意性流程的示意图；
图12是说明业务供应商(SP)与属性管理机构(AA)或者属性登记管理机构(ARA)之间组信息共享处理的示意图；
图13是图示握手协议(TLS1.0)的示意图，该握手协议(TLS1.0)是公共密钥加密方法的一个验证方法；
图14是图示MAC(消息验证码)生成配置的示意图；
图15是图示发放策略表和组信息数据库的信息配置实例的示意图；
图16是图示在作为用户装置的终端实体(EE)的安全芯片(SC)是组属性证书的发放请求实体情况下的处理顺序的示意图；
图17是说明生成电子签名的处理的流程图；
图18是说明验证电子签名的处理的流程图；
图19是说明发放对应于用户标识装置(UID)内的用户安全芯片(USC)的组属性证书的过程的顺序图；
图20是说明利用组属性证书开始业务使用权限配置的处理的顺序图；
图21是说明公共密钥证书(PCK)与属性证书(AC)之间的关系的示意图；
图22是图示属性证书(AC)的验证处理流程的示意图；
图23是图示公共密钥证书(PKC)的验证处理流程的示意图；
图24是说明利用组属性证书开始包括业务使用权限确认的业务的处理的顺序图；
图25是说明组属性证书(Gp.AC)的检查处理的顺序图；
图26是说明属于多个不同组的用户或者用户装置是提供业务的条件的情况的概念的示意图；
图27是说明基于对应于用户标识装置(UID)内的用户安全芯片(USC)发放的组属性证书的提供业务的处理的顺序图；
图28是说明基于对应于用户标识装置(UID)内的用户安全芯片(USC)发放的组属性证书的提供业务的处理的顺序图；
图29是说明在用户装置之间发放组属性证书并存储组属性证书的处理的顺序图；
图30是说明发放具有作为属性的访问准许信息的组属性证书的处理顺序的示意图；
图31是说明具有作为组信息的访问准许信息的组属性证书与另一个组属性证书之间相互关系的实例的示意图；
图32是说明被访问请求的用户装置不自己执行属性证书发放处理，而是把属性证书发放处理委托给另一个用户装置的处理顺序的示意图；
图33是说明利用把访问准许信息定义为组信息的组属性证书的伴随访问准许/不准许确定处理的业务使用顺序的示意图；
图34是图示用于业务的组属性证书的实例的示意图；
图35是说明根据第一组属性证书A发放包含作为组信息的内容使用准许信息的第二组属性证书B的处理的顺序图；
图36是说明把第二组属性证书B展示给业务供应商、确认内容试用权限、以及接收业务的供应即内容分配业务的处理的顺序图；
图37是说明应用于处理的属性证书的实例的示意图，其中应用多个不同属性证书以确认用户或用户装置的内容使用权限，并且提供业务；
图38是说明应用不同的组属性证书的内容使用权限确认以及业务供应处理的流程图；
图39是图示作为业务供应条件的组属性证书的组合表数据配置实例的示意图；
图40是应用多个组属性证书的使用权限确认处理的示意图；
图41是图示应用于医学处理的组属性证书的实例的示意图；
图42是说明执行医学处理的远程控制***中的各个装置中存储的属性证书的示意图；
图43是说明执行医学诊断程序执行业务的使用权限确认处理、应用用户标识装置中存储的组属性证书以及启动业务的处理顺序的示意图；
图44是说明执行用于医学诊断程序的执行结果的诊断数据处置处理业务的使用权限确认处理、应用组属性证书以及启动业务的处理顺序的示意图；
图45是图示应用于远程维护处理的组属性证书的示意图；
图46是说明执行维护业务的***中的每个装置中存储的属性证书的示意图；
图47是说明执行业务的时候业务属性证书和控制属性证书的使用安排的示意图；
图48是说明如维护等处理的业务处理、应用家用电器(EE)中存储的业务属性证书以及业务供应商中存储的控制属性证书的顺序图；
图49是说明业务属性证书的检查处理的示意图；
图50是说明基于控制属性证书的业务，例如用于家用电器的执行维护处理的顺序的示意图；
图51是说明从维护侧装置(SP)向用户侧家用电器(EE)发送维护执行程序的处理的实例的示意图；
图52是说明从制造商侧装置(SP)向用户侧家用电器(EE)连续地发送来自维护执行程序的命令、从家用电器(EE)接收基于命令执行的答复以及响应所述答复的处理实例的示意图；
图53是说明在请求业务供应的时候，向制造商侧(SP)提供业务属性证书和控制属性证书的处理实例的示意图；
图54是说明应用于通信业务的组属性证书的实例的示意图；
图55是说明适用于通信业务的组属性证书的存储配置实例的示意图；
图56是说明应用组属性证书执行聊天室参与业务的使用权限确认处理并启动该业务的处理顺序的示意图；
图57是说明应用组属性证书执行访问权限确认处理并启动通信的处理顺序的示意图；
图58是说明执行属性证书的概况的示意图；
图59是说明执行属性证书的使用过程的概况的流程图；
图60是说明用于执行属性证书的发放顺序的示意图；
图61是说明用于执行属性证书的发放顺序的示意图；
图62是图示执行AC表的配置实例的示意图；
图63是在安全模块(SM)上生成登记密钥生成执行AC的处理的示意图；
图64是说明基于安全芯片上执行的登记密钥生成执行AC，生成登记密钥的处理的示意图；
图65是在安全模块(SM)上生成业务供应执行AC的处理的示意图；
图66是显示用户装置侧的业务供应执行AC的应用顺序的示意图；
图67是说明安全芯片(SC)上的业务供应处理的处理细节的示意图；
图68是说明安全芯片(SC)登记密钥毁坏处理的示意图；
图69是说明是基于复位请求的登记密钥的毁坏处理的复位处理的示意图；
图70是说明执行属性证书复位(毁坏)处理的示意图，其中在业务供应商(SP)确认的条件下破坏执行属性证书，并且把毁坏被成功地执行通知给业务供应商；
图71是说明执行属性证书复位(毁坏)处理的示意图，其中在业务供应商(SP)确认的条件下破坏执行属性证书，并且把毁坏被成功地执行通知给业务供应商；
图72是说明复位确认结果生成处理的细节的示意图；
图73是说明基于执行AC的登记密钥毁坏处理的示意图；
图74是说明在用户装置上，利用次数限制应用业务、应用业务供应执行属性证书的处理的示意图；
图75是说明在用户装置上，利用次数限制应用业务、应用业务供应执行属性证书的处理的示意图；
图76是说明在遵从更新的使用次数≥1的情况下，安全芯片(SC)上的处理的示意图；
图77是说明在遵从更新的使用次数＝1的情况下，安全芯片(SC)上的处理的示意图；
图78是应用具有转让功能的业务供应执行属性证书的处理的示意图；
图79是遵从具有转让功能的业务供应执行属性证书的解密处理的处理细节的示意图；
图80是说明具有转让功能的业务供应执行属性证书的解密处理的处理细节的示意图；
图81是说明已加密数据解密处理、应用具有转让功能的业务供应执行属性证书的示意图；
图82是说明检查代理执行属性证书的概况的示意图；
图83是说明应用检查代理执行属性证书的处理的示意图；
图84是说明生成和发放检查代理组属性证书的处理的示意图；
图85是说明输入检查代理执行属性证书并生成检查代理组属性证书的处理的示意图；
图86是说明代签名执行属性证书的概况的示意图；
图87是说明应用代签名执行属性证书的处理的示意图；
图88是说明在显示来自如业务供应商(SP)等的验证者的代签名组属性证书的请求的时候执行的处理的示意图；
图89是图示如用户装置、业务供应商等的实体的信息处理装置的配置实例的示意图。
具体实施方式
下文是参照附图的本发明的详细说明。请注意，下面的说明将按照下述的条目的顺序进行。
(1)权限管理***配置概述
(2)用户装置配置
(3)组属性证书发放和使用处理
(3-1)发放组属性证书的预备处理
(3-2)组属性证书发放处理
(3-3)组属性证书使用处理
(4)用户装置之间的组属性证书的发放和使用处理
(5)组属性证书的特定使用实例
(5-1)内容分配业务
(5-2)远程控制业务
(5-3)远程维护业务
(5-4)个人通信业务
(6)执行属性证书(执行AC)
(6-1)执行属性证书概述
(6-2)执行属性证书发放处理
(6-3)执行属性证书应用处理
(6-4)登记密钥请求处理
(6-5)执行属性证书复位(毁坏)处理
(7)执行属性证书的特定使用处理
(7-1)具有次数限制的业务供应执行属性证书
(7-2)具有转让的业务供应执行属性证书
(7-3)代理执行属性证书
(8)实体的配置
(1)权限管理***配置概述
如图1所示，本发明的权限管理***具有作为基础结构的基于公共密钥证书(PKC)121的公共密钥基础结构(PKI)101，以及基于属性证书(AC)122的权限管理基础结构(PMI)102，并且具有在带反篡改安全芯片(或安全模块)的用户装置111和113与业务供应商侧的业务供应商装置112之间执行的权限确认处理，或者在相互的用户装置111与113之间执行的权限确认处理的配置，并且根据权限确认执行业务供应处理。
用户装置111和113是用户的终端，用于接收来自业务供应商112的诸如音乐、图像、程序等的各种类型的内容提供业务，以及其它信息使用业务和付款业务等，特别是例如用户装置111和113是PC、游戏终端、DVD或CD的重现装置、便携通信终端PDA、存储器卡等。
此外，用户装置111和113是能够在用户装置之间进行互通信处理的终端，并且根据权限确认执行关于是否能够对用户装置进行访问的处理。用户装置设有具有反篡改配置的安全芯片。稍后将说明用户装置的细节。
业务供应商112是执行向具有安全芯片的用户装置111和113提供各种业务的业务供应商，所述各种业务比如内容供应、付款处理等。尽管图1仅仅显示了两个用户装置和一个业务供应商，但是在公共密钥基础结构(PKI)101和权限管理基础结构(PMI)的基础结构下，可以存在大量的用户装置和业务供应商，其中的每一个都根据权限确认执行业务供应。请注意，不仅业务供应商向用户装置提供业务，而且还在用户装置之间相互提供业务。
(公共密钥证书：PKC)
下面将说明公共密钥基础结构。公共密钥基础结构(PKI)101是能够应用公共密钥证书(PKC)执行通信实体之间的验证处理、传递数据的加密处理等的基础结构。下面将参照图2、图3和图4对公共密钥证书(PKC)进行说明。公共密钥证书是证明管理机构(CA)发放的证书，并且是向证明管理机构展示自己的ID、公共密钥等的用户或者实体创建的证书，并且证明管理机构方添加证明管理机构的ID、有效期限等，并且还附加证明管理机构的签名。
现在，提供作为证明管理机构(CA)的代理的登记管理机构(RA)已经成为普通的事情，利用接受公共密钥证书(PKC)发放申请的配置，在登记管理机构(RA)检查请求者并执行管理。
图2至图4显示了公共密钥证书格式的实例。这是顺从公共密钥证书格式ITU-TX.509的实例。
版本指示证书格式的版本。
序号是由公共密钥证书的证明管理机构(CA)设置的公共密钥证书的序号。
签名是证书的签名算法。请注意，这里存在用于签名算法的椭圆曲线加密和RSA，并且在应用椭圆曲线加密的情况下，记录参数和密钥长度；并且在应用RSA的情况下，记录密钥长度。
发放者是以可标识格式(可辨别的名称)记录的公共密钥证书的发放者名称，即公共密钥证书发放管理机构(IA)的名称的字段。
有效性记录了作为证书的有效期限的起始日期和时间以及结束日期和时间。
主题公共密钥信息存储作为证书持有者的公共密钥信息的密钥以及密钥的算法。
管理机构密钥标识符(密钥标识符、管理机构证书发放者、管理机构证书序号)是标识用于签名证明的证书发放者的密钥的信息，并且存储密钥标识符、管理机构证书发放者的名称以及管理机构证书序号。
在验证公共密钥证书的多个密钥的情况下，主题密钥标识符存有标识密钥的标识符。
密钥使用是指定密钥使用目的的字段，下面的使用目的被指定为：(0)用于数字签名，(1)用于拒绝预防，(2)用于密钥加密，(3)用于消息加密，(4)用于发送共享密钥，(5)用于验证的签名确认，(6)用于撤销列表中的签名确认。
私人密钥使用期限记录对应于证书中存储的公共密钥的秘密密钥的有效期限。
证书策略记录了公共密钥证书发放者的证书发放策略。一个实例是策略ID和顺从ISO/IEC 9384-1的认证标准。
策略映射是存储信息的字段，该信息涉及关于认证路径中策略的限制，并且仅仅对证明管理机构(CA)证书是必要。
主题Alt名是记录证书持有者的替代名的字段。
发放者Alt是记录证书发放者的替代名的字段。
主题目录属性是记录证书持有者所需的目录的属性的字段。
基本约束是辨别待证明的公共密钥是否是用于证明管理机构(CA)签名或者证书持有者的字段。
准许子树约束名(名约束准许子树)是存储由发放者发放的证书名的限制信息的字段。
约束策略(策略约束)是存储关于认证路径的策略的限制信息的字段。
CRL参考点(证书撤销列表分配表)是说明撤销列表的参考点的字段，用于在证书的持有者使用证书的时候，确认证书是否无效。
签名算法是存储用来在证书上署名的算法的字段。
签名是公共密钥证书发放者的签名字段。电子签名是通过把散列函数应用于整个证书的产生散列值(hash value)，并且利用关于该散列值的发放者的秘密密钥而生成的数据。在消除签名和散列的时候能够进行窜改，但是如果可以检测到这一情况，则效果基本上与防篡改相同。
证明管理机构发放图2至图4所示的公共密钥证书，更新有效期限到期的公共密钥证书，并且创建、管理和分配撤销列表，以拒绝从事未授权活动的用户。此外，根据需要产生公共密钥和秘密密钥。
另一方面，在利用公共密钥证书的时候，用户使用用户自身拥有的证明管理机构的公共密钥，以检验公共密钥证书的电子签名，在成功检验电子签名之后，从公共密钥证书中提取公共密钥，并且使用公共密钥。所以，使用公共密钥证书的所有用户需要持有共同的证明管理机构公共密钥。
(属性证书)
权限管理基础结构(PMI)102是能够应用属性证书(AC)122执行权限确认处理的基础结构。组属性证书(组AC)是属性证书的形式，下面将参照图5至图7说明组属性证书。属性证书的功能是业务使用权限的确认功能，其中如业务供应商的内容和业务的使用权限的关于权限的信息，和关于权限的持有者属性信息被描述在属性证书中。
属性证书是基本上由属性管理机构(AA)发放的证书，该属性证书存储了关于证书发放的属性信息，该属性证书由属性管理机构侧创建，并附有诸如ID和有效期限等的消息，并且还附有带属性管理机构的秘密密钥的签名。然而，请注意，在下面的说明中，组属性证书和执行属性证书不必要被限制到作为其发放管理机构的属性管理机构(AA)，在业务供应商或者用户装置也可以进行发放处理。
提供作为属性管理机构(AA)的代理的属性登记机构(ARA)、执行属性证书(AC)发放申请接收、请求者的检查以及管理，允许分散处理负荷。
本发明的配置所应用的组属性证书(组AC)是一个属性证书，其中多个对象，比如多个用户或多个用户装置被设置为具有相同属性的集合的一组，该属性证书被发放给构成作为单位的集合组的组的诸多装置或用户。组属性证书拥有对应于由某些装置或者某些用户构成的组的被存储的信息组标识信息集合，并且还具有发放者附加其上的电子签名。
该证书被发放给具有公司、组织、学校等的属性的用户或者用户装置，这些用户或者用户装置属于多个人或者属于诸如家庭的组。或者，把证书发放给多个用户的单位的组的成员(用户、用户装置)，这些用户接收单一业务供应商提供的业务。可以做出关于组的各种设置，稍后将说明特定实例。
现在，稍后将说明的执行属性证书保存有作为被存储数据的、包括经过加密处理的数据处理命令的加密执行命令，以及地址(Ad)信息，该地址信息指示登记密钥在用户装置存储器中的存储区，所述登记密钥适用于加密执行命令的解密处理。执行属性证书的细节将稍后进行说明。
ITU-TX.509规定了属性证书的基本格式，并且利用IETF PKIX WG建立了基本轮廓。与公共密钥证书不同，这不包括持有者的公共密钥。然而，附加了属性证书管理机构的签名，因此与公共密钥证书相同，通过检验该签名进行确定是否存在篡改。
请注意，本发明应用的组属性证书或者执行属性证书可以被配置成顺从于属性证书的基本格式。然而，遵从由ITU-TX.509规定的格式是必要的，并且原始格式可以被用来配置属性证书。
利用本发明的配置，业务供应商或者用户装置可以处置发放和管理属性证书(AC)的属性证书管理机构(AA)的功能以及属性登记管理机构(ARA)的功能。当然，业务供应商或者用户装置本身可以被配置成充当属性证书管理机构(AA)或者属性登记管理机构(ARA)。
属性证书基本上用于公共密钥证书。也就是说，用公共密钥证书确认属性证书持有者是否为真实个人，并且还确认哪种权限被提供给该持有者。例如，在业务供应商向用户或者用户装置提供业务的时候，通过验证属性证书来确认用户或者用户装置是否具有接收业务的权限。在验证属性证书的时候，在证书的签名验证之后，还执行与属性证书相关的公共密钥证书的验证。
此时，作为一个规则，优先跟踪证书链直到最高阶公共密钥证书，并且按顺序进行检验。利用其中存在于分层安排中的多个证明管理机构(CA)的证明管理机构配置，由发放公共密钥证书的较高阶证明管理机构签署较低阶证明管理机构本身的公共密钥证书。也就是说，存在链公共密钥证书发放配置，其中较高级的证明管理机构(CA-High)向较低的证明管理机构(CA-Low)发放公共密钥证书。公共密钥证书的链验证是指从底部到顶部追踪证书链，以便获得链信息直到最高阶公共密钥证书，从而执行签名验证直到最高阶(根CA)公共密钥证书。
通过缩短属性证书的有效期限，可以不执行撤销处理。在此情况下，可以省略证书的撤销过程和撤销信息的参考过程等，这有利于简化***。然而，对于证书的未授权使用必需采用某类测量，所以足够谨慎是必要的。
下面将参考图5说明组属性证书的配置。
证书的版本号指示证书格式的版本。
AC持有者的公共密钥证书信息是关于属性证书(AC)的发放者的公共密钥证书(PKC)的信息，并且是RKC发放者名称、PKC序号、PKC发放者唯一ID等的信息，具有作为与对应的公共密钥证书相关联的链接数据的功能。
属性证书发放者的名称是属性证书的发放者名称的字段，也就是，以可标识的格式(可辨别的名称)记录属性管理机构。
签名算法标识符是记录属性证书的签名算法标识符的字段。
证书的有效期限记录作为证书的有效期限的开始日期和时间以及结束日期和时间。
属性信息字段存储标识组属性证书的组的作为组标识信息的组ID。组ID是一个标识符(ID)，该标识符对应于由利用组属性证书执行权限确认的业务供应商所拥有的业务供应商(SP)管理的组信息数据库的项目(参见图5中下右部分)。
业务供应商具有的业务供应商(SP)管理的组信息数据库是一个表，该表关联例如组属性证书(ARA)的发放者和作为组标识符(组ID)的组标识信息，以及组信息如“公司A的雇员”和“B先生的家庭成员”，如图5的下右部分所示。业务供应商根据组标识信息(组ID)从表中提取对应项目，以作为基于组证书的权限确认处理中的证书存储数据，并且获得包括组信息的组属性证书信息。
请注意，在属性信息字段中可以存储除了组标识信息(组ID)的各种类型的信息，例如内容使用限制信息如内容使用限制等，关于权限的具体信息如业务使用限制信息等，以及各种类型的信息如业务供应商(ID)、业务供应商名称等等。尽管稍后将描述其细节，但是这还可以应用为用于存储获取用来解密已加密内容的内容密钥所需的信息的字段。
业务供应商向用户装置发送组属性证书，并且在属性证书的验证之后，用户装置在它自己的安全芯片的存储器中存储组属性证书。
属性证书还存储签名算法，具有由属性管理机构(AA)的属性证书发放者制作的签名。在发放者是业务供应商或者用户装置的情况下，附加每个发放者的签名。电子签名是通过产生把散列函数应用于整个属性证书的散列值，并且使用关于散列值的属性证书的发放者的安全密钥，而生成的数据。
图6显示了组属性证书(组AC)的发放者、持有者、检验者和属性信息的配置实例。在向属于例如一个公司或者一个家庭的用户的多个用户装置组的每一个发放组属性证书的情况下，所发放的组属性证书被存储在用户所拥有的装置内的安全芯片(SC)或者用户安全芯片(USC)中。稍后描述用户装置的细节。
根据发放给用户装置的组属性证书执行权限确认的验证者是，例如业务供应商装置内的安全模块(SM)，或者是用户装置内的安全芯片(SC)，所述业务供应商装置是业务供应实体。请注意，用户装置内的安全芯片或者业务供应商装置中的安全模块最好具有限制外部数据读出的反篡改配置。
组属性证书具有作为属性信息的充当标识信息的组标识信息(组ID)，它能够例如标识一个公司或者一个家庭。
图7图示了组属性证书的发放策略表的配置实例。组属性证书发放策略表是由发放组属性证书的实体管理的表，所述实体比如是属性证书管理机构(AA)、充当属性证书管理机构的代理的属性登记管理机构(AGA)或者业务供应商或用户装置，并且是其中发放的组属性证书的组标识信息(组ID)、组信息以及诸如发放标准的发放策略等被相互关联的表。例如，在最新发放、附加发放或者更新组属性证书的时候，根据组属性证书的发放策略表执行检查，并且只要该策略被满足就执行诸如发放和更新的过程。
图8图示了说明权限管理***上参与的实体的信托关系配置的信托模型。
***持有者(SH)130是执行本发明的整个权限管理***的集中式管理的实体，即***操作实体，并确保***中参与的实体的安全芯片(SC)和安全模块(SM)的合法性，并且负责发放公共密钥证书(PKC)。***持有者(SH)130包括作为最高阶证明管理机构的rootCA131、分层配置中的多个证明管理机构(CA)132、以及充当公共密钥证书发放代理的登记管理机构(RA)133.
***持有者(SH)130向实体发放公共密钥证书(PKC)，所述实体即属性管理机构(AA)140、属性登记管理机构(ARA)150、业务供应商160以及充当用户装置170的用户标识装置(UID)171和终端实体(EE)172，在某些情况下，每个实体把公共密钥证书(PKC)存储到外部存储装置、内置反篡改配置安全芯片(SC)或者安全模块(SM)中。
此外，组属性证书(组AC)在属性证明管理机构(ARA)150处接收来自业务供应商160、作为用户装置170的用户标识装置(UID)171和终端实体(EE)172等的属性证书发放请求，执行遵从之前参照图7说明的策略表151的策略(发放条件等)的属性证书发放检查，并且在确定可准许发放的情况下，把发放委托从属性登记管理机构(ARA)150转移给属性管理机构(AA)140。
属性管理机构(AA)140根据组属性证书发放委托存储组标识信息(组ID)作为属性信息，并且向发放请求者发放具有附加有属性管理机构(AA)140的秘密密钥的签名的组属性证书(见图5)。
如上所述，可以配置属性管理机构(AA)140和属性登记管理机构(ARA)150，使业务供应商或者用户装置执行其功能。
(2)用户装置配置
下面将说明充当使用业务的信息处理装置的用户装置的配置。用户装置根据其功能被分成两类。一类是充当相互使用业务的终端实体(EE)，其实例是各类数据处理装置，比如PC、家用服务器、PDA和类似便携终端、IC卡等，它们具有接收由业务供应商提供的业务信息的接口。这些装置具有带反篡改配置的安全芯片(SC)或者模块(SM)，根据需要，存储对应于装置的公共密钥证书以及对应于装置的组属性证书。
另一类是用于个体验证处理的用户标识装置(UID)。用户标识装置(UID)也被配置成类似终端实体的装置，但是它不必要具有直接接收由业务供应商提供的业务信息的接口。经由终端实体(EE)执行与业务被供应装置的通信。用户标识装置(UID)是适用于用户验证的装置。这些装置具有带有反篡改配置的安全芯片(SC)或者模块(SM)，根据需要，存储对应于装置的公共密钥证书以及对应于装置的组属性证书。
请注意，尽管终端实体(EE)和用户标识装置(UID)可以被配置为个体装置，但是也可以做成其中把两种功能提供到单一装置上的配置。
至于特定配置实例，存在这样一种配置，其中诸如IC卡的装置构成用户标识装置(UID)和PC终端实体(EE)。利用这种配置，在可以进行数据传递的状态下，IC卡被设置在PC中，首先经由PC在IC卡与业务供应商之间进行通信，以应用公共密钥证书和组属性证书以执行用户验证和用户权限确认处理，在该处理之后，可以在作为终端实体的PC服务与业务供应商之间进一步执行验证和权限确认的处理。稍后将说明权限确认处理的细节。
下面参照图9说明充当用户装置的终端实体(EE)和用户标识装置(UID)中包含的安全芯片的配置的实例。请注意，终端实体被配置为具有通信功能的，充当数据处理装置的CPU、PC、游戏终端、便携终端、PDA、IC卡(存储卡)、用于DVD或CD的播放或记录/播放装置等，并且具有带反篡改配置的安全芯片(SC)。
如图9所示，由终端实体(EE)或用户标识装置(UID)组成的用户装置200具有内置的安全芯片210，以便能够向用户装置控制单元221互传递数据。
安全芯片210包括具有程序执行功能和计算处理功能的CPU(中央处理单元)201，并且还具有：带数据通信接口功能的通信接口202；存储由CPU201执行的各类程序如加密程序的ROM(只读存储器)203；充当执行程序加载区、处理程序的工作区的RAM(随机存取存储器)204；加密处理单元205，用于与外部装置执行验证处理、生成电子签名、验证处理以及包括被存储数据的加密和解密的加密处理；存储单元206，例如具有EEPROM(电可擦除可编程ROM)的配置，用于存储每个业务供应商的信息，以及只有该装置才有的信息，包括各类密钥数据。
用户装置200包括具有EEPROM或者硬盘等的配置的外部存储单元222，充当存储已加密内容或者业务信息等的存储区。外部存储单元222还可以用作公共密钥证书和组属性证书的存储区。
在用户装置具有连接到诸如业务供应商的外部实体的安全芯片，并且执行数据传递处理的情况下，经由网络接口232执行与业务供应商的连接。然而，如上所述，终端实体(EE)具有执行与业务供应商连接的接口，并且用户标识装置(UID)不必要具有网络接口232；因此，经由用户标识装置(UID)的连接装置接口231连接终端实体(EE)的连接装置接口231，并且执行经由终端实体的网络接口232的通信。
也就是说，用户标识装置(UID)经由终端实体执行与业务供应商装置的通信。
在诸如终端实体(EE)和用户标识装置(UID)的用户装置的安全芯片210与业务供应商之间传递数据的情况下，在安全芯片210与外部实体之间执行相互认证，并且如果需要还加密传递的数据。稍后将说明这种处理的细节。
图10显示了用户装置的安全芯片中的存储的数据的实例。在配置EEPROM(电可擦可编程ROM)如非易失存储器的闪存的存储单元中存储了许多这样的数据，但是在安全芯片内或者外部存储器中可以存储公共密钥证书、组属性证书和稍后所述的执行属性证书。
下面将说明各种类型的数据。
公共密钥证书(PKC)：公共密钥证书是向第三方指示公共密钥是可信的证书，并且该证书包括要分配的公共密钥，并且可靠的证明管理机构的电子签名被附加在该证书上。在与用户装置进行数据通信的时候，用户装置存储获取应用于验证、加密、解密处理等的公共密钥所需的公共密钥证书，比如具有上述分层配置的最高阶证明管理机构(根CA)的公共密钥证书、向用户装置提供业务的业务供应商的公共密钥证书。
组属性证书(AC)：尽管公共密钥证书标识证书用户(持有者)的真实个人，但是组属性证书用于标识证书用户的组并确认给予构成该组的成员的使用权限。通过展示组属性证书，用户可以根据在组属性证书中列出的权利和权限信息使用业务。请注意，组属性证书是根据预定发放过程发放的，接收组属性证书的每个实体将其存储到具有反篡改配置的安全芯片(SC)或安全模块(SM)内，或者在某些情况下，将其存储到外部存储器中。稍后将说明发放和存储处理的细节。
执行属性证书：这是一个属性证书，具有：作为存储数据的包括经过加密处理的数据处理执行命令的加密执行命令，和地址(Ad)信息，指示用户装置的存储器内的存储区，即存储要应用于加密执行命令的解密处理的登记密钥的地方；因而应用根据地址信息从用户装置内的存储器获得的登记密钥，解密加密执行命令，来获得执行命令，从而执行各种类型的业务。稍后将说明这种处理的细节。
密钥数据：存储的密钥数据包括：用于安全芯片的公共密钥和秘密密钥对集合；在解密上述执行属性证书中存储的加密执行命令的时候应用登记密钥；复位密钥应用于登记密钥的毁坏(复位)处理；随机数生成密钥；相互认证密钥等。请注意，登记密钥的存储区位于由预先确定的地址决定的存储区中。稍后将详细说明登记密钥和复位密钥。
标识信息：对于标识信息，存储充当安全芯片的标识符的安全芯片ID。此外，还可以存储充当业务供应商(SP)(由此接收连续业务)的标识符的业务供应商ID、供应给使用用户装置的用户的用户ID、标识对应于业务供应商所提供的业务的应用的应用ID，等等。
其它：用户装置还存储：随机数生成种子信息，即生成遵从ANSI X9.17的用于验证处理、加密处理的随机数的信息；关于应用各种使用限制的业务的使用信息，例如，在使用具有内容使用次数限制的内容时更新的使用内容的次数的信息，付款信息或类似信息，以及根据信息计算的散列值。
请注意，图10所示的配置实例仅仅是一个实例，可以根据需要存储与涉及用户装置接收业务的信息不同的其它各种信息。
此外，请注意，还可以利用类似于图9所示的用户装置上的安全芯片配置的配置实现在业务供应侧的业务供应商侧的安全芯片或安全模块，以便充当用于稍后说明的组属性证书验证处理和生成处理，以及执行属性证书验证处理和生成处理的各种执行装置。例如，与图9所示的安全芯片相同的配置还可以被应用为，对经由是数据发送/接收单元的网络接口接收的组属性证书或者执行属性执行验证处理的装置，或者被应用为执行组属性证书或者执行属性证书的生成处理的装置。
(3)组属性证书发放和使用处理
下面将说明，组属性证书发放处理和把多个用户或装置设为组的使用处理，比如所述用户属于学校或公司或一个家庭的相同组织的不同集合，所述装置是同一制造商制造的装置，多个用户和多个装置接收相同业务供应商的业务，并且向属于组的每个用户或装置发放组属性证书。
组属性证书是一个可以确认试图接收业务的用户或者装置(用户装置)属于某个组的事实的证书，并且在接收业务的时候被展示给例如业务供应实体、业务供应商。业务供应商执行所展示的组属性证书的验证处理，并且在已经做出用户或用户装置适于某个组的确认的条件下提供业务。
组属性证书是具有作为被存储信息的、对应于构成某些装置或某些用户的集合的组的组标识信息集合的证书，并且携带发放者的电子签名。
图11示意地说明了组属性证书的发放申请、发放处理和使用处理的流程。期望接收由业务供应商314提供的业务的用户装置311，即具有安全芯片的终端实体(EE)或者用户标识装置(UID)首先向组属性证书的发放实体提出发放请求，其中所述业务供应商314在根据组属性证书确认属于组的证据的条件下提供业务。例如，向属性登记管理机构(ARA)312提出发放组属性证书的申请。
属性登记管理机构(ARA)312根据发放申请查阅发放策略表313，并且在满足策略的情况下，委托属性管理机构(AA)发放属性证书，并且向用户装置311发送属性管理机构(AA)已经发放的组属性证书316。
组属性证书316把充当组标识符的组ID存储到属性信息字段中(参见图5)。用户装置311在接收业务供应商314提供的某类业务比如内容分配、付款处理等的时候，向业务供应商314展示组属性证书316。业务供应商314通过组属性证书的验证处理以及查阅组信息数据库315，确定请求要提供的业务的用户装置311具有接收业务的权限，并且在确定用户装置311具有权限的情况下，执行业务的供应。
下面将按照以下三个条目说明组属性证书发放和使用处理：
(3-1)发放组属性证书之前的预备处理
(3-2)组属性证书发放处理
(3-3)组属性证书使用处理
(3-1)发放组属性证书之前的预备处理
首先说明发放组属性证书之前的预备处理。如上所述，在常规方式下，组属性证书基本上由属性管理机构发放，属性登记管理机构(ARA)接收来自属性证书发放请求实体的发放请求，在属性证书发放请求被传送给属性管理机构(AA)之后，执行策略检查和类似检查，进行准许发放的确定，并且经由属性登记管理机构(ARA)把属性管理机构(AA)发放的属性证书发送给发放请求实体。然而，如下所述，可以在相应的策略下在业务供应商(SP)和用户装置处进行发放。
一旦确定了某类可标识的组，比如家庭、学校、公司某个制造商的诸多装置，就把本发明的组属性证书发放给构成组的成员(装置或用户)，同时提供业务的业务供应商根据该组属性证书确定请求业务的用户或装置是否属于某个组。因此，在需要组属性证书发放处理执行实体和根据组属性证书执行权限确认(验证处理)并提供业务的实体具有对应于组属性证书定义的组的共同理解的情况下，需要在组属性证书发放实体与业务供应商实体之间，共享关于对应于组属性证书定义的组的信息，即组信息的处理，以作为发放组属性证书之前的预备处理。
下面是参照图12对在组属性证书发放实体是属性管理机构(AA)或属性登记管理机构(ARA)，以及业务供应商实体是业务供应商(SP)的情况下关于组信息共享处理的说明。
请注意，在下面的说明中，属性管理机构(AA)和属性登记管理机构(ARA)处于信托关系，并且通过一个配置的实例进行说明，其中属性登记管理机构(ARA)执行发放组属性证书的检查，属性管理机构(AA)根据属性登记管理机构(ARA)执行的检查结果执行组属性证书发放处理。因此，组信息共享管理机构是业务供应商(SP)和属性登记管理机构两者。
下面将参照图12所示的处理顺序图说明业务供应商(SP)与属性登记管理机构(ARA)之间的组信息共享处理。
首先，在步骤S101中，在业务供应商(SP)与执行组属性证书的发放检查的属性登记管理机构(ARA)之间执行相互认证处理。请注意，以下将执行组属性证书发放检查的属性登记管理机构(ARA)称作组属性证书登记管理机构(ARA)。
业务供应商(SP)与组属性证书登记管理机构(ARA)之间执行的相互认证是为了在执行数据发送/接收的两个实体之间确认其它方是否是适当数据通信方所执行的处理。数据传递是在建立验证的条件下执行的。此外，最好在相互认证处理的时候产生对话(session)密钥，以用于在基于作为共享密钥的对话密钥的加密处理下进行数据传递的配置。公共密钥加密或者共享密钥加密也可以用于相互认证方法。
这里将参照图13所示的顺序图说明握手协议(TLS1.0)、是公共密钥加密方法类型的相互认证方法。
在图13中，实体A(客户机)和实体B(服务器)是执行通信的两个实体，并且对应于业务供应商(SP)或者组属性证书登记管理机构(ARA)。首先，(1)实体B向实体A发送如hello请求的用于确定加密说明的协商启动请求。(2)一旦收到hello请求，实体A就向实体B侧发送如客户机hello的加密算法、对话ID和协议版本候选。
(3)实体B侧向实体A发送作为业务hello的关于已经确定使用的加密算法、对话ID和协议版本。(4)实体B向实体A发送一组到达它自己的根CA的公共密钥证书(X.509v3)(服务器证书)。在不跟踪为了执行验证证书链直到最高阶公共密钥证书的情况下，不绝对需要发送公共密钥证书(X.509v3)的集合到根CA。(5)实体B向实体A发送RSA公共密钥或者Diffie & Hellman公共密钥信息(服务器密钥交换)。这是在不能使用证书的情况下临时应用的公共密钥信息。
(6)然后，实体B侧向实体A请求实体A的证书以作为证书请求，并且(7)通知实体B进行的协商处理结束(服务器hello结束)。
(8)收到服务器hello结束的实体A向实体B发送到达它自己的根CA的公共密钥证书的集合(X.509v3)(客户机证书)。在不执行公共密钥证书的链验证的情况下，不绝对需要发送公共密钥证书的集合。(9)实体A用实体B的公共密钥加密48字节随机数，并将其发送给实体B。实体B和实体A根据该值产生一个主秘密(master secret)，该主秘密包括用于生成用于发送/接收数据验证处理的消息验证码(MAC)的数据等。
(10)实体A加密使用客户机的秘密密钥的消息等地摘要，以确认客户机证书的正确性，将其发送给实体B(客户机证书实体)，(11)通知开始使用先前确定的加密算法和密钥(改变密码说明)，并且(12)通知验证的开始。另一方面，(13)实体B侧还通知实体A开始使用先前确定的加密算法和密钥(改变密码说明)，和(14)通知验证结束。
在上述处理中确定加密算法之后，执行实体A与实体B之间的数据传递。
通过把消息验证码(MAC)(依据上述验证处理中，实体A与实体B之间达成一致时所产生的主秘密计算该消息验证码)添加到每个实体的发送数据上，执行数据篡改的验证，从而执行消息篡改验证。
图14说明了消息验证码(MAC)的生成配置。数据发送侧把基于在验证处理中产生的主秘密生成的MAC秘密添加到发送的数据上，从整个数据算出散列值，并根据MAC秘密、填充和散列值算出散列，从而生成消息验证码(MAC)。所生成的MAC被附加到发送的数据上，并且在已接收的MAC匹配基于接收方的接收数据而成生的MAC的情况下，确定该数据未被篡改，并且在不匹配的情况下，确定该数据已经被篡改。
在图12所示的步骤S101中，在业务供应商(SP)与已经执行组属性证书发放检查的属性登记管理机构(ARA)之间执行遵从上述实例顺序的相互认证处理，并且一旦确认两者都是正确通信方时，在步骤S102，在业务供应商(SP)与属性登记管理机构(ARA)之间执行组信息共享处理。
特别是，作为设置由组属性证书发放实体(例如，属性登记管理机构(ARA))管理的发放策略表，以及基于验证和组属性证书的验证的业务供应实体(例如业务供应商(SP))的组信息数据库以便保持匹配信息的处理，执行组信息共享。
如上所述，组属性证书发放实体(例如，属性登记管理机构(ARA))具有发放策略表，基于验证和组属性证书的验证的业务供应实体(例如，业务供应商(SP))具有组信息数据库。图15示出了该信息的配置实例。
(A)发放策略表由属性登记管理机构(ARA)保持和管理，并且被传送以用于组属性证书发放处理和类似处理。另一方面，(B)组信息数据库(DB)由业务供应商(SP)保持和管理，并且在提供业务时验证组属性证书的时候，参阅组信息数据库。
属性登记管理机构(ARA)保持和管理的发放策略表，和业务供应商(SP)保持和管理的组信息数据库(DB)一致是必需的。在图15所示的实例中，(A)发放策略表的项目341与(B)组信息数据库(DB)的项目351相一致，(A)发放策略表的项目342与(B)组信息数据库(DB)的项目352相一致。(A)属性登记管理机构(ARA)保持和管理的发放策略表与(B)业务供应商(SP)保持和管理的(B)组信息数据库(DB)之间的这个一致维护处理是图12的顺序图中的组信息共享处理步骤S102。
请注意，这里存在以下两个组信息共享处理的安排的实例。
策略接受型：基于验证和组属性证书的验证的业务供应实体(例如，业务供应商(SP))学习各种属性证书发放实体(例如，属性登记管理机构(ARA))的发放策略，选择适合于它自己业务的组ARA，并且业务供应商(SP)获得这里所选择的组ARA管理的组信息。
发放委任型：由业务供应实体(例如，业务供应商(SP))基于验证和组属性证书的验证设置的发放策略被展示给组属性证书发放实体(例如组属性证书登记管理机构(ARA))，该组属性证书发放实体没有自己的属性证书发放策略，而仅仅被委托发放组属性证书，并且组属性证书登记管理机构(ARA)执行遵从所展示的策略的组属性证书发放处理。
可以对特定的组信息共享处理安排做出各种安排，比如一个安排是，其中由组属性证书发放管理机构(例如，组属性证书登记管理机构(ARA))设置关于组属性证书的信息，如组ID、发放者、组信息、发放策略等，根据验证和组属性证书的验证将该信息展示给业务供应实体(例如，业务供应商(SP))，并且由此使两个实体一致；一个安排是，其中业务供应商设置这样的信息并把该信息展示给组ARA，由此使两个实体一致；一个安排是，其中由每个实体设置每个信息，并且使全部信息相互一致；一个安排是，其中业务供应商单方面信托组属性证书登记管理机构(ARA)；等等。
请注意在发放委托安排的情况下，在新的业务供应商(SP)启动使用组属性证书的新业务的情况下，则属性登记管理机构(ARA)在执行上述的组信息共享处理之后，执行业务供应商(SP)自身的登记检查。
一旦步骤S102的组信息共享处理结束，在步骤S103业务供应商(SP)根据一致信息对它自己管理的组信息数据库执行数据更新处理。如图15所示，组信息数据库存储发放者的数据，组标识信息(组ID)和组信息，并且执行关于该信息的数据登记和更新。另一方面，在步骤S104，属性登记管理机构(ARA)根据一致信息对它自己管理的发放策略表执行数据更新处理。如图15所示，发放策略表存储组ID的数据、组信息和发放策略，并且执行关于该信息的数据登记和更新。
请注意，上述处理是以下情况下所需的处理：在业务供应商(SP)和属性登记管理机构(ARA)被配置为独立实体情况下，并且在业务供应商(SP)还充当属性登记管理机构(ARA)的情况下，业务供应商(SP)自己保持和管理全部组信息数据库和发放策略表，所以可以省略上述的业务供应商(SP)与属性登记管理机构(ARA)之间的组信息共享处理。
此外请注意，上述实例是这样一种情况，其中组属性证书发放实体是属性登记管理机构(ARA)，并且基于验证和组属性证书的验证的业务供应实体是业务供应商(SP)，但是上述处理根据各种实体的组合执行的。
(3-2)组属性证书发放处理
下面将说明组属性证书发放处理。作为一个规则，由属性管理机构(AA)执行组属性证书发放处理。然而，业务供应商和用户装置还可以根据自己的发放策略进行发放。在下面的说明中，将描述由属性管理机构(AA)执行的组属性证书发放处理顺序。
利用常规属性证书发放顺序，一种处理安排，其中属性登记管理机构(ARA)接收来自属性证书发放请求实体的发放请求，执行策略检查等，并且在确定发放准许之后，把属性证书发放请求转送给属性管理机构(AA)，并且经由属性登记管理机构(ARA)把属性管理机构(AA)发放的属性证书转送给发放请求实体。
下面将参考图16说明在用户装置的终端实体(EE)的安全芯片是组属性证书发放请求实体的情况下的处理。请注意在图16中，
UID：用户标识装置(用户装置)控制单元，
USC：配置在UID内的用户安全芯片，
EE：终端实体(用户装置)控制单元，
SC：配置在EE内的安全芯片，
组ARA：组属性证书登记管理机构控制单元，
组AA：组属性管理机构控制单元。
首先，在步骤S111中，用户经由终端装置(EE)的输入接口输入用于组属性证书(Gp.AC)的发放请求命令。此时，用户输入发放组属性证书的所需的属性值。属性值是组ID、证明属于该组的信息、或类似信息。
一旦终端实体(EE)接收用户的组属性证书(GP.AC)发放请求的输入，在步骤S112中，终端实体(EE)就向组ARA提出连接请求，并且在步骤S113中向终端实体(EE)内的安全芯片(SC)输出相互认证启动请求。
在步骤S114中，在安全芯片与组ARA之间执行相互认证。该相互认证例如是作为参照图13所述的公共密钥方法的相互认证处理来执行的。在步骤S115中，从安全芯片向终端实体输出相互认证完成通知，包括相互认证的建立或者未建立的结果信息。在未建立相互认证的情况下，取消处理的继续。在建立相互认证的情况下，在步骤S116中，终端实体(EE)向组ARA发送组属性证书(Gp.AC)发放请求。该组属性证书(Gp.AC)发放请求包括终端实体信息和属性信息(例如，组ID，组信息)。
在步骤S117中，已收到来自终端实体(EE)组属性证书(Gp.AC)发放请求的组ARA参阅发放组策略表，确定是否可以做到遵从策略的组属性证书的发放，并且在可以做到顺从的情况下，流程前进到步骤S118，而在不能做到顺从的情况下，把不准许发放消息通知给终端实体。
在步骤S118中，组ARA向组AA发送具有属性值(组ID)的组属性证书(Gp.AC)发放请求，在步骤S119中，组AA把组ID存储为属性信息，生成附有电子签名的组属性证书(参见图5)，然后将其发送给组ARA。
在步骤S120中，组ARA向终端实体(EE)发送被发放的组属性证书(Gp.AC)。终端实体(EE)把收到的组属性证书(Gp.AC)存储到它的存储器中。此时，对接收的组属性证书(Gp.AC)的电子签名进行验证，并且在确认没有篡改之后，将其存储到存储器中。
下面参照图17和图18说明，由组AA在产生组属性证书的时候，执行的电子签名生成，并在存储组属性证书的时候，由终端实体执行的电子签名验证处理。
附加签名使得能够进行数据篡改的验证，并且可以使用上述的MAC值，以及还可以使用利用公共密钥加密方法的电子签名。
首先，将参照图17说明利用公共密钥加密方法的生成电子签名的方法。图17所示的处理是利用EC-DSA((椭圆曲线数字签名算法)，IEEE P1363/D3)的电子签名数据生成处理。这里所述的实例把椭圆曲线密码***(以下称作ECC)用作公共密钥加密。请注意，对于本发明的数据处理装置，除了椭圆曲线密码***之外，还可以使用诸如RSA加密((Rivest，Shamir，Adleman)，等(ANSI X9.31))的类似公共密钥加密。
下面说明图17中的步骤。在步骤S1中，P作为素数，a和b作为椭圆曲线系数(椭圆曲线：y2＝x3+ax+b，4a3+27b2≠0(mod p))，G作为椭圆曲线上的基点，r作为G的阶数，Ks作为秘密密钥(0＜Ks＜r)。在步骤S2中，计算消息M的散列值，使f＝Hash(M)。
现在将说明利用散列函数获得散列值的方法。散列函数是把消息作为输入的函数，将其压缩成预定比特长度的数据，并输出为散列值。散列函数很难从散列值(输出)中预测，并且把1比特的数据输入变成散列函数，会在散列值中将改变大量的比特，此外，很难用相同散列值得出不同的输入数据。存在MD4、MD5、SHA-1等用于散列函数的情况，以及使用SES-CBS的情况。在此情况下，是最终输出(检验值：等同于ICV)的MAC是散列值。
接着，在步骤S3中，生成随机数u(0＜u＜r)，并且在步骤S4中，计算基点乘以u的坐标(Xv，Yv)。请注意，对椭圆曲线的加和加倍被定义为下式。
有P＝(Xa，Ya)，Q＝(Xc，Yb)，R＝(Xc，Yc)＝P+Q，
在P≠Q(加)时。
Xc＝λ2-Xa-Xb
Yc＝λ×(Xa-Xc)-Ya
λ(Bb-Ya)/(Xb-Xa)，
在P＝Q(加倍)时，
Xc＝λ2-2Xa
Yc＝λ×(Xa-Xc)-Ya
λ＝((3Xa)2+a)/(2Ya)
这些用来计算点G的u倍(尽管很慢，但是按以下方式执行最容易理解的计算方法：计算G、2×G、4×G等等，把u变换成二进制，并且把21×G(G被加倍i次(i是从LSB算出的比特位置))加到1的地方)。
在步骤S5，计算c＝Xv mod r，在步骤S6确定该值是否为0，如果不为0，则在步骤S7计算d＝[(f+cKs)/u]mod r，在步骤S8确定d是否为0，如果不为0，则在步骤S9作为电子签名数据输出c和d。假定r具有160的比特长度，则电子签名数据将为320比特长。
在步骤S6中c为0的情况下，流程返回到步骤S3，并且再次产生新的随机数。同样地，在步骤S8中的d为0的情况下，流程返回到步骤S3，并且再次生成随机数。
下面参照图18说明使用公共密钥加密方法的电子签名的验证方法。在步骤S11中，M是消息，P是为素数，a和b作为椭圆曲线系数(椭圆曲线：y2＝x3+ax+b，4a3+27b2≠0(mod p))，G作为椭圆曲线上的基点，r作为G的阶数，G和Ks×G作为公共密钥(0＜Ks＜r)。在步骤S12中，验证电子签名数据c和d是否满足0＜c＜r，0＜d＜r。在满足的情况下，在步骤S13中计算消息M的散列值，如f＝Hash(M)。然后，在步骤S14中，计算h＝1/d modr，并且在步骤S15中，计算h1＝fh mod r，h2＝ch mod r。
在步骤S16中，利用已经计算的h1和h2计算点P＝(Xp，Yp)＝h1×G+h2·ks×G。电子签名验证者知道基点G和Ks×G，所以可以以图17的步骤S4的相同方式计算与椭圆曲线上的点的标量相乘的计算。在步骤S17中，确定点P是否是无穷远点(infinite apoapse)，如果不是无穷远点，则流程进行到步骤S18(实际上，无穷远点的确定可以在步骤S16进行。也就是，加P＝(X，Y)，Q＝(X，-Y)显示不能计算λ，从而揭示P+Q是无穷远点。在步骤S18中，计算Xp mod r，并与电子签名数据c相比较。最后，在该值匹配的情况下，流程前进到步骤S19，并确定电子签名是否正确。
在确定电子签名是正确的情况下，这将告知没有篡改，并且告知对应于公共密钥的秘密密钥的持有者已经生成电子签名。
在步骤S12中，如果电子签名数据c或d不满足0＜c＜r，0＜d＜r，则流程前进到步骤S20。此外，如果点P在步骤S17中也是无穷远点，则流程前进到步骤S20。此外，如果在步骤S18中Xp mod r的值也不匹配电子签名数据c，则流程前进到步骤S20。
如果在步骤S20中确定电子签名是不正确的，这将告知数据已经被篡改，或者对应于公共密钥的秘密密钥的持有者没有生成电子签名。如上所述，尽管消除签名和散列将能够实现篡改，但是对其检测意味着具有基本上与防篡改相同的效果。
下面参照图19说明发放对应于用户标识装置(UID)中的用户安全芯片(USC)的组属性证书的过程。如上所述，配置UID以便能够经由终端实体(EE)进行外部通信，所以也可以经由终端实体(EE)执行属性证书获取处理。
步骤S131至S135的处理与参照图16所述的步骤S111至S115的处理相同，因此将省略对其说明。
当在步骤S134中建立终端实体与组ARA内的安全芯片之间的相互认证时，就在步骤S137中执行用户标识装置(UID)内的用户安全芯片(USC)与终端实体内的安全芯片(SC)之间的相互认证。经由终端实体(EE)和用户标识装置(UID)的连接装置接口231(参见图9)执行验证处理。该验证处理可以作为以下处理来执行，即，基于先前参照图13所述的公共密钥方法的验证处理来执行，以及集中于安全芯片和安全模块的加密处理单元(参见图9)的处理。在步骤S138中，对终端实体(EE)做出包括验证建立信息的验证完成通知，并且在已经建立验证的条件下，流程前进到下一个步骤。
在步骤S139，从终端实体(EE)输出用户安全芯片(USC)相互认证启动请求，并且在步骤S140中，在USC与组ARA之间执行相互认证。在步骤S141中，从USC向终端实体(EE)通告包括验证建立信息的验证完成通知，并且在已经建立验证的条件下，终端实体(EE)在步骤S142向组ARA发送组属性证书(Gp.AC)发放请求。组属性证书(Gp.AC)发放请求包括终端实体信息和属性值(例如，组ID，组信息)。
从终端实体(EE)的接收组属性证书(Gp.AC)发放请求时，组ARA就在步骤S143参阅发放策略表，确定是否能够顺从该策略发放组属性证书，如果可以发放证书，则流程前进到步骤S144，如果不能发放证书，则向终端实体通告不准许发放消息。
在步骤S144中，组ARA向组AA发送伴随属性值(组ID)的组属性证书(Gp.AC)发放请求，并且在步骤S145中，组AA存储作为属性信息的组ID，生成附加了电子签名的组属性证书(参见图5)，并且将其发送给组ARA。
在步骤S146中，组ARA经由终端实体(EE)向UID发送已发放的组属性证书(Gp.AC)。UID把收到的组属性证书(Gp.AC)存储到存储器中。此时，执行组属性证书(Gp.AC)的电子签名的验证，并且在确认没有篡改之后，执行存储器中的存储。
如上所述，为了使不具备与组ARA的直接通信功能的用户标识装置(UID)获得对应于用户安全芯片(USC)的组属性证书，存在通过终端实体(EE)的需要。此时，为了在用户安全芯片(USC)和组ARA之间执行相互认证，执行例如以下各项的建立：
(1)EE的SC与组ARA之间的相互认证，
(2)EE的SC与UID的USC之间的相互认证，
(3)UID的USC与组ARA之间的相互认证。或者作为简单匹配，可以构成当连接EE时，EE就基本上接受(认为已验证)UID的处理配置，并且在此情况下，可以省略上述的相互认证(2)。此外，可以实现上述三种不同组合下的验证配置。
(3-3)组属性证书使用处理
下面说明使用被存储在用户装置的安全芯片(SC)或者用户安全芯片(USC)中的组属性证书的处理。但是这里将不说明特定的业务格式，并且将研究基于组属性证书的业务使用权限验证处理，直到业务的开始。稍后将根据不同条目说明特定业务安排。
下面参照图20说明直到业务启动的处理，包括使用发放给充当使用装置的终端实体(EE)内的安全芯片(SC)的组属性证书的业务使用权限确认。请注意，在图20中，
UID：用户标识装置(用户装置)控制单元，
USC：配置在UID内的用户安全芯片，
EE：终端实体(用户装置)控制单元，
SC：配置在EE内的安全芯片，
SP：业务供应商控制单元，
SM：SP内的安全模块。
请注意，用户装置(EE)的安全芯片(SC)、用户标识装置(UID)的用户安全芯片(USC)和业务供应商(SP)的安全模块具有例如与图9所述的安全芯片相同的配置。
首先，在步骤S151中，用户经由实体(EE)的输入接口输入组属性证书(Gp.AC)使用请求命令。此时，用户指定在要使用的组属性证书中设定的组ID。然而，如果通过指定某种业务可以确定单一组ID，则可以做出其中只指定业务的安排。
当终端实体(EE)接收从用户输入的组属性证书(Gp.AC)使用请求时，终端实体(EE)就在步骤S152进行到业务供应商(SP)的连接请求，另一方面，在步骤S153中，向终端实体(EE)内的安全芯片(SC)输出相互认证启动请求。
在步骤S154中，执行安全芯片与业务供应商(SP)的安全模块(SM)之间的相互认证。这是集中于例如图9所示的加密处理单元205的处理，该加密单元205被配置在业务供应商(SP)的安全模块(SM)的安全芯片内，并且作为例如参照图13所述的公共密钥相互认证处理来执行。
在步骤S155中，从安全芯片向终端实体输出包括相互认证已建立/未建立结果信息的验证完成通知。如果未建立相互认证，则取消持续处理。如果建立相互认证，则在步骤S156中，终端实体(EE)向业务供应商(SP)的安全模块(SM)发送存在它自己的存储器中的组属性证书(Gp.AC)。或者，构成响应来自业务供应商(SP)的发送请求进行发送组属性证书(Gp.AC)的配置。此外，存在终端实体(EE)提出组属性证书(Gp.AC)的使用请求并发送组属性证书(Gp.AC)的情况。该组属性证书(Gp.AC)把组标识信息(组ID)存储为属性值。
业务供应商利用作为例如接收单元的具有与例如图9所示的用户装置相同的配置的网络接口，从终端实体(EE)接收组属性证书(Gp.AC)，并把该证书传递到安全模块(SM)。安全模块(SM)在步骤S157中执行组属性证书验证处理。如上所述，安全模块具有与图9所示的用户装置的安全芯片相同的配置，所以，安全模块充当组属性证书验证处理单元。
下面参照图21至图23说明组属性证书的验证处理的细节。首先，参照图21说明属性证书(AC)与公共密钥证书(PKC)之间的相关确认处理。图21所示的流程图是在验证属性证书(AC)时执行的涉及属性证书(AC)的公共密钥证书(PKC)的确认处理。
当属性证书(AC)被确认为是集合时(S21)，提取属性证书的AC持有者的公共密钥证书信息(持有者)字段(S22)，确认被存储在已提取的密钥证书信息(持有者)字段内的公共密钥证书的发放者信息(PKC发放者)和公共密钥证书序号(PKC序号)(S23)，根据公共密钥证书的发放者信息(PKC发放者)和公共密钥证书序号(PKC序号)搜索公共密钥证书(PKC)(S24)，并获得与属性证书(AC)相关的公共密钥证书(PKC)(S25)。
如图21所示，属性证书(AC)和公共密钥证书(PKC)利用属性证书AC持有者的公共密钥证书信息(持有者)字段中存储的公共密钥证书(PKC发放者)的发放者信息和公共密钥证书序号(PKC序号)相关属性证书(AC)和公共密钥证书(PKC)。
下面参照图22说明属性证书(AC)的验证处理。首先，设置待验证的属性证书(AC)(S51)，并且根据属性证书(AC)的被存储信息，标识属性证书(AC)的持有者和其签名者(S52)。此外，直接或者从存储库(repository)获得属性证书(AC)的持有者的公共密钥证书(S53)，并且执行公共密钥证书验证处理(S54)。
下面参照图23说明公共密钥证书(PKC)的验证处理。图23所示的公共密钥证书(PKC)的验证是一个链处理流(chain processing flow)，其中通过从较低阶到较高阶跟踪证书链直到最高阶公共密钥证书，并且验证公共密钥证书的签名直到最高阶(根CA)，以获得链信息。首先，设置待验证的公共密钥证书(PKC)，根据公共密钥证书(PKC)的被存储信息标识公共密钥证书(PKC)的签名者(S32)。此外，确定该公共密钥证书是否为待验证的证书链的最高阶公共密钥证书(S33)，在不是最高阶的情况下，直接或者从存储库或类似物中获得最高阶公共密钥证书(S34)。当获得和设置最高阶公共密钥证书时(S35)，获得签名验证所需的验证密钥(公共密钥)(S36)，确定待验证的签名是否为自己的签名(S37)，在不是自己签名的情况下，则设置较低阶PKC(S39)，并且根据从最高阶公共密钥证书获得的验证密钥(公共密钥)执行签名验证(S40)。也就是说，在步骤S37的自己签名确定中，在该签名是自己的签名的情况下，则用自己的公共密钥作为验证密钥执行验证(S38)，并且流程前进到步骤S41。
如果签名验证是成功的(S41中的是)，则确定是否完成目标PKC的验证(S42)，并且如果已经完成该验证，则结束PKC验证。如果未完成该验证，则流程返回到步骤S36，并重复获取签名验证和较低阶公共密钥证书的签名验证所需的验证密钥(公共密钥)。如果签名验证失败(S41中的否)，则流程前进到步骤S43，并执行差错处理，比如停止随后的处理。
返回步骤S22，继续说明属性证书验证处理。如果图23所述的公共密钥证书的验证失败(S55中的否)，则流程前进到步骤S56，并执行差错处理。例如，取消随后的处理。在公共密钥证书的验证成功的情况下(S55中的是)，直接或者从存储库或类似物获得对应于属性证书(AC)的签名者的公共密钥证书，并且执行对应于属性证书(AC)的签名者的公共密钥证书的验证处理(S58)。
如果对应于属性证书(AC)的签名者的公共密钥证书的验证失败(S59中的否)，则流程前进到步骤S60，并执行差错处理。例如，取消随后的处理。如果公共密钥证书的验证是成功的(S59中的是)，则从对应于属性证书(AC)的签名者的公共密钥证书中提取公共密钥(S61)，并且利用已提取得公共密钥执行属性证书(AC)的签名验证处理(S62)。如果签名验证失败(S63中的否)，则流程前进到步骤S64，并执行差错处理，例如取消随后的处理。如果签名验证成功(S63中的是)，则属性证书验证结束，并且流程前进到随后的处理，例如为提供业务所执行的其它条件确认处理。
现在返回图20的顺序图继续进行说明。当由上述处理执行步骤S157中的组属性证书(Gp.AC)的验证时，安全模块(SM)向业务供应商(SP)输出验证结果，如果验证不成功，则执行差错处理并取消业务供应而不执行。在此情况下，可以执行其中通知终端实体组AC的验证不成功的处理。
一旦确认组属性证书验证(Gp.AC)成功和组属性证书(Gp.AC)的真实性，流程就前进到步骤S161。下面参照图24说明从步骤S161开始的处理。在步骤S161中，执行组属性证书(Gp.AC)的检查。根据业务供应商拥有的组信息数据库执行检查。
下面参照图25说明组属性证书的检查处理。在步骤S161中，业务供应商(SP)从已检验的组属性证书(Gp.AC)获取发放者信息。此外，在步骤S161-2中，从属性字段中获取属性值，即组标识信息(组ID)。
在步骤S161-3中，根据从组属性证书(Gp.AC)获取得AC发放者和组ID搜索组信息数据，并且确认是否存在已登记的实体。如果存在对应的登记实体，则在步骤S161-4中从组信息数据库获取组信息。
下面返回图24中的顺序图继续进行说明。如果不存在对应于组属性证书(Gp.AC)登记的组信息，或者如果用户不满足组信息中指示的条件，则检查不成功(S162中的否)，并且在步骤S163中执行差错处理。例如，向终端实体(EE)通告达到组AC的检查已经成功并且不可能执行业务的效果的消息。此外，如果多个组属性证书的验证和检查对于提供业务是必要的，则在业务信息数据库中管理这些条件。
业务信息数据库是存储关于组AC提供业务所需的信息的数据库。然而，不特别需要保持分别独立的上述组信息数据库和业务信息数据库，并且可以构成整合或者链接组信息数据库和业务信息数据库的数据库配置。也就是说，可以构成其中从上述组信息数据库或者组信息数据库的链接信息获取关于哪个组AC是提供业务所需的数据。在下文中，将说明还充当业务信息数据库的组信息数据库。
现在返回图24中的顺序图，继续进行说明。如果检查成功(S162中的是)，则确定执行业务是否需要其它条件。这些条件是业务供应商可以任意设置的条件。此外，在步骤S165中，确定其它组属性证书是否是提供业务所必需的。
这是假定如图26所示，用户或者用户装置属于作为业务供应条件的多个不同组的情况。例如，如图26(a)所示，可以做出通过证明属于两个不同组来提供业务的设置。
特别地，设置是当展示和验证两个组属性证书时提供业务；组属性证书A(组A)证明用户的住宅属于某个区域，组属性证书B(组B)指示用户是某个制造商的装置。
此外，如图26(b)所示，可以做出通过真名属于三个或者多个不同组提供业务的设置。特别是，设置是当展示和验证三个组属性证书时提供业务；组属性证书A(组A)证明用户的住宅属于某个区域，组属性证书B(组B)指示用户装置是某个制造商的装置，；组属性证书C(组C)指示用户的年龄在某个范围内。
这样，如果用户或者用户装置属于多个不同组的条件下提供业务，应用两个或者多个发放给用户或者用户装置的不同组属性证书，则业务供应商(SP)在步骤S166中请求终端实体展示另一个组属性证书(Gp.AC)。在步骤S167中，响应该请求，由终端实体(EE)把组属性证书发送给业务供应商(SP)的安全模块(SM)。安全模块(SM)执行从图20的步骤S157开始的处理，即关于从终端实体(EE)重新接收组属性证书的处理，也就是组属性证书验证处理、检查处理等等。
提供业务所需的组属性证书的验证和检查已经成功的条件下，在步骤S168中执行业务供应。这些业务是各种各样的，比如业务供应商提供的内容分配，付款处理，作为用户装置(例如，家用电器)的装置的远程控制，远程维护处理，通信业务等等。稍后将说明这些处理的特定实例。
下面参考图27和图28说明，根据对应于作为用户装置的用户标识装置(UID)内的用户安全芯片(USC)所发放的组属性证书，到达业务供应的处理。用户标识装置(UID)是充当个体标识装置的装置。组属性证书可以被单独地发放给终端实体和用户标识装置。主要是把发放给用户标识装置的组属性证书发行为能够确认用户他自己/她自己是否为某个组的成员的证书。UID具有可以经由终端实体(EE)进行外部通信的配置，所以还经由终端实体(EE)执行属性证书的使用处理。
按照图20的步骤S151至S155中的处理一样的方式，在终端实体(EE)内的安全芯片(SC)与业务供应商(SP)的安全模块(SM)之间执行图27的步骤S171至步骤S175。
如果在步骤S174中，在终端实体的安全芯片(SC)与业务供应商(SP)的安全模块(SM)之间建立相互认证，则在步骤S177中，在用户标识装置(UID)内的用户安全芯片(USC)与终端实体内的安全模块芯片(SC)之间执行相互认证。经由终端实体(EE)和用户表示装置(UIS)的连接装置接口231(参见图9)执行该验证处理。该验证处理可以被执行为基于图13所述的公共密钥方法的验证处理，以及为集中于安全芯片和安全模块的加密处理单元(参见图9)的处理。在步骤S178中，把包括验证已建立信息的验证完成通知告知终端实体(EE)，然后在已经建立验证的条件下，流程前进到下一个步骤。
在步骤S179中，把相互认证启动请求从终端实体(EE)输出到用户安全芯片(USC)，并且在步骤S180中，在USC于业务供应商(SP)的安全模块(SM)之间执行相互认证。在步骤S181中，从USC向终端实体(EE)通告包括验证已建立信息的验证已完成通知，并且在已经建立验证的条件下，在步骤S182中，用户标识装置(UID)向业务供应商(SP)的安全模块(SM)发送组属性证书(Gp.AC)。组属性证书(Gp.AC)是发放给用户标识装置(UID)的用户安全芯片(USC)的组属性证书(Gp.AC)。
一旦收到来自用户安全芯片(USC)的组属性证书(Gp.AC)，业务供应商(SP)的安全模块(SM)就在步骤S183中执行所接收的组属性证书的验证处理。该验证处理与参照图21至图23所述的处理相同。步骤S184至步骤S198(图28)的处理基本上与对应于参照图20和图24所述的终端实体的安全芯片(SC)的组属性证书的处理相同，因此将省略对其说明。然而在图28所示的步骤S197中，由用户标识装置(UID)执行新的组属性证书的发送。
如上所述，在没有与业务供应商(SC)的直接通信功能的用户标识装置(UID)获取对应于用户安全芯片(USC)的组属性证书的情况下，则存在通过终端实体(EE)的需要。此时，为了在用户安全芯片(USC)与业务供应商(SP)之间执行相互认证，执行例如以下各项的建立：
(1)EE的SC与业务供应商(SP)之间的相互认证，
(2)EE的SC与UID的USC之间的相互认证，
(3)UID的USC与业务供应商(SP)之间的相互认证。或者作为简单匹配，可以构成当连接EE时，EE就基本上接受(认为已验证)UID的处理配置，并且在此情况下，可以省略上述的相互认证(2)。此外，可以实现上述三种不同组合下的验证配置。
请注意，尽管在图20和图24中，已经说明了使用对应于终端实体(EE)的安全芯片(SC)的组属性证书的处理，并且在图27和图28中，已经说明了使用发放给用户标识装置(UID)的用户安全芯片(USC)的组属性证书的处理，但是，可以做出基于多个组属性证书的验证和检查提供业务的配置，即，比如先前参照图26所述的、对应于终端实体(EE)的安全芯片(SC)的组属性证书，和发放给用户标识装置(UID)的用户安全芯片(USC)的组属性证书。在这种情况下，组合并执行如图27和图28中所示的处理和图20和图24中所示的处理。
例如，可以做出一个配置，其中业务供应商根据从基于具有作为成员的终端实体的组定义的第一组属性证书获取的第一组标识信息，执行关于充当用户装置的终端实体是否为业务准许的对象的检查，并且根据从基于具有作为成员的终端实体的组定义的第二组属性证书获取的第二组标识信息，执行关于发自用户标识装置的用户是否为业务准许的对象的检查，以及在所有组标识信息都被确定为是准许业务的对象的条件下，执行业务准许确定处理。
(4)用户装置之间的组属性证书的发放和使用处理
在上述说明中，组属性证书已经被描述为主要用作从业务供应商向用户装置提供的确认业务使用权限的证书。尽管组属性证书发放实体主要是组属性证书管理机构(组AA)，但是可以做出其中业务供应商(SP)执行组属性管理机构(组AA)和组ARA的功能的安排，以便依据业务供应商(SP)的自己的策略发放组属性证书。此外，可以做出用户装置自身执行组属性管理机构(组AA)和组ARA的功能的安排，以便依据用户装置自己的策略发放组属性证书。以下是对其中用户装置发放组属性证书并利用组属性证书执行对用户装置的访问限制的配置的说明。
对于特定的使用安排，认为访问权限管理安排，其中，如果作为例如具有通信功能的通信处理的用户装置(终端实体)打算只允许某些成员访问，则用户装置发放某些成员被设置为组的组属性证书，并且其它用户装置请求访问需要展示所发放的组属性证书，检验所展示的组属性证书，并准许访问。
尽管可以利用其中业务供应商(SP)发放组属性证书的配置来实现该业务供应安排，即访问准许业务供应安排，但是把某些朋友、家庭成员、同一公司、学校等设置为一组，并且生成和发放被存储为对应所设置组的组标识信息的组属性证书的用户装置可以在个体等级(individual level)上实现访问安排。
首先，将参照图29对发放组属性证书并将其存储在诸多用户装置中的请求进行说明。
下面参照图29对充当是用户装置的通信处理装置的终端实体(EE)的安全芯片(SC)是组属性证书的发放实体的情况进行说明。请注意在图29中，
UID：访问请求用户标识装置(用户装置)控制单元，
USC：配置在UID内的访问请求用户安全芯片，
访问请求EE：访问请求终端实体(用户装置)控制单元，
SC1：配置在访问请求EE内的安全芯片，
被访问请求的EE：被访问请求的终端实体(用户装置)控制单元，和
SC2：配置在被访问请求的EE内的安全芯片。
这里访问EE和被访问EE分别是不同的用户通信处理装置。此外，安全芯片(SC1和SC2)和用户安全芯片(USC)具有图9所示的安全芯片相同的配置，通过验证安全芯片上的组属性证书，执行访问权限确定处理和类似处理。
也就是说，用如网络接口等的接收单元接收从访问请求装置向被访问请求的装置发送的组属性证书的被访问请求的装置，把被接收的组属性证书递交给充当访问权限确定处理单元的安全芯片，并且根据安全芯片内的已接收的组属性证书执行访问权限确定处理。
请注意，图29的处理顺序图说明了从证明访问权限的组属性证书发放处理的阶段开始的处理过程。也就是说，首先，通信处理装置的安全芯片执行组属性装置生成处理，并且执行证明权限的组属性证书地发放处理。接着，在该顺序中，在通信处理装置之间交换已发放的组属性证书，从而确认访问权限。因此，通信处理装置的安全芯片充当组属性证书的生成装置和检验装置。
下面说明图29的顺序图的处理过程。首先，在步骤S210中，访问请求用户经由终端实体(访问EE)的输入接口输入组属性证书(Gp.AC)的新的发放命令。
当终端实体(访问EE)收到来自用户的组属性证书(Gp.AC)发放请求的输入，在步骤S202中，终端实体(访问EE)向被访问请求的终端实体(被访问EE)提出连接请求，另一方面，在步骤S203中，向访问终端实体(访问EE)内的安全芯片(SC)输出验证启动请求。
在步骤S204中，在访问请求用户装置的安全芯片(SC1)与被访问请求的终端实体(被访问EE)的安全芯片(SC2)之间执行相互认证。该相互认证按参照图13所述的公共密钥证书相互认证处理来执行。在步骤S205中，在访问请求用户装置的安全芯片(SC1)与用户安全芯片(USC)之间执行相互认证，并且在步骤S206中，在访问请求用户安全芯片(USC)与对应于被访问请求的终端实体(被访问EE)的安全芯片(SC2)之间执行相互认证。在步骤S207中，包括相互认证建立/未建立的相互认证完成通知从访问请求用户安全芯片(USC)输出到终端实体(EE)。
请注意，如果发放对应于访问请求用户安全芯片(USC)的组属性证书，则步骤S205至S207的处理是必需的处理，并且如果发放对应于访问请求安全芯片(SC1)的组属性证书，则可以省略步骤S205至S207的处理。
如果未建立上述相互认证的任何一个，则取消处理的继续。如果建立了所有相互认证，则在步骤S208中，访问请求终端实体(EE)向被访问请求的安全芯片(SC2)展示它已经拥有的组属性证书(Gp.AC)，并且请求新的组属性证书(Gp.AC)的发放。
这里的处理是用于验证访问请求者已经拥有的组属性证书(Gp.AC)并且发放具有不同定义的新的组属性证书(Gp.AC)的处理的实例。也就是说，由现存的组属性证书(Gp.AC)的属性确认被包含在要新发放的组属性证书(Gp.AC)地发放策略中。例如，根据已经存在的组属性证书(Gp.AC)执行用户的标识的确认、装置是某制造商的装置的确认等，并且在做出确认的条件下执行新的组属性证书(Gp.AC)的发放处理。
现存的组属性证书(Gp.AC)的实例是***公司发放的组属性证书，例如通过执行与用户标识装置(UID)的用户安全芯片(USC)的相互认证，对应于用户发放组属性证书。另一个是作为与终端实体(EE)的安全芯片(SC)的相互认证的结果的终端实体(EE)中存储的组属性证书，其中所述终端实体(EE)比如是充当通信处理装置、PC或类似装置的通信终端，并且该证书证由证明制造商已经制造该终端的该制造商发放。
被访问请求的装置的安全芯片(SC2)检验从访问请求装置的终端实体(EE)接收的已经发放的组属性证书。该验证处理是与参照图21至图23所述的处理相同的处理，并且是包括属性证书签名验证、对应和链公共密钥证书验证等的处理。
被访问请求的安全芯片(SC2)向被访问请求的终端实体(EE)输出验证结果，并且如果验证是不成功的，则不执行后续处理而是取消该处理，作为错误处理。在此情况下，可以执行把差错通知发送给访问中断实体(EE)的处理。
如果组属性证书(Gp.AC)的验证是成功的，并且已经确认组属性证书(Gp.AC)的真实性，则流程前进到步骤S211。在步骤S211中，执行组属性证书(Gp.AC)的检查。根据被访问请求的终端实体(EE)拥有的组信息执行检查。该检查处理是与参照图25所述的处理相同的处理。也就是说，从已检验的组属性证书(Gp.AC)获取发放者信息和组标识信息(组ID)，根据所获得的AC发放者和组ID搜索组信息数据库，并且确认是否存在已登记的实体。如果存在对应的登记实体，则从组信息数据库获取组信息。
如果不存在对应于组属性证书(Gp.AC)的登记的组信息，或者如果不满足组信息条件，则检查是不成功的，以及作为差错取消该处理。另一方面，如果检查是成功的，则在步骤S212中，根据请求，把新的组属性证书生成请求输出到安全芯片(SC2)，该安全芯片(SC2)在步骤S213中根据请求生成组属性证书，并且在步骤S214中把新的组属性证书(Gp.AC)从被访问终端实体(EE)发放给访问用户装置的用户标识装置(UID)。
在访问请求用户装置是例如通信终端装置的情况下，如存储公司B的安全信息的PC，则新发放的组属性证书将对应于这样的属性，比如：
“从公司B发放给UID的“公司B的职员”的属性”，
“从公司B发放给UID的“计划C的成员”的属性”或类似属性。
是诸如存储公司B的安全信息的PC的通信终端装置的访问请求用户装置，在不确定的用户装置提出访问请求的时候，可以请求组属性证书的展示，执行已展示的组属性证书的验证和检查，并确定访问是否可准许。
下面参照图30说明具有作为属性的访问准许信息的组属性证书的发放处理顺序。在图30中，步骤S221至步骤S235对应于图29中的步骤S201至S215，并且其处理是相同的。
在图30中，在步骤S228中，访问请求终端实体(访问EE)展示给访问被请求用户装置的组属性证书是具有“从公司B发放给UID的“公司B的职员”的属性”的证书，并且被访问请求的用户装置的安全芯片(SC2)执行该属性证书的验证和检查，并发放新的组属性证书，即具有作为属性的准许访问装置(被访问请求的用户装置)的属性信息的证书。
现在，如果作为发放具有是准许访问装置(被访问请求的用户装置)的组信息的属性信息的证书的条件，除“从公司B发放给UID的“公司B的职员”的属性”之外还需要另一个组属性证书的证据，则重复与组属性证书所需的数量一样多次的步骤S228至S231的处理。
下面参照图31说明具有作为组信息的访问准许信息的组属性证书与另一个组属性证书之间相互关系的实例。在图31(a)中，具有作为组信息的访问准许信息的组属性证书对应于组δ，并且发放对应于该组δ的组属性证书的条件例如是组α的成员。可以用证明“从公司B发放给UID的“公司B的职员”的属性”的组属性证书证明是组α的成员，并且在展示了证明组α的成员资格的组属性证书以及验证和检查已经成功的条件下，发放对应于组δ的组属性证书。
在图31(b)中，具有作为组信息的访问准许信息的组属性证书对应于组δ，并且发放对应于该组δ的组属性证书的条件是例如满足是组α的成员，是组β的成员，是组γ的成员的所有条件。
特别地，设置是在展示和验证三个组属性证书时具有作为组信息的对应于组δ的访问准许信息的条件下发放组属性证书；组属性证书α(组α)证明用户的住宅属于某个区域的，组属性证书β(组β)指示用户装置是某个制造商的装置；组属性证书γ(组γ)指示用户年龄为某个范围之内。
通过向作为构成访问请求装置的个体标识装置的用户标识装置发放组属性证书，甚至在作为通信处理装置的终端实体(EE)已经被改变的情况下，可以在根据发放给充当个体标识装置的用户标识装置的组属性证书进行检查时准许访问，从而避免了由于改变通信处理装置(终端实体(EE))而拒绝访问的情况。
下面参照图32说明访问请求装置本身不执行属性证书发放处理而是委托另一个用户装置进行属性证书发放处理所执行的处理顺序。在图32中，
UID：访问请求用户标识装置(用户装置)控制单元，
USC：配置在UID内的访问请求用户安全芯片，
访问请求EE：访问请求终端实体(用户装置)控制单元，
SC1：配置在访问请求EE中的安全芯片，
被访问请求的EE：被访问请求的终端实体(用户装置)控制单元，
SC2：配置在被访问请求的EE内的安全芯片，
其它EE：第三用户装置(过程代理用户装置)
SC3：其它EE的安全芯片。
在图32中，步骤S241至步骤S248对应于图29中的步骤S201至S208，并且处理是相同的，因此将省略对其说明。在步骤S248中，被访问请求的用户装置终端实体(被访问EE)把访问请求终端实体(访问EE)所展示的组属性证书转交给过程代理用户装置的安全芯片(SC3)，安全芯片(SC3)执行被转交的组属性证书的验证(S250)，并且过程代理用户装置的终端实体(其它EE)还根据验证结果通知(S251)执行检查(S252)。
此外，在验证和检查已经成功的条件下，组属性证书生成请求被输出给安全芯片(SC3)(S253)；在步骤S254中，安全芯片(SC3)根据该请求生成组属性证书；在步骤S255中，新的组属性证书(Gp.AC)从过程代理终端实体(其它EE)发放给访问请求用户装置的用户标识装置(UID)；在步骤S257中，访问请求用户装置的用户标识装置(UID)存储已接收的组属性证书。
图32所示的处理顺序是一个配置，其中如果被访问请求的用户装置没有属性证书验证、检查和发放功能，则可以委托第三装置执行这些处理。请注意，过程代理用户装置可以由业务供应商(SP)或类似装置构成。
下面参照图33说明使用其中访问准许信息被定义为组信息的组属性证书进行访问准许/不准许确定处理的业务使用顺序。
首先，在步骤S261中，是组属性证书(Gp.AC)使用处理的访问请求命令是访问请求用户经由终端实体(访问EE)的输入接口输入。
当终端实体(访问EE)接收来自用户的请求时，在步骤S262中，终端实体(访问EE)提出对被访问请求的终端实体(被访问EE)的连接请求，并且在另一方面，在步骤S263，向访问中断实体(访问EE)内的安全芯片输出相互认证启动请求。
在步骤S264中，在访问请求用户装置的安全芯片(SC1)与被访问请求的终端实体(被访问EE)的安全芯片(SC2)之间执行相互认证。该相互认证被执行为例如参照图13所述的公共密钥证书相互认证处理。在步骤S265中，在访问请求用户装置的安全芯片(SC1)与用户安全芯片(USC)之间执行相互认证；并且在步骤S266中，在访问请求用户安全芯片(USC)与对应于被访问请求的终端实体(被访问EE)的安全芯片(SC2)之间执行相互认证。在步骤S267中，从访问请求用户安全芯片(USC)向终端实体(EE)输出包括相互认证建立/未建立的相互认证完成通知。
请注意，如果使用对应于访问请求用户安全芯片(USC)的组属性证书，则步骤S265至步骤S267的处理是必需的处理，如果使用对应于访问请求安全芯片(SC1)的组属性证书，则可以省略处理步骤S265至S267。
如果未建立上述相互认证的任何一个，则取消该处理的继续。如果建立了所有相互认证，在步骤S268中，访问请求终端实体(EE)则把组属性证书(Gp.AC)展示给被访问请求的安全芯片(SC2)，并请求访问准许。
被访问请求的装置的安全芯片(SC2)验证从访问请求终端实体(EE)接收的组属性证书(S269)。该验证处理与先前参照图21至图23所述的处理相同，并且是包括属性证书签名验证、对应和链公共密钥证书验证等地处理。
被访问请求的安全芯片(SC2)把验证结果输出给被访问请求的终端实体(EE)(S270)，并且如果验证是不成功的，则不执行随后的处理，而是作为差错处理取消该处理。在此情况下，可以执行向访问终端实体(EE)发送差错通知的处理。
如果组属性证书(Gp.AC)的验证是成功并且已经确认了组属性证书(Gp.AC)的真实性，则流程前进到步骤S721。在步骤S271中，执行组属性证书(Gp.AC)的检查。基于被访问请求的终端实体(EE)拥有的组属性数据库执行检查。这个检查处理与参照图25所述的处理相同。也就是说，从已验证的组属性证书(Gp.AC)获得发放者信息和组标识信息(组ID)，并且基于已获得的AC发放者和组ID搜索组信息数据库，以及确认是否存在已登记得实体。如果存在对应的登记实体，则从组信息数据库获得组信息。组信息包括诸如“准许该装置访问”或者“只准许数据读出”等的信息，并且在该确认之后提供业务。
如果不存在对应于组属性证书(Gp.AC)登记的组信息，或者如果不满足组信息条件，则检查不成功，并且作为差错取消该处理。另一方面，如果该检查是成功的，则在步骤S272中准许业务供应，即准许访问作为组信息登记的业务，例如一个装置。
(5)组属性证书的特定使用实例
(5-1)内容分配业务
(5-2)远程控制业务
(5-3)远程维护业务
(5-4)个人通信业务
下面分别说明这些使用安排。
图34显示了用于各种业务的组属性证书的实例。图34以相关方式示出了组属性证书发放者、发放定时、持有者、验证者和属性。如上所述，发放者除了可以是仅仅执行组属性证书发放处理的组ARA之外，还可以是各种发放实体，比如业务供应商、用户装置等，业务供应商的实例包括：发放***的“***公司A”、比如“公司B”或“市政厅”的某个组织、个体用户“A先生”、制造商终端实体(EE)如PC、通信终端、游戏机等的“EE制造商C”。
可以根据基于证书提供的业务把发放组属性证书的定时设置为各种定时，比如在如PC、通信终端、游戏机等的终端实体(EE)的购买时、制造时或者购买后的任意定时。
组属性证书的持有者是作为某个组的成员的用户或者用户装置，并且以例如“A先生”的用户作为其持有者发放的组属性证书是基于A先生的用户标识装置(UID)的用户安全芯片(USC)的验证被发放给用户安全芯片(USC)的，并且分发给例如家庭的成员的组属性证书是基于该家庭成员的用户标识装置(UID)的用户安全芯片(USC)的验证被发放给用户安全芯片(USC)的，并且提供给诸如PC、通信终端、游戏机等的用户装置的组属性证书是基于用户安全芯片(USC)的验证被发放给终端实体(EE)的安全芯片(SC)的。
这些组属性证书的验证处理的执行者是根据组属性证书证明的属性提供业务的业务供应商(SP)的安全模块(SM)，或者是用户装置的安全芯片(SC，USC)(尽管图中未示出)。
组属性证书证明的持有者属性的实例包括：“***公司A成员”、“公司B的职员”、“A先生的家庭”、“已登记的用户”、“已登记的用户装置”、“组属性证书发放者的装置(EE)”、“A先生的装置(EE)”等等，具有通过验证和检查组属性证书，证明组属性证书中的关于展示的用户或者展示的装置的上述属性。组属性证书验证者比如业务供应商等根据已证明的持有者属性提供预定业务。
(5-1)内容分配业务
首先对使用组属性证书的内容分配业务进行说明。在应用组属性证书的内容分配中，存在确认内容使用权限的各种安排。
首先，作为一个实例，说明一个处理实例，其中根据证明用户是持有***公司发放的***的成员的第一组属性证书A、作为包含作为组信息的内容使用准许信息的内容分配业务实体的内容分配业务供应商发放的第二组属性证书B，并且一旦执行内容分配业务，就应用第二组属性证书B执行内容使用权限的确认。
下面参照图35根据证明用户装置是***成员的第一组属性证书A，说明发放包括作为组信息的内容使用权限的第二组属性证书B的处理。
在图35的实例中，发给用户标识装置(UID)的用户安全芯片(USC)的证明***成员资格的第一组属性证书A被展示给组属性证书登记管理机构(Gp.ARA)，并且组属性管理机构(Gp.AA)发放内容分配业务供应商是发放实体的第二组属性证书B。这里，内容分配业务供应商被假定为在组属性证书发放策略上与组属性证书登记管理机构(Gp.ARA)一致。
在图35中，
UID：用户标识装置(用户装置)控制单元，
USC：配置在UID内的用户安全芯片，
EE：终端实体(用户装置)控制单元，
SC：配置在EE内的安全芯片，
组ARA：组属性证书登记管理机构控制单元，
组AA：组属性管理机构控制单元。
首先，在步骤S301中，用户经由终端实体(EE)的输入接口输入组属性证书(Gp.AC)发放请求命令。此时，用户输入发放组属性证书所需的属性值。属性值是组ID或者是证明属于该组的信息。
一旦收到从终端实体(EE)的用户输入的组属性证书(Gp.AC)发放请求，在步骤S302中，在用户安全芯片(USC)与组ARA之间执行相互认证。尽管这里作了省略，但此时为了在没有直接与组ARA进行通信的功能的用户标识装置(UID)之间执行相互认证，执行例如以下各项的建立：
(1)EE的SC与组ARA之间的相互认证，
(2)EE的SC与UID的USC之间的相互认证，
(3)UID的USC与组ARA之间的相互认证。或者作为较简单配置，可以构成当连接EE时EE基本接受(认为已经验证的)UID的处理配置，并且在此情况下，可以省略上述相互认证(2)。此外，可以实现上述三种不同组合之下的认证配置。
该验证处理主要被执行为，相应装置的安全芯片的加密处理单元(参见图9)上的加密处理，比如参照图13所述的公共密钥相互认证处理。在步骤S303中，从用户安全芯片(USC)向终端实体输出包括相互认证建立/未建立的结果信息的相互认证完成通知。如果未建立相互认证，则取消处理的继续。如果建立了相互认证，则在步骤S304，终端实体(EE)向组ARA发送组属性证书(Gp.AC)发放请求。组属性证书(Gp.AC)发放请求包括终端实体信息和属性信息(例如，组ID，组信息)，并且还包括证明是***成员的第一组属性证书A，该第一组属性证书A将要作为发放其中内容分配供应商是发放实体的第二组属性证书的条件来展示。
在验证证明是***成员的第一组属性证书A之后，接收来自终端实体(EE)的组属性证书(Gp.AC)发放请求的组ARA在步骤S305中参阅发放策略表，以确定是否可以顺从该策略发放组属性证书，如果准许发放证书，则流程前进到步骤S306，如果不准许发放证书，则用不准许发放消息通知终端实体。
在步骤S306中，组ARA向组AA发送具有属性值(组ID)的组属性证书(Gp.AC)发放请求；在步骤S307中，组AA存储作为属性信息的组ID，产生附有电子签名的组属性证书，即包括作为组信息的内容使用准许信息的第二组属性证书B，并将其发送给组ARA。
在步骤S308中，组ARA向用户标识装置(UID)发送已发放的组属性证书(Gp.AC)。用户标识装置(UID)存储已经接收的组属性证书(Gp.AC)。此时，执行组属性证书(Gp.AC)的电子签名的验证，并在确定没有篡改后，将其存储在存储器中。
下面，参照图36说明处理，其中，通过上述处理发放的组属性证书B，即包括作为组信息的内容使用准许信息的第二组属性证书B被展示给业务供应商，确认存在内容使用权限，并且接收业务供应，即内容分配业务。在步骤36中，
UID：用户标识装置(用户装置)控制单元，
USC：配置在UID内的用户安全芯片，
EE：终端实体(用户装置)控制单元，
SC：配置在EE内的安全芯片，
SP：业务供应商控制单元，和
SM：SP内的安全模块。
请注意，安全芯片(SC)、用户安全芯片(USC)和安全模块(SM)具有与图9所述的安全芯片的相同的配置，并且通过在安全芯片上验证组属性证书执行权限确定处理和类似处理。也就是说，用作为网络接口或类似接口的接收单元接收从业务请求装置发送到业务被请求装置的组属性证书的业务供应商，把已接收的组属性证书交给作为权限确定处理单元的安全模块(芯片)，并且根据安全模块(芯片)内接收的组属性证书执行权限确定处理。
首先，在步骤S311中，用户经由实体(EE)的输入接口输入组属性证书(Gp.AC)使用请求命令。此时，用户指定在待使用的组属性证书中设置的组ID。然而，如果通过指定某个业务可以确定单个组ID，则可以进行其中仅仅指定业务的安排。
一旦终端实体(EE)收到用户输入的组属性证书(Gp.AC)使用请求，就在步骤S312中，在用户安全芯片(USC)与业务供应商的安全模块(SM)之间执行相互认证。尽管在这里的说明中做出了省略，但是如果用户标识装置(UID)没有与业务供应商(SP)的直接通信功能，则执行以下各项：
(1)EE的SC与SP-SM之间的相互认证，
(2)EE的SC与UID的USC之间的相互认证，
(3)UID的USC与SP-SM之间的相互认证。或者作为更简单的配置，构成其中当连接EE时EE就基本接受(认为已验证)UID的处理配置，并且在此情况下可以省略上述的相互认证(2)。此外，可以实现上述三种不同组合之下的认证配置。
该验证处理被执行为，集中于安全芯片和安全模块的加密处理单元的先前参照图13所述的公共密钥相互认证处理。在步骤S313中，从安全芯片向终端实体输出包括相互认证建立/未建立结果信息的相互认证完成通知。如果未建立相互认证，则在步骤S314中，用户安全芯片(USC)把它自己存储器中存储的组属性证书(Gp.AC)发送给业务供应商(SP)的安全模块(SM)。该组属性证书(Gp.AC)是第二组属性证书B，其包括作为组信息的由参照图35所述的处理定义的内容使用准许信息。
在步骤S315中，从用户安全芯片(USC)接收组属性证书(Gp.AC)的安全模块(SM)执行组属性证书验证处理。组属性证书的验证处理如同参照图21至图23所述的处理，并且作为包括属性证书签名验证、对应的公共密钥证书(PKC)和链公共密钥证书确认处理的处理来执行。
在组属性证书(Gp.AC)的验证处理之后，安全模块(SM)向业务供应商(SP)输出验证结果，并且如果未建立验证，则不执行业务供应，并且取消处理作为差错处理。在此情况下，可以执行其中向终端实体通知不建立组AC的验证的结果的处理。
如果组属性证书(Gp.AC)的验证是成功的，并且已经确认组属性证书(Gp.AC)的真实性，则流程前进到步骤S317。在步骤S317，执行参照图25所述的组属性证书(Gp.AC)的检查。根据业务供应商拥有的组信息数据库执行该检查。也就是说，业务供应商(SP)从已验证的组属性证书(Gp.AC)获取发放者信息和组ID，根据所获取的信息检查组信息数据库，并且确认是否存在已登记的实体。如果存在对应的已登记实体，则从组信息数据库获取组信息。
此情况下的组信息是内容使用准许信息的组信息，例如3个月的游戏X的信息准许使用，等等。在步骤S318中，业务供应商(SP)执行业务供应，即根据组信息向用户装置的终端实体(EE)分配具有3个月使用期限设置的游戏程序。
尽管上述内容分配业务处理是用一个组属性证书执行内容使用权限确认的实例，但是下面将对于当应用证明不同的组属性的多个不同组属性证书来确认用户或者用户装置的内容使用权限时，提供业务的情况进行说明。
图37图示了适用于本实例的多个组属性证书。组属性证书(Gp.AC)AC01由大学A发放，并且是证明持有者是大学A的学生的学生ID卡，并且是根据与C的用户标识装置(UID)的用户安全芯片(USC)的验证来发放的组属性证书(Gp.AC)。组属性证书(Gp.AC)AC02由大学A发放，并且是证明持有者具有得到艺术课的权限的艺术课参与者卡，并且是根据与C的用户标识装置(UID)的用户安全芯片(USC)的验证来发放的组属性证书(Gp.AC)。
组属性证书(Gp.AC)AC03由大学A发放，并且是证明装置大学A管理的装置的被管理装置证书，并且是根据与充当终端实体(EE)的电视机D的安全芯片(SC)验证而发放的组属性证书(Gp.AC)。组属性证书(Gp.AC)AC04由教育、文化、体育、科学和技术部发放，并且是证明装置是用户教育使用的装置的教育装置证书，并且是根据与充当终端实体(EE)的电视机D的安全芯片(SC)的验证发放的组属性证书(Gp.AC)。
下面参照图38说明应用这四种不同的组属性证书AC01至AC04的内容使用权限确认和业务供应处理。
图38的左侧显示了用户装置方处理，右侧显示了业务供应商方处理。请注意，用户装置包括终端实体(EE)，EE内的安全芯片(SC)，用户标识装置(UID)以及UID内的用户安全芯片(USC)。
在步骤S321和步骤S331中，在用户装置与业务供应商之间执行相互认证处理。请注意，利用在EE的一个或者两个SC与SP-SM之间以及UID的USC与SP-SM之间执行的相互认证，根据对其发放的待展示的组属性证书的装置来执行相互认证。
在本实施例的情况下，在图37所示的四个组属性证书之中，AC01和AC02被发放给了C的用户标识装置(UID)的用户安全芯片(USC)，AC03和AC04被发放给了配置在充当终端实体(EE)的电视机D中的安全芯片(SC)，所以处理包括：C的用户标识装置经由连接装置接口231(参见图9)连接充当终端实体(EE)的电视机D，经由充当终端实体(EE)的电视机D的网络接口232(参见图9)连接业务供应商(SP)的安全模块(SM)，以及在EE地SC与SP-SM之间执行相互认证，已经在UID的USC与SP-SM之间执行相互认证。
该验证处理被作为集中于安全芯片和安全模块的加密处理单元的参照图13所述的公共密钥相互认证处理而执行。如果未建立相互认证，则取消处理的继续。如果建立了相互认证，则在步骤S322中，装置向业务供应商(SP)的安全模块(SM)发送它自己的存储器中存储的多个组属性证书(Gp.AC)AC01至AC04。组属性证书(Gp.AC)AC01至AC04是图37所示的四种组属性证书。
在提供业务的时候，组属性证书需要的组合数据可以是从业务供应商向用户方通知的配置的数据。业务供应商拥有作为例如图39所示的业务供应条件设置的组属性证书组合表数据。在图39的实例中，存储数据，指示为了观看作为业务的内容B，作为大学A发放的学生ID卡的组属性证书，指示作为由教育、文化、体育、科学和技术部发放的教育装置证书的组属性证书，是必需的，并且这个表适用于向用户装置通知必要的组属性证书的展示。
在步骤S332中，从该实例的用户装置接收提供业务所需的四种组属性证书(Gp.AC)AC01至AC04的安全模块(SM)在步骤S333中，从多个组属性证书中顺序地选择一个组属性证书，并执行验证处理。组属性证书验证处理如参照图21至图23所述，并且作为包括属性证书签名验证、对应公共密钥证书(PKC)和链公共密钥证书确认处理的处理而执行。
在组属性证书(Gp.AC)验证处理之后，如果未建立验证(步骤S334的否)，不执行业务的供应并且取消该处理作为错误处理(S339)。在此情况下，可以执行把未建立组AC验证的结果通知该给终端实体的处理。
如果组属性证书(Gp.AC)的验证是成功的(S334的是)，并且已经确认组属性证书(Gp.AC)的真实性，则流程前进道步骤S335。在步骤S335，则执行参照图25所述的组属性证书(Gp.AC)的检查。该检查是基于业务供应商拥有的组信息数据库执行的。也就是说，业务供应商从已验证证明的组属性证书(Gp.AC)中获取发放者信息和组ID，根据已获得的信息搜索组信息数据库，并且确认是否存在已登记的实体。如果存在对应的已登记实体，则从组信息数据库获得组信息。此情况下的组信息是包括内容分配准许信息的信息。
如果组属性证书的检查失败(S336的否)，例如如果获得组信息已经失败，则不执行业务供应，并取消该处理作为错误处理(S339)。在此情况下，可以执行把未建立组AC的验证结果通知给终端实体的处理。
如果组属性证书的检查被建立(S336的是)，则确定所有已展示的组属性证书的验证和检查是否已经结束，并且如果还没有全部结束，则对还没有完成的组属性证书执行从步骤S333开始的验证和检查处理。
如果在步骤S337中确定对展示的组属性证书的所有验证和检查都已经结束，则在步骤S338中执行业务，并且用户装置在步骤S340执行业务接收。特别是，用户C可以在是终端实体的电视机D(参见图37)上观看分发的内容。
图40显示了应用上述多个组属性证书的使用权限确认处理的模型图。也就是说，利用图40中组AC01至AC04图示说明定义四种不同类型属性的定义范围，以便准许上述内容的使用权限，存在如图40的(a)所示的用户组属性和如图40的(b)所示的装置的装置组属性之需要，其中所述用户组属性属于学生ID卡(组属性证书(AC01))和艺术课参与者卡(AC02)的两个组，所述装置的装置组属性用来满足拥有作为装置组属性的管理装置证书和教育装置证书的条件。
通过验证和检查对应于用户标识装置(UID)的用户安全芯片(USC)的组属性证书，确认属于作为图40的(a)所示的用户组属性的学生ID卡(组属性证书(AC01))和艺术课参与者卡(AC02)的两个组的证据，并且通过验证和检查对应于终端实体(EE)的安全芯片(SC)的组属性证书，确认是拥有作为图40的(b)所示的装置组属性的管理装置证书和教育装置证书的装置的证据。
请注意，利用参照图39所述的流程图，对于在四个组属性证书的验证和检查都是成功的条件下执行处理以便提供业务，而不是对于在四个组属性证书的验证和检查都是成功的条件下提供业务，执行发放新的组属性证书以准许业务供应的处理，用户重新展示这个新发放的组属性证书，并且其验证能够实现业务供应。
然而请注意，在此情况下，新发放的组属性证书定义用户组和装置组的两个组，所以匹配组定义的用户标识装置(UID)被设置为匹配组定义的装置(EE)，并且通过在UID的用户安全芯片(USC)与业务供应商(SP)的安全模块(SM)之间的相互认证建立UID的用户安全芯片(USC)的验证，此外，通过终端实体(EE)的安全芯片(SC)与业务供应商(SP)的安全模块(SM)之间的相互认证建立安全芯片(SC)的验证。此外，为上述新发放的组属性证书建立的验证和检查是使用业务的条件。
(5-2)远程控制业务
业务使用实例是通过执行权限确认，执行作为终端实体(EE)的装置的远程控制，作为基于组属性证书的数据处理***配置的一个实例。
这里将说明一个医疗处理实例，其中医疗装置是终端实体(EE)，安装在住宅中的医疗装置和充当业务供应商的医院侧医疗装置(SP)进行通信，以便根据安装在住宅中的医疗装置(EE)执行的用户医疗诊断以及检查，医院侧医疗装置(SP)发送命令，并且安装在住宅中的医疗装置(EE)把诸如检查数据等的已获得信息发送到医院侧医疗装置(SP)。
在执行数据处理***的每个处理以执行上述医疗处理的时候，根据每个组属性证书的验证和检查确认是否可以进行处理，并且在执行准许/不准许确认之后，进行关于医疗处理过程的各种数据处理。图41显示了待应用的组属性证书的实例。
组属性证书AC01的发放者是充当业务供应商(SP)的医院侧医疗装置；持有者，即通过与医院侧医疗装置(SP)(是发放证书时的组属性证书AC01的发放者)执行验证处理，发放组属性证书的对象，是利用住宅侧医疗装置(EE)接收医疗服务的A先生的用户标识装置(UID)的用户安全芯片(USC)。或者，这可以是住宅侧医疗装置(EE)的安全芯片(SC)。
在确定是否可以执行医疗程序的确认处理时，应用组属性证书AC01，并且从是持有者的用户装置的USC或者SC向医院侧医疗装置(SP)发送该组属性证书，在验证和检查组属性证书AC01之后，医院侧医疗装置(SP)准许该业务，即运行医疗诊断程序。
组属性证书AC02的发放者是住宅侧医疗装置(EE)；其持有者，即在发放组属性证书AC02时，通过与作为发放者的住宅侧医疗装置(EE)执行验证处理，发放组属性证书的对象，是充当业务供应商(SP)的医院侧医疗装置的安全模块(SM)。
组属性证书AC02是通过执行医疗程序从诊断(A先生)主题获得的，并且在确定是否可以执行从住宅侧医疗装置(EE)向医院侧医疗装置(SP)发送诊断数据(比如，血压值，脉搏，血样数据等)的处理时，应用该组属性证书AC02。
组属性证书AC02从医院侧医疗装置(SP)发送到住宅侧医疗装置(EE)，并且在住宅侧医疗装置(SP)验证和检查组属性证书AC02之后，执行业务、业务供应，即医疗诊断结果数据的发送处理。
请注意，尽管可以从医院侧医疗装置(SP)或住宅侧医疗装置(EE)，或者充当组属性管理机构(组AA)和组属性证书登记管理机构(组ARA)的用户标识装置(UID)发放组属性证书AC01和AC02的发放处理，但是也可以做出委托组属性管理机构(组AA)和组属性证书登记管理机构(组ARA)执行发放处理的配置。然而，在此情况下，执行遵从发放者策略的处理是一个条件。
例如，对于组属性证书AC01的发放处理，优选的方法是，作为发放者的医院侧医疗装置(SP)，或者作为发放代理的组属性证书登记管理机构(组ARA)使作为医疗诊断对象的A先生展示证明用户是A先生的已发放的组属性证书，比如由***公司发放的组属性证书，并且在验证已展示的组属性证书之后，执行新的组属性证书AC01的发放处理。依据这样的已经发放的组属性证书的验证的条件发放新的组属性证书的处理顺序与参照图29、图30、图32等所述的处理顺序相同。
同样地，对于组属性证书AC02的发放处理，优选的方法是，作为发放者的住宅侧医疗装置(EE)，或者作为发放代理的组属性证书登记管理机构(组ARA)使医院侧医疗装置(SP)展示证明它是医院侧医疗装置(SP)的已发放的组属性证书，比如由制造商或者公共管理组织发放的组属性证书，并且验证已展示的组属性证书之后，执行新的组属性证书AC02的发放处理。
在执行医疗处理的远程控制***中，存储在装置中的组属性证书如图42所示。充当业务供应商的医院侧医疗装置(SP)401和充当终端实体的住宅侧医疗装置(EE)411能够经由通信网络相互传递数据，以及住宅侧医疗装置(EE)411和用户标识装置(UID)421能够经由它们分别连接的装置接口231(参见图9)相互传递数据。
每个装置设有具有反篡改配置的(用户)安全芯片412、423或者安全模块403，用于在数据通信处理时执行被传递数据的相互验证处理或者加密和解密。此外，(用户)安全芯片412、423或者安全模块403执行组属性证书的验证处理。
用户标识装置421存储参照图41所述的组属性证书AC01、422。组属性证书AC01、422的发放者是充当业务供应商的医院侧医疗装置(SP)401，并且适用于确定是否可以执行医疗程序的确认处理，从作为持有者的用户装置USC421发送到医院侧医疗装置(SP)401，并且在医院侧医疗装置(SP)401的安全模块(SM)403上验证和检查组属性证书AC01之后，提供业务，即执行医疗诊断程序。
此外，充当业务供应商的医院侧医疗装置(SP)401存储组属性证书AC02、402。对于组属性证书AC02、402的发放者，发放者是住宅侧医疗装置(EE)411，持有者是医院侧医疗装置(SP)401，并且从医院侧医疗装置(SP)向住宅侧医疗装置(EE)发送，在从住宅侧意料证书(EE)411向医院侧医疗装置(SP)401发送从诊断对象(A先生)获得的诊断数据之前，在住宅侧医疗装置(EE)的安全芯片(SC)412执行组属性证书AC02、402的验证和检查，并且在验证和检查成功的条件下执行诊断结果数据的发送。
下面将参照图43说明应用存储在用户标识装置421的组属性证书AC01、422来执行医疗诊断程序的执行业务的使用权限确认处理并启动业务的处理顺序。在图43中，
UID：用户标识装置(用户装置)控制单元，
USC：配置在UID内的用户安全芯片，
EE：住宅侧医疗装置(EE)控制单元，
SC：配置在EE内的安全芯片，
SP：医院侧医疗装置(SP)控制单元，
SM：SP内的安全模块。
还请注意，安全芯片(SC)、用户安全芯片(USC)和安全模块(SM)具有与图9所述的安全芯片相同的配置，并且通过在安全模块或者芯片的组属性证书的验证，执行权限确定处理和类似处理。也就是说，利用比如网络接口或类似接口的接收单元已经接收从数据处理请求装置向数据处理被请求装置发送的组属性证书的业务供应商或者用户装置，把已接收的组属性证书交给充当权限确定处理单元的安全模块(芯片)，并且根据安全模块(芯片)内接收的组属性证书来执行权限确定处理，并且根据权限确定执行各种类型的数据处理。
首先，在步骤S321中，用户经由充当终端实体的住宅侧医疗装置(EE)的输入接口输入组属性证书(Gp.AC)＝AC01使用请求命令。该组属性证书(Gp.AC)是图41和图42中显示的AC01。此时，用户指定设置在待使用的组属性证书AC01中的组ID。然而，如果通过指定某个业务可以确定单一组ID，则可以做出仅仅指定业务的安排。
一旦住宅侧医疗装置(EE)收到从用户输入的组属性证书(Gp.AC)AC01使用请求，在步骤S322中，就在用户安全芯片(USC)与充当业务供应商(SP)的医院侧医疗装置(SP)之间执行相互认证。尽管这里的说明中做出了省略，但是如果用户标识装置(UID)没有与SP的直接通信功能，则执行以下各项：
(1)EE的SC与SP-SM之间的相互认证，
(2)EE的SC与UID的USC之间的相互认证，
(3)UID的USC与SP-SM之间的相互认证。或者作为更简单配置，做出一旦连接EE，EE就基本接受(认为已验证)UID的处理配置，在此情况下，可以省略上述的相互认证(2)。此外，可以实现上述三种不同组合之下的认证配置。
验证处理被执行为，集中于安全芯片和安全模块的加密处理单元(参见图9)的参照图13所述的公共密钥相互认证处理。在步骤S323中，从用户安全芯片向终端输出包括相互认证建立/未建立结果信息的相互认证完成通知。如果未建立相互认证，则取消处理的继续。如果建立了相互认证，则在步骤S324中，用户安全芯片(USC)向业务供应商(SP)的安全模块(SM)发送在它自己的存储器中存储的组属性证书(GP.AC)AC01。组属性证书(Gp.AC)AC01是参照图41和图42所述的适用于确定医疗程序的业务接收权限的处理的组属性证书AC01。
在步骤S325中，已经从用户安全芯片(USC)接收组属性证书(Gp.AC)AC01的医院侧医疗装置(SP)的安全模块(SM)执行组属性证书验证处理。组属性证书的验证处理如参照图21至图23所述的处理，并且被执行为，包括属性证书签名验证的确认处理、对应公共密钥证书(PKC)和链公共密钥证书确认处理等的处理。
在组属性证书(Gp.AC)的验证处理之后，安全模块(SM)向医院侧医疗装置(SP)输出验证结果，并且如果未建立验证，则不执行业务的供应并取消该处理作为错误处理。在此情况下，可以执行向终端实体通知未建立组AC验证的结果的处理。
如果组属性证书(Gp.AC)验证是成功的，并且已经确认组属性证书(Gp.AC)的真实性，则流程前进到步骤S327。在步骤S327中，执行先前参照图25所述的组属性证书(Gp.AC)的检查。根据充当业务供应商的医院侧医疗装置(SP)拥有的组信息数据库执行检查。也就是说，医院侧医疗装置(SP)从已验证的组属性证书(Gp.AC)AC01获得发放者信息和组ID，根据已获得的信息搜索组信息数据库，并确认是否存在已登记的实体。如果存在对应的已登记实体，则从组信息数据库获取组信息。
此情况下的组信息包括医疗诊断程序执行准许信息。在步骤S328中，充当业务供应商的医院侧医疗装置(SP)执行业务供应处理，即执行顺从该组信息的医疗诊断程序。也就是说，执行远程控制的医疗诊断处理，即向住宅侧医疗装置(EE)发送诊断程序的执行命令，并经由住宅侧医疗装置(EE)执行用户的诊断。
下面参照图44说明处理顺序，即应用存储在医院侧医疗装置(SP)401中的组属性证书AC02、402以执行诊断数据事务处理业务的使用权限确认处理并启动业务，其中所述诊断数据事务处理业务是医疗诊断程序执行结果。
首先，在步骤S331中，操作医院侧***的用户经由医院侧医疗装置(SP)的输入接口输入组属性证书(Gp.AC)＝AC02使用请求命令。该组属性证书(Gp.AC)是图41和图42中所示的AC02。此时，操作医院侧***的用户指定设置在待使用的组属性证书AC02中的组ID。然而，如果通过指定某个业务可以确定单一组ID，则可以做出仅仅指定业务的安排。
一旦医院侧医疗装置(SP)收到组属性证书(Gp.AC)AC02使用请求输入，就在用户安全芯片(USC)与充当业务供应商(SP)的医院侧医疗装置(SP)的安全模块(SM)之间执行相互认证。尽管在这里的说明中做出了省略，但是如果用户标识装置(UID)没有与SP的直接通信功能，则执行以下各项：
(1)EE的SC与SP-SM之间的相互认证，
(2)EE的SC与UID的USC之间的相互认证，
(3)UID的USC与SP-SM之间的相互认证。或者作为更简单配置，做出一旦连接EE，EE就基本接受(认为已验证)UID的处理配置，在此情况下，可以省略上述的相互认证(2)。此外，可以实现上述三种不同组合之下的认证配置。
验证处理被执行为，集中于安全芯片和安全模块的加密处理单元(参见图9)的参照图1 3所述的公共密钥相互认证处理。在步骤S333中，从用户安全模块(SM)向医院侧装置(SP)输出包括相互认证建立/未建立结果信息的相互认证完成通知。如果未建立相互认证，则取消处理的继续。如果建立了相互认证，则在步骤S334中，医院侧医疗装置(SP)的安全模块(SM)向住宅侧医疗装置的用户安全芯片(USC)发送存储在自己的存储器中的组属性证书(GP.AC)AC02。组属性证书(Gp.AC)AC02是参照图41和图42所述的适用于确定诊断结果数据的业务接收权限的处理的组属性证书AC02。
在步骤S335中，已经从医院侧医疗装置(SP)的安全模块(SM)接收组属性证书(Gp.AC)AC02的用户安全芯片(USC)执行组属性证书验证处理。组属性证书的验证处理如参照图21至图23所述的处理，并且被执行为，包括属性证书签名验证的确认处理、对应公共密钥证书(PKC)和链公共密钥证书确认处理等的处理。
在组属性证书(Gp.AC)的验证处理之后，用户安全芯片(USC)向住宅侧医疗装置(EE)输出验证结果(S336)，并且如果未建立验证，则不执行诊断结果传送业务的供应并取消处理作为错误处理。在此情况下，可以执行向医院侧医疗装置(SP)通知未建立组AC验证的结果的处理。
如果组属性证书(Gp.AC)验证是成功的，并且已经确认组属性证书(Gp.AC)的真实性，则流程前进到步骤S337。在步骤S337中，执行先前参照图25所述的组属性证书(Gp.AC)的检查。根据住宅侧医疗装置(EE)拥有的组信息数据库执行检查。也就是说，住宅侧医疗装置(EE)从已验证的组属性证书(Gp.AC)AC02获得发放者信息和组ID，根据已获得的信息搜索组信息数据库，并确认是否存在已登记的实体。如果存在对应的已登记实体，则从组信息数据库获取组信息。
此情况下的组信息包括医疗诊断程序的诊断结果传送准许信息。在步骤S338中，住宅侧医疗装置(EE)执行业务供应处理，即执行遵从组信息的医疗诊断程序的诊断结果的传送处理。也就是说，执行从住宅侧医疗装置(EE)向医院侧医疗装置(SP)发送医疗诊断处理结果的处理。
(5-3)远程维护业务
作为根据组属性证书执行权限确认以执行数据处理的数据处理***的配置实例，是使用对作为终端实体(EE)例如家用电器的装置进行远程维护的业务的一个实例。
这里将说明一个实例，其中具有通信功能的各种家用电器，如音频-视频设备、空调、电冰箱等是终端实体(EE)，并且在安装在家中的家用电器等与制造商处的业务供应装置(SP)之间执行通信，从而根据从业务供应装置(SP)发送的命令，对安装在家中的家用电器(EE)进行维修、维护、更新和其它控制处理。
在执行上述处理的时候，根据对每个组属性证书的验证和检查确认是否可以执行处理的处理，并且在执行准许/不准许确认之后，执行每个处理。图45显示了待应用的组属性证书的实例。组属性证书被分成两个普通类别。一个是业务属性证书(AC)，另一个是控制属性证书(AC)。
对于业务属性证书(AC)，发放者是充当业务供应商(SP)的家用电器制造商侧装置；持有者，即通过与在发放业务属性证书是的发放者的家用电器制造商侧装置(SP)执行验证处理的组属性证书的发放对象，是利用安装在家中的家用电器的用户标识装置(UID)的用户安全芯片(USC)，或者是家用电器(EE)的安全芯片(SC)。
业务属性证书被发放给给予权限的家用电器组的家用电器购买者组，授权由购买家用电器时与制造商方订立客户合同的购买家用电器的用户接收关于家用电器(EE)的维修、维护升级和其它控制处理的后续业务。所以，业务属性证书是发放给家用电器购买者组或者家用电器组的组属性证书。
如果证书发放给家用电器购买者组，则在用户标识装置(UID)的用户安全芯片(USC)与家用电器制造商(SP)的安全模块之间建立相互认证的条件下，执行发放处理，并且如果证书发放给家用电器组，则在家用电器的安全芯片(SC)与家用电器制造商(SP)的安全模块之间建立相互认证的条件下执行发放处理。
在请求家用电器(EE)的维修、维护、升级或者其它控制业务的时候，从家用电器(EE)或者用户标识装置(UID)向制造商侧装置(SP)发送业务属性证书，并且在制造商侧装置(SP)验证和检查组属性证书之后，转换到业务的供应。
对于控制属性证书，发放者是家用电器(EE)，它接收维修、维护、升级或者其它控制业务；持有者，即通过在发放控制属性证书时与家用电器(EE)执行相互认证发放组属性证书的对象，是充当业务供应商(SP)的制造商方装置的安全模块(SM)。
该控制属性证书是在购买家用电器的用户与制造商方之间，在购买家用电器后拥有业务属性证书的条件下发放的证书，并且例如从具有相同制造商的多个家用电器的用户向作为业务供应商的制造商方装置发放证书，该证书对应于每个家用电器，并且作为说明每个家用电的维护业务的执行范围的证书。或者可以做出为一个家用电器发放记录差别(difference)控制权限信息的证书地安排。一个实例是仅仅准许作为已接收业务的向委托软件升级处理的升级处理的属性证书，仅仅准许定期检查的检查处理等的作为家用电器控制信息的属性证书。
控制属性证书是向由一个用户拥有的多个家用电器的家用电器组或者向一个家用电器发放多个的组属性证书。如果向由单个用户所拥有的多个家用电器的家用电器组发放，则在用户标识装置(UID)的用户安全芯片(USC)与家用电器制造商(SP)的安全模块之间建立相互认证的条件下执行发放处理；如果发放给一个特定家用电器，则在UID的USC或者特定家用电器(EE)的安全芯片(SC)与家用电器制造商(SP)的安全模块之间建立相互认证的条件下执行发放处理。
控制属性证书是从用户方(EE或者UID)发放并被存储在提供业务的制造商方装置的，并在执行家用电器(EE)的维修、维护、升级或者其它控制业务的时候，从制造商方装置向用户方(EE或者UID)发送控制属性证书，并在用户方(EE或者UID)验证和检查控制属性证书之后，进行转换以提供业务。
执行组属性管理机构(AA)和组属性登记管理机构(ARA)功能的制造商方装置(SP)或者家用电器(EE)或者用户标识装置(UID)自己可以执行业务属性证书或者控制属性证书的发放，但是也可以做出把发放处理委托给组属性管理机构(AA)和组属性证书登记管理机构(ARA)的配置。然而，遵从执行发放者策略的处理是这种情况下的条件。
例如，最好由作为发放者的制造商方装置(SP)或者充当发放代理的组属性证书登记管理机构(ARA)执行业务属性证书的发放处理，使希望接收业务的用户展示证明用户身份的已发放的组属性证书，比如从***公司发放的组属性证书，并且在验证所展示的组属性证书之后，作为新的组属性证书发放业务属性证书，或者使家用电器展示证明家用电器属于制造商所制造的产品组的组属性证书，其中所述家用电器在被制造时已经存储了组属性证书，并且在验证已展示的组属性证书之后，执行把业务属性证书发放为新的组属性证书的发放处理。至于以此方式验证已经发放组属性证书的条件，发放新的组属性证书的处理顺序与参照图29、图30、图32等所述的处理顺序相同。
并且，对于控制属性证书的发放处理，一个优选方法是，同样，作为发放者或者充当发放代理的组属性证书登记管理机构(ARA)的家用电器(EE)，使制造商方装置(SP)展示证明它是制造商方的真实装置的已发放组属性证书，比如由上述的制造商发放的充当组属性证书的业务属性证书，并且在验证所展示的证书之后，对作为新的组属性证书的控制属性证书执行发放处理。
在执行维护业务的***中，存储在装置中的属性证书如图46所示。充当业务供应商的制造商方装置(SP)451、和充当终端实体的用户方家用治疗装置(461)能够通过通信网络相互传递数据，并且用户方家用电器(EE)461和用户标识装置(UID)471能够经由每一个的连接装置接口231(参见图9)，通过通信网络相互传送数据。
每个装置具有(用户)安全芯片463和472或者安全模块453，它们具有反篡改配置，并在数据通信处理的时候执行相互认证处理，以及所传送数据的加密和解密。此外，在(用户)安全芯片463和472或者安全模块453上执行组属性证书的验证处理。
参照图45所述的业务属性证书462被存储在用户方家用电器(EE)461中。业务属性证书462把充当业务供应商的制造商方装置(SP)451作为其发放者，并且应用于确定它是否准许执行家用电器维护或者维修等的确认处理，以及从作为持有者的用户方家用电器(EE)461的SC 463发送到制造商方装置(SP)451。在制造商方装置(SP)451的安全模块(SM)463上进行验证和检查之后，执行业务，即控制属性证书的传送以及由控制属性证书准许的权限范围内的维修等。
控制属性证书452被存储在充当业务供应商的制造商方装置(SP)451上。控制属性证书452把用户方家用电器(EE)461作为发放者，该证书的持有者是制造商装置(SP)451，并且制造商方装置(SP)把该证书发送给用户方家用电器(EE)461，在执行诸如维护等业务之前，在用户方家用电器(EE)461的安全芯片(SC)上执行控制属性证书的验证和检查，并且在已经建立验证和检查的条件下，在由控制属性证书确认的权限范围内执行诸如维护、维修、升级等的处理。
下面参照图47说明在执行业务时使用业务属性证书和控制属性证书的安排。首先，从希望接收诸如维护、维修、检查、升级等的业务的家用电器(EE)，或者连接家用电器的用户标识装置(UID)向制造商方装置(SP)482展示业务属性证书(AC)484。在安全模块(SM)上验证业务属性证书之后，制造商方装置(SP)482根据对应于业务属性证书的组ID搜索组信息数据库483，提取如组数据的控制AC或者控制AC标识数据，并且获取对应于业务AC的控制AC。
制造商方装置(SP)482向家用电器(EE)或者连接家用电器的用户标识装置(UID)发送所获得的控制属性证书(AC)485，并且在家用电器(EE)的安全芯片或者连接家用电器的用户标识装置(UID)上进行验证之后，向家用电器(EE)提供诸如维护或维修的业务，该业务紧随控制属性证书(AC)准许的控制信息。
请注意，维护、维修、升级的执行程序可以被预先存储在家用电器内，并且被使用，或者根据执行的需要，将该程序从制造商方发送给家用电器。最好是，在发送执行程序的时候执行验证处理和发送数据的加密处理。
下面参照图48说明，使用存储在作为用户装置的家用电器(EE)中的业务属性证书以及存储在业务供应商中的控制属性证书，执行涉及诸如家用电器的维护和维修的业务的使用权限确认处理的处理。在图48中，
EE：用户方家用电器(EE)控制单元，
SC：配置在EE内的安全芯片，
SP：制造商方装置(SP)控制单元，和
SM：SP内的安全模块。
请注意，安全芯片(SC)、用户安全芯片(USC)和安全模块(SM)具有与图9所述的安全芯片相同的配置，并且通过安全模块或者芯片上的组属性证书的验证，来执行权限确定处理和类似处理。也就是说，利用诸如网络接口或类似接口的接收单元接收从请求业务(即数据处理，比如维护处理或类似处理)的请求装置向业务被请求装置发送的组属性证书的业务供应商或者用户装置，把已接收的组属性证书交给充当权限确定处理单元的安全模块(芯片)，并且根据安全模块(芯片)内接收的组属性证书执行权限确定处理，并且根据拥有权限的确定执行各种数据处理。
首先，在步骤S341中，用户经由充当终端实体的用户方家用电器(EE)的输入接口输入用于是组属性证书(Gp.AC)的业务属性证书(AC)的使用请求命令。此时，用户指定被设置在待使用的业务属性证书(AC)中的组ID。然而，如果通过指定某个业务可以确定单一组ID，则可以做出仅仅指定业务的安排。
一旦用户方家用电器(EE)收到用户输入的业务属性证书(AC)使用请求，在步骤S342中，就在安全芯片(SC)与充当业务供应商(SP)的制造商方装置(SP)之间执行相互认证。请注意，尽管这里的说明是使用发放给家用电器(EE)的安全芯片(SC)的业务属性证书的一个实例，但是同样可以做出使用发放给用户标识装置(UID)的安全芯片的业务属性证书的安排。然而，如果用户标识装置(UID)没有与SP的直接通信功能，则执行以下各项：
(1)EE的SC与SP-SM之间的相互认证，
(2)EE的SC与UID的USC之间的相互认证，
(3)UID的USC与SP-SM之间的相互认证。或者作为更简单配置，可以做出一旦连接EE，EE就基本接受(认为已验证)UID的处理配置，在此情况下，可以省略上述的相互认证(2)。此外，可以实现上述三种不同组合之下的认证配置。
验证处理被执行为，集中于安全芯片和安全模块的加密处理单元(参见图9)的参照图13所述的公共密钥相互认证处理。在步骤S343中，从用户安全芯片向终端输出包括相互认证建立/未建立结果信息的相互认证完成通知。如果未建立相互认证，则取消处理的继续。如果建立了相互认证，则在步骤S344中，安全芯片(SC)向作为制造商方装置的业务供应商(SP)的安全模块(SM)发送存储在它自己的存储器中的业务属性证书。
在步骤S345中，已经从用户方家用电器的安全芯片(SC)接收业务属性证书的制造商方装置(SP)的安全模块(SM)执行业务属性证书验证处理。业务属性证书的验证处理如参照图21至图23所述的处理，并且被执行为，包括属性证书签名验证、对应公共密钥证书(PKC)和链公共密钥证书确认处理等的处理。
在业务属性证书的验证处理之后，安全模块(SM)向制造商方装置(SP)输出验证结果，并且如果未建立验证，则不执行业务的供应并取消该处理作为错误处理。在此情况下，可以执行向终端实体通知未建立业务AC验证的结果的处理。
如果业务属性证书的验证是成功的，并且已经确认业务属性证书的验证，则流程前进到步骤S347。在步骤S347中，执行业务属性证书的检查。根据充当业务供应商的制造商方装置(SP)拥有的组信息数据库执行检查。
下面参照图49说明业务属性证书的检查处理。在步骤S351中，业务供应商(SP)从已经验证的业务属性证书中获得作为属性的组ID。在步骤S352中，根据从业务属性证书获得的组ID检查组信息数据库，并且从已登记的项目中获得控制属性证书信息，例如控制属性证书的标识符(ID)。
如图49所示，业务供应商拥有的组信息数据库(DB)存储发放者、业务AC的组ID以及对应的充当诸如ID的组信息的控制属性证书信息。业务供应商(SP)根据用户方家用电器接收的从已经验证的业务属性证书(AC)获得的组ID搜索组信息数据库(DB)，并获得对应于作为组信息的业务AC的控制属性证书(AC)。
接着，在步骤S348中(图48)，充当业务供应商的制造商方装置(SP)根据从组信息数据库(DB)获得的控制属性证书(AC)的ID获得控制属性证书(AC)。
下面将参照图50说明，已经接收业务属性证书的业务供应商根据控制属性证书执行家用电器的业务处理，比如维护、检查、维修、升级、控制等的顺序。
在图50的步骤S370中，操作制造商方装置的操作员经由制造商方装置(SP)的输入接口输入应用控制属性证书的维护处理执行命令。在此处理的时候，操作员指定设置在待使用的控制属性证书中的组ID。
一旦制造商方装置(SP)收到应用控制属性证书的维护处理执行请求输入，就在步骤S371中，在家用电器(EE)的安全芯片(SC)与充当业务供应商的制造商方装置(SP)的安全模块(SM)之间执行相互认证。请注意，如果基于图50所示的控制属性证书的业务供应顺序是在参照图48所述的业务属性证书的验证处理顺序相同的对话中执行的，则不需要该相互认证处理。
如果执行了验证处理，则在步骤S372中，从安全模块(SM)向制造商方装置(SP)输出包括相互认证建立/未建立结果信息的相互认证完成通知。如果未建立相互认证，则取消处理的继续。如果建立了相互认证，则在步骤S373中，制造商方装置(SP)的安全模块(SM)向用户方家用电器的安全芯片(SC)发送基于已接收的业务属性证书提取的控制属性证书。如上所述，该控制属性证书是应用于确认家用电器的控制范围处理权限的处理的组属性证书。
在步骤S374中，已经从制造商方装置(SP)的安全模块(SM)接收控制属性证书(AC)的安全芯片(SC)执行控制属性证书验证处理。控制属性证书验证处理如参照图21至图23所述的处理，并且被执行为，包括属性证书签名验证、对应公共密钥证书(PKC)和链公共密钥证书确认处理等的处理。
在控制属性证书的验证处理之后，安全芯片(SC)向用户方家用电器(EE)输出验证结果(步骤S375)，并且如果未建立验证(S376的不好)，则取消维护处理和类似处理作为错误处理。在此情况下，可以执行向制造商方装置(SP)通知未建立控制属性证书验证的结果的处理。
如果控制属性证书验证是成功的(S376的好)，并且已经确认控制属性证书的验证，则流程前进到步骤S378。在步骤S378中，家用电器(EE)搜索维护执行程序。维护执行程序是存储在与控制属性证书ID或组ID相关的家用电器(EE)的存储器中的程序，或者是执行处理的时候从制造商方装置(SP)发送的程序，并且按照需要被预先加密。在该顺序图中，一个实例是维护执行程序被存储在与控制属性证书ID或组ID相关的家用电器(EE)的存储器中的情况。
在步骤S379中，将家用电器(EE)提取的被加密维护执行程序传送给安全芯片(SC)，并且在步骤S380中，在安全芯片(SC)方执行解密处理。解密处理是根据例如业务供应商(SP)方提供的密钥或者用户装置专有的密钥等执行的。各种处理方法都可以被用于程序加密格式，比如公共密钥、共享密钥等等。请注意，可以利用存储密钥的属性证书用来向安全芯片提供密钥的配置。
在步骤S381中，向作为家用电器的终端实体(EE)输出来自安全芯片(SC)的解密的维护程序，并且在步骤S382中，执行维护程序，并且在执行程序之后，在步骤S383中向业务供应商(SP)发送执行结果。
图51类似图50，是已经接收到业务属性证书的业务供应商根据控制属性证书执行业务的顺序，即例如家用电器的维护、检查、维修、升级或控制等的处理，并且是从制造商方装置(SP)向用户方家用电器(EE)发送维护执行程序的实例。步骤S384至S392对应于图50的步骤S370至S377。
在步骤S393中，当控制AC的验证OK(好)之后，从用户方家用电器(EE)向制造商方装置(SP)输出维护程序的传送请求，并且在步骤S394中，是业务供应商的制造商方装置执行维护程序搜索，并在步骤S395中向用户方家用电器(EE)发送已搜索的程序，这不同于图50所示的处理顺序。
请注意，根据需要加密所传送的程序。在用基于例如对话密钥、业务供应商(SP)方提供的密钥、或者用户装置独有的密钥或类似密钥、以各种可解密格式进行加密之后进行传送。各种处理方法可以用于程序加密格式，比如公共密钥、共享密钥等。请注意，可以利用存储密钥的属性证书用来为安全芯片提供密钥的配置。
图52类似图50和图51，是已经接收业务属性证书的业务供应商根据控制属性证书执行业务的顺序，即例如家用电器的维护、检查、维修、升级或控制的处理，并且是从制造商方装置(SP)向用户方家用电器(EE)发送维护执行程序的实例，具有基于从用户方家用电器(EE)接收的命令的执行的应答以及对应于执行的应答的处理。
步骤S410至S420对应于图51的步骤S384至S394。利用该配置，业务供应商(SP)在步骤S421中按照需要加密与维护程序相应的命令，并将其发送给家用电器(EE)，在步骤S422中，家用电器(EE)把加密的命令交给安全芯片，在安全芯片(SC)上执行解密(S423)，并且在安全芯片(SC)递交解密的命令之后(S424)，在家用电器(EE)(S425)上执行命令，执行结果从家用电器(EE)传送给业务供应商(SP)作为命令执行结果，并且已经收到应答的业务供应商(SP)向家用电器(EE)发送基于应答的下一个执行命令。
一旦在维护程序结束后执行所有命令，就在步骤S427中结束维护程序执行处理。
上述维护处理安排是从用户方家用电器向制造商方装置展示业务属性证书，而制造商方装置向家用电器展示控制属性证书，执行互属性证书的验证和检查，并且接收业务或者进行所提供的范围内的权限确认的安排。
业务属性证书和控制属性证书的使用安排不限于上述的处理安排，而是如图53所示，可以做出，利用在请求业务时展示给制造商方(SP)492的业务属性证书493和控制属性证书494，把两个属性证书存储在用户方装置491中的安排，由此在制造商方(SP)492执行业务属性证书493和控制属性证书494的验证和检查，并且在确认双方的关系之后，在控制属性证书494所指示的权限范围之内对用户方装置491执行维护处理。
此外，可以做出在家用电器中存储程序的安排，该家用电器利用以可编程的时间间隔向制造商方发送具有业务属性证书的维护请求，以及制造商方根据请求的接收而执行的控制属性证书传送和维护处理，以某个时间间隔周期地自动执行维护。
(5-4)个人通信业务
下面说明，当根据组属性证书执行权限确认时，使用充当终端实体(EE)的PC、PDA或者其它类似通信终端的通信业务使用实例。
这里将说明一个实例，其中安装在家中的通信终端(是诸如PC、PDA或者其它类似通信终端的终端实体(EE))连接提供聊天室的业务供应商的服务器，经由聊天室在通信终端之间的通信以及终端实体(EE)之间的直接通信被执行为使用组属性证书进行访问限制处理的通信业务。
组属性证书AC01的发放者是充当业务供应商(SP)的聊天管理员；而持有者，即通过在发放组属性证书AC01的时候与聊天管理业务供应商(SP)一起执行验证处理，发给组属性证书AC01的持有者，是终端实体的安全芯片(SC)，该终端实体是用户A先生的通信终端或者是A先生的用户标识装置(UID)的用户安全芯片(USC)。
该组属性证书AC01是证明具有访问构成聊天室(由聊天管理业务供应商(SP)提供)的服务器的权限的属性证书，并且被发放给具有权限加入聊天室的用户组或者用户装置。
组属性证书AC02的发放者是B先生的用户装置(EE或者UID)；而持有者，即发放者在发放组属性证书AC02时，通过与B先生的用户装置的安全芯片(SC)(SC或者USC)一起执行验证处理，来发放组属性证书AC02给持有者，是B先生的用户装置的安全芯片(SC或USC)。
组属性证书AC02是证明具有访问B先生的用户装置的管理业务的权限的组属性证书，并且被发放给具有访问B先生的用户装置的管理服务器的权限的用户组或者用户装置组。
请注意，业务供应商(SP)，或者充当终端实体(EE)的B先生的用户装置，或者自身执行组属性管理机构(AA)和组属性证书登记管理机构(ARA)的功能的用户标识装置(UID)可以执行组属性证书AC01和AC02的发放处理，但是还可以做出把发放处理委托给组属性管理机构(AA)和组属性证书登记管理机构(ARA)的配置。然而，遵从执行发放者策略的处理是该情况下的条件。
例如，最好由作为发放者的业务供应商(SP)、B先生的用户装置(EE，UID)或者充当发放者代理的组属性证书登记管理机构(ARA)执行组属性证书AC01和AC02的发放处理，以使作为发放请求者的A先生展示证明用户身份的已发放的组属性证书，比如***公司发放的组属性证书，并且在验证已展示的组属性证书之后，作为新的组属性证书发放组属性证书AC01和AC02。至于按此方式验证已经发放的组属性证书的条件，发放新的组属性证书的处理顺序与参照图29、图30、图32等图所述的处理顺序相同。
图54所示的用于发放和存储组属性证书的安排如图55所示。聊天室业务供应商(SP)501、充当终端实体的A先生的通信终端(EE)531和B先生的通信终端(EE)531能够通过通信网络相互传送数据，通信终端(EE)511和用户标识装置(UID)521以及通信终端(EE)531和用户标识装置(UID)533能够经由每个的连接装置接口231(参见图9)通过通信网络相互传送数据。
每个装置具有(用户)安全芯片512、522、532、534或者安全模块502，它们具有反篡改配置，并在数据通信处理的时候执行相互认证处理，以及执行所传送数据的加密和解密。此外，在安全芯片和安全模块上执行组属性证书的验证处理。
A先生的用户标识装置521存储如参照图54所述的组属性证书AC01、523。业务属性证书AC01、523把聊天室业务供应商(SP)501作为发放者，并且应用于聊天室参与权限确认处理，该证书从作为持有者的A先生的用户装置的USC 521转交给聊天室业务供应商(SP)501，并且，在聊天室业务供应商(SP)501的安全模块(SM)上进行验证和检查之后，准许业务，即准许参与聊天室。
此外，A先生的用户标识装置521还存储如参照图54所示的组属性证书AC02、524。业务属性证书AC02、524把B先生的用户装置(EE531或者UID533)作为发放者，并且应用于访问B先生的用户装置的管理服务器的访问权限确认处理，该证书从作为持有者的A先生的用户装置的USC 521转交给B先生的用户装置(EE 531或UID 533)，并且在B先生的用户装置(EE 531或UID 533)的安全芯片(SC 532或USC 534)上的验证和检查之后，准许业务，即准许访问B先生的装置的管理服务器。
下面参照图56说明，应用存储在A先生的用户标识装置421中的组属性证书AC01、523执行聊天室参与业务的用户权限确认处理以及启动业务的处理顺序。在图56中，
UID：A先生用户标识装置(用户装置)控制单元，
USC：配置在UID内的用户安全芯片，
EE：A先生通信装置(用户装置)控制单元，
SC：配置在EE内的安全芯片，
SP：聊天室业务供应商(SP)控制单元，
SM：SP内的安全模块。
首先，在步骤S451中，用户(A先生)经由充当终端实体的A先生的通信终端(EE)的输入接口输入组属性证书(Gp.AC)＝AC01使用请求命令。该组属性证书(Gp.AC)是图54和图55中显示的AC01。此时，用户指定设置在待使用的组属性证书AC01中的组ID。然而，如果通过指定某个业务可以确定单一组ID，则可以做出仅仅指定业务的安排。
一旦A先生通信终端(EE)收到用户输入的组属性证书(Gp.AC)AC01使用请求，在步骤S452中，就在用户安全芯片(USC)与充当业务供应商的聊天室业务供应商(SP)的安全模块(SM)之间执行相互认证。尽管这里的说明中做出了省略，但是如果用户标识装置(UID)没有与SP的直接通信功能，则执行以下各项：
(1)EE的SC与SP-SM之间的相互认证，
(2)EE的SC与UID的USC之间的相互认证，
(3)UID的USC与SP-SM之间的相互认证。或者作为更简单配置，做出一旦连接EE，EE就基本接受(认为已验证)UID的处理配置，在此情况下，可以省略上述的相互认证(2)。此外，可以实现上述三种不同组合之下的认证配置。
验证处理被执行为，集中于安全芯片和安全模块的加密处理单元(参见图9)的参照图13所述的公共密钥相互认证处理。在步骤S453中，从用户安全芯片向终端输出包括相互认证建立/未建立结果信息的相互认证完成通知。如果未建立相互认证，则取消处理的继续。如果建立了相互认证，则在步骤S454中，用户安全芯片(USC)向业务供应商(SP)的安全模块(SM)发送被存储在它自己的存储器中的组属性证书(GP.AC)AC01。组属性证书(Gp.AC)AC01是参照图54和图55所述的适于确定聊天室参与者接收权限的处理的组属性证书AC01。
在步骤S455中，已经从用户安全芯片(USC)接收组属性证书(Gp.AC)AC01的聊天室提供业务供应商(SP)的安全模块(SM)执行组属性证书验证处理。组属性证书的验证处理如参照图21至图23所述的处理，并且被执行为，包括属性证书签名验证、对应公共密钥证书(PKC)和链公共密钥证书确认处理等的处理。
在组属性证书(Gp.AC)的验证处理之后，安全模块(SM)向聊天室提供业务供应商(SP)输出验证结果，并且如果未建立验证，则不执行业务的供应并取消该处理作为错误处理。在此情况下，可以执行向终端实体通知未建立组AC验证的结果的处理。
如果组属性证书(Gp.AC)验证是成功的，并且已经确认组属性证书(Gp.AC)的真实性，则流程前进到步骤S457。在步骤S457中，执行参照图25所述的组属性证书(GP.AC)的检查。基于充当业务供应商的聊天室提供业务供应商(SP)拥有的组信息数据库执行检查。也就是说，聊天室提供业务供应商(SP)从已验证的组属性证书(Gp.AC)AC01获得发放者信息和组ID，根据已获得的信息搜索组信息数据库，并确认是否存在已登记的实体。如果存在对应的已登记实体，则从组信息数据库获取组信息。
此情况下的组信息包括聊天室参与准许信息。在步骤S458中，充当业务供应商的聊天室提供业务供应商(SP)执行业务供应处理，即遵从组信息准许加入聊天室。也就是说，执行准许访问提供聊天室的服务器的处理。
下面参照图57说明处理顺序，即应用存储在A先生的用户标识装置421中的组属性证书AC02、524对B先生的用户装置执行用户权限确认处理，并启动A先生与B先生之间的通信。在图57中，
UID：A先生用户标识装置(用户装置)控制单元，
USC：配置在UID内的用户安全芯片，
EE1：A先生通信装置(用户装置)控制单元，
SC1：配置在EE1内的安全芯片，
EE2：B先生通信装置(用户装置)控制单元，
SC2：配置在EE2内的安全芯片。
首先，在步骤S461中，用户(A先生)经由充当终端装置的A先生的通信终端(EE1)的输入接口输入组属性证书(Gp.AC)＝AC02使用请求命令。该组属性证书(Gp.AC)是图54和图55中所示的AC02。此时，用户指定设置在待使用的组属性证书AC02中的组ID。
一旦A先生通信终端(EE1)从用户收到组属性证书(Gp.AC)AC02使用请求输入，就在步骤S462，在用户安全芯片(USC)与B先生的用户装置的安全芯片(SC2)之间执行相互认证。请注意，这里所述的实例是组属性证书(Gp.AC)AC02的发放实体是B先生的通信终端(EE)的安全芯片(SC)的情况。在发放实体是B先生的用户标识装置(UID)的情况下，应当与B先生的用户表示装置(UID)的用户安全芯片(USC)执行相互认证。
验证处理被执行为，集中于安全芯片和安全模块的加密处理单元的参照图1 3所述的公共密钥相互认证处理。在步骤S463中，从A先生用户安全芯片(USC)向终端实体(EE1)输出包括相互认证建立/未建立结果信息的相互认证完成通知。如果未建立相互认证，则取消处理的继续。如果建立了相互认证，则在步骤S464中，用户安全芯片(USC)向B先生的通信终端(EE)的安全芯片(SC2)发送存储在自己的存储器中的组属性证书(GP.AC)AC02。组属性证书(Gp.AC)是参照图54和图55所述的适于确定访问B先生的用户装置的服务器的访问权限的处理的组属性证书AC02。
在步骤S465中，已经从用户安全芯片(USC)接收的组属性证书(Gp.AC)AC02的B先生的通信终端(EE)的安全芯片(SC2)执行组属性证书验证处理。组属性证书的验证处理如参照图21至图23所述的处理，并且被执行为，包括属性证书签名验证的确认处理、对应公共密钥证书(PKC)和链公共密钥证书确认处理等的处理。
在组属性证书(Gp.AC)的验证处理之后，B先生的通信终端(EE)的安全芯片(SC2)向B先生的通信终端(EE)输出验证结果，并且如果未建立验证，则不执行业务供应，并取消该处理作为错误处理。在此情况下，可以执行向A先生通知未建立组AC验证的结果的处理。
如果组属性证书(Gp.AC)验证是成功的，并且已经确认组属性证书(Gp.AC)的真实性，则流程前进到步骤S467。在步骤S467中，执行参照图25所述的组属性证书(Gp.AC)的检查。基于B先生的通信终端(EE)拥有的组信息数据库执行检查。也就是说，B先生的通信终端(EE)从已验证的组属性证书(Gp.AC)AC02获得发放者信息和组ID，根据已获得的信息搜索组信息数据库，并确认是否存在已登记的实体。如果存在对应的已登记实体，则从组信息数据库获取组信息。
此情况下的组信息包括用于访问B先生的通信终端服务器的访问权限信息。在步骤S468中，B先生的通信终端(EE)执行业务供应处理，即准许访问B先生用户装置的服务器。
(6)执行属性证书(执行AC)
下面将说明不仅能够利用属性证书根据权限信息确定业务供应安排中的业务接收权限，而且还能够由属性证书限制业务自身的执行的执行属性证书(执行AC)。
(6-1)执行属性证书概述
上述的组属性证书，或者已知的普通属性证书能够通过签名验证，检验属性证书的被存储数据，如权限信息或者是持有者属性的类似信息没有被篡改。下面所述的执行属性证书(执行AC)不仅通过验证来确认证书未被篡改，而且还具有由证书持有者解密执行属性证书中存储的加密数据(程序)的配置，并且接收基于加密数据(程序)的解密的业务。
用于解密被存储在执行属性证书中的加密数据(程序)的密钥(已登记密钥)是一个秘密共享密钥，只有执行属性证书的发放者以及是对应于业务接收机的用户装置的安全芯片(SC)的执行属性证书的持有者才可以知道该秘密共享密钥。因此，只有预定的用户装置才能执行基于执行属性证书的业务。
请注意，在下文中将说明，用户装置(是终端实体(EE))的安全芯片(SC)实施执行属性证书的处理，但是下面所述的安全芯片(SC)的处理是用户标识装置(UID)的用户安全芯片(USC)同样可以执行的处理，如同上述的组属性证书的处理。
如图58(a)所示，执行属性证书具有：是诸如执行已经用登记密钥加密的供应的业务所需的程序等的执行命令的数据；存储区块地址，它是地址数据，用于指示存储登记密钥的安全芯片的存储器中的登记密钥存储区，例如图58(C)所示的形成于安全芯片的EEPROM206内的共享密钥存储区207中的登记密钥存储区。此外，执行属性证书具有各种类型的属性证书数据(参见图5)，并附有发放者的签名。通过签名验证，可以执行数据反篡改验证。在参照图17和图18所述的处理之后，可以执行签名生成和验证处理。
请注意，执行属性证书可以被配置为顺从于属性证书的基本格式，顺从例如ITU-TX.509。然而，在下文中，顺从ITU-TX.509规定的格式不是必需的，原格式也可以用来配置属性证书。
如图58(b)所示，安全芯片(SC)的共享密钥存储区207已经存储了对应于一个充当用户装置的终端实体(EE)拥有的多个执行属性证书、对应于预定的块地址的多个执行属性证书。
共享密钥存储区207是由固定大小(比如64比特)的块构成的非易失性存储器的存储区。在预定处理之后，执行登记密钥的存储处理和复位处理。稍后将说明该处理。除了复位命令之外，可以仅仅通过使用待访问的块中存储的登记密钥所加密的命令实现对登记密钥存储存储区(storage memoryregion)的访问。此外，对于秘密密钥，除了不能读出秘密密钥的安排之外，还可以构想一种不能用秘密密钥直接读出加密或者解密结果的安排。这里，术语“不能直接读出”是指可以实现应用散列函数之后的秘密密钥，或者解密和执行用公共密钥加密的命令。在下文中，作为执行属性证书的持有者的安全芯片或者模块应当被理解为具有这样的安排。
下面将依据图59的流程图，说明执行属性证书的使用过程的概要。图59说明了示意地示出了通过执行属性证书，在充当执行属性证书的发放者的业务供应商(SP)以及充当业务的接收机的用户装置上的处理的流程图。在步骤S501中，在业务供应商(SP)与用户装置之间执行相互认证，并且在步骤S502中，执行根据如上述实例所述的组属性证书的业务使用权限的检查。这里所述的处理与上述的利用组属性证书的认证处理和验证处理相同，并且认证处理被执行为，集中于安全芯片和安全模块的加密处理单元(参见图9)上的参照图13所述的公共密钥相互认证处理。验证处理如参照图21至图23所述，并且被执行为，包括属性证书签名验证、对应公共密钥证书(PKC)和链公共密钥证书确认处理等的处理。
接着，如在步骤S503中的处理，执行根据执行属性证书(执行AC)的业务供应处理。通过以下之一执行基于执行属性证书(执行AC)的业务供应处理：步骤S504所示的执行属性证书(执行AC)发放处理；步骤S505所示的执行属性证书(执行AC)应用处理；和步骤S506所示的执行属性证书(执行AC)毁坏处理。
(6-2)执行属性证书发放处理
首先说明执行属性证书发放处理。图60示出了执行属性证书的发放顺序。在图60中，
EE：用户装置终端实体控制单元，
SC：配置在EE内的安全芯片，
执行AC表：管理表存储器和存储器控制单元的执行AC，
SP：实施执行AC发放处理(SP)控制单元的业务供应商装置，和
SM：SP内的安全模块。
首先，在步骤S511中，用户经由充当用户装置的终端实体(EE)的输入接口输入用于执行属性证书(执行AC)的发放请求命令。一旦终端实体(EE)收到从用户输入的执行属性证书发放请求，就在步骤S512中，在安全芯片(SC)与业务供应商(SP)的安全模块(SM)之间执行相互认证，以及验证和检查应用于执行属性证书(执行AC)的发放条件的已经发放的组属性证书。
认证处理被执行为，集中于安全芯片和安全模块的加密单元(参见图9)上的参照图13所述的公共密钥相互认证处理。验证处理如参照图21至图23所述的处理，并且被执行为包括属性证书签名验证、对应公共密钥证书(PKC)和链公共密钥证书确认处理等的处理。
请注意，尽管这里的说明是向终端实体(EE)的安全芯片(SC)发放执行属性证书的发放处理的实例，但是如果向用户标识装置(UID)的用户安全芯片(USC)发放执行属性证书，则执行以下各项：
(1)EE的SC与SP-SM之间的相互认证，
(2)EE的SC与UID的USC之间的相互认证，
(3)UID的USC与SP-SM之间的相互认证。或者作为更简单的配置，构成当连接EE时，EE就基本接受(认为已验证)UID的处理配置，并且在此情况下可以省略上述的相互认证(2)。此外，可以实现上述三种不同组合之下的认证配置。
一旦在步骤S512建立了认证、组属性证书验证和检查，业务供应商(SP)就实施生成对用户装置的终端实体(EE)的信息请求处理的登记密钥生成执行AC。特别是，这是请求存储器中的可用存储区地址的处理，该存储器将被用作登记密钥的存储区，其中所述登记密钥应用于执行属性证书的执行命令(图58)的加密和解密处理。
一旦终端实体(EE)收到登记密钥生成执行AC生成信息请求，就在步骤S514中，向执行AC表控制单元输出用于登记密钥的存储区的存储器的可用存储区地址搜索，并且执行AC表(控制单元)通过参阅执行AC表，并通知终端实体用来存储新登记的登记密钥的可用存储区地址，来答复该请求。例如如图62所示，执行AC表是关联SPSP信息和业务信息以及一个执行AC的表，其中SP信息是业务供应商的标识数据，业务供应商提供所述业务信息，比如加密内容信息，并且所述执行AC被存储为使用由业务供应商提供的业务信息所需程序的执行命令。
执行AC表(控制单元)参阅对应于已经存储的执行AC的登记密钥的存储区块地址，检测它自己安全芯片中的可用地址，并通知终端实体应当存储新登记的登记密钥的可用存储区地址。执行AC表控制单元是执行对存储执行AC表的存储器访问控制的控制单元，并且由CPU或者执行数据提取的类似部件组成，并且用于执行对终端实体(EE)或者安全芯片(SC)的存储器访问控制处理。
在步骤S516中，终端实体(EE)向业务供应商(SP)发送可用地址。在步骤S517，具有收到新登记密钥存储区块地址的业务供应商(SP)向安全模块(SM)输出用于登记密钥生成执行AC的生成请求。在步骤S518中，安全模块(SM)执行用于登记密钥生成执行AC的生成处理。从业务供应商(SP)向安全模块(SM)输出的登记密钥生成执行AC生成请求包括：存储安全芯片公共密钥(KpSC)的安全芯片公共密钥证书，用来复位登记密钥的复位密钥(Kreset)，登记密钥生成命令(GenKer)，和存储区块地址(Ad)。
下面将参照图63说明安全模块(SM)上的登记密钥生成执行AC的生成处理的细节。
安全模块(SM)601具有与参照图9所述的安全芯片配置的相同配置，图63示出了提取加密处理单元和其存储单元。加密处理单元包括公共密钥引擎602和共享密钥加密引擎603。安全模块(SM)601具有参照图9所述的诸如CPU、RAM、ROM等的配置，并且还能够进行数据处理和数据输入/输出处理。
公共密钥加密引擎602公共密钥加密，比如椭圆曲线加密或者RSA(Rivest-Shanir-Adleman)加密，并且执行诸如数据加密和解密、签名生成、验证处理等处理。共享密钥加密引擎603执行共享密钥加密处理，比如DES、三元(triple)DES等，并且执行数据加密和解密等。安全模块(SM)601还具有散列生成处理和随机数生成处理功能。
在诸如上述的登记密钥生成执行AC生成请求的时候，安全模块(SM)输入存储安全芯片公共密钥(KpSC)的安全芯片公共密钥证书、用于复位登记密钥(Kreset)的复位密钥、登记密钥生成命令(GenKer)和存储区块地址(Ad)。
在步骤S541地随机数生成处理中，使用安全芯片公共密钥(KpSC)加密登记密钥生成命令(GenKer)(步骤S542)，从而生成已加密的数据(Ep(GenKcr‖Kcs；KpSC)。请注意，a‖b指示被链接的数据，EP(a；b)指示基于应用密钥b的a的公共密钥加密方法的加密消息。
然后在步骤S543中，执行完成执行命令附加处理。Dpc[a]指示用于在以根据公共加密方法用秘密密钥进行解密为基础的数据中的命令的执行命令。此外，在步骤S544中，执行基于复位密钥(Kreset)的共享密钥加密处理，从而生成加密数据(Ec(Dpc[Ep(GenKcr|||Kcs；KpSC)]；Kreset)。Ec(a；b)指示基于应用密钥b的a的共享密钥加密方法的加密消息。
此外，在步骤S545中，加密数据(Ec(Dpc[Ep(GenKcr|||Kcs；KpSC)]的链接数据和指示新登记密钥的存储区的存储区块地址(Ad)进行应用安全模块(SM)的秘密密钥(KsSM)的签名处理。作为这些处理的结果，产生登记密钥生成执行AC611。
登记密钥生成执行AC611具有一个配置，包括：
指示新登记密钥的存储区的存储区块地址(Ad)，
加密数据(Ec(Dpc[Ep(GenKcr|||Kcs；KpSC)]，和
签名数据Ep(H(Ad‖Ec(Dpc[Ep(GenKcr‖Kcs；KpSC)]；Kreset，KsSM)。请注意，H(a)指示a的散列值。
下面返回到图60的顺序图继续进行说明。在步骤S518中，一旦在安全模块(SM)上的登记密钥生成执行AC生成处理结束，就从安全模块(SM)向业务供应商(SP)发送登记密钥生成执行AC，并且在步骤S519中，从业务供应商(SP)向用户装置的终端实体(EE)发送登记密钥生成执行AC。
在步骤S520中，用户装置的终端实体(EE)向执行AC表(控制单元)的执行AC表(参见图62)发送更新请求，其中执行AC表(控制单元)在步骤S521中更新执行AC表。执行AC表的更新请求(参见图62)包括通过应用新登记的密钥、业务供应商信息和存储区块地址可以使用的内容信息，并且该信息作为新的项目被登记到执行AC表上。
此外，在步骤S522中，用户装置的终端实体(EE)向安全芯片(SC)输出登记密钥生成请求。该请求被执行为，向安全芯片(SC)发送登记密钥生成执行AC的处理。
安全芯片(SC)在步骤S523中执行登记密钥生成处理。下面将参照图64说明基于安全芯片上执行的登记密钥生成执行AC的登记密钥生成处理。
安全芯片(SC)605具有与参照图9所述的安全芯片配置的相同配置。然而，这包括如参照图58所述的共享密钥存储区。图64说明了加密处理单元和以提取方式配置的存储器单元。加密处理单元包括公共密钥加密引擎606和共享密钥加密引擎607，并且具有用于其存储单元的共享密钥存储区608。安全芯片(SC)605具有如参照图9所述的诸如CPU、RAM、ROM等的配置，并且还能够进行数据处理，比如基于在加密处理单元上加密的执行命令的数据处理，以及数据输入/输出处理。例如，根据CPU的控制向/从共享密钥存储器写和读数据、外部数据输入、外部数据输出、装置间的数据传递和类似数据处理。
公共密钥加密引擎606执行诸如椭圆曲线加密的公共密钥加密或者RSA(Rivest-Shamir-Adleman)加密，并执行诸如数据加密和解密、签名生成、验证处理等的处理。共享密钥引擎607执行共享密钥加密处理，如DES、三重DES等等，并且执行数据加密和解密等。共享密钥存储区608是存储登记密钥的存储器，并且是由诸如64比特的固定大小的块构成的非易失性存储器所形成的存储器。安全芯片(SC)605还具有散列生成处理以及随机数生成处理功能。
安全芯片(SC)在登记密钥生成请求时输入来自终端实体的登记密钥生成AC611。
在步骤S551中，通过应用复位密钥(Kreset)的共享密钥解密，来提取登记密钥生成AC 611的执行命令数据(Dpc[Ec(GenKcr‖Kcs；KpSC])，并且在步骤S552中，作为对应于已解密的执行命令的数据处理，通过应用安全芯片的秘密密钥(KsSC)的公共密钥解密来提取登记密钥生成命令(GenKer)和对话密钥(Kcs)的链接数据。
步骤S553也是对应于解密执行命令的数据处理，并且是登记密钥生成处理(GenKer)的执行处理步骤。在步骤S554中，生成基于随机数的登记密钥(Ker)，并且在步骤S555中，根据是登记密钥的存储区地址的存储区块地址(Ad)把登记密钥(Kcr)写入共享密钥存储区608。
此外，在步骤S556中，用对话密钥(Kcs)加密登记密钥(Kcr)与存储区块地址(Ad)的链接数据，并且作为登记密钥生成结果612输出给终端实体(EE)。
向终端实体(EE)输出登记密钥生成结果612的输出步骤等同于图61的步骤S524。
从用户装置的终端实体(EE)向业务供应商(SP)发送通过用对话密钥(Kcs)加密的登记密钥(Kcr)与存储区块地址(Ad)的链接数据而获得的登记密钥生成结果。
一旦收到登记密钥生成结果，业务供应商(SP)就在步骤S526中向安全模块(SM)发送登记密钥生成结果，由此请求生成业务供应执行AC。安全模块(SM)在步骤S527中执行业务供应执行AC生成处理。
下面将参照图65说明安全模块(SM)的业务供应执行AC生成处理。
首先在步骤S561中，应用对话密钥(Kcs)执行登记密钥生成结果的解密处理，并且获得登记密钥(Kcr)与存储区块地址(Ad)的链接数据(Ad‖Kcr)。此外，在步骤S562中，应用登记密钥(Kcr)加密用于存储到业务供应商执行AC的执行命令(DecEData‖Kcd)613。请注意，执行命令是根据业务供应执行AC设置的用于执行程序等的执行命令。这里，描述了一个由数据解密密钥(Kcd)和加密数据解密命令(DecEData)的链接数据配置的执行命令的实例。
此外，在步骤S563中，安全模块的秘密密钥(KsSM)用来生成关于加密数据(Ec(DecEData‖Kcd)；Kcr)的签名(参见图17)，其中执行命令(DecEData‖Kcd)613已经用登记密钥(Kcr)加密，并且用来生成存储登记密钥(Ker)的用户装置的安全芯片的存储区块(Ad)的数据，从而生成业务供应执行AC 614。这里，业务供应执行AC 614是一个执行属性证书，用于执行作为业务的已加密数据的加密处理。
登记密钥(Kcr)的应用对于解密在执行属性证书中存储的执行命令是必不可少的，并且只是具有登记密钥信息的应用是参与业务供应执行AC生成处理的用户装置的安全芯片(SC)，和业务供应商的安全模块(SM)。
返回到图61，继续顺序图的说明。在步骤S527，一旦安全模块(SM)生成业务供应商执行AC，就在步骤S528将其从权限业务供应商(SP)发送到用户装置的终端实体(EE)，并且在步骤S529中，将其发送到执行AC表控制单元，在步骤S530中，将其存储在执行AC表(参见图62)。
由于如图58(a)所示的上述处理，在用户装置中存储，存储登记密钥的用户装置的安全芯片的存储区块地址、用登记密钥加密的执行命令、发放者签名和具有上述数据的执行属性证书(执行AC)。请注意，除了这些数据之外，还可以任选地存储参照图5所述的组属性证书的字段的数据。然而，对作为反篡改检验的对象的所有数据都必须执行签名。
(6-3)执行属性证书应用处理
下面将说明上述过程所发放的执行属性证书的应用处理。图66是业务供应执行AC的用户装置方上的应用顺序。通过上述处理，业务供应执行AC已经被存储在用户装置的执行AC表中。
在步骤S571中，用户经由终端实体(EE)的用户接口输入业务供应执行AC应用处理请求。该处理请求包括执行AC标识符，或者业务供应商(SP)信息、由此可标识业务内容的数据，比如使用内容或者使用程序被指定数据。在步骤S572，终端实体(EE)向执行AC表输出用户已经指定的业务供应AC的搜索请求。搜索密钥是例如内容信息、业务供应商(SP)信息等。
在步骤S573中，执行AC表从终端实体搜索基于输入密钥的对应业务供应执行AC，并且在步骤S574向终端实体(EE)输出从该表中提取的业务供应执行AC。
在步骤S575中，终端实体(EE)向安全芯片(SC)输出已接收的AC，并且做出业务供应执行AC应用处理请求。在步骤S576中，安全芯片执行用于已接收AC的供应处理，即依据执行属性证书(执行AC)的业务供应。
下面参照图67说明安全芯片(SC)上的步骤S576中的业务供应处理细节。安全芯片605输入业务供应执行AC 614。
业务供应执行AC 614包括：用登记密钥(Kcr)加密执行命令(DecEData‖Kcd)的(Ec(DecEData‖Kcd；Kcr)数据，存储登记密钥(Kcr)的用户装置的安全芯片中的存储区块地址(Ad)，以及每个数据已经被安全模块的安全密钥(KsSM)签名的数据。
在步骤S581中，安全芯片605依据业务供应执行AC内的存储区块地址(Ad)从共享密钥存储区608获取登记密钥(Kcr)，使用所获得的登记密钥(Kcr)对业务供应执行AC内的加密数据(Ec(DecEData‖Kcd)；Kcr)执行解密处理，从而获得数据解密密钥(Kcd)和加密数据的解密命令(DecEData)。
在步骤S582中，执行基于解密的执行命令的数据处理。也就是说，应用数据解密密钥(Kcd)以执行从外部输入的待解密的加密数据(Ec(data；Kcd)的解密处理，从而输出解密数据616。待解密的加密数据(Ec(data；Kcd))615是诸如用密钥(Kcd)加密的图像、音乐、程序和类似内容的数据，并且可以由数据解密密钥(Kcd)解密，所述数据解密密钥(Kcd)是通过用业务供应执行AC内的登记密钥解密存储执行命令而获得的。
现在回到图66的顺序图，继续进行说明。在步骤S576提供业务之后，在步骤S577中，安全芯片(SC)执行登记密钥毁坏处理。该登记密钥毁坏处理在某些情况下是根据业务供应执行AC执行的，并且在其它情况下则不需要执行。在基于业务供应执行AC的业务供应处理是仅仅一次的情况下，依据业务供应处理执行该毁坏处理。
下面将参照图68说明步骤S577中的SC(安全芯片)登记密钥毁坏处理。通过改写(overwrite)共享密钥存储区608中的登记密钥的存储区中的复位密钥(Kreset)，执行登记密钥复位处理。如果由待毁坏的登记密钥(Kcr)的存储区块地址(Ad)和复位密钥(Kreset)构成的复位处理命令617例如从终端实体(EE)输入，则在步骤S583中，在对应于复位处理命令617中存储的存储区块地址(Ad)的存储区执行复位密钥(Kerset)的写处理，从而完成登记密钥的删除。
现在回到图66的顺序图，继续进行说明。在步骤S577中，一旦完成登记密钥的毁坏，就在步骤S578向终端实体(EE)输出登记密钥毁坏通知，并且在步骤S579中，终端实体(EE)向执行AC表输出业务供应执行AC删除请求，并且执行AC表(控制单元)从执行AC表删除对应的执行AC。
(6-4)登记密钥复位处理
请注意，在业务供应执行AC的供应处理之后，不执行登记密钥毁坏处理，并且可以根据任意定时的复位请求执行是登记密钥毁坏处理的复位处理。下面参照图69说明基于该复位请求的处理。
在步骤S601中，用户经由终端实体(EE)的用户接口输入对应于用户装置中存储的业务供应执行AC的登记密钥复位请求。在步骤S602中，终端实体(EE)向执行AC表输出搜索请求。存在两种用于复位请求的安排。一种安排是用于用户忘记写入执行AC表的某个存储区块地址的业务内容的情况，其中利用作为密钥的存储区块地址来搜索执行AC表，并且如果确定对应于输出SP信息/内容信息的登记密钥是不必要的，则做出复位执行请求。该处理请求包括执行AC标识符，或者用于指定业务内容的数据，所述业务内容比如内容、程序或者业务供应商(SP)信息数据。第二种安排是用于用户知道SP信息和内容信息的情况，并且利用作为密钥的这些信息搜索执行AC表，并且向SC发送输出存储区块地址以及复位执行请求。请注意，登记密钥的存储区块地址可以作为对应于业务供应商的数据被任意存储在内容或者终端实体中。
在步骤S603中，执行AC表从终端实体中搜索基于输入密钥的相应业务供应执行AC，并且在步骤S604，搜索对应于业务供应执行AC的业务供应商和可用内容，该可用内容被输出给终端实体(EE)。
终端实体(EE)显示业务供应商和可用内容信息，并且如果确定是不必要的，则在步骤S606向安全芯片输出复位执行请求。
通过用复位密钥(Kreset)改写共享密钥存储区块中的登记密钥的存储区，执行登记密钥复位处理，由待毁坏的登记密钥(Kcr)的存储区块地址(Ad)和复位密钥(Kreset)构成的复位处理命令是从终端实体(EE)输入的，并且在步骤S607中，在对应于存储区块地址(Ad)的存储区上执行复位密钥(Kreset)的写处理(如参照图68所述)，由此登记密钥被复位。一旦在步骤S607中完成登记密钥的请求，就在步骤S608向终端实体(EE)输出复位完成通知。
(6-5)执行属性证书复位(毁坏)处理
下面，将说明执行属性证书复位(毁坏)处理，即毁坏用户装置中存储的执行属性证书，并且向业务供应商通知成功执行毁坏的事实。
下面依据图70和图71的处理顺序进行说明。在图70和图71中，
EE：用户装置终端实体控制单元，
SC：配置在EE内的安全芯片，
执行AC表：管理表存储器和存储器控制单元的执行AC，
SP：实施执行AC发放处理的业务供应商装置控制单元(SP)，和
SM：SP内的安全模块。
首先，在步骤S611中，用户经由终端实体(EE)的输入接口输入执行属性证书(执行AC)毁坏应用请求命令。根据该请求，把执行属性证书毁坏应用发送给业务供应商。该应用例如包括，能够标识待毁坏的执行属性证书(执行AC)的执行属性证书(执行AC)ID，或者指定数据的内容和业务等。
一旦业务供应商装置控制单元(SP)收到执行属性证书毁坏应用，就在步骤S612中执行安全芯片(SC)与业务供应商(SP)的安全模块(SM)之间的相互认证，并且如果需要，则执行应用为执行属性证书(执行AC)毁坏条件的发放给业务供应商的已经发放的组属性证书的验证和检查。把执行属性证书毁坏处理视为业务，则终端实体充当业务供应商。
验证处理被执行为，集中于安全芯片和安全模块的加密单元(参见图9)上的参照图13所述的公共密钥相互认证处理。验证处理如参照图21至图23所述的处理，并且被执行为包括属性证书签名验证、对应公共密钥证书(PKC)和链公共密钥证书确认处理等的处理。
请注意，尽管这里的说明是对终端实体(EE)的安全芯片(SC)的执行属性证书的毁坏处理的实例，但是如果毁坏用户标识装置(UID)的用户安全芯片(USC)的执行属性证书，则执行以下各项：
(1)EE的SC与SP-SM之间的相互认证，
(2)EE的SC与UID的USC之间的相互认证，
(3)UID的USC与SP-SM之间的相互认证。或者作为更简单的配置，构成当连接EE时，EE就基本接受(认为已验证)UID的处理配置，并且在此情况下，可以省略上述的相互认证(2)。此外，可以实现上述三种不同组合之下的认证配置。
一旦在步骤S612建立了认证、组属性证书验证和检查，在步骤S613，用户装置的终端实体就向执行AC表提出用于待毁坏的执行AC的搜索请求。搜索密钥是例如内容信息或者业务供应商(SP)信息等。
在步骤S614中，执行AC表基于终端实体的输入密钥，搜索对应的业务供应执行AC，并且在步骤S615中，向终端实体(EE)输出从该表提取的业务供应执行AC。此外，在步骤S616，执行AC表(控制单元)从执行AC表中删除待毁坏的执行AC的项目( )。
在步骤S617中，终端实体(EE)向安全芯片输出复位(resent)执行请求。在步骤S618中，把用于改写共享密钥存储区中的登记密钥的存储区中的复位密钥(Kreset)的处理执行为登记密钥复位处理(参见图68)，并且向终端实体(EE)输出复位完成通知。
此外，终端实体(EE)在图71所示的步骤S621中向业务供应商(SP)发送复位完成通知。该复位完成通知具有待毁坏的执行AC。在步骤S622，接收待毁坏的执行AC的业务供应商(SP)向安全模块(SM)输出用于复位确认执行AC的生成请求。该请求与待毁坏的执行AC一起执行。
在步骤S623中，安全模块(SM)从待毁坏的执行AC中提取存储对应的登记密钥的存储区块地址信息，并且在步骤S624中执行复位确认执行AC生成处理。复位确认执行AC是一个数据配置，包括：存储对应待毁坏的执行AC的登记密钥的存储区块地址信息(Ad)；执行命令，它是由复位确认执行AC在用户装置的安全芯片(SC)上执行的命令；以及发放者即安全模块(SM)(参见图72中的复位确认执行AC 621)的签名。
在步骤S625，所生成的复位确认执行AC从业务供应商(SP)发送到终端实体(EE)，并且在步骤S626中被发送给安全芯片(SC)。
在安全芯片(SC)上，在步骤S627，执行基于复位确认执行AC的复位确认结果生成处理。现在参照图72说明步骤S627的复位确认生成处理的细节。
如图72所示，在步骤S641中，安全芯片605应用基于在复位确认执行AC 621中存储的地址的从共享密钥存储区608提取的复位密钥(Kreset)，解密复位确认执行AC的执行命令，获得用安全芯片的公共密钥(KpSC)加密的数据(Ep(ConfReset‖Kcs；KpSC))的解密命令数据(Dpc[Ep(ConfReset‖Kcs；KpSC)]，并且在步骤S642中用安全芯片(KsCS)的秘密密钥进行解密，获得复位信息结果生成命令(ConfReset)和对话密钥(Kcs)，并且执行步骤S643的复位确认结果生成处理。
至于步骤S643中的复位确认结果生成处理，首先，在步骤S644中，根据复位确认执行AC 621中存储的地址，从共享存储区608读取复位密钥(Kreset)，并且在步骤S645中，用对话密钥(Kcs)加密存储区块地址信息(Ad)与复位密钥(Kreset)的链接数据，并且向终端实体(EE)输出由加密数据(Ec(Ad‖Kreset；Ksc))形成的复位确认结果622。
终端实体(EE)在图71的步骤S628中向业务供应商(SP)发送复位确认结果，在步骤S629，业务供应商(SP)向安全模块(SM)发送复位确认结果，安全模块(SM)向业务供应商(SP)发送复位确认结果，从而结束处理。
至于上述的处理，在业务供应商确认之下，以可靠方式(sure manner)执行发放的执行AC地毁坏处理。
请注意，登记密钥毁坏处理可以根据执行AC来执行。下面参照图73说明基于执行AC所执行的登记密钥毁坏处理。登记密钥执行AC是由例如已经发放对应的业务供应执行AC的业务供应商(SP)发放的，并且经由用户装置的终端实体(EE)输入给安全芯片(SC)。
登记密钥毁坏执行AC 623是一个AC，具有：存储待毁坏的登记密钥的共享密钥存储区的存储区块地址信息(Ad)，用登记密钥加密的登记密钥毁坏命令(RevK)，和发放者签名，如图73所示。
在步骤S651中，根据从共享密钥存储区608获取(依据登记密钥毁坏执行AC 623的存储区块地址信息(Ad)获取)的登记密钥(Kcr)加密登记密钥毁坏执行AC 623的执行命令，获得毁坏命令(RevK)，并在步骤S652基于命令执行毁坏处理。在步骤S653中，基于登记密钥毁坏执行AC 623的存储区块地址信息(Ad)在对应的存储区中改写复位密钥(Kreset)，从而毁坏(复位)登记密钥。
(7)执行属性证书的特定使用处理
下面将说明应用上述执行属性证书(执行AC)的特定处理。作为使用处理的实例，将分别说明以下各项：
(7-1)具有次数限制的业务供应执行属性证书
(7-2)具有传递功能的业务供应执行属性证书
(7-3)代理执行属性证书。
(7-1)具有对次数限制的业务供应执行属性证书
首先，说明具有对次数限制的业务供应执行属性证书的应用处理。图74和图75说明了应用具有次数限制的业务供应执行属性证书，解密和使用具有次数限制的加密数据(如图像音乐，程序和类似内容)的处理顺序。下面将依据步骤说明处理顺序。
让我们假定，用户装置已经具有带存储在存储器上的次数限制的业务供应执行属性证书，例如，具有使用的剩余次数为n次的上述执行AC表。次数或者剩余使用次数数据(例如，n次)被存储在具有作为标识值的可应用次数的次数限制的业务供应执行属性证书的执行命令中。下面将说明记录的实例。
在步骤S701中，经由用户经由终端实体(EE)的用户接口输入业务供应执行AC，在此情况下，输入的是用于加密的数据解密执行AC的应用处理请求。该处理请求包含执行AC标识符，或者业务供应商(SP)信息，数据标识业务内容，例如使用内容指定数据。在步骤S702中，终端实体(EE)向执行AC表输出用于用户指定的业务供应执行AC(已加密数据解密执行AC)。搜索密钥是，例如内容信息或者业务供应商(SP)信息等。
在步骤S703中，执行AC表基于来自终端实体的输入密钥，搜索对应的加密数据解密执行AC，并且在步骤S704中，向终端实体(EE)输出从该表中提取的已加密数据解密执行AC。在该加密的数据解密执行AC中记录剩余次数＝n的次数信息。
在步骤S704中，终端实体(EE)向安全芯片(SC)输出已接收的AC，并且提出用于业务供应执行AC(已加密数据解密执行AC)的应用处理请求。该应用处理被执行为如下。首先，在步骤S705中，通过解密具有登记密钥的已加密数据解密执行AC的执行命令，来执行解密密钥设置处理，向终端实体(EE)输出解密密钥设置完成通知(S706)，并且在EE上，从例如外部存储器获取待解密的已加密数据(S707)，向SC提出解密请求(S708)，在SC执行数据解密处理(S709)，执行从SD向EE发送解密数据的数据解密处理(S710)，并且在步骤S711中，将已加密的数据解密执行AC的执行命令内的使用次数的剩余次数从n更新为n-1。
随后，在确定更新后的使用次数的剩余次数之后(S712)，如果使用次数的剩余次数≥1，则遵从图75(a)中所示的顺序，所以重新生成和保存登记密钥(S721)，重新生成已加密的数据解密执行AC(S722)，向EE发送，以及响应来自EE的已加密数据解密执行AC保存请求(S723)，将其保存到执行AC表上(S724)。
另一方面，如果使用次数的剩余次数＝0，则遵从图75(b)中所示的顺序，所以在SC上执行登记密钥毁坏处理(S725)，并且在对EE的登记密钥毁坏通知(S726)之后，根据来自EE的已加密数据解密执行AC删除请求(SC)，为执行AC表执行已加密数据解密执行AC删除(S728)。
下面参照图76和图77说明从步骤S705开始的在安全芯片(SC)上的处理。图76是在使用次数的剩余次数≥1的情况下执行的处理，图77是在使用次数的剩余次数＝0的情况下执行的处理。
首先，将参照图76说明在使用次数≥1的情况下在安全芯片(SC)上的处理。
具有对次数限制的业务供应执行属性证书701包括：执行命令(Ec(DecEData‖Kcd‖NumTr(n)；Kcr1))，存储用于加密执行命令的登记密钥的共享密钥存储区中的块地址(Ad)，以及发放者签名。执行命令包含已加密的数据解密命令(DecEData)，数据解密密钥(Kcd)，以及对应于使用次数的剩余次数(n)的次数处理执行命令(NumTr(n))，并且是用登记密钥(Kcr1)加密这些数据的执行命令(Ec(DecEData‖Kcd‖NumTr(n)；Kcr1))。
首先，在步骤S731，安全芯片(SC)应用根据执行AC的块地址(Ad)从共享密钥存储区提取的登记密钥(Kcr1)解密执行AC 701的执行命令，提取数据(DecEData‖Kcd‖NumTr(n))，并且在步骤S732应用数据解密密钥(Kcd)，以便执行已加密数据702的解密(Ec(Data；Kcd))，比如，外部输入的已加密内容或类似物，并向终端实体输出已解密的内容(数据)。
此外，在步骤S733中，根据处理命令(NumTr(n))的次数执行处理。该处理是对象是通过更新使用次数的剩余次数生成具有对次数限制的新业务供应执行属性证书704的处理。
通过随机数生成处理，生成新的登记密钥Kcr2(S734)，并且将其写入对应于块地址的共享存储区608，该地址是写入具有对次数限制的原业务供应执行属性证书701的地址。所以，用新的登记密钥(Kcr2)替代以前写入的登记密钥(Kcr1)。
在步骤S736中，一旦执行内容解密处理，基于次数处理命令提取的使用次数的剩余次数＝n就经历递减1的更新。这将执行命令中的数据(DecEData‖Kcd‖NumTr(n))改写成(DecEData‖Kcd‖NumTr(n-1))，并且在步骤S737中，执行使用新生成的登记密钥(Kcr2)的解密处理。加密数据等同于具有对次数限制的新的业务供应执行属性证书704内的执行命令(Ec(DecEData‖Kcd‖NumTr(n-1)；Kcr2))。
在步骤S738中，通过安全芯片的秘密密钥(KsSC)执行基于具有在步骤S737中成生的使用次数已更新的剩余次数的执行命令的块地址(Ad)和电子签名，并且新生成具有对次数限制的新的和更新的业务供应执行属性证书。
在图75中的步骤S722，具有新生成的次数限制的新的和更新的业务供应执行属性证书从安全芯片(SC)输出到终端实体(EE)，然后在步骤S724被保存在执行AC表中。
另一方面，将参照图77说明，在确定用于图74的处理步骤712中的使用次数剩余次数检查的使用次数的剩余次数＝0情况下，在安全芯片(SC)上的处理。
具有对次数限制的业务供应执行属性证书705具有：执行命令(Ec(DecEData‖Kcd‖NumTr(1)；Kcr1))，存储用于解密执行命令的登记密钥的共享密钥存储区的块地址(Ad)，以及发放者签名。
首先，在步骤S741，安全芯片(SC)应用基于执行AC中的块地址(Ad)从共享密钥存储区中提取得登记密钥(Kcr1)解密执行AC 705的执行命令，提取数据(DecEData‖Kcd‖NumTr(n))，并在步骤S742应用数据解密密钥(Kcd)，以便执行已加密数据706(Ec(Data；kcd))的解密，比如外部输入的已加密内容等，并把已解密的内容(数据)707输出到终端实体。
此外，在步骤S743中，基于次数处理命令(NumTr(1))执行处理。该处理是对象是毁坏登记密钥、停止利用执行AC的业务的进一步使用，即解密已加密的数据的处理。也就是说，在步骤S744中，毁坏登记密钥(Kcr1)。登记密钥的毁坏被执行为，改写共享存储区中的块地址(Ad)的对应区的复位密钥的处理，所述共享存储区存储被记录在具有对次数限制的业务供应执行属性证书705中的登记密钥。
由于这个处理，毁坏了对在具有对次数限制的业务供应执行属性证书705中存储的执行命令进行解密的登记密钥(Kcr1)，所以执行命令的解密变得不可能，并且停止了应用执行AC的业务使用。在该处理之后，执行步骤75显示的步骤S727和步骤S728，并且从执行AC表删除对应的AC。
(7-2)具有转让功能的业务供应执行属性证书
下面将说明具有转让功能的业务供应执行属性证书的应用处理。图78说明了启动具有转让功能的业务供应执行属性证书的应用处理的处理顺序，即基于具有在用户装置之间的转让功能的业务供应执行属性证书执行处理，生成具有转让功能的新的业务供应执行属性证书，或者业务供应执行属性证书，并把该证书发送给另一个用户装置(转让目的地)，同时在自己的装置(转让始发者)执行登记密钥毁坏，从而使得能够在(enable)另一个装置上使用的已加密的数据(例如，已加密内容)。
在图78中，
EE1：转让始发用户装置终端实体(EE)控制单元，
SC1：配置在EE1中的安全芯片，
执行AC表1：转让始发终端实体(EE)执行AC表控制单元，
EE2：转让目的地用户装置终端实体(EE)控制单元，
SC2：配置在EE2内的安全芯片，
执行AC表2：转让目的地终端实体(EE)执行AC表控制单元。
首先，在步骤S752中，转让目的地用户经由终端实体(EE)的输入接口输入转让请求，以用于根据具有转让功能的业务供应执行属性证书执行转让处理，即在转让目的地用户装置上使得能够进行加密数据的执行。转让请求包含：具有转让功能ID的业务供应执行属性证书、持有者信息、或者使用内容(已加密数据)，或者业务供应商信息等，以作为标识待应用的具有转让功能的业务供应执行属性证书。
一旦终端实体(EE2)收到来自用户的转让请求，在步骤S752中，终端实体(EE2)就向具有带转让功能的业务供应执行属性证书的转让始发者终端实体(EE1)提出连接请求，并且在用户装置的安全芯片(SC1)与安全芯片(SC2)之间执行相互认证。该相互认证被执行为例如参照图13所述的公共密钥相互认证处理。
一旦建立相互认证，在步骤S753中，转让始发用户装置的终端实体(EE1)就向执行AC表1输出用于指定的具有转让功能的业务供应执行属性证书的搜索请求。搜索密钥例如是，内容信息或者业务供应商(SP)信息或类似信息。
在步骤S754中，执行AC表1基于来自终端实体(EE1)的输入密钥搜索对应的具有转让功能的业务供应执行属性证书，并且向终端实体(EE)输出从该表提取的执行AC。
在步骤S755中，终端实体(EE)向安全芯片(SC)输出已接收的AC，并且提出用于具有转让功能的业务供应执行属性证书的应用处理请求。在步骤S756中安全芯片执行用于已接收的AC的处理，即根据从被存储在执行属性证书(具有转让功能的业务供应执行属性证书)中的地址(Ad)所指定的存储区中获得的登记密钥，解密执行命令(S756)。
此外，在步骤S757中，终端实体(EE1)向安全芯片(SC)输出转让处理请求，并且在步骤S758中，终端实体(EE1)请求转让目的地用户装置(EE2)展示转让处理所需的组属性证书。该组属性证书是证明持有者是准许转让的装置或者用户组的组属性证书等，并且被例如发放具有转让功能的业务供应执行属性证书的业务供应商(SP)管理。
在步骤S759，转让目的地用户装置终端实体(EE2)向转让始发用户装置终端实体(EE1)发送指定的组属性证书(Gp.AC)，终端实体(EE1)向安全芯片(SC1)转让已接收的AC，并且安全芯片(SC1)检验组属性证书(S761)。验证处理如同参照图21至图23所述的处理，并且被执行为包括属性证书签名验证、对应公用密钥证书和链公共密钥证书验证处理等的处理。
如果没有建立验证，则不执行后续处理，并取消该处理作为错误处理。在此情况下，执行向转让目的地终端实体(EE2)传送错误通知的处理。
如果组属性证书(Gp.AC)的验证是成功的，并且已经确认组属性证书(Gp.AC)的真实性，则流程前进到步骤S762。在步骤S762中，生成并且发送执行属性证书，以在转让目的地用户装置上使得能够使用加密数据。该处理是对应于利用执行图60和图61中的业务供应商(SP)的处理的转让始发用户装置，如图60和图61所述，生成和验证登记密钥生成执行AC以及生成和传送业务供应执行AC的处理。
在步骤S762中，生成新的业务供应执行AC，此情况下的业务供应执行属性证书，并发送给转让目的地用户装置。此外，在步骤S763中，删除应用于解密具有转让功能的业务供应执行属性证书的执行命令的登记密钥，所述登记密钥被保持在始发用户装置上。通过用上述的复位密钥进行改写，执行该处理。请注意，尽管这里已经提及了转让功能，但是利用不删除登记密钥的执行属性证书能够实现复制转让功能而不是复制功能。
下面参照图79和图80说明在转让始发用户装置的安全芯片(SC1)上执行的步骤S756中，对具有转让功能的业务供应执行属性证书的解密之后的处理细节。
具有转让功能的业务供应执行属性证书(AC)711具有以下数据：执行命令，存储用于解密执行命令的登记密钥的共享密钥存储区608中的块地址(Ad1)，发放者签名。执行命令(Ec(Sel‖Jdg(SDB)‖GenAC(Genkcr)‖GenAC(Ex)‖Revk‖DecEData‖Kcd；Kcr1))具有数据配置，包括处理选择命令(Se1)，验证检查命令(Jdg(SCB))，登记密钥生成执行AC生成命令(GenAC(Genkcr))，执行AC编译命令(GenAC(Ex))，登记密钥毁坏命令(Revk)，已加密数据解密命令(DecEData)，以及数据加密密钥(Kcd)，这些数据用登记密钥(Kcr1)加密。
验证检查命令(Jdg(SDB))是基于业务信息数据库(SDB)的执行AC的验证检查处理命令。请注意，业务信息数据库(SDB)具有：与提供业务所需的AC信息相同数据结构，上述(参见图15)的组信息数据库，以及组信息。
输入具有转让功能的业务供应执行属性证书(AC)711，并执行为转让目的地发放新的具有转让功能的业务供应执行属性证书的处理的转让始发安全芯片(SC)，首先根据具有转让功能的业务供应执行属性证书(AC)711的地址(Ad1)，从共享密钥存储区608获得登记密钥，并解密具有转让功能的业务供应执行属性证书(AC)711内的执行命令。然后，根据来自终端实体的转让执行触发712的输入，执行从步骤S772开始的转让执行处理。
转让执行触发712是指基于具有转让功能的业务供应执行属性证书(AC)711的来自执行转让处理的终端实体的处理请求。具有转让功能的业务供应执行属性证书(AC)711是一个执行AC，不仅用于转让处理而且还应用于已加密数据的解密处理，而且通过来自终端实体的请求(触发)来选择是否执行该处理。来自具有转让功能的业务供应执行属性证书(AC)711的执行命令(Ec(Sel‖Jdg(SDB)‖GenAC(Genkcr)‖GenAC(Ex)‖Revk‖DecEData‖Kcd；Kcr1))的选择处理产生(yield)，对应于转让执行处理的执行命令(Jdg(SDB‖GenAC(Genkcr)‖GenAC(Ex)‖Revk)，并且依据执行命令执行自步骤S772开始的处理。
在步骤S722中，依据验证检查命令(Jdg(SDB))，对从转让目的地获得的组属性证书(Gp.AC)713执行验证和检查。验证处理如同参照图21至图23所述的处理，并且被执行为，包括属性证书签名验证、对应公共密钥证书和链公共密钥证书确认处理等的处理。如果未建立验证，则不执行后续处理，并且取消该处理作为错误处理。如果组属性证书(Gp.AC)是成功的，并且已经确认组属性证书(Gp.AC)的真实性，则流程前进到步骤S773。
自步骤S773开始，生成并转让在转让目的地用户装置上的加密数据的执行属性证书启动(enabling)使用。这是对应于参照图60、图61和图63至图65所述的登记密钥生成执行AC的生成和验证，以及业务供应执行AC的生成和传送的处理，并且是其中在转让始发用户装置上执行图60和图61所示的业务供应商(SP)的处理的处理。
从转让目的地用户装置等获取该处理所需的数据714，比如恢复密钥(Kreset)、转让目的地上的共享存储器的登记密钥存储区的块地址(Ad2)以及转让目的地的安全芯片的公共密钥(KpSC2)。根据该所需数据，首先在步骤S773中，依据执行命令中的登记密钥生成执行AC编译命令(GenAC(GneKcr))执行登记密钥成生执行AC 715的生成处理。该处理与参照图63所述的登记密钥生成执行AC的生成处理相同。
然后，已经接收登记密钥生成执行AC的转让目的地用户装置的安全芯片遵从执行命令中的执行AC编译命令(GenAC(Ex))，并生成跟随参照图64所述的处理的登记密钥生成执行结果(图80中的721)，并且把该结果发送到转让始发用户装置的安全芯片。
一旦收到来自转让目的地用户装置的安全芯片的登记密钥生成执行结果(图80的721)，转让始发用户装置的安全芯片就执行图80的处理，并生成具有转让功能(AC)的新的业务供应执行属性证书722，并将其发送给转让目的地用户装置，同时执行毁坏在自己的共享密钥存储区内的登记密钥的处理。
在图80的步骤S781中，应用对话密钥(Kcs)执行登记密钥生成结果的解密处理，并获取登记密钥(Kcr2)和存储区块地址(Ad2)。此外，在步骤S782中，使用转让目的地用户装置的登记密钥(Kcr2)加密要存储在具有转让功能(AC)的新的业务供应执行属性证书内的执行命令(Ec(Sel‖Jdg(SDB)‖GenAC(GenKcr)‖GenAC(Ex)‖Revk)‖DecEData‖Kcd；Kcr2))。请注意，执行命令是例如设置在充当业务供应执行AC的具有转让功能的新的业务供应执行属性证书(AC)722内的执行程序等。
此外，在步骤S783中，对于通过已经用登记密钥(Kcr2)加密的执行命令和存储登记密钥(Kcr2)的转让目的地用户装置上的安全芯片的存储区块地址(Ad2)而获得的数据，利用转让始发安全芯片(SC1)的秘密密钥(KcSC1)生成签名，从而生成具有转让功能(AC)的新的业务供应执行属性证书722，该证书被发送给转让目的地用户装置。
此外，在步骤S784中，把复位密钥写入已经被存储在具有转让功能的始发业务供应执行属性证书(AC)711中的地址(Ad1)，即把复位密钥写入转让始发用户装置的共享密钥存储区中的登记密钥存储地址，并且执行登记密钥毁坏处理。
尽管上述说明已经描述了生成并发送从转让始发者到转让目的地的具有转让功能的新的业务供应执行属性证书(AC)722的配置的实例，但是还可以是，替代具有转让功能的业务供应执行属性证书(AC)722的，生成和发送常规的即没有转让功能的业务供应执行属性证书(AC)的配置。
如前所述，具有转让功能(AC)的业务供应执行属性证书是不仅适用于转让处理，而且还适用于加密数据的解密处理的执行AC。通过来自终端实体的请求(触发)选择待执行的处理。下面将参照图81说明触发是已加密的数据解密处理顺序情况下的安全芯片上的处理。
具有转让功能的业务供应执行属性证书(AC)731具有：执行命令的数据，存储用于解密执行命令的登记密钥的共享密钥存储区608的块地址(Ad1)，以及发放者签名。
一旦收到具有转让功能的业务供应执行属性证书(AC)731的输入，安全芯片(SC)首先根据具有转让功能(AC)的业务供应执行属性证书的地址(Ad1)从共享密钥存储区608获得登记密钥，并且解密具有转让功能(AC)的业务供应执行属性证书之内的执行命令。然后，一旦终端实体输入已加密的数据解密触发732，就在步骤S786中，选择基于触发即数据解密执行的选择处理，并且在步骤S787中，执行解密处理。
也就是说，从具有转让功能的业务供应执行属性证书(AC)731的执行命令(Ec(Sel‖Jdg(SDB)‖GenAC(GenKcr)‖GenAC(Ex)‖RevK‖DecEData‖Kcd；Kcr1))中获得对应于数据解密处理的执行命令(DecEData‖Kcd)，并且在步骤S787中，应用数据解密密钥(Kcd)执行待解密的外部输入已加密数据(Ec(Data；Kcd))的解密处理，并且输出已解密的数据734。待解密的已加密数据(Ec(Data；Kcd))733是已经用密钥(Kcd)加密内容，比如图像、音乐、程序等的数据，并且可以由通过解密存储执行命令而获得的数据解密密钥(Kcd)来解密，该存储执行命令存在于具有登记密钥(Kcr1)的转让功能(AC)的业务供应执行属性证书中。
还可以设想组合转让功能和次数限制的应用实例。例如，设置待转让的执行AC的次数信息，以便当转让执行AC时递减1，以便能够实现转让次数收到限制。此外，还可以设想组合复制功能与次数限制的应用实例。例如，设置待转让的执行AC的次数信息，以便每次执行复制时递减1，以便能够实现限制复制次数。这里，术语“复制”是指执行没有转让功能的业务供应执行属性证书。此外，提供次数信息递减1的功能，可以实现检入/检出(check-in/check-out)功能，而不是毁坏已经复制的业务供应执行属性证书。
下面简要地说明检入/检出。业务使用权限转让到另一个装置被称之为检验，业务使用权限从具有检验的装置转让到原始装置被称作签到。如果业务使用权限不能从具有检验的装置转让到不同于原始装置的装置，则称之为具有检入/检出功能。
(7-3)代理执行属性证书
下面将说明代理执行属性证书。在(6-3)执行属性证书应用处理中，用加密内容的数据针对数据的解密业务进行解密，但是执行属性证书还可以用来在执行属性证书中执行写只有业务供应商知道的加密密钥的业务，以及发放使用加密密钥署名的证书的业务。该业务供应执行属性证书是代理执行属性证书。
至于加密密钥，有使用共享密钥的方法和使用秘密密钥的方法。下面说明使用秘密密钥的情况。如果验证使用代理执行属性证书发放的证书，则验证者必需知道对应于秘密密钥的公共密钥。所以，代理执行属性证书的发放者发放用于公共密钥的证书，使用代理执行属性证书发放的证书持有者向验证者展示公共密钥证书。该公共密钥证书被称作代签名密钥证书。下面将分别说明用于代理执行属性证书的以下各项。
(7-3-1)检查代理执行属性证书
(7-3-2)代签名执行属性证书
下面将说明每一项。
(7-3-1)检查代理执行属性证书
首先，说明检查代理执行属性证书。如果向不易直接与属性证书管理机构交换信息的终端实体发放属性证书，则能够直接交换信息的另一个终端实体被属性证书管理机构启用(enable)，以便用约定的发放策略执行由代理发放的检查，该检查是检查代理执行属性证书是什么。
下面参照图82说明检查代理执行属性证书的概要。图82(a)示出了常规属性证书发放安排，以用于此情况下的组属性证书(Gp.AC)，其中属性持有者是向例如属性管理机构(AA)、属性证书登记管理机构(ARA)或者业务供应商(SP)提出发放请求(S801)的属性证书(AC)的用户。在该情况下，必须展示证明AC用户的属性的数据。在上述实例中，所作的说明涉及展示已经发放的组属性证书的实例，该组属性证书是***公司发放给AC用户的。
发放者执行作为AC用户的属性的用户确认的检查(S802)，并且一旦确定建立了检查，就向用户发放证明AC用户的属性的属性证书(该情况下是一个Gp.AC)(S803)。
在(b)中所示的实例是应用检查代理执行属性证书的组属性证书(Gp.AC)发放顺序，下面将进行详细说明。
首先，代理中向的AC用户发放组属性证书的检查代理，向原始发放者，例如属性管理机构(AA)、属性证书登记管理机构(ARA)、或者业务供应商(SP)的发出检查代理执行属性证书发放请求(S811)，并且是真实发放者的属性管理机构(AA)、属性证书登记管理机构(ARA)、或者业务供应商(SP)检查检查代理(S812)。该处理如同传统处理一样，是根据证明检查代理的属性或者展示已经发放的书信证书的数据执行的。在检查建立之后，发放者向检查代理提供代签名密钥证书804以及检查代理执行属性证书803(S813)。
代签名密钥证书804具有用于成生和验证代签名的公共密钥(Kpc)以及发放者签名数据。此外，检查代理执行属性证书803如同上述的执行证书一样，由以下各项组成：块地址(Ad)，用于指示检查代理的用户装置的共享密钥存储器内的登记密钥(Kcr)的存储区；用登记密钥(Kcr)加密的执行命令(Ec(代理检查命令‖属性信息‖Ksa；Kcr))；发放者签名。
执行命令中包含的秘密密钥(Ksa)是用于生成和验证代签名的秘密密钥，并且是对应于上述公共密钥(Kpa)的秘密密钥。
步骤S811至步骤S813是代理委托阶段，在代理委托阶段之后，开始代理执行阶段。AC用户(属性持有者)向检查代理发出属性证书(Gp.AC)(S814)。这里，检查代理发放的组属性证书被称作检查代理组属性证书。
已经收到检查代理组属性证书发放请求的检查代理检查用户(S815)。根据检查代理与AC用户之间的信任关系执行这里所用的检查，并且证明检查代理的属性或者展示已经发放的属性证书的数据不总是必需的。例如，在其中检查代理是一个家庭以及用户是该家庭的设置中，根据检查代理与AC用户之间的信任关系，比如认为当检查代理辨识该家庭时就相信检查被建立，执行随意地检查。
在检查建立之后，检查代理成生检查代理组属性证书802。检查代理组属性证书802持有参照图5所述的信息，比如发放到AC持有者(属性持有者)的安全芯片的公共密钥证书(PKC)序号、属性信息等。此外，应用检查代理已经从发放者接收的检查代理执行属性证书802中的执行命令中存储的秘密密钥(Ksa)附加一个签名。
检查代理把生成的检查代理组属性证书802和代签名密钥证书804一起发送给AC用户(S816)。AC用户向例如业务供应商(SP)展示检查代理组属性证书802，以证明属性并接收业务。
下面参照图83说明包括业务供应的实体之间的数据的流程。首先，在代理委托阶段，从发放者811向检查代理812发送检查代理执行AC 822和代签名密钥证书821。然后，在代理执行阶段，向AC用户(属性持有者)813发送检查代理组属性证书823和代签名密钥证书821。此外，从AC用户(属性持有者)813向诸如业务供应商(SP)的验证者814发送检查代理组属性证书823和代签名密钥证书821，其中验证者814根据检查代理组属性证书823和代理密钥证书821执行AC用户的属性验证，并且在建立验证的条件下提供业务。
在代签名密钥证书821的签名验证之后，诸如业务供应商(SP)的验证者814提取代签名密钥证书821中存储的代签名验证的公共密钥(Kpa)，并且执行应用所提取得公共密钥(Kpa)的检查代理组属性证书823的签名验证。
下面将参照图84说明，已经从发放者接收检查代理执行AC 822和代签名密钥证书821的检查代理，根据来自AC用户的请求生成和发放检查代理组属性证书823的处理。在图84中，
EE1：属性证书使用用户装置终端实体(EE)控制单元，
SC1：配置在EE1内的安全芯片，
EE2：检查代理用户装置终端实体(EE)控制单元，
SC2：配置在EE2内的安全芯片，和
执行AC表：EE2执行表控制单元。
请注意，检查代理不限于用户装置，并且可以做出业务供应商(SP)可以执行此的安排。这里将说明充当检查代理的用户装置。
首先，在步骤S821中，作为AC用户(属性持有者)的用户经由终端实体(EE1)的输入接口输入检查代理组属性证书(Gp.AC)发放请求。该请求包括生成检查代理组属性证书(Gp.AC)所需的信息，比如检查代理指定数据、待使用的内容或业务供应商的信息，等等。
一旦终端实体(EE1)从用户收到检查代理组属性证书(Gp.AC)发放请求，在步骤S822，终端实体(EE1)就向检查代理用户装置的终端实体(EE2)发出链接请求，并且在用户装置的安全芯片(SC1)与(SC2)之间执行相互认证。该相互认证被执行为，例如参照图13所述的公共密钥相互认证处理。
一旦建立了相互认证，在步骤S823中，检查代理用户装置的终端实体(EE2)就向执行AC表输出用于检查代理执行AC的搜索请求。搜索密钥例如是内容信息或者业务供应商(SP)信息等。
在步骤S824中，执行AC表根据来自终端实体(EE2)的输入密钥搜索对应的检查代理执行AC，并且向终端实体(EE2)输出从该表中提取的执行AC以及由发放者发放并附加到AC上的代签名证书(参见图82中的804)。
在步骤S825中，终端实体(EE2)向安全芯片(SC2)输出已接收的AC，并且做出执行属性证书的应用处理请求。安全芯片(SC2)在步骤S826中执行用于已接收的AC地处理，即，根据从存储在执行属性证书(检查代理执行属性证书)的地址(Ad)所指定的存储区获得的登记密钥，解密执行命令。
此外，在步骤S827中，AC用户的终端实体(EE1)把检查AC用户的组属性证书输入到检查代理的终端实体(EE2)，并且在检查代理的安全芯片(SC2)上执行验证处理。
如上所述，检查代理可以根据检查代理与AC用户之间的信任关系执行AC用户的检查，并且尽管展示证明检查代理的属性的数据，或者展示已经发放的属性证书并不总是需要的，但是这里示出了在展示和验证已经发放的组属性证书的条件下，发放检查代理组属性证书的一个实例。
安全芯片(SC2)的组属性证书的验证与参照图21至图23所述的验证相同，并且被执行为，包括属性证书签名验证、对应公共密钥证书和链公共密钥证书确认处理等的处理。如果未建立验证，则不执行后续处理并且取消该处理作为错误处理。在此情况下，可以执行向AC用户终端实体(EE1)发送错误通知的处理。
如果组属性证书(Gp.AC)的验证是成功的，并且已经确认组属性证书(Gp.AC)的真实性，则在步骤S830中，从终端实体(EE2)向安全芯片(SC2)输入生成检查代理组属性证书所需的附加信息(Addinfo)，并且安全芯片(SC2)生成检查代理组属性证书，以及在向终端实体(EE2)发送证书之后，将该证书从终端实体(EE2)发送给AC用户的终端实体(EE1)(S832)。在发送处理的时候，将代签名密钥证书附加到已生成的检查代理组属性证书。
下面将参照图85说明检查代理的安全芯片(SC2)上执行的处理的细节，即输入检查代理执行属性证书并生成检查代理组属性证书的处理。检查代理执行属性证书(AC)851持有执行命令的数据、存储用于解密执行命令的登记密钥(Kcr)的检查代理安全芯片(SC1)861的共享密钥存储区864的块地址(Ad)、以及发放者签名。执行命令(Ec(Jdg(SDB)‖GenAC(Gp)‖att‖Ksa；Kcr))包含：验证检查命令(Jdg(SDB))，组属性证书编辑命令(GenAC(Gp))，属性信息(att)和代签名秘密密钥(Ksa)，执行命令具有用登记密钥(Kcr)加密它们的数据结构。
一旦输入检查代理执行属性证书(AC)851，首先根据检查代理执行属性证书(AC)851的地址(Ad)，从共享密钥存储区864获取登记密钥，并且解密在检查代理执行属性证书(AC)851内的执行命令。然后，在步骤S842中，根据验证检查命令(Jdg(SDB))执行经由终端实体从AC用户输入的组属性证书的验证。验证处理如同参照图21至图23所述的处理，并且被执行为，包括属性证书签名验证、对应公共密钥证书和链公共密钥证书确认处理等的处理。如果未建立验证，则不执行后续处理并且取消该处理作为错误处理。如果组属性证书(Gp.AC)的验证是成功的，并且已经确认组属性证书(Gp.AC)的真实性，则流程前进到步骤S843。
在步骤S843，根据在检查代理执行AC 851的执行命令内的组属性证书编译命令(GenAC(Gp))生成和发送检查代理组属性证书。该处理是对应于参照图60、图61和图63至图65所述的生成和验证登记密钥生成执行AC，以及业务供应执行AC的生成和发送的处理，并且与图63至图65中的业务供应商(SP)的安全模块上的处理相同。最好将附加信息(addinfo)853附在指示它是检查代理属性证书的检查代理属性证书上，从而指示与常规属性证书的差异。
在步骤S844中，从检查代理执行属性证书851的执行命令获得的代签名秘密密钥(Ksa)被应用于对附加信息(addinfo)和属性信息(att)签名，从而生成检查代理组属性证书854，该证书经由终端实体(EE2)发送给AC用户(属性持有者)。请注意，代签名密钥证书被附在已生成的检查代理组属性证书上，并且被发送给AC用户。
AC用户向诸如业务供应商等的验证者展示通过上述处理发放的检查代理组属性证书和代签名密钥证书，并且在验证属性条件下接收业务。诸如业务供应商的验证者等应用可以从代签名密钥证书获得的密钥，以便能够验证检查代理组属性证书的签名。
应用上述检查代理组属性证书的实例是发放计数(accounts)次数受到限制的检查代理组属性证书。如果业务供应商(SP)向A先生的家庭的所有家庭成员提供业务，则利用证明家庭A的亲属的组属性证书(Gp.AC)检查是否为A先生的亲属。
此时，尽管，如果具有基本市民信息的第三方组织(比如市政厅)发放的属性证书(AC)被用作证明A家庭的成员资格的组属性证书(Gp.AC)，则可以实现具有高可靠性的属性检查，但是这种属性证书也许不能使用。另一方面，A先生自己发放证明A家庭的亲属资格的组属性证书(Gp.AC)可能依赖于A先生的意愿。然而，个体的A先生可以被确定为可信赖的属性管理机构(AA)(即属性证书的真实发放实体)是不太可能的。
所以，应用上述的检查代理执行AC，发放检查代理组属性证书。在此情况下，A先生应用检查代理执行AC发放检查代理组属性证书，以充当代表A先生家庭的检查代理。根据检查代理(A先生)与AC用户(A先生的家庭)之间的信任关系，可以实现发放检查代理组属性证书的检查，并且不总是需要展示证明检查代理的属性的数据或展示已经发放的属性证书。因而，根据检查代理与AC用户之间的信任关系，比如一旦检查代理是亲属的事实被辨别就认为已经建立了检查，可以发放检查代理组属性证书。
然而，存在A先生向不是家庭成员但具有显示是A先生家庭成员的属性的朋友B先生发放检查代理组属性证书的可能性。为了减少这种情况的可能性，可以对发放的检查代理组属性证书的数量进行限制，比如设置上限＝5，从而防止过多的未授权的使用。
以其中由A先生拥有的装置被设置为一组的组属性证书，同样可以实现上述的检查代理组属性证书发放处理安排，并且A先生可以根据检查代理执行AC向每一个他自己的装置发放检查代理发放组属性证书，其中A先生充当具有应用检查代理执行AC的检查代理组属性证书的检查代理。
此外，应用检查代理组属性证书的处理的实例是选举投票的应用的实例。使用检查代理组属性证书能够使投票人能够投票，使投票赞成的候选人本人可以得知谁是投赞成票的投票人，而谁是投赞成票的投票人连选举委员会成员也不知道。
在该处理实例中，让我们假定，
检查代理：投票人
AC用户(属性持有者)：候选人。
该投票***是在投票的时候，取代选举委员会的选举人候选人通信的模型，这与实际选举不同。首先，业务供应商(SP)向投票人发放检查代理执行AC。候选人告诉投票人唯一的标识值，即不同于所有其它投票的标识值，并且根据检查代理执行AC发放检查代理组属性证书(Gp.AC)，该检查代理组属性证书(Gp.AC)具有作为属性的投票人打算投票赞成的候选人的编号和PKC序号。当生成检查代理组属性证书(Pg.AC)之后，检查代理执行AC被自动毁坏。
根据发放给每个候选人的检查代理组属性证书(Gp.AC)的数量计算投票的数量，由此确定获胜者。具有相同标识编号的所有检查代理组属性证书被视为已经被复制，并且仅仅计算为一次投票。
(7-3-2)代签名属性证书
下面将说明代签名执行属性证书。代签名执行AC能够使AC用户(属性持有者)本人发放用于自己业务应用的组属性证书(代签名组属性证书)。
下面参照图86说明代签名执行属性证书的概要。图86(a)示出了常规属性证书的发放和应用处理安排。发放属性证书、此情况下的组属性证书(Gp.AC)的请求，从作为属性证书用户的属性持有者发送到发放者，即属性管理机构(AA)、属性证书登记管理机构(ARA)或者业务供应商(SP)(S901)。在该实例情况下，展示证明AC用户属性的数据是必要的。在上述实例中，描述了展示***公司已经发放给AC用户的已经发放组属性证书的实例。
发放者执行作为用户确认的检查(S902)，即检查AC用户等的属性，并且一旦确定已经建立了检查，就向用户发放证明AC用户的属性的属性证书921(这里是Gp.AC)(S903)。
通过向诸如业务供应商(SP)的验证者展示已发放的组属性证书(Gp.AC)，AC用户(属性持有者)可以接收业务应用，其中AC用户(属性持有者)响应来自验证者的组属性证书(Gp.AC)展示请求(S904)，展示组属性证书(Gp.AC)(S905)，从而由验证者执行组属性证书(Gp.AC)的验证(S906)。
在(b)所示的实例是应用代签名执行属性证书的组属性证书(Gp.AC)发放和应用处理顺序。
首先，AC用户(属性持有者)向发放者(例如，属性管理机构(AA)、属性证书登记管理机构(ARA)、或者业务供应商(SP))发放代签名执行属性证书(AC)(S911)。发放者执行证明AC用户的属性的数据检查，例如检查已经发放的组属性证书(S912)，并且一旦确定已经建立检查，就发放代签名执行属性证书923。此时，发放者还向AC用户(属性持有者)提供代签名密钥证书924。
代签名密钥证书924具有用于生成和验证代签名的公共密钥(Kpa)和发放者签名数据。此外，与上述的执行证书相同，代签名执行属性证书923由以下各项构成：块地址(Ad)，用于指示检查代理的用户装置的共享密钥存储器内的登记密钥(Kcr)的存储区；用登记密钥(Ksa)加密的执行命令(Ec(代签名命令‖属性信息‖Ksa；Kcr))；发放者签名。
包含在执行命令中的秘密密钥(Kcr)是用于生成和验证代签名的秘密密钥，并且是对应于上述公共密钥(Kpa)的秘密密钥。
步骤S911至步骤S913是发放阶段，在发放阶段之后，开始验证阶段。在步骤S914中，诸如业务供应商(SP)的验证者执行对AC用户(属性持有者)的代签名组属性证书(Gp.AC)的展示请求。在展示请求的时候，诸如业务供应商(SP)等的验证者向AC用户(属性持有者)发送用于代签名组属性证书(Gp.AC)的验证随机数(Ra)。
在步骤S915中，AC用户(属性持有者)响应来自诸如业务供应商(SP)的验证者的代签名组属性证书(Gp.AC)展示请求，应用先前从发放者接收的代签名组属性证书生成代签名组属性证书(Gp.AC)922。稍后将描述该生成处理的细节。代签名组属性证书(Gp.AC)922包括从验证者接收的验证随机数(Ra)信息，比如AC用户(属性持有者)的公共密钥证书(PKC)的随机数属性信息等，以及使用存储在先前从发放者接收的代签名执行属性证书923的执行命令中的秘密密钥(Ksa)附加一个签名。
AC用户(属性持有者)将所生成的代签名组属性证书922与代签名密钥证书924一起发送给验证者(S916)。在代签名密钥证书924的签名验证之后，验证者提取代签名密钥证书924中存储的代签名验证公共密钥(Kpa)，并且应用所提取得公共密钥(Kpa)执行代签名组属性证书922的签名验证。此外，验证代签名组属性证书中存储的随机数与自身在前生成的随机数之间的匹配，通过该验证，准许确认已经响应验证者的请求展示代签名组属性证书。
下面参照图87说明包括业务供应的实体之中的数据的流(flow)。首先，在发放阶段，从发放者931向AC用户(属性持有者)932发送代签名密钥证书941和代签名执行属性证书942。然后，一旦从AC用户(属性持有者)932向诸如业务供应商(SP)等的验证者933发出业务请求，验证者933就向AC用户(属性持有者)932发出代签名组属性证书(Gp.AC)展示请求。在该展示请求的时候，验证者933向AC用户(属性持有者)932发送用于代签名组属性证书(Gp.AC)的验证随机数(Ra)。
AC用户(属性持有者)932响应来自验证者933的代签名组属性证书(Gp.AC)展示请求，应用先前从发放者接收的代签名组属性证书以产生代签名属性证书(Gp.AC)943。代签名组属性证书(Gp.AC)943包括从验证者接收的验证随机数(Ra)信息，比如AC用户(属性持有者)932的公共密钥证书(PKC)的随机数，属性信息等，并且使用先前从发放者接收的代签名执行属性证书942的执行命令中存储的秘密密钥(Ksa)附加一个签名。
然而，AC用户(属性持有者)932把代签名组属性证书943和代签名密钥证书941一起发送给验证者，并且根据代签名组属性证书943和代签名密钥证书941执行AC用户的属性验证，并且在建立验证的条件下提供业务。
在代签名密钥证书941的签名验证之后，诸如业务供应商(SP)的验证者933提取代签名密钥证书941中存储的代签名验证公共密钥(Kpa)，并且应用已提取得公共密钥(Kpa)执行代签名组属性证书943的签名验证，并且通过核对已存储的随机数验证代签名组属性证书943。
下面参照图88说明，当诸如业务供应商(SP)等的验证者提出代签名组属性证书展示请求的时候，由具有发放者所发放的代签名组属性证书和代签名密钥证书的AC用户执行的处理细节。在图88中，
SP：执行属性证书的验证的业务供应商控制单元，
SM：SP的安全模块
EE：使用用户装置终端实体(EE)控制单元的属性证书，
SC：配置在EE内的安全芯片
执行AC表：EE的执行AC表控制单元。
图88所示的处理示出了在业务供应商(SP)的安全模块(SM)与用户装置的安全模块(SC)之间建立的相互认证之后的处理。
在相互认证建立之后，业务供应商(SP)在安全模块(SM)的属性证书验证的时候，做出生成待应用的随机数的请求(S951)，并且在步骤S952中，安全芯片(SM)响应该请求生成输出给业务供应商(SP)的随机数。
在步骤S953中，业务供应商(SP)向终端实体(EE)发出代签名组属性证书展示请求。此时，业务供应商(SP)还向终端实体(EE)发送代签名组属性证书(Gp.AC)的验证随机数(Ra)。
在步骤S954中，终端实体(EE)搜索执行AC表，以查找要应用于生成代签名组属性证书(Gp.AC)的代签名执行属性证书，并且在步骤S955中，执行AC表向终端实体(EE)输出代签名执行属性证书和对应的代签名密钥证书。
在步骤S956中，终端实体(EE)请求安全芯片(SC)的代签名执行属性证书的应用处理，即代签名组属性证书生成处理，并且在步骤S958中，安全芯片(SC)执行代签名组属性证书生成处理。代签名组属性证书生成处理的细节与基于参照图85所述的代签名执行属性证书的代签名组属性证书相同。然而，请注意从验证者接收的随机数(Ra)被存储在代签名组属性证书中。
在步骤S958中，安全芯片(SC)向终端实体(EE)发送所生成的代签名组属性证书。在步骤S959中，终端实体(EE)向业务供应商方的安全模块(SM)发送代签名组属性证书，以及先前已经从发放者接收的代签名密钥证书。
一旦业务供应商方的安全模块(SM)收到代签名组属性证书和代签名密钥证书，就提取代签名密钥证书中存储的用于代签名验证的公共密钥，并且将所提取得公共密钥(Kpa)应用于执行代签名组属性证书的签名验证，并且基于代签名组属性证书中所存储的随机数的核对处理进行验证，以及向业务供应商(SP)通知验证结果。如果根据答复结果建立了验证，则业务供应商(SP)提供业务，并且如果未建立验证，则执行业务停止处理。
常规属性证书是应用代签名执行属性证书的一个实例。也就是说，使用代签名执行属性证书替代常规属性证书，允许使用执行属性证书的毁坏处理功能，所以可以解决撤销处理的麻烦，比如每次执行验证时查阅用于毁坏的列表，以及可靠性的降低。
再一个应用实例是限制证明属性的次数的代签名属性证书。也就是说，使用具有次数限制的代签名执行属性证书充当用于准许业务供应，而不是对加密数据解密的组属性证书，可以实现待供应的受限制业务，而且没有外部实体如服务器保持次数信息的麻烦，以及不降低处理效率。
(8)实体配置
下面将参照附图说明充当信息处理装置的实体的配置实例，该信息处理装置比如是，具有安全芯片(SC)的终端实体(EE)或者具有安全芯片(SC)的用户标识装置(UID)，或者业务供应商(SP)，或者充当执行上述处理(即，生成、验证、发送/接收等)的用户装置的类似装置。
终端实体信息处理装置，比如用户装置和业务供应商以及类似装置分别具有用户执行各类数据处理和控制的CPU，并且还具有能够与其它实体通信的通信装置，并且可以被配置为各种信息处理装置，比如服务器、PC、PDA、便携通信终端装置等等。
图89示出了信息处理装置配置实例。请注意，图89所示的配置实例是一个实例，并且实体不一定需要具有这里所示的所有功能。图89所示的CPU(中央处理单元)95 1是运行各种应用程序和OS(操作***)的处理器。ROM(只读存储器)952存储由CPU 951运行的程序以及固定数据比如计算参数。RAM(随机存取存储器)953被用作存储区和工作区，以用于由CPU 951的处理运行的程序，和根据程序处理的需要改变的参数。
HDD 954执行硬盘的控制，并且执行向硬盘存储和从硬盘读出各种数据及程序的处理。安全芯片962具有上述的反篡改结构的配置，并且具有加密处理单元，数据处理单元以及存储器，用于存储加密处理、作为权限确认处理的属性证书验证、执行生成处理等所需的密钥数据。
总线960备配置为PCI(***部件接口)总线等，并且能够经由模块和输入/输出接口961实现与输入/输出装置的数据转让。
输入单元955被配置成键盘、指向装置等，并且通过用户操作来向CPU951输入各类命令和数据。输出装置956是CRT、液晶显示器等，并且显示文本、图像等地各种信息。
通信单元957被配置成诸如网络接口、链接装置接口等的装置，实现与例如业务供应商等的通信处理，以及在CPU 951的控制下执行，发送从存储单元供应的数据、CPU 951处理的数据、已加密的数据、或者接收来自其它实体的数据的处理。
驱动器958是执行可移动记录媒介959如软盘、CD-ROM(致密盘只读存储器)、MO(磁光)盘、DVD(数字通用盘)、磁盘、半导体存储器等的记录和重现的驱动器，并且从可移动记录媒介959重现程序或者数据，以及把程序或者数据存储到可移动记录媒介959上。
如果读出记录媒介中记录的程序或者数据并在CPU 951上运行或者处理，则已经读出的程序或数据被供应给例如经由接口961和总线960链接的RAM 953。
上述的在用户装置、业务供应商等上执行处理的程序，或者被存储在例如ROM 952中并被CPU 951处理，或者被存储在硬盘中并经由HDD 954供应给CPU 951，以待执行。
至此已经参照特定实施例说明了本发明。然而，不言而喻，在不背离本发明的精神和范围的条件下，本领域熟练技术人员可以做出各种修改和替代。也就是说，已经通过实例公开了本发明，但不是限制性地解释本发明。本发明的本质应当根据本发明的权利要求部分确定。
请注意，以上所述的处理序列可以由硬件、软件或者两者组合的配置来执行。如果用软件执行处理，则描述处理顺序的程序被安装在被构建成专用硬件的计算机的存储器中，或者将该程序安装在能够执行各种处理的通用计算机中，以便运行。
例如，程序可以被预先记录在充当记录媒介的硬盘或者ROM(只读存储器)中。或者，程序可以被临时或者永久地存储在软盘、CD-ROM(致密盘只读存储器)、MO(磁光)盘，DVD(数字通用盘)、磁盘、半导体存储器等的可移动记录媒介中。可以按所谓的封装软件提供这样的可移动记录媒介。
此外，软件除了从可移动记录媒介安装到计算机中外，还可以从下载站点无线传送到计算机，经由通向电缆通过网络如LAN(局域网)或互联网传送到计算机，计算机接收以这种方式传送的程序，并将其安装到记录媒介如内置硬盘上。
此外，请注意，说明书所述的各种处理不限于按照所述的时间顺序执行，而是可以根据执行该处理的装置的处理能力或者按照需要，并行地或者独立地执行。请注意，本说明中所用的术语“***”是多个装置的逻辑组，而不限于单个壳体内的组件装置。
工业应用性
如上所述，根据本发明的权限管理***、信息处理装置和方法，组属性证书被发放给业务接收实体，其中所述组属性证书具有作为被存储信息的、对应于某些通信装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名，然后借助用户装置展示的组属性证书的签名验证，验证是否存在篡改，并根据组属性证书中存储的组标识信息检查是否为业务准许组，以及根据该检查确定是否可以提供业务；因此，可以做出对应于不同用户集合或者装置集合的集中式权限确认，因而可以省略各自的权限信息管理，从而能够进行有效的权限管理。
此外，根据本发明的权限管理***、信息处理装置和方法，能够应用把组标识符与属于该组的成员的已准许的业务信息相关联的组信息数据库，实现是否可以提供业务的确定处理，从而能够辨别每组的设置权限的具体区别。
此外，根据本发明的权限管理***、信息处理装置和方法，根据用户装置展示的多个不同的组定义，为多个组属性证书获得的不同组标识信息的多个集合的每一个，执行关于是否为业务准许对象的检查，并且在所有组标识集合都是业务准许对象的条件下，执行关于是否可以提供业务的确定处理；从而可以实现权限设置的各种安排，比如根据多个条件如对应于装置的组集合的组集合和用户的组集合等提供业务。
此外，根据本发明的权限管理***、信息处理装置和方法，根据组属性证书中存储的组标识信息，执行访问请求装置是否为属于访问被准许组的装置的检查，并且根据该检查进行是否准许访问的检查，从而只允许访问一个访问请求通信处理装置组，该访问请求通信处理装置组是具有通信处理装置的用户随意设置的组成员的用户或者用户装置，其中所述的组属性证书具有作为被存储信息的、对应于某些通信装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名。
此外，根据本发明的权限管理***、信息处理装置和方法，根据被发放给是构成访问请求装置的个体标识装置的用户标识装置的组属性证书，检查访问请求装置是否为属于访问被准许组的用户所拥有的装置，并且根据该检查，确定是否准许访问，所以即使通信处理装置已经被改变，也准许在检查中根据被发放给个体标识装置的用户标识装置的组属性证书进行访问，并且可以避免由于改变通信处理装置造成的禁止访问的情况。
根据本发明的数据处理***、数据处理装置和方法，在执行多个可相互通信的装置之间的数据处理的数据处理***中，向正在与其通信的其它装置请求数据处理的数据处理请求装置，把具有作为被存储信息的、对应于某些通信装置的集合的组的组标识信息的组属性证书发送给数据处理被请求装置，在数据处理被请求装置上执行已接收的组属性证书的验证处理，根据该验证，确定数据处理请求装置是否具有数据处理请求权限，并且根据权限确定，执行数据处理，所以避免了错误装置或者用户执行处理的情况，并且执行基于有效权限的适当数据处理。
此外，根据本发明的数据处理***、数据处理装置和方法，利用多个数据处理装置请求和与其正在通信的其它装置的数据处理，从而协作地执行数据处理的安排，在与其正在通信的其它装置的数据处理请求的时候，每个装置发送自身存储的组属性证书，并且在接收装置建立验证的条件下，相互地执行对应于数据处理请求的处理，从而能够在多个数据处理装置之间执行伴随通信的适当协作数据处理。
此外，根据本发明的数据处理***，数据处理装置和方法，维护执行装置和维护业务接收装置分别存储控制属性证书和业务属性证书，在执行维护业务时交换属性证书，并且在每个装置上相互验证和检查属性证书，其中在已经建立检查的条件下，执行维护处理，所以可以在每个设置权限范围之内以确实方式实现维护处理。

Claims (75)

1、一种管理用户装置的业务接收权限的权限管理***；
其中作为业务接收实体的用户装置持有组属性证书，该组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；
其中，作为业务供应实体的业务供应商具有一个配置，用于借助签名验证执行所述用户装置展示的组属性证书是否存在篡改的验证，根据存储在该组属性证书中的组标识信息执行关于是否是业务准许组的检查，并且根据所述检查执行关于是否可以提供业务的确定。
2、根据权利要求1所述的权限管理***，其中，所述组属性证书是在组属性证书发放实体与用户装置之间建立相互认证的条件下，向对应于装置或者用户的用户装置发放的证书，并且被发给证书的装置或者用户遵循所述业务供应商准许的发放策略。
3、根据权利要求1所述的权限管理***，其中，新的组属性证书的发放处理是在组属性证书发放实体处建立关于用户装置已经持有的已经发放的组属性证书的验证的条件下，执行的配置的处理。
4、根据权利要求1所述的权限管理***，其中，所述业务供应商的配置具有组信息数据库，其中所述组标识符和属于该组的成员的准许业务信息被相互关联，其中根据用户装置展示的所述组属性证书中所存储的组标识信息，搜索所述组信息数据库，并执行关于是否可以提供业务的确定处理。
5、根据权利要求1所述的权限管理***，其中，所述业务供应商具有一个配置，其中根据所述用户装置展示的多个不同的组定义，对于从多个组属性证书获得的不同组标识信息的多个集合的每一个执行关于是否为业务准许对象的检查，并且在所有组标识集合都是业务准许对象的条件下，执行关于是否可以提供业务的确定处理。
6、根据权利要求1所述的权限管理***，其中，所述业务供应商具有一个配置，其中根据来自其中装置是组成员的所述用户装置的组定义，对于从第一组属性证书获得的第一组标识信息执行关于是否为业务准许对象的检查，并且根据来自其中装置是组成员的所述用户装置的组定义，对于从第二组属性证书获得的第二组标识信息执行关于是否为业务准许对象的检查，并且在所有组标识集合都是业务准许对象的条件下，执行关于是否可以提供业务的确定处理。
7、根据权利要求1所述的权限管理***，其中，用户装置具有一个配置，包括：作为执行与所述业务供应商通信的装置的终端实体，以及作为各个标识装置的用户标识装置；
其中所述组属性证书被单独地发放给所述终端实体和用户标识装置的每一个，该发放处理是在组属性证书发放实体与所述终端实体或者所述用户标识装置之间已经建立相互认证的条件下执行的。
8、根据权利要求1所述的权限管理***，其中，其中所述组属性证书是属性管理机构发放的属性证书，而组标识符被存储在被归档于属性证书内的属性信息中。
9、根据权利要求1所述的权限管理***，其中，所述组属性证书具有存储关于对应于所述组属性证书的公共密钥证书的链接信息的配置；
其中所述业务供应商具有一个配置，其中在执行所述组属性证书的验证的时候还执行通过所述链接信息获得的公共密钥证书的验证。
10、一种信息处理装置，用于执行作为业务供应处理的数据处理，包括：
数据接收单元，用于接收组属性证书，该组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；
组属性证书验证处理单元，用于借助签名验证执行组属性证书是否存在篡改的验证，根据存储在所述组属性证书中的组标识信息执行关于是否是业务准许组的检查，并且根据所述检查执行关于是否可以提供业务的确定。
11、根据权利要求10所述的信息处理装置，还包括组信息数据库，其中所述组标识符和属于该组的成员的准许业务信息被相互关联；
其中所述组属性证书验证处理单元根据所述用户装置展示的组属性证书中所存储的组标识信息，搜索所述组信息数据库，并执行关于是否可以提供业务的确定处理。
12、根据权利要求10所述的信息处理装置，其中，所述组属性证书验证处理单元具有一个配置，其中根据所述用户装置展示的多个不同的组定义，对于从多个组属性证书获得的不同组标识信息的多个集合的每一个执行关于是否为业务准许对象的检查，并且执行关于是否可以提供业务的确定处理。
13、一种管理用户装置的业务接收权限的权限管理方法，包括：
在作为业务接收实体的用户装置处的执行步骤，用于向作为业务供应商实体的业务供应商发送组属性证书，该组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；
以及，在所述业务供应商处的执行步骤，用于借助签名验证执行从所述用户装置展示的组属性证书是否存在篡改的验证，根据存储在所述组属性证书中的组标识信息执行关于是否是业务准许组的检查，并且根据所述检查执行关于是否可以提供业务的确定。
14、根据权利要求13所述的权限管理方法，还包括组属性证书发放处理步骤，用于向对应于装置或用户的用户装置发放所述组属性证书；
其中所述组属性证书发放处理步骤是，在组属性证书发放实体与用户装置之间建立相互认证的条件下，向对应于装置或者用户的用户装置发放组属性证书的处理步骤，并且被发给证书的装置或者用户遵循所述业务供应商准许的发放策略。
15、根据权利要求14所述的权限管理方法，其中所述组属性证书发放步骤包括关于用户装置已经持有的已经发放的组属性证书的验证处理的步骤，其中在建立所述验证的条件下执行组属性证书的发放。
16、根据权利要求13所述的权限管理方法，其中所述业务供应商的配置具有组信息数据库，其中所述组标识符和属于该组的成员的准许业务信息被相互关联，其中根据所述用户装置展示的所述组属性证书中所存储的组标识信息，搜索所述组信息数据库，并执行关于是否可以提供业务的确定处理。
17、根据权利要求13所述的权限管理方法，其中所述业务供应商具有一个配置，其中根据所述用户装置展示的多个不同的组定义，对于从多个组属性证书获得的不同组标识信息的多个集合的每一个执行关于是否为业务准许对象的检查，并且在所有组标识集合都是业务准许对象的条件下，执行关于是否可以提供业务的确定处理。
18、根据权利要求13所述的权限管理方法，其中，在所述业务供应商处，根据来自其中装置是组成员的所述用户装置的组定义，对于从第一组属性证书获得的第一组标识信息执行关于是否为业务准许对象的检查，并且根据来自其中装置是组成员的所述用户装置的组定义，对于从第二组属性证书获得的第二组标识信息执行关于是否为业务准许对象的检查，并且在所有组标识集合都是业务准许对象的条件下，执行关于是否可以提供业务的确定处理。
19、根据权利要求13所述的权限管理方法，其中，所述组属性证书具有存储关于与组属性证书对应的公共密钥证书的链接信息的配置；
并且所述业务供应商具有一个配置，其中在执行所述组属性证书的验证的时候还执行通过所述链接信息获得的公共密钥证书的验证。
20、一种信息处理装置的信息处理方法，用于执行作为业务供应处理的数据处理，所述方法包括：
从业务供应装置接收组属性证书的证书接收步骤，所述组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名，以作为应用于业务使用权限确认处理的属性证书；以及
组属性证书验证处理步骤，借助组属性证书的签名验证执行关于是否存在篡改的验证，并且根据存储在所述组属性证书中的组标识信息执行关于是否是业务准许组的检查，以及根据所述检查执行关于是否可以提供业务的确定。
21、根据权利要求20所述的信息处理方法，所述信息处理装置还包括组信息数据库，其中所述组标识符和属于该组的成员的准许业务信息被相互关联；
其中所述组属性证书验证处理步骤包括，根据所述用户装置展示的所述组属性证书中所存储的组标识信息，搜索所述组信息数据库，并执行关于是否可以提供业务的确定处理的步骤。
22、根据权利要求20所述的信息处理方法，其中，所述组属性证书验证处理步骤包括，根据所述用户装置展示的多个不同的组定义，对于从多个组属性证书获得的不同组标识信息的多个集合的每一个执行关于是否为业务准许对象的检查，并且在所有组标识集合都是业务准许对象的条件下，执行关于是否可以提供业务的确定处理的步骤。
23、一种实施管理用户装置的业务接收权限的权限管理处理执行的计算机程序，所述程序包括：
从业务供应装置接收组属性证书的证书接收步骤，所述组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名，以作为应用于业务使用权限确认处理的属性证书；以及
组属性证书验证处理步骤，借助组属性证书的签名验证，执行关于是否存在篡改的验证，并且根据存储在所述组属性证书中的组标识信息执行关于是否是业务准许组的检查，以及根据所述检查执行关于是否可以提供业务的确定。
24、一种访问权限管理***，用于在具有通信功能的通信装置之间执行访问限制；
其中访问请求装置在存储装置中存储一个组属性证书，所述组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；
其中来自所述访问请求装置的访问请求对象的访问请求的装置，借助所述访问请求装置展示的组属性证书的签名验证，执行关于是否存在篡改的验证，并且根据存储在所述组属性证书中的组标识信息执行所述访问请求装置是否是属于访问准许组的装置的检查，以及根据所述检查执行关于是否准许访问的确定。
25、根据权利要求24所述的访问权限管理***，其中，所述被访问请求的装置具有一个执行检查的配置，用于根据发放给是构成所述访问请求装置的访问执行装置的终端实体的组属性证书，检查所述访问请求装置是否为属于访问准许组的终端实体，并根据所述检查确定是否准许访问。
26、根据权利要求24所述的访问权限管理***，其中，所述被访问请求的装置具有一个执行检查的配置，用于根据发放给是构成所述访问请求装置的个体标识装置的用户标识装置的组属性证书，检查所述访问请求装置是否为属于访问准许组的用户所拥有的装置，并根据所述检查确定是否准许访问。
27、根据权利要求24所述的访问权限管理***，其中，所述访问请求装置和所述被访问请求的装置具有带有反篡改配置的安全芯片，由此在相互的安全芯片之间执行相互认证，其中，在建立相互认证的条件下，所述被访问请求的装置执行所述访问请求装置所展示的组属性证书的签名验证，以及装置是否属于访问准许组的检查。
28、根据权利要求24所述的访问权限管理***，其中，所述被访问请求的装置从一个装置接收证明该装置是访问准许组成员的组属性证书的发放请求；
以及其中，在装置之间的相互认证已经被建立，并且组属性证书发放请求装置正在遵循由所述被访问请求的装置准许的发放策略的条件下，向对应于装置或者用户的装置发放组属性证书，以证明该装置是访问准许组成员。
29、根据权利要求24所述的访问权限管理***，其中，所述被访问请求的装置从一个装置接收证明该装置是访问准许组成员的组属性证书的发放请求；
以及其中，在装置之间的相互认证已经被建立，并且在对于由组属性证书发放请求装置已经拥有的已经发放的组属性证书建立了验证和检查的条件下，向对应于装置或者用户的装置发放组属性证书，以证明该装置是访问准许组成员。
30、根据权利要求24所述的访问权限管理***，其中，所述组属性证书具有存储关于对应于所述组属性证书的公共密钥证书的链接信息的配置；
并且其中，所述访问请求装置具有一个配置，其中在执行所述组属性证书的验证时候还执行对通过所述链接信息获得的公共密钥证书的验证。
31、一种执行访问限制处理的通信处理装置，包括：
接收单元，用于从访问请求装置接收组属性证书，所述组属性证书具有作为被存储信息的、对应于某些通信装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；
访问权限确定处理单元，用于执行组属性证书验证处理功能，它借助从所述访问请求装置接收的组属性证书的签名验证执行关于是否存在篡改的验证，并根据存储在所述组属性证书中的组标识信息执行所述访问请求装置是否为属于访问准许组的装置的检查，并且根据所述检查确定是否准许访问。
32、根据权利要求31所述的通信处理装置，其中，所述访问权限确定处理单元具有执行检查的配置，根据发放给在所述访问请求装置上的访问执行装置的终端实体的组属性证书，执行关于所述访问请求装置是否为属于访问准许组的终端实体的检查，并且根据所述检查确定是否准许访问。
33、根据权利要求31所述的通信处理装置，其中所述访问权限确定处理单元具有执行检查的配置，根据发放给是构成所述访问请求装置的个体标识装置的用户标识装置的组属性证书，执行所述访问请求装置是否为属于访问准许组的用户所拥有的装置的检查，并且根据所述检查，执行关于是否可准许访问的确定。
34、根据权利要求31所述的通信处理装置，包括用于与所述访问请求装置进行相互认证的加密处理单元；
其中，所述访问权限确定处理单元具有一个配置，用于在已经建立相互认证的条件下，对所述访问请求装置展示的组属性证书执行签名验证，并且检查该装置是否属于访问准许组。
35、根据权利要求31所述的通信处理装置，还包括：一个用于生成组属性证书的属性证书生成单元，所述组属性证书具有作为被存储信息的、对应于某些通信装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名。
36、根据权利要求31所述的通信处理装置，其中，所述组属性证书具有存储关于对应于所述组属性证书的公共密钥证书的链接信息的配置；
所述访问权限确定处理单元具有一个配置，其中在执行所述组属性证书验证的时候，还执行对通过所述链接信息获得的公共密钥证书的验证。
37、一种在具有通信功能的通信装置之间执行访问限制的访问权限管理方法，所述方法包括：
访问请求装置向是访问请求的对象的被访问请求的装置发送组属性证书的步骤，所述组属性证书具有作为被存储信息的、对应于某些通信装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；
被访问请求的装置接收由所述访问请求装置展示的组属性证书的步骤；
检查步骤，借助所述访问请求装置展示的组属性证书的签名验证，执行关于是否存在篡改的验证，并且根据存储在所述组属性证书中的组标识信息执行所述访问请求装置是否是属于访问准许组的装置的检查；
以及根据所述检查步骤的检查结果，执行关于是否可以准许访问的确定的步骤。
38、根据权利要求37所述的访问权限管理方法，其中，所述被访问请求的装置根据发放给在所述访问请求装置上的访问执行装置的终端实体的组属性证书，检查所述访问请求装置是否为属于访问准许组的终端实体，并根据所述检查确定是否准许访问。
39、根据权利要求37所述的访问权限管理方法，其中，所述被访问请求的装置根据发放给在所述访问请求装置上的个体标识装置的用户标识装置的组属性证书，检查所述访问请求装置是否为属于访问准许组的用户所拥有的装置，并根据所述检查确定是否准许访问。
40、根据权利要求37所述的访问权限管理方法，还包括在所述访问请求装置和所述被访问请求的装置的具有反篡改配置的安全芯片之间的相互认证执行步骤；
其中，在建立相互认证的条件下，所述被访问请求的装置执行从所述访问请求装置展示的组属性证书的签名验证，以及检查该装置是否属于访问准许组。
41、根据权利要求37所述的访问权限管理方法，还包括步骤：所述被访问请求的装置从一个装置接收证明该装置是访问准许组成员的组属性证书的发放请求的步骤；以及
一个步骤，其中在已经建立装置间的相互认证，并且组属性证书发放请求装置正在遵循由所述被访问请求的装置准许的发放策略的条件下，向对应于装置或者用户的装置发放组属性证书。
42、根据权利要求37所述的访问权限管理方法，还包括，在已经建立装置间的相互认证，以及在对于由组属性证书发放请求装置已经拥有的已经发放的组属性证书建立了验证和检查的条件下，向对应于装置或者用户的装置发放组属性证书，以证明该装置是访问准许组成员的执行处理的步骤，以作为所述被访问请求的装置响应来自一个装置的发放请求，发放证明该装置是访问准许组成员的组属性证书的执行步骤。
43、根据权利要求37所述的访问权限管理方法，其中，所述组属性证书具有存储关于对应于所述组属性证书的公共密钥证书的链接信息的配置；
所述访问请求装置具有一个配置，其中在执行所述组属性证书验证的时候，还执行对通过所述链接信息获得的公共密钥证书的验证。
44、一种执行访问限制处理的通信处理装置的通信管理方法，所述方法包括：
接收步骤，用于从访问请求装置接收组属性证书，所述组属性证书具有作为被存储信息的、对应于某些通信装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；以及
访问权限确定处理步骤，用于借助从所述访问请求装置接收的组属性证书的签名验证执行关于是否存在篡改的验证，并根据存储在所述组属性证书中的组标识信息执行所述访问请求装置是否为属于访问准许组的装置的检查；以及
访问准许/不准许确定步骤，根据访问权限确定处理结果，确定是否能够准许访问。
45、根据权利要求44所述的通信管理方法，其中，所述访问权限确定处理步骤包括执行检查的步骤，根据发放给在所述访问请求装置上的访问执行装置的终端实体的组属性证书，检查所述访问请求装置是否为属于访问准许组的终端实体。
46、根据权利要求44所述的通信管理方法，其中，所述访问权限确定处理步骤包括执行检查的步骤，根据发放给是构成所述访问请求装置的个体标识装置的用户标识装置的组属性证书，检查所述访问请求装置是否为由属于访问准许组的用户所拥有的装置。
47、根据权利要求44所述的通信管理方法，还包括执行与所述访问请求装置相互认证的认证处理步骤；
其中，在所述访问权限确定处理步骤中，在建立了相互认证条件下，执行对所述访问请求装置展示的组属性证书的签名验证，并且检查所述装置是否属于访问准许组。
48、根据权利要求44所述的通信管理方法，其中，所述组属性证书具有存储关于对应于所述组属性证书的公共密钥证书的链接信息的配置；
其中，在所述访问权限确定处理步骤中，在执行组所述属性证书验证的时候还执行对通过所述链接信息获得的公共密钥证书的验证。
49、一种对于执行访问限制处理的通信处理装置实施通信管理方法的执行的计算机程序，该程序包括：
接收步骤，用于从访问请求装置接收组属性证书，所述组属性证书具有作为被存储信息的、对应于某些通信装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；以及
访问权限确定处理步骤，用于借助从所述访问请求装置接收的组属性证书的签名验证执行关于是否存在篡改的验证，并根据存储在所述组属性证书中的组标识信息执行所述访问请求装置是否为属于访问准许组的装置的检查；以及
访问准许/不准许确定步骤，根据访问权限确定处理结果，确定是否能够准许访问。
50、一种在多个能够相互通信的装置之间执行伴随数据通信处理的数据处理的数据处理***，其中在所述多个装置之中，向与其进行通信的其它装置请求数据处理的数据处理请求装置持有组属性证书，所述组属性证书具有作为被存储信息的、对应于某些通信装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名，并且所述数据处理请求装置在数据处理请求处理的时候，向数据处理被请求装置发送组属性证书；
并且其中所述数据处理被请求装置执行被接收的组属性证书的验证处理，根据所述验证确定所述数据处理请求装置是否具有数据处理请求权限，并且根据权限的确定执行数据处理。
51、根据权利要求50所述的数据处理***，其中，存储在所述数据处理请求装置中的组属性证书把数据处理被请求装置作为其发放者，并且附有数据处理被请求装置的电子签名；
其中，所述数据处理被请求装置具有应用自己的公共密钥执行电子签名验证处理的配置，以作为被接收的组属性证书的验证处理。
52、根据权利要求50所述的数据处理***，其中，所有的所述可相互通信的多个装置是相互请求与其正在通信的其它装置的数据处理的装置，每个这样的装置具有一个配置，用于存储由通信对象装置发放的组属性证书，并且在与其正在通信的其它装置的数据处理请求的时候，发送自己存储的组属性证书，以及在接收装置建立验证的条件下，相互执行对应于数据处理请求的处理。
53、根据权利要求50所述的数据处理***，其中，所有的所述的可互通信的多个装置都具有带反篡改配置的安全芯片，在与其正在通信的其它装置的数据处理请求的时候，在相互的安全芯片之间执行相互认证，其中，在建立相互认证的条件下，执行装置间的组属性证书的所述发送，以及执行被发送的组属性证书的验证。
54、根据权利要求50所述的数据处理***，其中，存储在数据处理请求装置中的组属性证书把数据处理被请求装置作为其发放者；
并且其中，在数据处理请求装置与数据处理被请求装置之间建立相互认证的条件下，执行发放处理。
55、根据权利要求50所述的数据处理***，其中，在所述可相互通信的多个装置之中，至少一个或多个装置包括：作为装置配置的一个终端实体，用于执行与其它装置的通信处理和数据处理；和一个用户标识装置，具有能够与所述终端实体交换数据的个体标识功能；
并且其中，在向构成某个用户组的诸多成员发放所述组属性证书的情况下，在所述用户标识装置与组属性证书发放处理执行装置之间建立相互认证的条件下，执行发放处理。
56、根据权利要求50所述的数据处理***，其中，在所述可相互通信的多个装置之中，一个装置是执行诸多装置的维护处理的维护执行装置；
并且其中，其它装置是接收来自所述维护执行装置的维护业务的业务接收装置；
并且其中，所述业务接收装置存储业务属性证书，该业务属性证书是由所述维护执行装置发放的组属性证书；
并且其中，所述维护执行装置存储控制属性证书，该控制属性证书是由所述业务接收装置发放的组属性证书；
并且其中，所述业务属性证书适用于在所述维护执行装置上执行所述业务接收装置属于具有维护业务接收权限的一组装置或用户的验证；
并且其中，所述控制属性证书适用于在所述业务接收装置上执行所述维护执行装置属于具有维护业务执行权限的一组装置或用户的验证。
57、根据权利要求56所述的数据处理***，其中，在所述业务接收装置上执行的维护程序，作为加密维护程序被发送给业务接收装置或者存储在该装置中；
并且其中，所述业务接收装置具有一个解密配置，对具有反篡改配置的安全芯片内的所述加密维护程序进行解密，然后在所述业务接收装置上运行该程序。
58、根据权利要求56所述的数据处理***，其中，根据从所述维护执行装置发送到所述业务接收装置的命令实施在所述业务接收装置上执行的维护处理；
并且其中，所述业务接收装置向所述维护执行装置发送所述命令的执行结果的答复，并且所述维护执行装置根据所发送的答复向所述业务接收装置发送新命令。
59、一种根据来自数据处理请求装置的数据处理请求执行数据处理的数据处理装置，所述数据处理装置包括：
数据接收单元，用于从所述数据处理请求装置接收组属性证书，所述组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；
权限确定处理单元，用于执行被接收组属性证书的验证处理，并根据所述验证确定所述数据处理请求装置是否具有数据处理请求权限；和
数据处理单元，用于根据权限的确定执行数据处理。
60、根据权利要求59所述的数据处理装置，其中，所述权限确定处理单元具有应用自己的公共密钥执行电子签名验证处理的配置，该电子签名验证处理作为被接收的组属性验证的验证处理。
61、根据权利要求59所述的数据处理***，其中，所述数据处理装置具有一个安全芯片，该安全芯片带有反篡改配置并且包括一个加密处理单元；
并且其中，所述加密处理单元具有一个配置，其中响应来自数据处理请求装置的数据处理请求，与数据处理请求装置一起执行相互认证；
并且其中，所述权限确定处理单元具有一个在建立了相互认证的条件下执行组属性证书的验证的配置。
62、根据权利要求59所述的数据处理***，其中，所述数据处理装置具有包括属性证书生成处理单元的配置，该单元具有生成组属性证书的功能，所述组属性证书具有作为被存储信息的、对应于某些装置或某些用户的集合的组的组标识信息，并且还附有电子签名。
63、一种数据处理方法，用于在多个能够相互通信的装置之间执行伴随数据通信处理的数据处理，其中在多个所述装置之中，向与其进行通信的其它装置请求数据处理的数据处理请求装置执行发送步骤，即在数据处理请求处理的时候向正在与其进行通信的其它装置发送组属性证书，所述组属性证书具有作为被存储信息的、对应于某些通信装置或者某些用户的集合的组的组标识信息，并且还附有发放者的电子签名；
并且其中，所述数据处理被请求装置执行：
用于被接收的组属性证书的验证处理步骤；
根据所述验证，确定所述数据处理请求装置是否具有数据处理请求权限的步骤；和
根据权限的确定执行数据处理的步骤。
64、根据权利要求63所述的数据处理方法，其中，在所述数据处理请求装置中存储的组属性证书把数据处理被请求装置作为证书的发放者，并且还附有数据处理被请求装置的电子签名；
并且其中，在所述数据处理被请求装置上的所述验证处理步骤中，应用自己的公共密钥执行电子签名验证处理，以作为被接收的组属性证书的验证处理。
65、根据权利要求63所述的数据处理方法，其中，所有所述可互通信的多个装置相互请求与其进行通信的其它装置的数据处理，其中每个装置都具有一个存储由通信对方装置发放的组属性证书配置，并且在与其正在进行通信的其它装置的数据处理请求的时候，发送自身存储的组属性证书，以及在接收装置上建立的验证条件下，相互执行对应于数据处理请求的处理。
66、根据权利要求63所述的数据处理方法，其中，所有所述可相互通信的多个装置具有带反篡改配置的安全芯片，在与其进行通信的其它装置的数据处理请求的时候，在相互的安全芯片之间执行相互认证，并且其中，在建立相互认证的条件下，执行装置之间的组属性证书的所述发送以及被发送的组属性证书的验证。
67、根据权利要求63所述的数据处理方法，还包括用于存储在数据处理请求装置中的组属性证书的发放处理步骤；
在数据处理请求装置与数据处理被请求装置之间已经建立相互认证的条件下，执行所述发放处理步骤。
68、根据权利要求63所述的数据处理方法，还包括用于存储在数据处理请求装置中的组属性证书的发放处理步骤；
其中，在向构成某个用户组的成员发放所述组属性证书的情况下，在与由数据处理请求装置构成的具有个体标识功能的用户标识装置一起建立相互认证的条件下，执行所述发放处理步骤。
69、根据权利要求63所述的数据处理方法，其中，在所述可相互通信的多个装置之中，一个装置是执行装置的维护处理的维护执行装置，并且其中，其它装置是从所述维护执行装置接收维护业务的业务接收装置，所述方法包括：
所述业务接收装置向所述维护执行装置发送业务属性证书的步骤，所述业务属性证书是由所述维护执行装置发放的组属性证书；
所述维护执行装置执行被接收的业务属性证书的验证的业务属性证书验证步骤；
所述维护执行装置向所述业务接收装置发送控制属性证书的步骤，所述控制属性证书是所述业务接收装置发放的组属性证书；
所述业务接收装置执行所述控制属性证书的验证的控制属性证书验证步骤；以及
在已经建立所述业务属性证书验证和所述控制属性证书验证的条件下，执行维护处理的维护处理步骤。
70、根据权利要求69所述的数据处理方法，其中，在所述业务接收装置上执行的维护程序被发送到或被存储在所述业务接收装置中，作为被加密的维护程序；
并且其中，所述业务接收装置具有一个配置，用于解密在具有反窜改配置的安全芯片内的已加密维护程序，然后在所述业务接收装置上执行该程序。
71、根据权利要求69所述的数据处理方法，其中，根据从所述维护执行装置发送到所述业务接收装置的命令，执行在所述业务接收装置上执行的维护处理；
其中，所述业务接收装置向所述维护执行装置发送所述命令的执行结果的答复，并且所述维护执行装置根据所发送的答复向所述业务接收装置发送新命令。
72、一种根据来自数据处理请求装置的数据处理请求，执行数据处理的数据处理方法，所述方法包括：
从所述数据处理请求装置接收组属性证书的数据接收步骤，所述组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且附有发放者的电子签名；
权限确定处理步骤，用于执行被接收的组属性证书的验证处理，并根据所述验证，确定所述数据处理请求装置是否具有数据处理请求权限；
数据处理步骤，用于根据权限确定，执行数据处理。
73、根据权利要求72所述的数据处理方法，其中，所述权限确定处理步骤包括一个应用自己的公共密钥执行电子签名验证处理的步骤，所述电子签名验证处理作为被接收的组属性证书的验证处理。
74、根据权利要求72所述的数据处理方法，还包括响应来自数据处理请求装置的数据处理请求，与数据处理请求装置一起执行相互认证的步骤；
并且其中，在已经建立相互认证的条件下，所述权限确定处理步骤执行组属性证书的验证。
75、一种根据来自数据处理请求装置的数据处理请求，实施数据处理执行的计算机程序，所述程序包括：
从所述数据处理请求装置接收组属性证书的数据接收步骤，所述组属性证书具有作为被存储信息的、对应于某些装置或者某些用户的集合的组的组标识信息，并且附有发放者的电子签名；
权限确定处理步骤，用于执行被接收的组属性证书的验证处理，并根据所述验证，确定所述数据处理请求装置是否具有数据处理请求权限；
数据处理步骤，用于根据权限确定，执行数据处理。
CN03818944.5A 2002-06-07 2003-05-27 数据处理***、数据处理装置及其方法和计算机程序 Pending CN1675879A (zh)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
JP167148/2002 2002-06-07
JP2002167358A JP3786055B2 (ja) 2002-06-07 2002-06-07 データ処理システム、データ処理装置、および方法、並びにコンピュータ・プログラム
JP2002167260A JP2004015507A (ja) 2002-06-07 2002-06-07 アクセス権限管理システム、通信処理装置、および方法、並びにコンピュータ・プログラム
JP167358/2002 2002-06-07
JP167260/2002 2002-06-07
JP2002167148A JP2004015495A (ja) 2002-06-07 2002-06-07 権限管理システム、情報処理装置、および方法、並びにコンピュータ・プログラム

Publications (1)

Publication Number Publication Date
CN1675879A true CN1675879A (zh) 2005-09-28

Family

ID=29740542

Family Applications (1)

Application Number Title Priority Date Filing Date
CN03818944.5A Pending CN1675879A (zh) 2002-06-07 2003-05-27 数据处理***、数据处理装置及其方法和计算机程序

Country Status (4)

Country Link
US (1) US20060106836A1 (zh)
EP (1) EP1505765A4 (zh)
CN (1) CN1675879A (zh)
WO (1) WO2003105400A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103268552A (zh) * 2013-04-16 2013-08-28 北京小米科技有限责任公司 一种数据处理方法和***
CN105915338A (zh) * 2016-05-27 2016-08-31 北京中油瑞飞信息技术有限责任公司 生成密钥的方法和***
CN108810002A (zh) * 2018-06-21 2018-11-13 北京智芯微电子科技有限公司 安全芯片的多ca应用***及方法
CN110493234A (zh) * 2019-08-23 2019-11-22 中国工商银行股份有限公司 证书处理方法、证书处理装置和电子设备
US20220021522A1 (en) * 2020-07-20 2022-01-20 Fujitsu Limited Storage medium, relay device, and communication method

Families Citing this family (96)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2002341670A1 (en) * 2001-09-14 2003-04-01 Safe Stop Systems, Inc. Descent control device
GB0211517D0 (en) 2002-05-20 2002-06-26 Tyco Electronics Raychem Nv Optical fibre sealing
JP4624732B2 (ja) * 2003-07-16 2011-02-02 パナソニック株式会社 アクセス方法
CA2550768C (en) * 2003-07-24 2015-09-22 Koninklijke Philips Electronics N.V. Hybrid device and person based authorized domain architecture
US7650409B2 (en) * 2004-04-12 2010-01-19 Nokia Siemens Networks Oy System and method for enabling authorization of a network device using attribute certificates
US8156339B2 (en) * 2004-07-21 2012-04-10 Sanyo Electric Co., Ltd. Method for transmission/reception of contents usage right information in encrypted form, and device thereof
JP2006139747A (ja) * 2004-08-30 2006-06-01 Kddi Corp 通信システムおよび安全性保証装置
KR100677152B1 (ko) * 2004-11-17 2007-02-02 삼성전자주식회사 사용자 바인딩을 이용한 홈 네트워크에서의 콘텐츠 전송방법
KR100667333B1 (ko) * 2004-12-16 2007-01-12 삼성전자주식회사 홈 네트워크에서 디바이스 및 사용자 인증 시스템 및 방법
US8281282B2 (en) * 2005-04-26 2012-10-02 Ca, Inc. Method and apparatus for in-built searching and aggregating functionality
WO2006120946A1 (ja) * 2005-05-10 2006-11-16 Brother Kogyo Kabushiki Kaisha ツリー型ネットワークシステム、ノード装置、放送システム及び放送方法等
JP4690779B2 (ja) * 2005-06-03 2011-06-01 株式会社日立製作所 属性証明書検証方法及び装置
US20070005553A1 (en) * 2005-06-30 2007-01-04 Ravi Sahita System for composite instrumented resource data
US20070039039A1 (en) * 2005-08-10 2007-02-15 Microsoft Corporation Authorization of device access to network services
JP4818664B2 (ja) * 2005-09-05 2011-11-16 富士通株式会社 機器情報送信方法、機器情報送信装置、機器情報送信プログラム
EP2060055B1 (en) * 2006-09-07 2014-06-04 BlackBerry Limited Destroying a Secure Session maintained by a Server on behalf of a Connection Owner
US20080077201A1 (en) 2006-09-26 2008-03-27 Juniper Medical, Inc. Cooling devices with flexible sensors
US8192474B2 (en) 2006-09-26 2012-06-05 Zeltiq Aesthetics, Inc. Tissue treatment methods
US9132031B2 (en) 2006-09-26 2015-09-15 Zeltiq Aesthetics, Inc. Cooling device having a plurality of controllable cooling elements to provide a predetermined cooling profile
US7613915B2 (en) * 2006-11-09 2009-11-03 BroadOn Communications Corp Method for programming on-chip non-volatile memory in a secure processor, and a device so programmed
US8095970B2 (en) * 2007-02-16 2012-01-10 Microsoft Corporation Dynamically associating attribute values with objects
US20080287839A1 (en) 2007-05-18 2008-11-20 Juniper Medical, Inc. Method of enhanced removal of heat from subcutaneous lipid-rich cells and treatment apparatus having an actuator
US10231077B2 (en) 2007-07-03 2019-03-12 Eingot Llc Records access and management
US8600776B2 (en) * 2007-07-03 2013-12-03 Eingot Llc Records access and management
US8523927B2 (en) 2007-07-13 2013-09-03 Zeltiq Aesthetics, Inc. System for treating lipid-rich regions
US20090048853A1 (en) * 2007-08-13 2009-02-19 Jeffrey Hall Permission based field service management system
WO2009026471A1 (en) 2007-08-21 2009-02-26 Zeltiq Aesthetics, Inc. Monitoring the cooling of subcutaneous lipid-rich cells, such as the cooling of adipose tissue
KR100925329B1 (ko) * 2007-12-03 2009-11-04 한국전자통신연구원 디지털케이블 방송망에서 다운로더블 제한수신시스템을위한 상호인증 및 키 공유 방법과 장치
ES2670331T3 (es) 2008-03-11 2018-05-30 Flybits Inc. Procedimiento, aparato y sistema para establecimiento de redes sociales
US8458462B1 (en) * 2008-08-14 2013-06-04 Juniper Networks, Inc. Verifying integrity of network devices for secure multicast communications
EP2199993A1 (en) * 2008-12-17 2010-06-23 Gemalto SA Method and token for managing one processing relating to an application supported or to be supported by a token
US8603073B2 (en) 2008-12-17 2013-12-10 Zeltiq Aesthetics, Inc. Systems and methods with interrupt/resume capabilities for treating subcutaneous lipid-rich cells
JP4879259B2 (ja) * 2008-12-19 2012-02-22 株式会社エヌ・ティ・ティ・ドコモ 端末装置及びアプリケーション一覧表示方法
US20100205074A1 (en) * 2009-02-06 2010-08-12 Inventec Corporation Network leasing system and method thereof
EP2769703B1 (en) 2009-04-30 2022-04-06 Zeltiq Aesthetics, Inc. Device for removing heat from subcutaneous lipid-rich cells
US8381987B2 (en) 2009-07-30 2013-02-26 Mela Sciences, Inc. Insertable storage card containing a portable memory card having a connection interface
US8677459B2 (en) * 2009-08-11 2014-03-18 Broadcom Corporation Secure zero-touch provisioning of remote management controller
US8433116B2 (en) 2009-11-03 2013-04-30 Mela Sciences, Inc. Showing skin lesion information
US8452063B2 (en) 2009-11-03 2013-05-28 Mela Sciences, Inc. Showing skin lesion information
CA2787374A1 (en) 2010-01-25 2011-07-28 Zeltiq Aesthetics, Inc. Home-use applicators for non-invasively removing heat from subcutaneous lipid-rich cells via phase change coolants, and associated devices, systems and methods
US9270663B2 (en) * 2010-04-30 2016-02-23 T-Central, Inc. System and method to enable PKI- and PMI-based distributed locking of content and distributed unlocking of protected content and/or scoring of users and/or scoring of end-entity access means—added
US20230132554A1 (en) * 2010-04-30 2023-05-04 T-Central, Inc. System and method to enable pki- and pmi-based distributed locking of content and distributed unlocking of protected content and/or scoring of users and/or scoring of end-entity access means - added
US9325677B2 (en) * 2010-05-17 2016-04-26 Blackberry Limited Method of registering devices
TWI422206B (zh) * 2010-05-31 2014-01-01 Intercity Business Corp 包容式金鑰認證方法
US8676338B2 (en) 2010-07-20 2014-03-18 Zeltiq Aesthetics, Inc. Combined modality treatment systems, methods and apparatus for body contouring applications
US9191813B2 (en) * 2010-12-30 2015-11-17 Mozido Corfire—Korea, Ltd. System and method for managing OTA provisioning applications through use of profiles and data preparation
US9774669B2 (en) * 2011-01-28 2017-09-26 Throughtek Co., Ltd. Service infrastructure for serving client nodes based on P2P connections
WO2012121024A1 (ja) * 2011-03-04 2012-09-13 日本電気株式会社 乱数値特定装置、乱数値特定システム、および、乱数値特定方法
WO2012155955A1 (en) * 2011-05-16 2012-11-22 Nokia Siemens Networks Oy Linking credentials in a trust mechanism
US10068084B2 (en) * 2011-06-27 2018-09-04 General Electric Company Method and system of location-aware certificate based authentication
US8762990B2 (en) 2011-07-25 2014-06-24 The Boeing Company Virtual machines for aircraft network data processing systems
US9239247B1 (en) 2011-09-27 2016-01-19 The Boeing Company Verification of devices connected to aircraft data processing systems
US8806579B1 (en) 2011-10-12 2014-08-12 The Boeing Company Secure partitioning of devices connected to aircraft network data processing systems
US8589020B1 (en) * 2011-11-29 2013-11-19 The Boeing Company Updating identity information in aircraft network data processing systems
US20130212381A1 (en) * 2012-02-15 2013-08-15 Roche Diagnostics Operations, Inc. System and method for controlling authorized access to a structured testing procedure on a medical device
US9137234B2 (en) * 2012-03-23 2015-09-15 Cloudpath Networks, Inc. System and method for providing a certificate based on granted permissions
US9124434B2 (en) 2013-02-01 2015-09-01 Microsoft Technology Licensing, Llc Securing a computing device accessory
US9844460B2 (en) 2013-03-14 2017-12-19 Zeltiq Aesthetics, Inc. Treatment systems with fluid mixing systems and fluid-cooled applicators and methods of using the same
US9545523B2 (en) 2013-03-14 2017-01-17 Zeltiq Aesthetics, Inc. Multi-modality treatment systems, methods and apparatus for altering subcutaneous lipid-rich tissue
US9819682B2 (en) * 2013-03-15 2017-11-14 Airwatch Llc Certificate based profile confirmation
CN106063182B (zh) * 2013-12-31 2019-11-19 威斯科数据安全国际有限公司 电子签名方法、***及设备
DE102014201234A1 (de) * 2014-01-23 2015-07-23 Siemens Aktiengesellschaft Verfahren, Verwaltungsvorrichtung und Gerät zur Zertifikat-basierten Authentifizierung von Kommunikationspartnern in einem Gerät
EP3099260A2 (en) 2014-01-31 2016-12-07 Zeltiq Aesthetics, Inc. Treatment systems, methods, and apparatuses for improving the appearance of skin and providing for other treatments
DE102014204044A1 (de) * 2014-03-05 2015-09-10 Robert Bosch Gmbh Verfahren zum Widerrufen einer Gruppe von Zertifikaten
US10675176B1 (en) 2014-03-19 2020-06-09 Zeltiq Aesthetics, Inc. Treatment systems, devices, and methods for cooling targeted tissue
USD777338S1 (en) 2014-03-20 2017-01-24 Zeltiq Aesthetics, Inc. Cryotherapy applicator for cooling tissue
US10952891B1 (en) 2014-05-13 2021-03-23 Zeltiq Aesthetics, Inc. Treatment systems with adjustable gap applicators and methods for cooling tissue
JP2015232810A (ja) * 2014-06-10 2015-12-24 株式会社東芝 記憶装置、情報処理装置および情報処理方法
EP3767896A1 (en) 2014-08-12 2021-01-20 Eingot LLC A zero-knowledge environment based social networking engine
US10568759B2 (en) 2014-08-19 2020-02-25 Zeltiq Aesthetics, Inc. Treatment systems, small volume applicators, and methods for treating submental tissue
US10935174B2 (en) 2014-08-19 2021-03-02 Zeltiq Aesthetics, Inc. Stress relief couplings for cryotherapy apparatuses
US10171532B2 (en) * 2014-09-30 2019-01-01 Citrix Systems, Inc. Methods and systems for detection and classification of multimedia content in secured transactions
US10129031B2 (en) 2014-10-31 2018-11-13 Convida Wireless, Llc End-to-end service layer authentication
US9881159B1 (en) * 2014-11-14 2018-01-30 Quest Software Inc. Workload execution systems and methods
EP3272094B1 (en) * 2015-03-16 2021-06-23 Convida Wireless, LLC End-to-end authentication at the service layer using public keying mechanisms
CA2990651A1 (en) 2015-06-30 2017-01-05 Visa International Service Association Confidential authentication and provisioning
EP3364900B1 (en) 2015-10-19 2021-08-18 Zeltiq Aesthetics, Inc. Vascular treatment methods for cooling vascular structures
US10305871B2 (en) 2015-12-09 2019-05-28 Cloudflare, Inc. Dynamically serving digital certificates based on secure session properties
CA3009414A1 (en) 2016-01-07 2017-07-13 Zeltiq Aesthetics, Inc. Temperature-dependent adhesion between applicator and skin during cooling of tissue
US10765552B2 (en) 2016-02-18 2020-09-08 Zeltiq Aesthetics, Inc. Cooling cup applicators with contoured heads and liner assemblies
US11382790B2 (en) 2016-05-10 2022-07-12 Zeltiq Aesthetics, Inc. Skin freezing systems for treating acne and skin conditions
US10682297B2 (en) 2016-05-10 2020-06-16 Zeltiq Aesthetics, Inc. Liposomes, emulsions, and methods for cryotherapy
US10555831B2 (en) 2016-05-10 2020-02-11 Zeltiq Aesthetics, Inc. Hydrogel substances and methods of cryotherapy
US11611429B2 (en) * 2016-06-14 2023-03-21 University Of Florida Research Foundation, Incorporated Comprehensive framework for protecting intellectual property in the semiconductor industry
US11076879B2 (en) 2017-04-26 2021-08-03 Zeltiq Aesthetics, Inc. Shallow surface cryotherapy applicators and related technology
CN108259460B (zh) * 2017-11-24 2021-02-26 新华三信息安全技术有限公司 设备控制方法和装置
US10601960B2 (en) 2018-02-14 2020-03-24 Eingot Llc Zero-knowledge environment based networking engine
CA3107932A1 (en) 2018-07-31 2020-02-06 Zeltiq Aesthetics, Inc. Methods, devices, and systems for improving skin characteristics
JP7218142B2 (ja) * 2018-10-16 2023-02-06 キヤノン株式会社 情報処理装置、情報処理装置の制御方法及びプログラム
US20210344515A1 (en) * 2018-10-19 2021-11-04 Nippon Telegraph And Telephone Corporation Authentication-permission system, information processing apparatus, equipment, authentication-permission method and program
JP2021060915A (ja) * 2019-10-09 2021-04-15 富士通株式会社 本人確認プログラム、制御装置及び本人確認方法
US11526928B2 (en) * 2020-02-03 2022-12-13 Dell Products L.P. System and method for dynamically orchestrating application program interface trust
US11722312B2 (en) * 2020-03-09 2023-08-08 Sony Group Corporation Privacy-preserving signature
TWI744844B (zh) * 2020-03-30 2021-11-01 尚承科技股份有限公司 憑證安全簽發與管理系統及方法
CN114531467B (zh) * 2020-11-04 2023-04-14 中移(苏州)软件技术有限公司 一种信息处理方法、设备和***
CN113079177B (zh) * 2021-04-15 2022-05-31 河南大学 一种基于时间及解密次数限制的遥感数据共享方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3458979B2 (ja) * 1994-12-02 2003-10-20 日本電信電話株式会社 ディジタル情報保護システム及びその方法
US5701343A (en) * 1994-12-01 1997-12-23 Nippon Telegraph & Telephone Corporation Method and system for digital information protection
US6718470B1 (en) * 1998-06-05 2004-04-06 Entrust Technologies Limited System and method for granting security privilege in a communication system
JP2001067319A (ja) * 1999-08-26 2001-03-16 Hitachi Ltd Ｗｗｗサーバを用いた検索システム
GB9922665D0 (en) * 1999-09-25 1999-11-24 Hewlett Packard Co A method of enforcing trusted functionality in a full function platform
JP2002139998A (ja) * 2000-11-01 2002-05-17 Sony Corp 属性確認処理を含むデータ通信システムおよび属性確認処理を含むデータ通信方法

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103268552A (zh) * 2013-04-16 2013-08-28 北京小米科技有限责任公司 一种数据处理方法和***
CN105915338A (zh) * 2016-05-27 2016-08-31 北京中油瑞飞信息技术有限责任公司 生成密钥的方法和***
CN105915338B (zh) * 2016-05-27 2018-12-28 北京中油瑞飞信息技术有限责任公司 生成密钥的方法和***
CN108810002A (zh) * 2018-06-21 2018-11-13 北京智芯微电子科技有限公司 安全芯片的多ca应用***及方法
CN108810002B (zh) * 2018-06-21 2020-02-21 北京智芯微电子科技有限公司 安全芯片的多ca应用***及方法
CN110493234A (zh) * 2019-08-23 2019-11-22 中国工商银行股份有限公司 证书处理方法、证书处理装置和电子设备
US20220021522A1 (en) * 2020-07-20 2022-01-20 Fujitsu Limited Storage medium, relay device, and communication method

Also Published As

Publication number Publication date
EP1505765A1 (en) 2005-02-09
EP1505765A4 (en) 2006-10-04
US20060106836A1 (en) 2006-05-18
WO2003105400A1 (ja) 2003-12-18

Similar Documents

Publication Publication Date Title
CN1675879A (zh) 数据处理***、数据处理装置及其方法和计算机程序
CN1296846C (zh) 信息发送***、发送装置和发送方法与信息接收***、接收装置和接收方法
CN1276612C (zh) 信息发送***、设备、方法和信息接收设备、方法
CN1476580A (zh) 内容使用权管理***和管理方法
CN1818990A (zh) 数据处理设备和数据处理方法
CN1252581C (zh) 保密文件和/或认证文件的远控打印
CN1222893C (zh) 电子水印方法和***
CN100338907C (zh) 信息处理***和方法、信息处理设备和方法
CN100340079C (zh) 数据再生设备
CN100350417C (zh) 内容分发***和内容分发方法
CN1460225A (zh) 数据处理***、存储设备、数据处理装置、及数据处理方法、以及程序
CN1300402A (zh) 信息处理设备、信息处理方法和提供介质
CN1940952A (zh) 用于管理内容数据的***和装置
CN1366751A (zh) 数据处理***、记录装置、数据处理方法和程序提供媒体
CN1366637A (zh) 数据记录再现播放器、保存数据处理方法和程序提供媒体
CN1365474A (zh) 认证装置
CN101047495A (zh) 用于传送数据的方法和***
CN1465160A (zh) 使用访问控制证书的数据访问管理***及管理方法数据访问管理***、存储器安装设备、数据访问管理方法及程序存储媒体
CN1914649A (zh) 认证***, 认证设备,以及记录介质
CN1659844A (zh) 内容复制管理***与网络化装置
CN1682174A (zh) 组形成/管理***,组管理装置,以及成员装置
CN1394408A (zh) 内容传送***和内容传送方法
CN1309487A (zh) 数据处理装置、数据处理***及其数据处理方法
CN1520655A (zh) 信息处理设备和方法以及存储媒体
CN1241144C (zh) 自主型集成电路卡

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication