HK1022968A1 - 个人信息安全与交换的工具 - Google Patents
个人信息安全与交换的工具 Download PDFInfo
- Publication number
- HK1022968A1 HK1022968A1 HK00101835.7A HK00101835A HK1022968A1 HK 1022968 A1 HK1022968 A1 HK 1022968A1 HK 00101835 A HK00101835 A HK 00101835A HK 1022968 A1 HK1022968 A1 HK 1022968A1
- Authority
- HK
- Hong Kong
- Prior art keywords
- electronic
- information
- personal information
- community
- trusted
- Prior art date
Links
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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3821—Electronic credentials
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/383—Anonymous user system
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0241—Advertisements
- G06Q30/0242—Determining effectiveness of advertisements
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0241—Advertisements
- G06Q30/0251—Targeted advertisements
- G06Q30/0253—During e-commerce, i.e. online transactions
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/10—Services
- G06Q50/18—Legal services
- G06Q50/188—Electronic negotiation
-
- 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
-
- 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/102—Entity profiles
-
- 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
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- 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
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Computer Hardware Design (AREA)
- Entrepreneurship & Innovation (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Human Resources & Organizations (AREA)
- Tourism & Hospitality (AREA)
- Game Theory and Decision Science (AREA)
- Data Mining & Analysis (AREA)
- Primary Health Care (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Operations Research (AREA)
- Technology Law (AREA)
- Quality & Reliability (AREA)
- Storage Device Security (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Electrical Discharge Machining, Electrochemical Machining, And Combined Machining (AREA)
- Numerical Control (AREA)
- Portable Nailing Machines And Staplers (AREA)
Description
技术领域
本发明涉及对一个网络计算机环境中的信息的软件管理。尤其是本发明涉及一个工作在因特网上的软件系统,它可以生成一个用户能够以可信任及可控制的方式去创作、保护、搜索、交换和处理个人信息的虚拟专用网络。这种软件系统封装了可信任的社区(community)和他们的成员,其中一种可信任的权利保证那些社区成员的身份与个人信息。用户一旦在一可信任的社区注册,该用户就能够随意制作和保护超媒体内容,支配和控制他们个人信息基于规则的演示和处理。
背景技术
因特网的引入和加速利用已经使个人信息在数量与可用性两方面的飞速发展。但是很遗憾,因为因特网一般不受限制,所以不能够保证所有的信息都是准确和可靠的,并且数据源经常是不可确定的。此外,除非采取特别的防范措施,否则任何通过因特网传送的信息都会受到窃取和滥用。对于数据可靠性和数据保护的这些利害关系可以结合到一种可信任的信息公用的多方面概念。如果数据是准确的并且能够被鉴别或确定,则数据具有可靠性与可信度。可信任的利用是指数据适合于被数据的拥有者批准的人进行访问或者处理,并且保证根据拥有者所建立的规则继续进行支配和控制。当处理个人数据时,可信任的利用或可信任的处理是特别关键。个人信息,如个人的信用度、医疗历史、职业背景、或者生活方式现在都可以通过各种途径出现在因特网上。执法机构、信贷部门、房东、以及其他人可以利用这些信息来帮助他们作出决定。如果所有这些社区利用不正确的数据,或者利用他们不应当有的信息来做出明显地影响私人生活的决定时,这可能是毁坏性的。
因此,人们认识到必须去做一些事情以保护个人的信息,以及随着更多的个人加入因特网,将使人们更紧迫地去搜集、使用以及销售可利用的个人信息,并且该个人将希望参与、支配和控制这种活动。总的来说,不能够用现有因特网上可利用的工具来适当地实现这些思想,而且也没有工具可以有效地结合这些思想。所以,现在需要为个人信息的安全与交换提供一种因特网设施(Internetutility)或工具。
因此,本发明的目的是通过以下方法来帮助在因特网上可信任地利用个人信息:1)为一些个人或者机构提供一种机制以安全地编写和封装个人数据、和用于处理支配个人信息的演示与处理的规则;以及2)准许个人或机构在网络计算环境内对他们的个人信息的随意支配和控制。
发明内容
本发明是一个用于工作在网络服务器上的软件系统,具有在个人用户的个人计算机系统上运行的支持应用程序,包括有线和无线远程-计算设备。本发明针对一种用于允许个人或组织在一个包括因特网的计算机网上保护、支配、控制、和处理个人信息的系统。尤其是,本发明方便于网络化的可信任电子社区的形成和使用,以下将其称为电子都市社区(E-MetroCommunities),其中每个电子都市社区都包括几个符合共同管理需求的成员。更可取的是,正是这个电子都市社区建立了注册规则以及验证成员本身的身份或者方便于使用其他可信任的证明授权。每个成员的信息身份被作为电子个人信息代理封装在电子都市社区中,此后称做E-PIA(电子个人信息代理),其中每个E-PIA表示一个成员的信息和行为,一些信息是由每个成员提供的,以及一些来自电子都市社区外部的可信任的数据源。通过建立和实施注册规则以及执行负责的和审查的成员身份验证,并且如果选择了个人信息证明,该电子都市社区就建立一个这样的社区,在该社区中,其每个成员都归属于其中并参与了可以实现私人的权利和责任以及确定自身信息的电子领域。因此,正是经过一个可信任的电子都市社区的协作和证明,一个成员在其他交易中就变成可信任的和可靠的,但是更重要的是增加了对他们的数据的控制。
一旦一个用户成为电子都市社区的成员,该成员能够向每条个人信息赋予访问规则。这些访问规则设置了在个人信息能够被处理之前所必须满足的规定。此外,电子都市社区可以针对所有交易获得必须满足的最少标准。当收到一个对特殊的信息的请求时,则由一个电子都市社区特定的处理来检查附加到这个条信息的电子都市社区标准与规则,此后将其称为电子都市社区的电子经纪(E-Broker)。电子经纪是检查请求者和条件是否满足规则的要求的实际过程。如果满足规则的要求,该电子经纪允许请求的信息被处理;如果不满足规则的要求,该电子经纪不允许请求的信息被处理。此外,该信息可以用附加的传输特权规则打包传送,也就是定义了由除原始成员之外的任何其他人进行处理所需的要求的规则。利用这些传输特权规则,一个成员能够保持在第三者目的地的支配和控制,以及对他们个人信息的处理。
一个成员还可以创建一个代理,此后称为E-AutoPIA(电子自治个人信息代理),以便与任何电子都市社区中的其他成员交互作用,或者甚至与对任何电子都市社区的外部数据交互作用。这个代理包含一个该成员个人信息的子集,附加地包含一个引导代理的活动的路线。因此,该代理能够以指引的路线与其他成员的个人信息进行交互作用。
附图说明
通过下面参照附图对优选实施例的详细描述本发明,上述的和其他的目的、特点和优点将更明显,附图包括:
图1显示了连接到网络服务器上访问因特网的一些用户。
图2显示了优选实施例的一个用户如何查看因特网上的其他电子社区。
图3显示了一个数字证书的组成部分,例如VeriSign(一个提供数字标识的机构)的数字标识。
图4显示了RSA(美国RSA实验室,以研究加密算法而著名)公共密钥如何工作,以及一个数字签名如何被生成和附加到一个文档去确保作者身份。
图5显示了一个在电子都市社区(E-MetroCommunities)外部操作的E-AutoPIA。
图6显示了一个已经从几个电子都市社区搜集几个信息化的E-PIA的E-AutoPIA。
图7显示了接到因特网和一个无线通信装置的几个网络服务器和用户的个人计算机。
图8显示了几个通过因特网互连的几个电子都市社区系统以及其他资源。
图9显示了电子都市可信任服务器的架构。
图10详细地显示了图9所示的电子都市可信任服务器中的DORMS(分布对象资源管理系统服务器)子系统。
图11a-d详细显示了用于优选实施例中的几种对象的详细存储结构。
图12详细地显示了用在图10的分布对象资源管理系统服务器子系统中的信息子系统。
图13是一个电子都市社区对象的Booch图。
图14是一个电子经纪对象的Booch图。
图15a是一个E-PIA对象的Booch图。
图15b是一个信息化的E-PIA对象的Booch图。
图16是一个E-AutoPIA对象的Booch图。
图17是一个路线对象的Booch图。
图18是一个交互指令对象的Booch图。
图19是一个交互协议对象的Booch图。
图20是一个规则对象的Booch图。
图21是一个参数对象的Booch图。
图22显示了用在优选实施例中的各类对象之间的的关系。
图23显示了在优选实施例中的对象模式描述中采用的基本Booch符号。
图24显示了采用RSA型安全和加密进行电子都市社区的外部通信。
图101是优选实施例中显示初始屏幕的用户界面。
图102是优选实施例中显示登录屏幕的用户界面。
图103是优选实施例中显示社区编目屏幕的用户界面。
图104是优选实施例中显示电子都市社区成员如何建立和执行搜索显示搜索结果的用户界面。
图106是优选实施例中显示一个已经编写的电子都市社区注册的初始页的户界面。
图107是优选实施例中的一个用户界面,它显示了选定电子人(E-Being)实现他们的个人信息的一个可信任表示,其具有一些组成部分和表示安全与锁定状态的属性,原因是请求观察者不符合由电子都市社区和电子都市社区成员设置的必要条件。
图108是优选实施例中展示通过公开的与不公开的访问处理规则表示附加个人信息属性的用户界面。
图109是优选实施例中展示规则编写以及对特殊个人信息属性和一个社区的特殊组或子社区两者的规则安排的用户界面。
图110是优选实施例中的用户界面,示出了决定信息处理器要满足何种标准才能满足对用户信息的访问处理的规则编写。
图201详细描述了电子集市电子经纪子系统。
具体实施方式
本发明的优选实施例主要工作在网络服务器上,并且具有工作在各自的个人计算机系统上的支持应用程序。对于一个用户,优选实施例表现为一个网站,所以可以通过已知网站地址来简单地访问它,但是它是一个具有综合安全保护措施的网站:防火墙、代理服务器、SSL(加密套接协议层)授权网络服务器和客户、数字证书、硬件令牌、安全策略和规程。不仅网站将典型地需要对访问进行基于证书的验证,而且电子都市社区及成员与其他电子都市社区之间的通信也将要加密。对于用户身份的附加确信,可以通过一个任选的硬件令牌或者可靠的卡安全系统来实现。这个安全系统将在后面的部分中进行讨论。
如前所述,信息的可信任处理有两个部分:内容的可靠性与可控制的处理,而且这二者都通过本发明的优选实施例进行阐述。采用一个大城市模拟来讨论优选实施例是最简单和最清楚的。正如在一个大城市里,因特网给一个个体提供一个地方与其他人相见,共享信息,寻求娱乐,做工作,以及购物。同样地,因特网上的每一个个体都有一个可以通信的相应地址。在城市里,当你第一次会见某人时,必须采用谨慎的态度,因为给予这不可信赖的某人太多信息是不明智的。还有,在商品的质量,支持的标准和产品的原产地未知的情况下,与一个陌生人进行商业交易必需要小心。在因特网上,新的相遇与交易出现中可以出现这些情况。
在城市里,人们利用一个不熟悉的个人的社团来降低那些新结交和交易的风险。例如,如果某人穿着一身警察制服,我们一般比较愿意向他们提供我们的驾驶执照编号,家庭住址,以及其他的个人信息。如果某人坐在律师办公室并且出示给我们印有律师头衔的名片,我们一般愿意陈述秘密信息。还有,如果某人生活在我们相同的社区中,可能是我们的邻居,我们将非常愿意共享信息并且认为进行交易是安全的。在因特网上,如果某人有一个以“.gov”结尾的地址,我们认为与他们做买卖安全,因为一些政府机构已经允许他们从一个政府的服务器访问因特网,从而给用户一种值得信赖的氛围。如果这个用户进行一件恶意的交易,则可以联系允许他们访问因特网的代理,并且代理可能惩罚这个用户。然而,大多数的因特网用户都来自没有提供关于他们的可信度的暗示的网络服务器。因此,本发明优选实施例提供一种方法来减少在新交互中的风险,并且增加其他用户说他们是他们所说的人的可能性:本优选实施例创建基于代理规则的可信任电子社区。
在城市中,市民属于几种社区。有一些社区是以地区,种族背景,宗教,母校,雇佣,或者习俗而划分的。一般地,人们从选择他们所属的社区中得到大量的认同和满足。对于有人要申请作为一个公司的雇员,一个宗教的信徒,或者一个业余的专家这都是非常普通的事。属于一个社区不仅对该成员是自我满足,而且还允许以电子都市社区的信用来降低与任何其成员进行交易的风险。
在本实施例中,一个用户可以加入一个或者多个电子都市社区。这些电子都市社区的每一个都独立地由一个设定入会要求、识别成员资格、发布数字证书、以及设置成员可用的服务的管理员操作。这些电子都市社区实际上是在因特网上作为一个网站实现的,但它们是一些特殊的网站,因为它们具有相当的智能和大量的工具。图2显示一个使用优选实施例的因特网的用户视图。该用户将是一个或多个电子都市社区11的成员,并且还知道因特网上有几个其他的电子都市社区11。该用户将使用一种在个人计算机上运行的网络浏览器如网景导航者15访问因特网,并且试图成为一个或多个电子都市社区11的一个成员。当期望成为一个电子都市社区的成员时,可能要从电子都市社区或者一个公共电子人存储库13检索一个未注册的或空的电子人对象,需要利用身份信息对该电子人对象进行初始化并进行鉴定,以便成为一个电子都市社区的一个成员。在访问期望要加入的电子都市社区之前,一个未注册的电子人可能被检索。一旦一个用户被批准加入到一个电子都市社区,该用户就变成这个电子都市社区的一个成员,并且可以使用电子都市社区管理员提供的服务。这些服务可能包括连接到其他的电子都市社区,购物,或者存取信息。除了标准的网景导航者15外,成员还将需要一些在他们本地计算机上的附加支持软件,客户子系统17。这些客户子系统17支持程序是一些允许网景导航者具有支持特定的电子都市社区的特定功能性的过程。这些程序作为优选实施例的一部分将被提供,但是它们可以由电子都市社区管理员或用户配置,以便提供特殊功能性。这些程序可以以任何语言编制,但是Java(一种Internet上广泛使用的OOP语言)是当前最可取的。然而,电子都市社区的目标应该是除了基于标准的浏览器以外不需要附加软件,因为这样保持了非常容易地支持客户软件子系统。此外,成员可能期望获得特权或者访问一些没有权限的特殊电子都市社区服务。电子都市社区可能需要以表格形式填写的进一步的信息,以便被提交用于批准。这些表格存储在一个电子人存储库13中,并且能够被建立为一个独立的网站,FTP站点,或者在因特网上被允许的任何其他存储结构。
可信任的处理包括可靠性和可控制的处理,在优选实施例中,通过两种手段改进私人数据的可信任的处理。首先,被处理的个人信息是由个人编写和监督。这个信息还可以由发放数字证书的第三方校准,数字证书用于证实由个人声称的事实。该存储信息对个人是透明的。此外,用户自己能够请求信任鉴定权以便校准和宣称该个人信息的可靠性。这些鉴定权限颁发数字证书宣称该数据的可靠性。一个例子是信用组织,它将证明个人财务或借贷数据。随着一个电子都市社区可靠性的信用以及个人信息处理的用户中央控制(user-centriccontrol)的增长,信息价值和其用户的相互信任也将增长。
通过本发明的优选实施例在两个方面来改进可信任的处理的其他方面,即数据的保护。首先,优选实施例采用最新的技术,如公共密钥加密方法,以安全地存储和传输信息。公共密钥加密方法将在以后章节更详细地讨论。这些技术确保数据在传输中如果被截获时不会被解密,而仅有预定的读者才能解密和获得该信息。优选实施例的第二个安全特点被设计成对被处理的信息的量进行控制,以及只有符合由用户制定的标准的收件人才可以利用该数据。这个安全特点允许用户设置一些用于管理个人信息的处理与使用的规则。例如,一条规则可以表述为:法律方面的历史信息可以发布给来自美国律师协会电子都市社区的用户。另一个规则可以表述为:可以允许一个单身的、来自一个特定的地区、并且同意使他们的家庭电话号码可以在一个被控制区域内使用的用户利用一个家庭电话号码。通过建立充分的规则,个人能够能够控制只有可信任的用户才能利用其个人信息。此外,用户可以建立传输规则附加到用于控制信息的电子发布处理的信息上。因此,当一个用户认可可信任的个人信息的远程处理时,该信息以这样一种方式被利用,使得用户可以对随后怎样利用信息保持支配和控制。
优选实施例此外还允许个人去为处理金钱或其他有价物质的个人信息建立一些规则。个人的偏爱,身体特征,以及购买习惯对那些销售的产品都是有价值的。传统上,销售公司将搜集和组织这样的信息,并且将这些邮件清单卖给那些具有能吸引该清单上的人的产品的商家。利用优选实施例,个人可以直接把他们自己的个人信息“许可”给商家或销售公司,从而共享由可靠的个人信息的可信任处理产生的价值。
现在参照图101,显示了当访问一个电子都市社区网站时用户可以看到的一个例子。在此,计算机用户在他们的个人计算机上正在运行网 景导航者,并且可以看到标准的网景导航者菜单项501。要做到这一点,用户必须把电子都市社区的网址提供给网景导航者,而网景导航者经过用户的网络服务器连接到该电子都市社区网站所位于的网络服务器。一旦访问成功,电子都市社区网络站点就把引导屏幕511发送给用户,它包含一个地理标志505和特定于这个电子都市社区的标题503。用户可以选择三个任选按钮之一:获得有关这个电子都市社区的更多信息,转到该电子都市社区中(需要安全登记)可用的服务,或者如果是一个新用户,进行注册以被允许进入该电子都市社区。如果用户选择注册,注册对象将由该电子都市社区提供或者从一个电子人存储库检索,并且用户将创建他们的电子人,类似于填写一个标准表格。
如果用户选择了服务选项,用户将被询问安全信息与/或硬件令牌。在图102中,电子都市社区仅仅询问一个基于证明的身份和一个安全码或者口令回答515。一旦用户选择“OK”517,并且用户被允许进入这个电子都市社区,用户就可以利用那些可用的服务。在这个例子中,成员是与图103中所示的社区可用屏幕521一起出现的,该屏幕521是由标志图505和社区连接523组成。在该电子都市社区中那些可用的服务包括搜索和选择,注册更新,广告,购物,顾客支持以及由电子都市社区管理员选定的其他服务。在该电子都市社区中提供的检索服务是可以执行参数查询。图104显示在这个电子都市社区中满足一个特殊搜索请求的成员的部分视图,允许搜索成员通过选择图形连接527来选择特殊的E-PIA。如果请求成员具有由被询问的成员设定的适当资格,被询问的成员的信息能够被该请求者看见。
优选实施例的前提是用户至少具有一个电子都市社区的成员资格,而电子都市社区确定了成员的义务和权利。在优选实施例中,电子都市社区具有三个基本的责任。第一,电子都市社区设定接纳要求,用以产生关于申请加入该社区的申请人就是他们所说的人的高可能性。第二,电子都市社区具有适当的安全措施以便合理地确保一个成员的身份不能被其他人窃取。第三,电子都市社区设定一些标准,用以产生关于准确地、真诚地做生意及公开的高可能性。
在优选实施例中以两步过程来满足用于确保申请人就是他们所说的人的第一责任。在第一步中,一个申请者利用网景导航者15访问他们想要加入的电子都市社区的网站。该用户从电子人存储库13中选择注册对象,填写它并将它提交给电子都市社区管理员。电子都市社区管理员审阅该申请以便保证申请者符合电子都市社区的资格。如果申请者符合资格,申请过程进行到第二步。在第二步中,申请者/用户个人出现在电子都市社区管理员或者其他可信任的权威或者机构如鉴定权威或公正人面前,以验证用户的身份。申请者可以提出一个或多个身份标识,如出生证明,驾驶执照,护照,社会安全卡或者其他可靠的身份手段。一旦申请者被识别并且产生一对密钥,他们就被发给一个数字证书,该数字证书结合了公共密钥和成员及电子都市社区信息。选中一个安全密码或询问应答访问方法,如果需要的话还可以选择硬件令牌。一个成员至少有一个数字证书和访问方法以完全地使用选定的和被批准的电子都市社区服务。电子都市社区现在合理地保证某人就是他所说的人,并且对注册者的申请的处理负责。
电子都市社区的第二个责任是保证仅有原始的申请者能够使用该成员的身份。上述的数字证书和安全密码或询问应答将帮助保证个人身份的安全性,但是新技术考虑到甚至更大的安全性。对于这种先进的安全性,电子都市社区可以发给用户一个硬件令牌或安全卡,如Gemplus,Schlumbarger,和Spyrus公司销售的商用硬件令牌或安全卡。虽然来自Spyrus的LYNKS安全卡有几种关于能够保持信息的选择,三种特别有用的项目是:1)关于用户的基本信息,2)一个数字证书,以及3)由检验电子都市社区数字地签署的电子都市社区数字证书。第一项可以包含几个信息,其中包括:口令、安全密码和能够被优选实施例使用以验证用户的身份的特殊的询问或码短语。为了这个询问安全性,用户利用仅有该用户知道的询问应答对来加载安全卡。当用户想要访问电子都市社区时,安全卡通过提供一个必须精确回答的询问短语询问用户。第二项,数字签名是一种先进的安全机制,这种机制允许发送者附加一个数字签名到文档上,以保证确实是由该发送者创建该文档。关于数字签名更详细的描述将在下文中讨论。那些本技术领域内的专业技术人员可以替换方案,例如生物测定学来保证用户身份目前的安全性。可能包含在卡中的第三项存储了关于证明这个特定成员的权威机构的信息。这个权威机构可能是政府部门、电子都市社区管理员或代理人、或商业机构。如果保证代理商的安全政策与程序具有越多的责任、更大的投入和更周密的计划,则他对成员的信用担保的可信度越高。
电子都市社区的第三个责任是要保证成员正当地进行交易,并且准确和诚实地公开个人信息。对于电子都市社区这是最主要的一个策略,那些违反交互政策的人将从电子都市社区被清除。规章的更严格实施将保证电子都市社区在可信度和准确度上具有更好的声誉。
一旦保证了成员的身份,安全性的下一级就是要保证成员能够与电子都市社区通讯而不被未授权的个人截取和获得消息和信息。这种安全性级别有两个主要部分。第一,优选实施例采用由网景批准的用于商业交易的安全协议,包括在因特网上用信用卡购买。第二,网景导航者网络浏览器已经建立了被称为公共密钥加密法的加密技术,它能够保证从成员到电子都市社区的通讯没有被外部截取和解译的危险。优选实施例采用由美国RSA数据安全有限公司提供的公共密钥加密法,但是本领域内的专业人士还可以有其他的选择。
公共密钥加密法是当前众所周知的一种用于信息的安全传输的方法。图3中所示的是公共密钥加密法的工作框图。在该方法中,每个用户有一个码对,其中一个码是公共的而一个是私有的。这些码通常称为密钥,所以每个用户都有一个公共密钥和一个私有密钥。公共密钥列表25被广泛地分发给任何一个可能需要发送信息的用户。然而,私有密钥是由用户保密的。例如,如果“A”想要安全地发送一个文件到“B”,A将用B的公共密钥19加密该文件。这个密钥是公开的并且任何需要它的人都可以得到。在加密后,文件21只能用B的私有密钥23解密,该密钥只有B知道。因此,如果B正确地保护了私有密钥,则只有B将能够接收和解读该加密的文件。不管该文件是通过一个没有加密的传输方法如电子邮件、因特网、或者电话线发送都没有关系,因为截取该信息的人不能解读它,除非他们通过某种途径盗用了B的私有密钥23。
第二个安全机制是先前介绍过的数字签名,它向接收者保证信息确实是从该信息所声明的发送者发来的。如上简述的,一个成员能够使用数字签名签署文件,从而高度保证该信息正是签名人发送的。图4将帮助说明数字签名的使用。要附加数字签名到一个文件,成员通过一个产生数字模式的数学公式31或者对于该文件唯一的信息摘要33来传输文件27。然后用上述的成员私有密钥23加密该信息摘要33,生成一个数字签名29。该数字签名然后可以结合一个特殊文件到一个私有密钥的特殊所有者。该成员然后附加数字签名29到文件27并且发送两者给接收者。在这个例子中,文件27是未加密发送的,但是如果该文件必须被安全地发送,成员可以使用先前段落描述的方法利用接收者的公共密钥来加密该文件。当收到该文件和签名时,接收者利用发送者的公共密钥19解译该数字签名29,获得对文件27唯一的数字模式33。如前所述,公共密钥可以从公开的公共密钥清单25中得到。如果该数字签名29是用任何其他用户的私有密钥做成,则结果模式将不匹配于文件,且接收者将知道该文件不是指定发送者发送的。使用数字签名技术,优选实施例可以高度保证某个特殊文件是由一个特定成员发送。
采用上述技术,就在很大程度上可靠保证信息和商业交易的安全性和准确性。然而,安全仅仅是一个成功的因特网交互作用的一部分。目前,因特网上的交互作用是一种非个人的并且经常是随机的经验。使用因特网的一个普遍评价是在线交互作用不允许我们有把握地去定位、理解和了解在电子邮件的标识或消息后面的人—去闻其声音、观其容貌,以及去了解一些关于发送者的人格、特性,以及可靠性的信息。没有了这些,交互作用不仅仅令个人不满意,而且是失败和没有用处。
虚拟的社区正在形成,但是人们不敢说能够控制他们的数字角色或交互作用,而且在这些虚拟社区背后的大部分理论基础是数据收集。这种数据收集是由试图跟踪消费者、对社区成员执行连续细微的监督的商业机构执行的。消费者强烈要求对他们个人信息的控制,并且他们要求立法,以防止这种无约束的个人信息的集中,交易和处理。本发明创建一个可信任的虚拟社区,该虚拟社区实现信息的保密和信息的自确定,其中人们可以各自地和共同地要求交换的数值,用于访问和处理控制构成了他们的信息存在的属性的个人信息。
一个数字角色或因特网人格是由适合于个人的个人信息来确定。信息越完整和越可靠,因特网人物就越准确地反映真实生活的人物。这种个人信息不仅对于准确地确定在线的存在的人是有价值的,而且如前所述,对其他人具有商业价值。个人信息可以有许多形式,包括健康,金融和法律记录,学校成绩单,职业历史,或者购买偏爱。这些信息的每一条如果准确,都是一种可以在因特网上进行有效地和令人愉快地交互作用的资源。在优选实施例中,根据单个电子都市社区成员的期望编辑这些信息资源,并且其他人可以得到这些信息资源。所有个人信息,作为一个整体构成一个个人的电子人或者数字角色。为了清楚和容易说明的目的,将这种在一个网站电子都市社区中的这种电子人看成是一个如前所介绍的电子个人信息代理或E-PIA是有用的。
E-PIA的一些信息资源是由其他人创造和保持的,但是可以根据嵌入在E-PIA中的规则被调度和处理,如医学档案和学校成绩单。其他的资源是一些可以由电子都市社区成员编写的资源。优选实施例允许成员自我保证或者合作地保证密封在E-PIA中的信息是准确和可靠的。
在图106中一个用户使用网景导航者访问了一个电子都市社区网站,并且正显示初始注册申请表21。标准的网景界面25位于图的顶部附近。尤其是,用户界面包括菜单条25,控制按钮27,快速访问树结构37,以及通讯激活指示器31。此外,位于图106的底部附近的钥匙图形33告诉我们安全保护在工作,所以所有与电子都市社区站点的通讯都是加密的。
登记者可以定位到左边滚动窗口所示的簿式视窗中的其他的数据项区域(职业、金融、医学)。如果用户选择职业数据区37,用户将看到职业简介并且开始数据项或者更新信息。
图107是一个调度的E-PIA,它显示个人简介的一部分。在图108中是Dieter的E-PIA的延续,图中没有显示家庭地址,并且一个闭合的锁图标伴随数据分布在右边。这表示此人对这条信息的访问请求不符合他的访问处理规则,而Dieter不愿意公开管理访问处理的规则是什么。当Dieter完成这个个人简介时,他就创建规则图109以确定谁得到访问每一项信息。由于访问该个人简介的用户不符合这些规则,所以不能得到家庭地址和其他信息。在优选实施例中,如果对信息的访问被拒绝,可以有机会去看看规则是什么,以及响应图108的右边的、由打开钥匙图标指示的家庭电话。
在这个例子中,根据Dieter对规则交互的期望以及他想要保持和委托给E-PIA的依次控制的级别,Dieter对于规则处理具有几种选择。Dieter只不过希望这个请求用户通过交换来提供他们的家庭电话号码,从而一个简单的规则交换将开始。或者是这个规则的处理将在验证规则满意的请求客户站点被执行,或者是利用一个用于授权封装的家庭电话数据的解密和显示的消息或信号来将消息系统激活,其中该信息被发回给Dieter的请求其家庭电话的家庭E-PIA,而该信号被发回给被调度的E-PIA。
假定预先确定了规则交互,则一个自动的基于规则的响应能够在客户端被执行,并且能够继续用户代理的对话,或者由通信系统支持的延时交互将继续该规则交互。Dieter的家庭E-PIA可能已经具有一个由一条规则建立的响应,这条规则表示如果你显示给我你的,我将显示给你我的,所以这个消息响应是半自动的。
在Dieter已经在请求客户端为处理他的家庭电话数据确定了一条规则的情况下,该交换被执行并且触发一个客户端消息给Dieter的E-PIA。所以,在请求用户的电子都市客户方申请中,Dieter的调度E-PIA接收一个信号以便为可控制的访问解密他的家庭电话号码。在电子都市客户方申请中的规则交互经纪检查看是否家庭电话被正确地提供。
在上述情况中,电子都市社区电子代理调度了一个已经用封装的加密数据加载的E-PIA,这些封装的数据将通过处理客户端的规则来保存消息发送,规则处理,和依次响应。Dieter将决定他如何去信任,因为在把他的数据释放到整个电子都市虚拟专用网络之前他可以依靠系统取回数据作为回报,或者可以依靠系统把数据和规则在这个用于客户端的处理权利的E-PIE内分派。
规则响应对话框显示一些规则,并给出请求人要响应的选择。该规则可以指定一个要发生的金融交易。在这种情况下,用户批准一个来自他们的电子都市钱包的、规则所需的借款数。
在图109中显示了规则细节。该图表描述一个对话屏幕,其中Dieter定位在左边—其PIA数据属性545,清单列出那一种规则将支配这个属性和属性组。访问组是一个通过特殊社区或子社区540对规则进行分组的工具。初始联系是一个组,Dieter已经规定它为一个子社区,在该子社区中他的年龄属性规则没有公开,并且这个属性在锁定550中,即没有显示在初始联系概要中。
他的其他属性:城市,出生日等是公开的,并且一旦处理就将显示出来。用这个屏幕Dieter能够创建一个“需要知道”提示,其中在请求中用户被提示需要知道什么。Dieter还必须自己经过电子都市通信系统处理这个响应。一些消息交互通过预先建立的规则响应例如“如果你显示给我你的规则我将显示给你我的”实现自动化。所以Dieter的家庭E-PIA能够自动地对规则消息作出反应。
一些数据属性将有时间要求,因为E-PIA之允许这么多的时间去传递,以观看和处理该E-PIA的数据。一种情况是Dieter仅允许24小时用于E-PIA的传递,然后他的E-PIA就锁定(加密)自己以避免进一步处理。
如图110所示,子社区初始联系555必须满足上面规则565和560,以便处理Dieter的E-PIA。所以Dieter正在规定其他人在处理Dieter的E-PIA之前所必须满足的标准。
因此社区成员将为处理发送查询给电子都市,而且虽然一个查询可能有几个匹配,但是由于请求者不满足他的规则要求,从而可能不发送关于分派满足该查询要求的E-PIA的决定。在先前的情况下,Dieter的E-PIA被分派是因为请求Dieter的E-PIA的人满足以上规则。
如图2所示,电子人存储库13可以在因特网的任何地方,即它可以在电子都市社区驻留的同一个服务器上,或者该电子都市社区可以使用一个驻留在因特网其他地方的电子人存储库。当一个成员加入一个电子都市社区时,首要任务之一就是根据用户判断编写个人简历。这些简介,加上来自外面资源的任何信息,组成了一个在因特网上代表个人的E-PIA。
在本实施例中一个用户可以属于几个电子都市社区。然而,用户必须选择一个电子都市社区作为主电子都市社区。被选定的电子都市社区收藏一个被指定给该主电子都市社区的E-PIA,该E-PIA保持对成员所属的其他所有电子社区的跟踪。在这种方法中,如果需要的话,主E-PIA中的变化可以用于更新所有其他社区中的信息。一旦成员加入一个电子都市社区并且指定该电子都市社区为他的主社区,该成员就可以通过简单地满足下一个电子都市社区的接纳要求然后复制这个E-PIA到新的电子都市社区来加入到另一个电子都市社区。如在随后一节要讨论的一样,当一个成员期望创建一个特殊的、被称作E-AutoPIA的E-PIA时,该E-AutoPIA仅能从主E-PIA派生出来,E-AutoPIA能够移动到其他的电子都市社区并且执行被请求的任务。然后,该E-PIA具有一个包含在原始主人物中的信息的子集,从而向遇到该E-AutoPIA的任何人保证该E-AutoPIA携带的信息与主E-PIA有关。
一个成员为他们的个人信息的访问处理定义了一些规则以便保证该信息被正确地处理。当一个用户试图访问一个成员的个人信息时,本优选实施例查看该用户是否符合对信息的可信任处理的要求。本实施例仅仅把E-PIA分派给包含有信息的请求用户,该信息是用户被授权并且有资格处理的信息。这些规则定义了信息处理的限制,并且形成在电子都市社区中的E-PIA之间交互的基础。即,当由一个E-PIA代表的成员接触另一个成员的E-PIA时,即使要,这两个E-PIA都能够确定什么样的信息可以交换而不要任何来自所代表的人物的同时输入。这条规则检查的细节在随后的一节讨论。
对于这一点,电子都市社区中的E-PIA已经简单地描述为有能力依据规则选择地发布信息的个人信息存储库,并且只在一个电子都市社区内起作用。然而,在优选实施例中,E-PIA还可以采取更灵活的结构形式,称为E-AutoPIA,E-AutoPIA一般能够与因特网上的其他电子都市社区以及其他电子都市社区的E-PIA进行无监督的活动。E-AutoPIA包含个人信息的一个子集和全部E-PIA的规则,附加一条知道其活动的路线。该路线告诉E-AutoPIA哪个电子都市社区要访问,什么样的信息要搜集,以及结合这些规则,什么样的信息可以处理。然后,利用一条路线,E-AutoPIA将在因特网上“移动”,访问在每个电子都市社区中可以用E-PIA交互的其他电子都市社区。
在优选实施例中,E-AutoPIA不直接与其他E-PIA交互。代替地,每个电子都市社区至少有一个在E-AutoPIA与该电子都市社区的E-PIA之间担当经纪代理的处理过程。这个经纪代理就是以前提出的电子经纪。当两个E-PIA或者一个E-PIA与一个E-AutoPIA期望交互时,双方用他们各自的规则介绍电子经纪,而且即便要,也是电子经纪确定什么样的信息可以交换。此外,电子都市社区管理员可以设置适用于将要发生在该电子都市社区中的所有由电子经纪作为媒介的交易的最少规则,以保证仅有符合最少电子都市社区标准的交易发生。
如暗示,这里有两种E-PIA交互的模式。一个由电子都市社区中的成员E-PIA电子表示的用户,可以经过他的网景浏览器和合适的HTML文档为电子都市社区激活单一的交互。这被称为在线交互方式(OnlineInteractionMode)。当E-AutoPIA在一个电子都市社区内激活交互时,这种被称为成批交互方式(BatchInteractionMode)。
图5在概念上显示了一个包含有几个E-PIA(成员)37的网站电子都市社区35。对于任何交互,成员37必须使用电子经纪39的服务。E-AutoPIA41可以在电子都市社区外部工作,如图6所示,E-AutoPIA41可以具有一条指导他与几个其他网络站点的电子社区35中的电子经纪39交互的路线。
电子经纪在电子都市社区内有三种主要功能。第一,电子经纪已经由电子都市社区管理员确定去检查想要进入电子都市社区的任何E-PIA的凭证。在这个监视角色中,电子经纪检查证明,核准身份,以及查询达到的E-PIA的进入目的。在应用这些由电子都市社区管理员设置的规则后,电子经纪将或者拒绝该E-PIA的访问或者允许该E-PIA进入电子都市社区。第二,电子经纪担当寻找满足由一个E-PIA在其请求交互期间指定的准则的成员。例如,如果一个E-PIA进入一个电子都市社区去寻找有兴趣买汽车的成员,该请求就传给电子经纪。然后,电子经纪采用优选实施例中的几个可用子系统去查询所有成员以找出那些已经表示有兴趣买汽车的人,并且建立一个符合必需的标准的所有成员清单。第三,电子经纪作为E-AutoPIA与电子都市社区E-PIA之间的一个中间媒介。在上述例子中,即使电子经纪已经建立了一个表示有兴趣买新车的成员清单后,电子经纪仍然作为一个中介。E-AutoPIA提出搜集信息规则,各个成员E-PIA提出公开规则,即便需要,也是电子经纪确定什么信息将被交换。当然,即使两者都同意交换信息,电子都市社区管理员也可以设置一个较严格的规则而不允许电子经纪完成这件交易。
电子经纪可以协商的可能任务之一是成员个人信息的可控制处理。假定电子都市社区与用户都希望处理个人信息,电子经纪被通知从一个想要个人信息的访问E-PIA收钱。在优选实施例中,收取的钱可以给电子都市社区,成员或者在他们之间分开。具有牢固的成员资格的电子都市社区将发现这是一种为其他电子都市社区服务提供经费的有吸引力方法。
电子都市社区能够提供几种服务给其成员。这些服务可以包括社区内的功能,如协作组,意见一致的建筑物或选举系统,用于管理由服务产生的社区收入的资金支付系统,用于保护顾客推销(promoting)的责任和顾客意见合理解决的在线顾客满意数据库,或者用于促进‘平等访问’政策目标的先进无线通信装置的社区津贴供给。电子都市社区还可以提供社区外服务,如为了慈善或政治目的访问交叉社区的动员工作,联合电子商务服务,以及对于所有全体成员的通讯基础结构费用的共享,以促进交叉社区的高级的或新引进的无线网络。
优选实施例的一个典型物理结构如图7所示,其中用户43利用个人计算机45访问因特网1以便连接到网络服务器11,而网络服务器11连接到因特网1。有线与无线连接两者都可以用,其中在一个网络服务器11上可以驻留有多于一个电子都市社区,而且电子都市社区甚至可以形成一个分层关系。即,一个电子都市社区不仅可以包含成员,而且还可以包含其他子社区。图7显示在每个服务器上有一个、两个或三个电子都市社区的网络服务器11。此外,对于为特殊电子都市社区编写成员信息的电子人对象可以从电子都市社区电子经纪中申请,或者如果可公开地利用,是在电子人存储库13中。优选实施例允许任何公共的存储子系统用于电子人对象。两种可能的存储子系统是一个FTP站点或邮件服务器,该邮件服务器只是一个用于保持分类的文件类型的文件存储和通信系统,并且可适合从网景或其他卖主脱离这个框架。这些电子人存储库可以在任何服务器11或13上,或者电子人对象甚至可以由用户在其个人计算机45上或者无线通讯器件42上保持。
我们现在回到优选实施例的特殊软件实现。优选实施例是一个模块化应用程序,即该应用程序被分为几个部分,每一个部分或模块被指定为特定的功能。这些模块的一些被设计成工作在一个或多个服务器上,同时其他的模块被设计成工作在用户本地计算机系统上。对优选实施例必要的用户与服务器如图8所示,并且与图7所示的物理器件相关。参照两个图,用户43用他们的个人计算机45运行网景导航者网络浏览器49,一个商业实用的应用程序。网景导航者49允许用户方便地访问任何电子都市社区站点。还有,网景导航者提供为带给优选实施例特殊工具的其他网景产品提供兼容性。除了网景导航者,用户在本地运行几种支持电子都市社区机构的实用程序。这些特殊的应用可以是DDLs(动态连接库),Java应用程序,小程序和过程,或者是一种类似支持特殊电子都市社区机构的特性的一些其他编码。然而,如先前所述,在几乎所有的情况中,附加子系统和DDLs都将不应该是必须的。
优选实施例的核心是网站电子都市社区系统47,它工作在网络服务器上。网站电子都市社区系统47构架的顶部水平视图如图9所示。该系统包括分布对象资源管理系统(分布对象资源管理系统服务器)57,其更详细的显示在图10中,网景企业服务器59,网景应用程序编程接口67,现场支付的支付卡交易处理器61,FPT服务器65,以及FPT客户63。这些系统单元的每一个都将在下面各自讨论,然后再描述他们的交互,但是首先要提出的是安全性的重要考虑。
为了确保只有想要的通信和消息传播发生,严格的安全性是必要的。安全一般能够分为两类:1)用以保证偷听者或偶然的收件人不能提取信息的安全机制,以及2)用以保证信息仅仅发布给可信任的实体的安全措施。第一类安全是采用加密技术在多个实体之间传输数据来完成的。参照图24,图中显示了几个网站电子都市社区系统47和一个利用网景浏览器访问优选实施例的用户。每个网站电子都市社区系统47是作为一个安全处理工作在网络服务器上。可以预料,对于精通安全性处理的任何人都能够为每个网站电子都市社区系统47创建一个本地安全处理。对于社区内部的通讯,每个网站电子都市社区系统47保持其自己的私有密钥和用于加密的公共密钥。
当一个源电子都市社区想要与另一个目的电子都市社区通信时,如当一个E-PIA被传输时,一种双重加密技术被使用。源电子都市社区用目的电子都市社区的公共密钥加密这个消息。然后源电子都市社区再加密目前已加密的信息,但是这次是用他自己的私有密钥。每个电子都市社区都知道所有其他电子社区和他们的公共密钥。当目的电子都市社区接收一个消息时,他首先用源电子都市社区的公共密钥解密该信息然后再用自己的私有密钥解密信息。这种“双重”加密向目的电子都市社区保证该源电子都市社区的确是该消息中提及的源电子都市社区,并且还向源电子都市社区保证将只有这个目的电子都市社区能够解密该消息。类似的安全检测用于从一个电子都市社区47到一个用户的通信。
另一个重要安全方面涉及到保证一个E-PIA或E-AutoPIA的来源。这个起源的保证是通过一个证明150和信任令牌159的使用来显示。证明是由所有E-PIA和E-AutoPIA持有的,并且包含所代表的个人和实体的名字以及与他们相关的公共密钥。因为由E-PIA或E-AutoPIA持有的个人信息已经用所代表的个人或实体的私有密钥加密,因此如果证明中的公共密钥与公开的公共密钥匹配,并且个人信息被正确地解密,则该E-PIA和E-AutoPIA必然是来自规定源的E-PIA或E-AutoPIA。然后,证明用来保证一个人就是他说他所代表的人,并且信息最初被该代表的人加密。信任令牌表示为执行一个交互所必需的特权,它是由电子经纪在E-PIA或E-AutoPIA编写时间给出的。每个必须要保密的交互将需要一个发放的信任令牌。在一个电子经纪处理一个请求交互之前,它将查看请求E-PIA是否有必要保证先前已经被授权去执行交互。每个信任令牌将与一个特殊交互相关,并且必须用请求E-PIA的私有密钥加密。利用请求E-PIA已知的公共密钥,该信任令牌能够被解密并且与期望的值比较,从而保证请求该交互的能力确实已被授权给该请求用户。
第二个安全机制保证这个信息仅发布给可信任的实体。当一个E-PIA把它的一些个人信息给另一个E-PIA时,给出的个人信息仍然由原始E-PIA保护和所有,所以随后的传播是能够控制的。这种机制涉及到信息的初始发布与由其他E-PIA的随后传播。利用网站电子都市社区管理员和个人设置的、在信息可以被发布之前必须满足的规则,来从之信息的初始发布。电子都市社区管理员可以设置一些一般适用于网站电子都市社区中的所有潜在的交换的规则,以允许电子都市社区保持对可接受的交易的控制。而且,个体能够赋予一条规则给他们E-PIA中的每条个人信息。通过设置这些规则,E-PIA将仅在一个可信任环境中与一个可信任人分享信息。一个更难的问题涉及到控制信息的随后传播。事实上,如果信息的接收者依次把该信息传送给第三E-PIA,优选实施例仍然知道个人信息的原始所有者,并且继续监管对信息的访问。这个随后的安全是由原始E-PIA宣布的传输特权规则设置的。传输特权规则创建一个传输信任,以致:如果A相信B具有信息X,且B相信C具有信息X,则A相信C具有信息X。根据为提交的数据而宣布的传输特权规则,这个重要的概念向A保证它的信息从不传送到一个它不信任的实体。信息总是作为提交其信息的一种E-PIA版本被传输。例如,假设一个E-PIA包含一个丰富的信息集合,其包括出生日期,地址,电话号码等等。更进一步,假设它希望在一个交互中仅仅发布其电话号码给另一个。该接收实体实际将接收一个E-PIA对象信息化的E-PIA,其仅包含电话号码。尤其是,接收的E-PIA对象是一种原始的E-PIA,该原始E-PIA表示提交E-PIA如何期望被接收实体理解。图6描述了通过一个移动E-AutoPIA收集的一些E-PIA版本40。这些版本的E-PIA对象是优选实施例中信息交换的唯一方式。
分布对象资源管理系统是网站电子都市社区系统47的工作中心。如图9所示,分布对象资源管理系统服务器57掌握着系统的几个核心行为,包括电子都市社区的存储、电子经纪,以及成员,E-PIA维持因特网上所有电子都市社区的目录,保持自治人,并且掌握E-PIA之间以及E-PIA与E-AutoPIA之间的交互。这些行为的每一个都将在下面讨论。
分布对象资源管理系统服务器57的行为是用一系列相互关联的子系统实现的,如图10所示。交互处理器73是分布对象资源管理系统服务器57的关键子系统,而且负责所有外部通讯和多数内部决策。一旦交互处理器73决定一个特殊的行为过程,该行为就利用一个电子经纪处理来实现。有几个可用的电子经纪来完成特殊的、再发生的任务。交互处理器的工作在后面的一节中详细讨论,但是首先其他分布对象资源管理系统服务器功能与各自子系统将被提出。
分布对象资源管理系统服务器对电子都市社区、电子经纪以及E-PIA的存储负责。尽管这些项的每个都不一样,但是它们所有都存在对象存储库75内的一个共同结构中。对象存储库75在一个关系数据库上使用一个简单的面向对象的接口。这个关系数据库可以是工作在网络服务器上的任何数据库,如通用的Oracle数据库系统。
电子都市社区、电子经纪、以及E-PIA都是优选实施例中的对象,电子都市社区、电子经纪以及电E-PIA的每一个实例都被分配一个唯一的对象标识符,或者OID91(原始标识符)。然后这些特征用图11a所示的形式与OID91一起存储。这个图表显示一个关系数据库内的表的每一行的结构。参考该图表,OID91位于第一字段。下一个字段是收集原始标识符93(CollectionOID93),它识别这个对象是否被包括在其他任何对象中,以便于建立对象之间的关系。例如,使用一个共同的收集原始标识符93,几个电子经纪、E-PIA或者甚至别的电子社区都可以与单一的电子都市社区相关。因此,收集原始标识符93是优选实施例用于跟踪电子社区之间分层关系的方法,也是优选实施例用于跟踪一个特殊电子都市社区内电子经纪与E-PIA分派的方法。紧随收集原始标识符93后面的是几个包含被选择的对象信息的关键字字段95。这些字段是一些可以用于通过数据库程序的查询和选择标准的“关键字”。在优选实施例中,六个关键字字段95被允许用于数据库的表的每行。当然,更多或更少的关键字也可以使用,或者替代的一些查询技术对于技术上熟知的人是很清楚的。关键字的特定身份留给电子都市社区管理员安排,因此为了高效的查询允许电子都市社区需要指定最有效的一些字段。该行的最后一项是对象自身,它是以BLOb(二进制大容量对象程序)的格式存储。BLOb格式是一种标准数据库存储结构,它允许数据库中的一个单个字段保持多条离散的信息并且不受每条信息内容的影响。因此,分布对象资源管理系统服务器能够在对象存储库75中搜索关键字字段95以快速选择合适的对象,而后从BLOb格式提取与查看对象本身,这是一个较慢的操作。
如上所述,电子都市社区、电子经纪以及E-PIA都使用这个共同的行结构。然而,每个使用稍有差别的命名约定。电子都市社区使用的约定如图11b所示。注意如果需要,收集原始标识符93通过主原始标识符99(ParentOID99)定位父电子都市社区。这样,优选实施例为电子都市社区保持分层结构。唯一不同的是第一个关键字字段95被安排为保持电子都市社区的名字。因为数据库引擎经常使用电子都市社区的名字去搜索,因此对于所有电子都市社区对象来说,该名字作为一个专用关键字是合适的。
电子经纪的行结构如图11c所示。如同电子都市社区,第一个关键字字段95是名字,在这种情况下它是一个特殊电子经纪的名字。然而,收集原始标识符93字段包含拥有该电子经纪的电子都市社区的OID,从而利用把一个特殊的电子经纪与一个使用社区OID101的特定电子都市社区联系起来。这种关联方法允许一种高效的方法去了解在一个电子都市社区中哪些电子经纪被允许操作。此外,这种相同的关联方法用E-PIA的行结构来执行,其如图11d所示。在该E-PIA中,收集原始标识符字段包含都市社区OID101,从而把一特特殊的E-PIA与一个特定的电子都市社区联系起来。如在图11d所看到的一样,所有六个关键字在E-PIA行结构中都是不确定的,允许电子都市社区管理员灵活地定义每个字段以符合特殊的电子都市社区需要。
再参照图10,分布对象资源管理系统服务器57还维持一个因特网上的所有电子社区的当前目录。这个目录是由一个电子都市社区内被称作目录经纪77(DirectoryBroker77)的特殊电子经纪来保留,每个电子都市社区都具有一个目录经纪77。该目录经纪77跟踪因特网上所有电子社区以及它们的地址。此外,目录经纪77保持有关在因特网上所有其他电子社区的所有其他电子经纪的信息。保持的信息包括电子经纪的名字、规则以及电子都市社区管理员希望保持的关于因特网上其他电子经纪的其他信息。为了保持目录信息最新,电子都市社区的目录经纪77将周期地查询看它的电子都市社区是否已经添加,删除,或者改变任何电子经纪或电子社区,如果是,该目录的经纪77将发出一个E-AutoPIA。这个E-AutoPIA将被发送到所有其他电子社区用来与他们的目录经纪交互,并利用变化来更新每个电子都市社区。更新的频数是变化的,但是最可能是,每天一次更新的安排表将足够支持准确的电子都市社区交互。
分布对象资源管理系统服务器57还包含允许电子都市社区发送一个E-AutoPIA给另一个电子都市社区的信息系统71。如大家从图表中看到的那样,分布对象资源管理系统服务器57通过FTP客户63以及FTP服务器65与其他远程电子都市社区通信。虽然FTP处理被显示为直接与通信子系统71连接,但是实际的通信是由交互处理器控制的。图12显示一个更详细的通信子系统图。如前面讨论的,通信子系统71利用FTP协议来便利地把消息发送给基于网站的电子都市社区或从基于网站的电子都市社区接收消息。这个通信子系统专门用于把E-AutoPIA从一个电子都市社区传送到另一个电子社区。当一个E-AutoPIA被发送到另一个远程电子都市社区时,交互处理器73首先利用目录电子经纪77检索该远程电子都市社区的地址。然后交互处理器73用这个远程地址打包E-AutoPIA并且把这个包转发给发送者调度器105。发送者调度器105把消息放在消息队列109里,并且通知FTP客户65一个要发送的消息(用电子都市社区地址打包的自治人)已经准备好。在方便时,FTP客户65把该消息(用电子都市社区地址打包的自治人)发送给接收者电子都市社区的FTP服务器,并且随后将输出消息从信息队列109中擦除。接收调度器107监视消息队列109,并且当看到一个新的消息时,接收调度器107拆包该消息,展现一个E-AutoPIA。接收调度器107然后通知交互处理器73一个新的E-AutoPIA已经到达,而交互处理器73决定下面要对E-AutoPIA做什么。对于进入到在消息队列109中的消息,直到该消息中的E-AutoPIA经在电子都市社区内完成了任务并且已经离开了该电子都市社区,该消息才从消息队列109中被删除。保存输入的信息保证了即使是在分布对象资源管理系统服务器错误地关机和丢失了在网络服务器上当前活动的的E-AutoPIA的情况下,E-AutoPIA被指定的任务也将被完成。当网络服务器重新启动时,E-AutoPIA能够从原始消息中重新启动并且完成它的任务。该消息队列109本身是一个标准的可以包括一个输入消息文件和一个输出消息文件的FTP文件系统。对本领域内的专业人士将很清楚其他的传输方法可以替代上述的FTP处理。
虚拟解释程序81是一个提供能够执行优选实施例的文本语言和规则语言的能力的软件子系统。虚拟解释程序81在规则处理器79和路线处理器中的使用中起重要作用,这两个处理器在下面一节讨论。
分布对象资源管理系统服务器57包含一个规则处理器79,它是确保信息被安全地分发的一个重要的子系统。一个成员或者电子都市社区管理员利用这些规则去设定个人信息发布的限制和控制。这些规则实际上是一系列字符串,以优选实施例选中的编程语言编写,它们定义了信息被释放时所必须满足的要求。能够根据需要使这些规则简单或者复杂。电子都市社区管理员可以提供适用于所有交易处理的最少规则,并且允许成员为他们的特殊需要调整这些规则。尽管优选实施例利用一个申请来设定规则,但是那些技术上熟练的人将很清楚,对于用户或管理员可以有几种代替的方法来输入规则。
如前所述,对于一个成员的个人信息的请求可能分别经过在线交互方式或者成批交互方式来自两个来源的任何一个:另一个E-PIA成员或者一个E-AutoPIA。如果一个E-AutoPIA进入一个电子都市社区,并且请求一个成员的信息,交互处理器73将启动一个电子经纪去处理该请求。将在已经说明所有的子系统之后,在后面的部分更详细地说明处理该请求的过程,但是一般来说,电子经纪接收这些定义E-AutoPIA的请求标准的规则,并且通过虚拟解释程序81把这些规则发送给规则处理器79。规则处理器79把该请求转换成一个标准的数据库查询请求,如一个标准SQL(结构化查询语言)SELECT(选择)命令,并且运行该查询从对象存储库75中选择E-PIA。然后电子经纪访问每一个选中的E-PIA的规则,再通过虚拟解释程序81把这些规则发送给规则处理器79,规则处理器79比较由成员E-PIA设置的要求和E-AutoPIA的特性,如果该要求被满足,则电子经纪把该被请求的信息从该E-PIA发送到E-AutoPIA。
如果同一电子都市社区的一个成员请求另一个成员的信息,处理是类似的,只是更简单些。在这种情况下,交互处理器73再一次启动电子经纪处理,电子经纪通过虚拟解释程序发送各个E-PIA的规则并且最后发送给规则处理器79。规则处理器79为各个成员比较规则,而且如果需要就决定什么信息可以被传播。
如先前预览的那样,一个E-AutoPIA是从用户的E-PIA中例示出来的,并且包括一条路线。路线是一组指导E-AutoPIA活动的指令。因此,E-AutoPIA为用户充当一个代理。象规则一样,路线可以是一个用Java、或为优选实施例选中的其他方便的语言编写的程序。如这些规则一样,那些技术上熟练的人将很清楚有几种替代的方法去创建一条路线以指导E-AutoPIA。
虚拟映像85是通过把选择的信息放在本地RAM(随机存储器)中以快速访问,来改进优选实施例的性能。因为系统能够以比它从一个位于硬盘驱动器上的数据库,如对象存储库73中检索信息快得多的速度访问RAM中的信息,因此系统可以更高效地运行。一旦优选实施例需要一个电子都市社区、电子经纪或者E-PIA,一个电子经纪就从对象存储库75中选择所需的实体并且把该实体的一个拷贝放在虚拟映像85中。此后,系统使用映像85中的拷贝而不用对象存储库75中的原件。
如从以前的讨论中理解的那样,电子经纪是一些在网络服务器上执行的处理,并用于一个电子都市社区内帮助这个电子都市社区有秩序和高效地运作。每个电子都市社区至少有一个电子经纪,但是也可以有多个。在优选实施例中存在两个特殊的电子经纪,但是可以有多个。第一个是强制的目录电子经纪77,以前讨论过该电子经纪77。第二个必须存在于要求安全修改访问E-PIA的电子社区中,并且被称为主电子经纪87。主电子经纪87负责保证只有E-PIA的拥有者能够编写访问他的主E-PIA。主电子经纪可以被设置为需要非常严格的安全访问,例如使成员使用一个安全卡,口令,以及质问系统,或者可以用弱安全性建立主电子经纪,例如仅仅使成员提供正确的成员身份名字。
每个电子经纪都是运行在网站中的、定制的可执行程序。每个电子经纪可执行程序76实现由它驻留的电子都市社区提供的一组特定E-PIA交互选择。当一个E-PIA请求一个特定交互时,交互处理器73激活电子都市社区的电子经纪,并且告诉它尝试该请求的交互。为了利用统一的通信协议使交互处理器73与每个电子经纪可执行程序通信,使用电子经纪适配器74。因此,交互处理器73实际上是与专门为该电子经纪可执行程序建立的电子经纪适配器74通信,再依次与电子经纪可执行程序76通信。因此,电子经纪适配器74在交互处理器73与一个电子经纪可执行程序之间的通信充当一个“桥梁”。这种适配器机制是必须的,因为从C,C++,Java,VisualBasic,PowerBuilder,或其他开发环境构造的电子经纪对于调用与信息传输可能需要不同的手段。
作为帮助所有电子经纪可执行程序可能需要执行的所有必需的活动的构造一种手段,电子经纪服务APIDLL(应用程序编程接口动态连接库)是作为分布对象资源管理系统服务器子系统的一部分被提供的。电子经纪必须能够调用一个DDL中的API以使用这些有用的服务。一些已经被确定的服务是:1)在满足这些规则的当前电子都市社区中输入一组规则和输出E-PIA的列表;2)与交易服务器交互来执行信用卡处理;3)填一个信用卡帐单;4)验证一个在线进入的安全卡。那些技术上熟练的人应该明白,当需要时其他API也可以加入。
再参照图9,迄今为止,网站电子都市社区系统的DORMS57、FTP客户63以及FTP服务器65部分已经讨论过,随后现场支付服务器61、网景企业服务器59以及网景API67也要详细介绍。
现场支付服务器61是一个来自网景的商业上可用的应用程序,它对支付卡交易处理、事件记录以及结算进行处理。现场支付服务器61将被定制用于处理支付卡交易。任何时间一个通过电子经纪的交易都涉及钱或价值的传递,电子经纪发送信息给交互处理器73,然后交互处理器73把该数据转发给定制的现场支付服务器61。此外,当定制的现场支付服务器61需要发送信息给一个电子经纪时,关于信用卡批准使用通知,定制的现场支付服务器61就把该数据发送给交互处理器73,并且该定制的现场支付服务器61把信息转发给适当的电子经纪。单个电子经纪与E-PIA可以定义他们自己的付帐政策,允许一个成员或者电子都市社区管理员为信息的发放去收取费用。例如,电子都市社区管理员可以为每个发布的名字和电话号码设置1美元的费用,但是个人也可以附加一个收费0.25美元的要求。如果一个E-AutoPIA想要使用该用户的名字和电话号码,费用就涨到1.25美元。因为定制的现场支付服务器61知道所有电子都市社区内的金融交易,它可以非常容易地建立准确的帐单和金融汇总。
网景企业服务器59也是网站电子都市社区系统47的一部分。这个服务器是一个由网景公司提供的标准的商用应用程序,当网景企业服务器59运行在一个网络服务器上时,它允许该网络服务器是一个网站、在因特网上通信以及高效地与网景导航者交互。网景导航者,如前所述,工作在用户的个人计算机上,并且对于网景企业服务器59是一个客户。
标准的网景企业服务器59,在提供基本的工具以允许网络服务器是网站以及访问因特网的同时,必须被加强以提供为支持优选实施例的电子社区所需的服务和工具。网景企业服务器59可以用网景API67(应用编程界面)修改。网景API67是一组可以从任何程序访问以执行修改企业服务器59的功能的命令。例如,在优选实施例中,网景API67被用于修改为相应请求所需的标准安全措施和方法。
现在所有的系统与子系统都已经描述过了,一个特殊的例子将用来演示系统交互。对于这个例子,假设一个远程用户已经建立了一个E-AutoPIA,该E-AutoPIA将要进入例子电子都市社区以检索该电子都市社区的选定成员的信息。对于下列处理步骤序列,参考图7,8,9,10,与12。为了方便,这些步骤被被组织为预备步骤和请求处理步骤,预备步骤只被执行一次以初始化电子都市社区,而请求处理步骤在一个E-AutoPIA每次请求电子都市社区信息时被重复执行。
预备步骤:
1.电子都市社区管理员加载优选实施例在一个网络服务器11上。这个管理员使用电子都市社区管理工具安装这个电子都市社区。管理员还创建几个电子经纪用于处理例如来自E-AutoPIA的请求或进行金融交易。可以通过修改一个现有的电子经纪构成这些电子经纪,或者是通过在任何适于该电子经纪适配器机制的编程环境中写一个新的电子经纪处理来构成这些电子经纪。管理员还定义成员可以得到什么服务(交互),并创建屏幕以显示信息给成员。后者是利用标准的网景企业服务器59或者任何能够创建网页的其他工具来完成的。管理员或创建或修改现有的接纳表格,并且把该表格放在一个表格对象存储库13中。该表格存储库13可以在与电子都市社区相同的网络服务器11,或者被放在任何得用的远程网络服务器11上。最后,电子都市社区管理员引入在线电子都市社区,并且宣布一个新的电子都市社区的出现。现在该电子都市社区已准备好接纳成员。
2.因特网用户或者其他电子社区的成员开始知道这个新电子都市社区,并且访问该电子都市社区网站地址以获得更多信息。他们利用他们的个人计算机45上的网景导航者49浏览器加入一个电子都市社区。他们可以访问接纳表格并且提交请求信息。在这一点上,管理员可以针对完整性和最少的电子都市社区要求来手工地检查这些接纳表格,或者多半,管理员将让一个电子经纪自动针对最少要求来检查这些表格,并且如果表格被接受就安排一个与用户的私人约会。取决于由电子都市社区管理员设置的其他要求,用户可能被通知来到电子都市社区管理员的办公室或者一些其他的可信任权威机构并且提供足够的身份证明和记录,以便向管理员证明他就是他所说的人。如果电子都市社区要求规定了应该保留安全措施,则该用户被发给一个口令、安全卡或其他安全机制。如果一切妥当,则用户将成为该电子都市社区的成员。如果成员选择了该电子都市社区作为他的/她的主电子都市社区,他们必须输入一个完整的个人和职业简介,包括由其他人保持的编写记录,如医学和法律记录。当该电子都市社区不是成员的主电子都市社区时,仅有一个信息的子集需要提交并且它将直接地从新成员所属的主电子都市社区得到。几个其他的用户还可以成为这个电子都市社区的成员。
3.在这一点上,有一个与活动成员现行相关的主电子都市社区。成员可以利用主电子都市社区的服务,与其他成员通信,或者创建一个能够出去并且浏览其他电子社区的E-AutoPIA。该成员还可以为发放个人和职业信息定义一些规则,包括为这种信息发放收费的能力,或者甚至要求其他方发放相似的信息。因为成员通过用一种与电子都市社区兼容的语言编写程序来建立规则,所以具有适应性。表格可在表格存储库13中得到,以帮助规则的建立,而且电子都市社区管理员甚至能够提供一组只需要修改的缺省规则。还有,电子都市社区管理员可能创建一组最少的规则,这组最少的规则将适用于所有交易,以便保证一个E-AutoPIA满足一定的最少标准并且所有在电子都市社区的交易都以一种合适的方式被完成。这些适用于每一个人的最少规则可以被称为电子都市社区规则。
请求处理步骤:
4.假设在这一点上,一个E-AutoPIA从另一个电子都市社区到达FTP服务器65。该服务器把消息放在消息队列109中,随后接收机调度器107识别出一个消息被收到。接收机调度器107通知交互处理器73一个E-AutoPIA消息正在消息队列109中等待并且去检索该包含E-AutoPIA的消息,但是不从消息队列109中删除原始拷贝。交互处理器将从接收机调度起中检索该消息,并且从该消息中拆包E-AutoPIA。然后交互处理器73启动一个电子经纪处理去处理由该E-AutoPIA请求的交互。因为E-AutoPIA是加密的,所以该E-AutoPIA必须用源分布对象资源管理系统服务器的公共密钥和本地分布对象资源管理系统服务器的私有密钥解密。如果该E-AutoPIA是发往该电子都市社区的,它将被正确地解密。每个E-AutoPIA还包含一个证书,以保证确实是该E-AutoPIA的所属者初始化了该E-AutoPIA的发送,这在以前章节讨论过。
当该E-AutoPIA出现在这个电子都市社区的时候,电子经纪为了易于存取把它放在虚拟映像85中。然后电子经纪从该E-AutoPIA中收集规则,并且利用虚拟解释程序81和规则处理器79来检查这些规则,并且将这些规则与电子都市社区规则对照,看该E-AutoPIA是否应该被允许与成员交互。如果不,电子经纪将把该E-AutoPIA发送给发送调度器105,而发送调度器105将把该E-AutoPIA发回给它的主电子都市社区。然而,如果该E-AutoPIA满足电子都市社区的规则,该E-AutoPIA将被允许与成员E-PIA交互。此外,该E-AutoPIA可以保持打算被电子通信或共享的数据。如果是这样,每个E-PIA的传输特权规则以一种类似的方式被检查,保证了只有在取自原始的E-PIA的传输特权规则被满足的情况下E-PIA才能被共享。
5.如果该交易已经进行到这一点,E-AutoPIA具有它来自它所说的地方的高度可能性,并且该E-AutoPIA满足进一步约定的一般规则。现在,优选实施例开始分析每个被请求的交互。E-AutoPIA发送他的第一请求和一个可信任令牌给电子经纪,在此电子经纪验证该E-AutoPIA持有用于特定请求的交互的可信任令牌。如果可信任令牌通过了检验,则该请求被保留并且被移到步骤6;如果没有通过,则该请求被删除。
6.电子经纪接收请求,并且再次利用规则处理器79为E-AutoPIA处理这些规则,但是这次要创建一个查询进入对象存储库75,以找出符合由该E-AutoPIA设置的标准的E-PIA。一旦规则处理器79开展该搜索,即SQL查询,电子经纪处理就在对象存储库75上运行查询并且把选定的E-PIA放在虚拟映像85内。
7.电子经纪现在从各个E-PIA收集规则,通过虚拟解释程序81发送这些规则,并把这些规则发送给规则处理器79。然后规则处理器79比较E-PIA的规则和特性、E-AutoPIA的规则和特性以及电子都市社区的规则,并向电子经纪报告,即便要,在E-AutoPIA与E-PIA之间什么信息可以被交换。一旦被同意,电子经纪随后就从各个E-PIA收集必需的信息,包括任何传输特权规则以及填表信息,并创建一个信息化的人。各个E-PIA都包含由从原始的人获得的证书、选定的个人信息以及传输特权规则。然后该信息化的人被传递给收集人。如果任何填表信息被收集,或者需要信用卡授权,则电子经纪与现场支付服务器61进行交互作用以满足这些需要。对于每个选定的E-PIA重复以上过程,或者是,如果E-AutoPIA具有一条只允许设定数量的交互作用的规则,则重复以上过程,知道该设定的数量达到为止。
8.在收集完信息之后,E-AutoPIA在该电子都市社区的任务就完成了,因此电子经纪把选定的E-PIA从虚拟映象85中删除。电子经纪查看E-AutoPIA的路线,并且利用路线解释程序83和虚拟解释程序81来确定该E-AutoPIA接下来应该被发往的电子都市社区。交互处理器与目录电子经纪77联系,以找出与下一个电子都市社区相关的地址,目录电子经纪77从位于对象存储库75中的电子都市社区目录中检索地址,并且将该检索出的地址答复给交互处理器。交互处理器然后把该E-AutoPIA和该地址打包为一条消息。交互处理器将该消息传递给发送调度器105,发送调度器105把该消息放在消息队列109中,并通知FTP客户65有一条消息等待发送。FTP客户65从消息队列109中检索出并发送该消息。因为E-AutoPIA已经从电子都市社区被发送出,所以发送调度器105现在从消息队列109中删除原始的输入消息。随着E-AutoPIA被成功地处理,交互处理器的当前对话结束了。
现在优选实施例中的所有过程和对象的交互作用都已明白了,重要的是描述一种被称为“电子集市”的电子都市社区的实现的特定的重要例子。这个例子的焦点是电子经纪的实现,因为正是电子经纪包含所有的机构并维持一个电子电子都市的行为。这种电子集市电子经纪保持独特的特性,这些特性是独创的,它们被包括在本发明的权利要求中。
电子经纪的例子:电子集市
电子集市是一种电子都市社区,它提供三种有用的商业方案或情况研究。当作为一个例子电子经纪时,电子集市电子经纪也是非常复杂的。这三种情况的研究是普通的允许保密的交易,半实时拍卖,以及大量销售。在所有着三种情况中,重要的对象是充当销售者E-PIA、充当买主的E-PIA以及电子经纪。注意,在这个环境下一个E-PIA还可以是一个E-AutoPIA。电子经纪直接代表该电子集市处理各种公共服务和交互作用,还在E-PIA的之间起交互的中介作用。电子经纪的一个重要目的是要验证在商业上交互的当事方彼此互相满足用于交互的特权规则。在该文档的环境下,术语“交易”将用于指代一个或者“买”或者“卖”的一般概念。此外,术语“广告客户”将用于指代那些发布想要做交易的期望的人。术语“买者”将用于指代那些浏览广告的人和那些可能最终发出一个定单要买的人。
允许保密的交易情况为买者和卖者提供一种手段做以下事情:
登出广告想要做交易
积极地为一个交易下定单
为一个交易履行定单。
当交易的交互发生时,根据由双方设定的所有特权规则来保证安全地在买者与卖者之间安全地、秘密地进行交易的交互。实际的交易活动是允许保密的。
对于半实时拍卖情况,除了卖者或买者已经决定登出电子拍卖广告之外,允许保密的交易情况一样。在这种情况下,货物或者服务一般都伴随当前报价一起做广告,所以其他潜在的投标人知道怎么去压价。然而,这些拍卖可以利用秘密投标进行。
对于大量的销售的情况,除了卖者或买者已经决定除非有一定量的货物或者服务否则将不做交易之外,也与允许保密的交易情况一样。因此,一个发出的定单可能不是被立即地履行。
将显示出,在本发明中电子集市能够用相同的框架(后面讨论的主题)来实现这三种情况研究的每一种。将显示出各案例之间的主要区别特点是购买或销售订单被履行的方式。
电子集市活动模型
当电子集市用于E-PIA在线交互方式中时,通过展示电子集市的活动生命周期来描述电子集市的概要是最佳的。以下列出在生命周期中的在线方式活动。参考图201。
1.有兴趣买或卖产品的因特网客户303(如E-PIA)通过提交有关产品的所有信息与电子集市电子经纪301交互作用,从而该电子集市能够把该信息公开给其他买者和卖者。
2.因特网客户303(如E-PIA)浏览电子集市上的产品和服务提供。
3.一旦请求,就可以获得特定的E-PIA广告客户的产品的产品信息317。
4.因特网客户303(如E-PIA)从做产品广告的该E-PIA获得一个感兴趣产品的定单315。
5.因特网客户303(如E-PIA)填写定单315并且递交填好的定购单给做产品广告的E-PIA。
6.该填好的定单由广告客户E-PIA指定的、被称为定单处理器319的一个程序来处理。该程序可能或可能不立即完成该订单。客户E-PIA或者立即被告知订单被履行了,或者被告知订单正在处理中。可以说这种订单在稍晚的时候被异步履行。
7.对于异步的定购履行,客户E-PIA或者被告知定购已被履行,或者稍后询问定购状态,或者接收一个有关定购状态的电子邮件。
对于E-AutoPIA成批交互方式,这些活动是相同的,除了交互活动的顺序将根据E-AutoPIA的路线被执行。对于E-AutoPIA广告客户,E-AutoPIA将提交产品信息给电子集市电子经纪作为他的路线的一部分,并且该E-AutoPIA通常继续移向另一个电子都市社区。然而,对于E-AutoPIA购买者,电子集市中的交互顺序一般差别很大。因为E-AutoPIA趋向于自动交互,很有可能该E-AutoPIA已经有了其需要的定单的的一个拷贝。该E-AutoPIA只需要递交填好的定单。因此,E-AutoPIA将避免了浏览和请求订单,而只是下订单。对于异步履行定购,E-AutoPIA能够在稍后检查其路线中的状态,或者代表E-AutoPIA的人可以等待因特网的电子邮件。
电子集市电子经纪管理工具
电子集市管理工具主要提供以下“起源”特点:
1.电子集市管理工具被用于在一个包含优选实施例的网络服务器中配置代表电子集市的空电子都市社区。
2.电子集市管理工具被用于配置空的电子集市。
电子集市管理工具协助一个管理员使电子集市准备好交易。主要的任务是确定哪种属性对于所有将在该电子集市中交易的货物和服务是最重要的。这种属性被称为电子集市的公开属性。例如,一些属性如商标(广告客户E-PIA的名字)和价格总是令人感兴趣的。电子集市管理工具将建议一直包括这些属性。其他的属性仅可能只令特殊种类的电子集市感兴趣。例如,一个专门做瓶装葡萄酒交易的电子集市将通常把年限包括进来作为一个公开的属性。然而,如果该电子集市做多种不同的产品的交易,则年限就不是对所有的产品都合适,因此在同一电子集市中一种葡萄酒产品就必须使用一种仅赋予葡萄酒产品的私有属性。注意所有的属性都可以与管理种类限制和其他的一般限制如价格范围的任何规则表达式相关。
在交易开始以前,电子集市还可以协助配置产品清单。这些产品是根据种类和类型组织的。种类表示具有相似性的一组产品。例如。在“牛奶”种类中人们可以发现产品的类型,如四分之一加仑牛奶、半加仑牛奶、几加仑牛奶以及冰激凌或者甚至奶酪。在这个例子中,牛奶、冰激凌以及奶酪都是该产品种类中的产品类型。最后,每个产品都有其自己的产品ID(标识符),它是由电子集市管理工具指定的编号。交互协议存在于电子集市电子经纪上,从而可以在运行时间增加产品。
电子集市电子经纪子系统构架
如前所述,电子经纪301的可执行程序可以是能够在优选实施例中执行的任何子系统。在电子集市电子经纪情况下,可执行程序是非常复杂的,它由数据库、文件以及根据与之交互的E-PIA而动态变化的子系统组成。在实际实施中,该子系统可以是一个激活几个DDL的EXE文件、一个Java应用程序,或者是维持以下提出的推荐子系统架构的其他任何替代物。
图201主要描述可执行的电子集市的子系统架构。它还显示了一个简化的因特网客户/可执行的电子集市交互的视图。因特网客户实际上通过HTTP(超文本传输协议)与分布对象资源管理系统服务器通信,依次激活一系列规则处理和交互以及安全验证。在如此处理之后,电子经纪可执行程序最终被激活。
如图201所示,可执行的电子集市的架构是这样的,有一个电子集市社区信息加密文件309,一个商用活动调度器305,一个可信任令牌处理器307,一个“公共产品数据库”311,以及对于每个广告客户的其他“可运行程序”(被包含在广告客户目录313中),其中每个广告客户都有其自己的定购处理器319,产品信息317,和维持产品交易的定单315。最后,每个广告客户将需要维持其自己的“私人活动数据库”321。
电子集市社区信息文件309包含要管理电子集市的各方面的信息。在实际发展中,可以发现该文件是存储附加信息的方便场所。
商用活动调度器305是电子集市的主要子系统。它处理所有进入的交互请求,涉及处理和控制信息从和到所有子系统、文件以及数据库(如果需要)的流程尤其是,它利用合适的电子集市电子经纪301处理许多被请求的交互,并且它还负责激活必需的电子经纪服务API(应用程序编程接口)72以确定特定的E-PIA交互。
可信任令牌处理器307记住E-PIA访问者的公共密钥,发放可信任令牌,并且验证由企图要做买卖的那些E-PIA呈现的信任令牌。
公共产品数据库311主要由一个表组成,在该表中一条记录代表一件已经被提交要被公开的产品。该表的列对应于由电子集市管理工具为电子集市中的所有产品配置的公开属性。同时,在包含每个产品的私有属性的目录表的表中有一个BLOb列。产品的表格的意义是被浏览和查询。
三个特殊的可运行程序被存储在一个被称为广告客户目录的根文件目录中。该广告客户目录313为每个广告客户设置一个子目录。当需要三个特殊的可运行程序之一时,广告客户为人所知,以便商业活动调度器305知道哪个子目录要得到所需的运行程序。电子经纪301一样有其自己的子目录。
私人活动数据库321为广告客户提供手段以存储待处理的定购(如果需要的话),存储详细目录,或存储它需要维持以便执行电子集市中的交易的其他任何信息。无论广告客户怎样期望,维持这种私人活动数据库应该是可能的。这正好表示定购处理器319将需要访问电子集市正在上面运行的网络服务器的外部的信息。这种外部信息应该能够驻留在一个外部数据库服务器或甚至一个大型机中。无论那种情况,对于外部数据库而言,如果需要的话局部驻留或远程驻留都应该是可能的。
电子集市应该具有多种简单的定购处理器以及产品信息317和订单315模板,以便一个广告客户可以快捷、容易地成为电子集市中的广告参与者。用这些简单的定购处理器,一个简单的数据库还可以被配置成驻留在网络服务器中,或者甚至驻留在与公共产品数据库相同的数据库内的表格中(只要数据库为每个表提供安全性)。
电子集市电子经纪交互协议
当E-PIA因特网客户经过HTTP与DORMS服务器通信时,这些请求被转换成交互请求而被提交给电子都市社区电子经纪。在该节中,将详细说明可以被请求的可得的交互。电子集市的这种完整列表和说明用于提供对所有可以在完全功能化的电子集市电子都市社区中发生的可能的、重要的活动的完整理解。
从迄今的讨论中明显看到,电子集市电子经纪是一个运行的电子集市电子都市社区的核心。在下面的表中列出了电子集市电子经纪提供的交互协议名字。这些交互协议在运行时是可以得到的。“卖者”列表示当卖者E-PIA初始化交互时与该卖者E-PIA交互的一方,而“买者”表示与买者E-PIA交互的一方。
交互协议概述卖者买者
| getSummary() | 获得概述电子集市编码的代码的可运行主体 | w/电子经纪 | w/电子经纪 |
| 获得概述广告客户提供的产品的代码的可运行主体 | w/买者 | w/卖者 | |
| getPublicProductAttributeTemplate() | 获得与他们规则有关的公开属性名字的目录表 | w/电子经纪 | w/电子经纪 |
| putProductToTradeInfo() | 放置一个新的产品在电子集市中公开地做广告 | w/电子经纪 | w/电子经纪 |
| getProductToTradeInfo() | 获得电子集市中的一个现有产品的所有信息 | w/电子经纪 | w/电子经纪 |
| getProducts() | 查询E-PIA广告客户的电子集市的清单,以获得匹配查询条件的产品 | w/买者 | w/卖者 |
| getPrivateProductAttributes() | 给出一个产品ID,获得与他们的价值相关的私有属性名字的目录表 | w/买者 | w/卖者 |
| getProductTradeForm() | 给出一个产品ID,获得一个代表能够被填写的定单的可运行代码的主体 | w/买者 | w/卖者 |
| putProductTradeOrder() | 给出一个填好的要被提交给广告E-PIA的订单,获得一个定购接受的指示或者一个“要被履行”的定购的定购号 | w/买者 | w/卖者 |
| cancelProductTradeOrder() | 给出一个“要被履行”的定购的定购号,取消定购以致它将不能被履行 | w/买者 | w/卖者 |
| getProductTradeOrde | 给出一个定购号,获得关于该定购的 | w/买者 | w/卖者 |
| rStatus() | 当前状态信息 | ||
| getOrderHistory() | 获得所有被提交给满足给定查询的E-PIA的定购的定购记录清单。 | w/电子经纪 | w/电子经纪 |
下面表格描述必须由每个交互协议实现的精确子系统活动。这将有助于读者理解用于各种交互请求的子系统之间的关系。
交互协议设计
| getSummary() | 从电子经纪子目录获得“产品信息”可运行程序,以便把电子集市的概述呈现给因特网客户。 |
| 该getSummary()请求是与规定一个单一E-PIA广告客户的规则一起被提交的。当该广告客户被确定时,其子目录被搜索以获得“产品信息”可运行程序,以便把电子集市的该书呈现给因特网客户。 | |
| GetPublicProductAttributeTemplate() | 电子集市电子都市社区信息文档被读取以便获得公开属性信息。 |
| PutProductToTradeInfo() | 在公开产品数据库表格中的一个新的记录被插入或者更新。与该记录有关的可运行程序被存储在相应的广告客户目录。如果该产品是新的并且有一个新的广告客户,一个新的子目录必须被创建。在这种情况下,广告客户的名字和其子目录名字联合必须被存储在电子集市电子都市社区信息文件中。 |
| getProductToTradeInfo() | 指定产品的记录被读取—其公开属性与私有属性BLOb被读取,以及其可运行程序从它的广告客户子目录中被检索。该公开属性与可运行程序一起被汇编到单一目录表中。根据需要,该目录表可以呈现给因特网客户和被执行的可运行程序。 |
| getProducts() | 一个提交的查询在公开产品数据库表上被执行。对于每个满足查询的产品,返回上述的相同的两个目录表。 |
| getPrivateProductAttributes() | 对于指定的产品,返回到BLOb化的私有属性目录表。 |
| getProductTradeForm() | 返回到定购单可运行程序以致于它能够被呈现给因特网客户。 |
| putProductTradeOrder() | 提交一个订单目录表以及它们相关的“填写”值给定购处理器,以便该定购能够被广告客户的个人定购处理子系统以该广告客户选择的任何方法处理。返回一个关于立即定购状态的布尔值和字符串。该布尔值只 |
| 是定购是否立即被履行。该布尔值与字符串内容可以呈现给因特网客户。 | |
| cancelProductTradeOrder() | 商业活动调度器必须确定哪个广告客户E-PIA要对与请求一起提交的规则提交取消。当广告客户被确定时,该定购号被提交给广告客户的私人定购处理器。返回一个关于取消状态的字符串,该返回的字符串能够被呈现给因特网客户。 |
| getProductTradeOrderStatus() | 商业活动调度器必须确定哪个广告客户E-PIA要对与请求一起提交的规则提交状态请求。当广告客户被确定时,该定购号被提交给广告客户的私人定购处理器。返回一个关于取消状态的字符串,该返回的字符串能够被呈现给因特网客户。 |
| getOrderHistory() | 商业活动调度器知道请求者就是所属的广告客户。查询被提交给广告客户的私人定购处理器以至于包含满足查询的定购的定购记录可以返回。然后这些就呈现给因特网客户。 |
现在将说明交互协议接口。在详细说明这些接口之前,介绍一下由交互协议使用的基础对象框架是很重要的。以下将介绍这些对象。在说明基本对象后,详细讨论交互协议,以根据基础对象框架中所述的类型来指示哪些参数是输入的,哪些参数是输出的,以及他们的类型。这将为读者提供关于以下方面的最大量细节:数据进出电子集市的流程,数据怎样被使用以便与电子集市中的广告客户和买者交互,以及什么时候特定的对象或数据被呈现给因特网客户。
可运行程序-一种与代码的可执行体相关的名字目录表,该代码的可执行体本身可以是可运行程序的实例。该目录表包括为运行一个特殊的子系统所需的所有可执行“程序片”。一些有用的子集是ExeApp(可执行应用程序)、Dll(动态连接库)、JavaAppelet(Java小应用程序)以及Html(超文本标识语言)。商业活动调度器知道怎样把包含在一个可运行程序中的可执行体下载到因特网客户,所以该调度器能够适当地执行这些可执行体。一种最简单的情况是一个具有单一Html文档的可运行程序。
产品信息-一种可运行程序,其目的是把产品信息呈现给一个购买者。
查询-表示一个SQL(结构化查询语言)SELECT(选择)语句的字符串。
公开属性-一个与表示产品公开属性的价格的相关的名字目录。一个例子显示如下。
名字规则例子
| 活动 | This.isKindOf(String)&&(this==“buy”||this==“sell” | “卖” |
| 广告客户 | this.isKindOf(String) | “Dad’s” |
| 产品分类名 | this.isKindOf(String) | “苏打” |
| 产品类型名 | this.isKindOf(String) | |
| 产品例子名 | this.isKindOf(String) | |
| 产品ID | this.isKindOf(String) | “D-RB10014” |
| 每单位的价格 | this.isKindOf(Money)&&this>0 | .79 |
| 单位尺寸 | this.isKindOf(Integer)&&this>0 | 48 |
| 产品信息 | this.isKindOf(Runnable) | Html文件 |
| 定购单 | this.isKindOf(Runnable) | Html文件 |
| 定购处理器 | this.isKindOf(Runnable) | Java应用程序 |
私有属性-一个与表示产品私人属性的价格的相关的名字目录。
定单-一种可运行程序,为个人提供需要用值去填写字段的定单。
填写的定购单-一个与被填写的字段的值相关的定单字段名的目录表。
定购处理器-一种处理定单的可运行程序。典型地这个可运行程序必须在一个私人数据库上执行处理。
产品ID-一个唯一识别一种产品的字符串。
定购号-一个唯一识别已经发出的定单的字符串。
定购记录-一个具有下面所示的格式的结构。注意,允许基于每个广告客户E-PIA来编写定购记录的结构可能是所希望的。
名字类型
| 产品ID | 字符串 |
| 单位数量 | 整数 |
| 什么时候 | 时间 |
| 价格 | 钱 |
| 履行 | 布尔值 |
| 解释 | 字符串 |
以下的交互协议接口描述说明了如何使用交互协议,以及什么数据是期望被输入和输出的。
getSummary(输出可运行程序aSummary)-依据选择的规则,获得一个aSummary,该aSummary能够被执行以给出一个电子集市的概要或者广告客户的概要。
getPublicProductAttributeTemplate(输出目录表aListOfPublicAttributeRules)-获得aListOfPublicAttributeRules,它是一个与它们的规则相关的属性名目录表。
putProductToTradeInfo(输入字符串aProductID,输入目录表aListOfPublicAttributes,输入目录表aListOfPrivateAttributes)-加入一个新的产品到公开产品数据库中,或修改一个现有的产品。如果企图加入一个新的产品,则aProductID必须为0,否则就表示一个现有的产品ID。aListOfPublicAttributes和aListOfPrivateAttributes包括要新加入或者修改的产品的所有属性。
getProductToTradeInfo(输入字符串aProductId,输出目录表aListOfPublicAttributes,输出目录表aListOfPrivateAttributes,输出字符串aGeneralStatus)-获得公开产品数据库中一个现有产品的所有信息,aProductId是一个表示现有产品的产品ID的字符串。aGeneralStatus是一个具有某些人类可读的状态信息的字符串。
getProducts(输入字符串aQuery,输出定购收集aListOfProductIdS,输出定购收集aListOfListOfPublicAttributes,输出定购收集aListOfListOfPrivateAttributes)-获得有关多余一个现有产品的所有信息。这些要被获取信息的产品是满足查询aQuery的产品。在输出参数中返回三个定购集合:aListOfProductIdS、aListOfListOfPublicAttributes和aListOfListOfPrivateAttributes。
getPrivateAttributes(输入字符串aProductId,输出目录表aListOfPrivateAttributes)-获得具有产品IDaProductId的产品的所有私有属性值。在目录表aListOfPrivateAttributes中返回这些私有属性。
getProductTradeForm(输入字符串aProductId,输出可运行程序anOrderForm)-获得一个代表具有产品IDaProductId的产品的定单的可运行程序anOrderForm。
PutProductTradeOrder(输入目录表aFilledOrderForm,输出字符串anOrderNumber,输出布尔值fulfilled,输出字符串aStatus)—发出一个具有目录表aFilledOrderForm的定购。返回一个代表被发出的定购的唯一定购号的字符串anOrderNumber。返回指示定购是被立即履行(TURE)还是以后再履行(FALSE)的布尔值fulfilled。还返回一个指示其他任何有关履行信息的一般状态字符串aStatus。
CancelProductTradeOrder(输入字符串anOrderNumber,输出字符串aStatus)—取消当前还没有被履行的定单anOrderNumber,以致该定单永远不被履行。返回指示其他任何取消信息的aStatus。
getProductTradeOrderStatus(输入字符串anOrderNumber,输出布尔值fulfilled,输出字符串aStatus)—提交定单anOrderNumber以获得该定单的当前状态信息。如果fulfilled为真(TRUE),则该定单已经被履行,否则该定单还没有被履行。aStatus是一个包含更深一层的状态信息的字符串。
getOrderHistory(输入查询aQuery,输出定购集合aListOfOrderRecords)—从满足aQuery中的SELECT查询的E-PIA中获得产品定单的所有定购记录。在定购集合aListOfOrderRecords中返回定购纪律。使用查询的有用例子是利用表达式“fulfilled==TRUE”来获得对应于实际被执行的交易的那些定购记录。
采用电子集市框架的商业方案
如上所述,任何E-PIA能够通过提供它自己的定购处理器、产品信息(ProductInfo)以及定单这些可运行程序的执行,来作为一个广告客户参与到电子集市中。这种框架允许一个做广告的E-PIA维持一个很普通的能力,以执行其所需的贸易。此外,该框架为高效的贸易方案提供手段,在没有一个电子贸易系统的情况下是不可能实现该高效的贸易方案的,而且在没有特别考虑如本发明提供的保密性、安全性以及特权的情况下,也是不可能实现该高效的贸易方案的。此外,E-PIA与E-AutoPIA还可以利用这个统一的框架作为买者参与,并且获得相同的效率、保密性、安全性以及特权等好处。这个环境下的效率适用于与贸易伙伴有关的努力,就像做生意用的成本一样。
如在电子集市讨论的开始所述,三种情况研究之间的主要区别是他们的定购处理器的执行。这个唯一的区别是有目的的,以便一个单个的电子集市框架能够成功地实现所有三种情况。电子集市能够处理的三种情况现在讨论如下。
“允许保密交易”情况允许任何期望交易安全和秘密进行。用于定购与履行定购的这种模式期望具有一般性。因此,由于框架所期望的一般性,使得框架本身能够完成这种情况,所以已经没有什么要详细描述了。因此,由于这种一般性,半实时拍卖与大量销售情况是“允许保密交易”情况的一些部分。注意因特网电子邮件是用于通知买者定单被异步履行的一个有用工具。
“半实时拍卖”情况需要产品信息及定购处理器可运行程序中的处理和功能性。产品信息可运行程序不仅应该如同正常的一样做产品信息广告,而且还应该显示当前报价和其他任何被认为必须要呈现给买主的拍卖实时参数。
定购的处理是有趣的,因为大多数最终将被取消。然而,如果定购处理器被编码以允许定单履行,则特别的定单履行是可能的。例如,它能够允许拍卖者去检查该订购历史。拍卖者能够决定在任何时候延长拍卖的时间,缩短拍卖时间,履行非最高投标(订购),履行多个投标(订购),或者取消所有的投标(一些订购)。该拍卖的行为是由定购处理器控制的。
因特网电子邮件在半实时拍卖中是非常有用的。建立这样一个半实时拍卖系统应该是可能的,该系统允许在线E-PIA客户周期地从电子集市实现周期的更新。
“大批量销售”情况通常需要在定购处理器可运行程序中一定的处理。对一种产品的所有订购将典型地保持一个“待处理的”未履行状态。在某些情况下,累积的某一产品定单数将超过为激活定单履行而设置的预定阈值。然而,对于大批量销售情况,在定购处理器为等待一定数量的定单到来而花费太长时间的情况下,该定购处理器必须允许过早履行定单。所有或者一些订购的过早取消也应该是有可能的。
还可以期望允许实时的价格调整。在这种情况下,一个广告客户可能发现维持拍卖和大量销售情况的混合是合乎需要的。对于这种广告客户,即他能够做少量产品的交易因为有足够的定单并且仍然有足够的利润,他应该能够上前并激活定单履行,而不是等待并且可能被留给大量的不想要的昂贵库存。
一些广告客户可能希望在产品信息可运行程序中显示实时信息,如当前的订购量与总的期望量。
电子邮件能够用来通知订购状态的突然变化,象其他交易情况一样。
特殊的对象
因为优选实施例被设计成要用一种面向对象的编程语言来实现,所以我们现在回到各个对象的设计。
在继续优选实施例中每个对象之前,以下列出将要出现的、构成优选实施例对象的基础对象类。在面向基础对象的框架中,这些对象类的决大多数都是很普通的,并且那些精通面向对象技术的专业人员应该很熟悉它们。看图22。
| 类型 | 描述 |
| 对象 | 象以下所列出的所有类的超类的抽象类。 |
| 类 | 一个类,其实例代表系统中定义的各个类。 |
| 整数 | 数 |
| 字符串 | 字符 |
| 浮点 | 数 |
| 布尔运算 | 表达式 |
| 集合 | 一个抽象类,它是代表对象集合的所有类的抽象类。 |
| 订购集合 | 一个集合子类,它代表一个以设定的顺序定购的对象列表。 |
| 集 | 一个集合子类,它代表无特殊定购的对象的一个列表。 |
| 目录表 | 一个键控对象的列表。 |
| 文件夹 | 能够利用分层排列的关键字存储对象。 |
| SQL语句 | 提供信息的快速查找。 |
| 可执行字符串 | 一段能够作为一个对象被传输的编码,当需要时能够被解释和执行。 |
| 编译器 | 一个类,其实例每个都代表代码的一个可执行体,该执行体可以把字符串翻译成能被运行时解释程序解释的定购集合代码。 |
| 扩展类 | 为了单个电子都市社区的需要,例如视频、声音等,将需要定义其他的类。 |
E-PIA对象135,显示在图15A中。该E-PIA通过存储信息化的资产并在由该E-PIA的所有者建立的规则下发放这些信息化资产,来封装个人数据和数据处理规则或真实个体或实体的行为。图15B显示一个被创建用于传递信息化资产的E-PIA。该信息化资产文件夹将包含批准的信息化资产的子集,而这些规则将包含原始E-PIA的传输规则(来自交互协议),因此对信息化资产在文件夹中的随后传播规定一个限制。证书能帮助向信息的随后用户保证该信息化资产来源于原始的E-PIA。
| E-PIA对象中的项 | 编号 | 类型 | 描述 |
| 核查跟踪 | 135 | 订购集合 | 记录事件154的一个定购集合,记录事件154记载一个E-PIA的历史 |
| 资产 | 155 | 文件夹 | 所有已知的关于该E-PIA的信息化资源都存储在一个未组织的文件夹中。可以利用从表格存储库中检索的表格把信息输入到文件夹。 |
| 交互协议 | 143 | 集 | 一个E-PIA可以包含存储在一个集中的几个交互协议。 |
| 信任令牌 | 157 | 集 | E-PIA将收集信任令牌交给电子经纪以保证任何交易的完整性。 |
| 特权规则 | 集 | E-PIA具有一组任何要被执行的交互协议所必须满足的规则 | |
| 证书 | 150 | 证书 | 证书包含E-PIA代表的实体的名字和公共密钥 |
交互协议对象141在图19中描述。交互协议为要发生的交互定义名字、输入参数、输出参数以及在订购中必须满足的条件。电子经纪实际上执行这个交互。交互指令引起交互协议启用。交互指令在下一节详细描述。
| 交互协议对象中的项 | 编号 | 类型 | 描述 |
| 141 | 交互协议 | 继承 | |
| 名字 | 191 | 字符串 | 每个协议必须有一个名字。 |
| 特权规则 | 185 | 集 | 已经在以前的表格中描述过。 |
| 最大指令数 | 193 | 整数 | 参看上述交互指令中的描述。 |
| 传输特权规则 | 185 | 集 | 参看上面交互指令中的描述。 |
| 缺省映像 | 197 | 目录表 | 因为交互指令在执行前必须被“填写”,所以缺省映像能够提供缺省值以帮助完成交互指令。 |
| 输入 | 197 | 集 | |
| 输出 | 198 | 集 | 如果后续的交互指令被成功地执行,什么信息化资产将被存储在信息E-PIA中。 |
规则对象201显示在图20中。
| 规则对象中的项 | 编号 | 类型 | 描述 |
| 一个规则对象实际只是一个可执行字符串对象 | 201 | 可执行字符串 | 一个可执行字符串表示一个用户定义的规则。 |
| 编译程序 | 187 | 字符串 | 编译程序的名字总是“规则”。 |
参数对象151显示在图21中。
| 参数对象中的项 | 编号 | 类型 | 描述 |
| 名字 | 211 | 字符串 | 参数的名字。 |
| 验证规则 | 187 | 规则 | 一个可执行字符串,其编译程序是“规则”。 |
E-AutoPIA151对象显示在图16中。这个E-AutoPIA是一个利用一条路线执行其所属者安排的特殊任务的智能代理。路线在下一节详细描述。只有原始的E-PIA才可以发出一个E-AutoPIA,但是原始的E-PIA可以发出几个E-AutoPIA,并且允许他们同时活动。
| E-AutoPIA对象中的项 | 编号 | 类型 | 描述 |
| 路线 | 161 | 集 | 一个E-AutoPIA可以有几条可分层调用路线的路线对象163。 |
路线对象163显示在图17中。
| 路线对象中的项 | 编号 | 类型 | 描述 |
| 名字 | 170 | 字符串 | 一条路线必须有一个名字。 |
| 指令 | 171 | 集 | 路线可能包含几个交互指令。如果存在几条指令并且没有脚本,则这些指令顺序地被执行。 |
| 脚本 | 175 | 目录表 | 脚本被存储在一个目录表对象中,它允许通过名字来引用一个可执行字符串。 |
| 传输特权规则 | 178 | 集 | 已经在以前的表格中描述过。 |
| 特权规则 | 172 | 集 | 已经在以前的表格中描述过。 |
交互指令173对象显示在图18中。交互指令引起在E-PIA与E-AutoPIA之间的交互。每个交互指令指定将要执行的交互协议,用于交互的实际参数,以及交互发生时所必须满足的规则。一个成功的交互指令的最终结果是如图15B所示的一个信息化E-PIA的创建。由信息化E-PIA持有的信息的每一项都利用原始E-PIA的私有密钥加密,因此当使用该E-PIA的公共密钥时,为随后的用户提供信息的可靠性。
一个交互协议本质上是对交互指令维持一个模板关系。交互协议由要填写的参数的一个签名表示,而交互指令副本与此相同,除了具有已填写的参数。交互协议和交互指令都是编写时的实体。交互协议表示由一个电子经纪提供的一些服务,并且是与该电子经纪一起被编写的。交互指令是在E-AutoPIA的路线的构造期间被编写的。每条交互指令表示一个被请求的交互或者交互协议的调用。当构造相应的交互指令时,输入、输出和缺省映像图从交互协议中被删除。
| 交互指令对象中的项 | 编号 | 类型 | 描述 |
| 交互协议名字 | 181 | 字符串 | 每个协议都有一个名字。 |
| 社区名字 | 131 | 字符串 | E-AutoPIA的E-PIA驻留的电子都市社区的名字。 |
| 特权规则 | 185 | 集 | 已经在以前的表格中描述过。 |
| 最大指令数 | 183 | 整数 | 在其上使用该指令的E-PIA的最大数。这个数可以是无穷大。 |
| 参数分配 | 182 | 目录表 | |
| 传输特权规则 | 185 | 集 | 已经在以前的表格中描述过。 |
电子都市社区对象130显示在图13中。电子都市社区对象130为E-PIA与其他电子社区提供一组概念。
| 电子都市社区对象中的项 | 编号 | 类型 | 描述 |
| 135 | E-PIA | 电子经纪类从E-PIA类继承。因此,电子经纪是E-PIA的一个子类,它包含了E-PIA所包含的所有项,但是又包括: | |
| 名字 | 131 | 字符串 | 每个电子都市社区都有一个名字。 |
| 社区 | 132 | 集 | 一个电子都市社区可以以一种分层关系包含其他电子社区。 |
| 电子经纪 | 133 | 集 | 每个电子都市社区将需要至少一个,和可能几个电子经纪136去执行特殊任务。这些电子经纪被组织成一个集。 |
| 人物 | 134 | 集集 | 在电子都市社区中的所有E-PIA135被保持在一个集中。 |
电子经纪对象136显示在图14中。电子经纪是所有E-PIA和E-AutoPIA的交互所需要的。正是电子经纪保证了只对满足由个人设置的要求的可信任实体释放信息。
| 电子经纪对象中的项 | 编号 | 类型 | 描述 |
| 135 | E-PIA | 电子经纪类从E-PIA类继承。因此,电子经纪是E-PIA的一个子类,它包含了E-PIA所包含的所有项,但是又包括: |
| 协议目录 | 143 | 集 | 该电子经纪可以包含几个存储在一个集中的交互协议。 |
结构与设计
该节对被称为“电子都市”的个人和私有信息保护及经纪业务系统的架构和设计进行说明。
引言--用户的电子都市世界
电子都市世界被用于存储电子都市特殊对象和/或执行电子都市活动的所有硬件和软件的集合。主要通过网景浏览器来获得电子都市世界的用户视图,并且从该应用程序(即网景浏览器)来看,视图是所有经由因特网互连的电子社区的视图,如图2所示。最后,用户不关心电子社区物理位置在哪儿,他们只关心这些电子社区作为一个逻辑位置而用于具有相似兴趣的其他E-PIA之间的交互。
作为一种用于建立个人的信息化资产结构的工具,电子都市表格存储库还是适用的。可以利用电子都市客户编辑工具检索电子都市表格,并根据一个有用的可重用的结构把检索出的表格并入现有的或新的E-PIA的表格,以增加信息。然后一个用户可以把他的E-PIA存储到一个或多个电子社区中。
系统结构概述
电子都市世界机械结构
事实上,每个电子社区驻留在一个电子都市网站服务器上。如图7所描述,在一个这样的服务器上可以驻留多于一个电子社区。而且,驻留在单个服务器上的电子社区可以被配置以维持一个相互之间的分层关系。
图7显示了两个电子人-表格存储库13。如图7中文本所指示的,一个电子人表格存储库是由一个FTP站点实现,同时另一个是由一个邮件服务器系统来实现。甚至可能没有表格存储库,以及表格被简单地管理为一个本地文档。
电子都市世界系统处理结构
图8显示了在一个电子都市世界中的客户与服务器处理。客户工作站由以下部分组成:网景浏览器,电子都市特定的DLL、JAVA脚本,或者具有类似特性以便于各种电子都市客户活动的其他一些客户代码。FTP服务器被认为是因特网上的主要角色,而网景服务器系统将在网景的服务器文档中讨论。这个文档的焦点是图8中的电子都市可信任服务器系统47。当使用电子都市的时候,客户总是与一个电子都市可信任服务器通信。在编辑时,交互协议与交互指令可能只能从正确的电子经纪那里获得(实际上,用于交互协议和交互指令的表格可以从存储库中获得,如果需要这样做的化,但是用于这些活动的可信任令牌只能从电子经纪中获得)。在运行时,电子都市客户查询一个用户在电子社区的主E-PIA,和它驻留的电子都市服务器,看看相关的E-AutoPIA的最新结果或状态。电子都市服务器系统实际是由将在下一节讨论的许多处理过程组成。
电子都市安全结构
电子都市强调信息资产的安全和可信任的交互。电子都市保证进入电子都市世界系统的所有信息将是安全的,以及只有那些可信任的人才能访问特定的信息。对加密传输何时何地发生的描述,读者可参考图24,加密传输实质上是电子都市世界系统的“公开”互连。所有需要加密的安全措施是由网景的SSL(加密套接字协议层)通信层来处理的。为保持所述的安全级别,需要维持下面的系统属性:
1)在一个网站上的每个电子都市可信任服务器子系统由当它们在运行时没有人能够访问的安全处理组成。假设一个在单机上对处理安全的技术精通的普通人能够取得这个运行时间的完整性。
2)每个电子都市信任服务器子系统保持他自己的私有密钥和公共密钥。一个特殊电子都市可信任服务器子系统的公共密钥经过目录服务器电子经纪被所有其他电子都市可信任服务器子系统知道。
3)所有E-PIA和E-AutoPIA当在电子都市可信任服务器系统网站之间传输时都被加密。加密是采用作为传输的目的地的电子都市可信任服务器子系统的公共密钥以及传输源的私有密钥两者来实现的。这种双重加密完成一种双重保证:
a)只有具有正确私有密钥的电子都市可信任服务器子系统(目的地)才能够解密该传输。
b)同样是这个电子都市可信任服务器子系统(目的地)将被保证该传输来自传输中所声明的源电子都市服务器,而不是来自一个欺骗性的源。
4)所有在E-PIA与E-AutoPIA之间的交互是在电子都市可信任服务器系统内的一台单机上私下执行。
5)当一个客户请求被包含在它的主E-PIA中的信息时,维持该主E-PIA的电子都市可信任服务器子系统利用该主E-PIA客户的公共密钥加密该信息,以便传输该信息,以致于只有该接收客户才能够解密该信息。当写信息到该主E-PIA时,利用目的电子都市可信任服务器子统的公共密钥加密该信息,以致只有正确的目的地才能够解密该信息。写信息还包括E-AutoPIA和相关的路线的编辑。参看图24。
6)当一个客户正在从电子经纪获取编辑信息时,因为该编辑信息是用这个客户的公共密钥加密的,所以只有该客户知道如何解密该信息。这种加密主要是对在编辑期间的可信任令牌的传输很重要,一旦收到该传输就必须立即通过客户的私有密钥来加密该传输。
都市可信任服务器系统
图9描述了一个电子都市服务器的顶层子系统。提供电子都市的主要服务的核心子系统是分布式对象资源管理系统服务器或DORMS。五个其他的子系统是一个FTP服务器和FTP客户处理以及三个网景网站服务器子系统,它们一起为一个完整的电子都市服务器实现所需的功能性。
分布式对象资源管理系统服务器
如上所述,分布式对象资源管理系统服务器是电子都市系统结构的核心。它实质上是利用更小的对象即电子社区和电子经纪来帮助管理所有电子都市对象与资源的可信任储存与经纪,它在内部管理电子社区和电子经纪。尤其是,DORMS服务器执行下列功能:
D1.存储电子社区
D2.存储电子经纪
D3.保持一个完整的、所有电子社区和电子经纪所处位置的的电子都市世界目录,并且保持目录最新。
D4.存储或者“银行存储”E-PIA
D5.为电子社区之间的E-AutoPIA传输维持一个通信子系统
D6.维持访问的E-AutoPIA
D7.驱动E-AutoPIA与E-PIA交互的的电子经纪中介
D8.维持特权规则处理器,该特权规则处理器协助DORMS保证安全的和可信任的交互
网景商业服务器
网景商业服务器是允许电子都市服务器是一个网站以及在因特网上交互的核心子系统。因为它使用开放的加密套接字协议层(SSL)协议,因此它提供完整的因特网安全性。SSL采用来自RSA数据安全的技术提供加密、服务器身份验证以及消息的完整性。当客户发出请求时,该客户最初总是与网景商业服务器通信。接着,网景商业服务器将通过网景服务器API(应用编程接口)与DORMS服务器合作。这中通过网景商业服务器与一个电子都市服务器的通信允许客户子系统可以主要由一个HTTP/HTML适应的万维网(WWW)浏览器如网景导航者组成。这种合作的详细内容将在下一节讨论。
网景事务服务器
如图9中所示,网景事务服务器掌握着信用卡处理、事务记录、以及帐单管理。当某人希望开始第一次使用电子都市服务时,或者添加新的性能到他们的E-PIA时,DORMS服务器就与信用卡处理功能交互。该事务服务器的信用卡功能自动地处理初次和新的性能所需的费用。DORMS服务器还与事务记录功能交互以便跟踪在电子都市网站上正在发生什么事,它也可以使用记帐单管理功能。假定精通计算机编程的普通人能够容易地按照所需的网景手册去配置DORMS服务器与事务服务器之间的合作。
一个重要的电子都市特点是单个电子经纪和多个E-PIA能够配置它们自己的记帐政策。电子经纪可以要求登记信用卡信息,以便它为交互协议或交互指令提交一个所需的可信任令牌。E-PIA可以做同样的事,但是应该知道E-PIA只能通过电子经纪的执行来做到这点。这将在后面讨论。
网景服务器API(NSAPI)
NSAPI与网景商业服务器紧密地一起工作,以便当一个正常HTTP兼容的请求进入商业服务器时为网站提供控制该处理的手段。为此,网景公司已经确定了以下的在正常响应处理中的步骤:
NS1.授权解读
NS2.名字解读
NS3.路径检查
NS4.对象类型
NS5.响应请求
NS6.记录事务
NSAPI提供这种能力:以上述这些步骤中的任意和所有步骤来重载被执行的处理。假定精通计算机编程的普通人能够容易地按照所需的NSAPI手册来启动必需的这些步骤的重载。尤其是,步骤1,2,3,和5将需要特定的电子都市替换。替换实现的概述列举如下:
对于NS1:
请求所需的电子社区特权规则能够被检查;以及
请求所需的信任令牌能够被检查。
对于NS2:
路径可以参考分层分布的电子经纪或电子社区。
对于NS3,电子经纪或电子社区被检查,看它是否存在。对于NS5,请求的DORMS服务被执行。有几种类型的请求,它们是:
1)客户请求浏览DORM目录。
2)客户向电子经纪请求编辑时间信息。
3)客户请求拥有E-PIA信息资源的恢复。
4)客户请求在资产在客户上被更新后储存E-PIA信息资产。
5)客户请求发出一个E-AutoPIA。
注意,E-AutoPIA没有使用这种入口点,因为E-AutoPIA的活动不是一个客户驱动的处理。
FTP服务器与FTP客户
如将在后面的结构中介绍的,电子经纪需要一个可靠的通信子系统用于把E-AutoPIA从电子社区传送到电子社区。因为因特网的电子邮件是不可靠的,所以FTP服务器与FTP客户被用来实现E-AutoPIA传送。E-AutoPIA被编组为一个BLOb并且通过一个文件被传送到远程站点。然后该文件经过一个电子都市服务器的FTP客户的初始化被上载到另一个电子都市服务器的FTP服务器。后面的章节讨论FTP用于通信子系统结构的细节。
分布式对象资源管理系统(DORMS)服务器
图10显示在DORMS服务器内的子系统的复杂布局。这一节的其余部分专用于讨论这些组成子系统的每一个。然而,要认识到交互处理器是焦点,因为正是这个驱动子系统由于一个经过网景商业服务器的客户请求或者由于一个经过通信子系统的E-AutoPIA到达而被调用。另一个在继续之前产生的要点是,所有的服务请求以某种方式作为一个与电子经纪的交互被执行。
交互处理器
如上所述,交互处理器是DORMS服务器的焦点,并且它经过一个电子经纪来满足所有的请求。当通信子系统提交一个E-AutoPIA给DORMS服务器时,它实际上是把该E-AutoPIA提交给交互处理器,交互处理器是整个DORMS服务器的代码的驱动体。当通信子系统这样做时,假设它还没有编组该E-AutoPIABLOb,以致于E-AutoPIA是以一种合适的形式用于对它的处理的其余部分。如下表1和2所列举的,对于一个客户请求以及对于一个访问E-AutoPIA,要完成许多处理。交互处理器处理的服务请求是下面列出的所有客户请求,以及进入的E-AutoPIA的交互指令。由交互处理器服务的请求的完整清单以及对这些请求怎样被处理的概述列举如下。
IP1.客户请求浏览DORMS服务器目录--该请求被重定向到一个被称为“目录服务”电子经纪的特殊电子经纪。
IP2.客户向一个电子经纪请求编辑时间信息--该请求被重定向到一个电子经纪,该电子经纪被指定去调用其特殊的编写时间服务(交互协议)之一,例如“交互协议目录”和“获得交互协议权利”。
IP3.客户请求检索拥有的E-PIA信息资产--该请求被重定向到一个被称为“主”电子经纪的特殊电子经纪。这个被使用的特殊服务被称为“检索资产”。这个特殊电子经纪必须存在于主E-PIA要被允许驻留的每个电子社区中。
IP4.客户请求在资产在客户上被更新后存储E-PIA信息资产--该请求通过调用其“存储资产”服务来使用“主”电子经纪。
IP5.E-AutoPIA请求经过其路线中的当前交互指令的交互--该请求是
| 6 | 电子经纪适配器 | 调用execute() |
| 7 | 电子经纪可执行程序 | 启动可执行代码执行服务 |
| 8 | 电子经纪服务API | 可能需要调用服务API程序 |
| 9 | 网景商业服务器 | 返回信息。利用请求客户的公共密钥加密该返回的信息。 |
表1一个来自客户应用程序的请求--交互处理器的步骤和DORMS内子系统的使用。
| 子系统使用 | 作用 | |
| 1 | 通信子系统 | 接收E-AutoPIA并且利用本地电子都市可信任服务器系统的私有密钥加密。 |
| 2 | 交互处理器与虚拟映像 | 利用E-AutoPIA把请求提交给DORMS。 |
| 3 | 具有虚拟解释程序的虚拟映像 | 查找在E-AutoPIA的交互指令中指定的电子社区 |
| 4 | 具有虚拟解释程序的规则处理器 | 验证电子社区的特权规则。 |
| 5 | 具有虚拟解释程序的规则处理器 | 验证被传输交换的、将要作为输入和输出参数被传送的E-PIA文本。 |
| 6 | 电子经纪 | 通过利用从E-AutoPIA的证书获得的E-AutoPIA公共密钥解密该E-AutoPIA,来验证该E-AutoPIA具有必需的可信任令牌。 |
| 7 | 电子经纪适配器 | 利用“获得可信任令牌”服务和作为参数的交互协议(立刻被执行)的名称来调用execute()。 |
| 8 | 电子经纪可执行程序 | 启动可执行代码以便为指定的交互协议产生唯一的可信任令牌。 |
| 9 | 具有虚拟解释程序的规则处理器 | 构造简化的SQL语句,为E-PIA选择和收集做准备 |
| 10 | 电子经纪 | 调用电子经纪 |
| 11 | 电子经纪适配器 | 调用execute(),但是只允许那些满足传输特权的输入被传递。 |
| 12 | 电子经纪可执行程序 | 启动可执行代码执行服务 |
| 13 | 电子经纪服务API,从对象存储库中读取E-PIA | 调用collectTrustedEPIAs() |
| 14 | 电子经纪可执行程序 | 执行电子经纪的服务执行中的可执行代码的其余部分 |
| 15 | 虚拟映像 | 利用用传输特权满足的输出更新E-AutoPIA。 |
| 16 | 路线解释程序 | 解释当前的脚本正本,并且确定下一个要执行的交互指令 |
| 17 | 目录服务电子经纪和虚拟映 | 为下一个交互指令的下一个电子社区查找 |
| 像 | FTP地址 | |
| 18 | 通信子系统 | 把E-AutoPIA提交回给通信子系统,以便被传送给下一个电子社区。通信子系统必须用目的地的公共密钥加密要传输的信息。 |
表2一个来自E-AutoPIA的请求--交互处理器的步骤和分布对象资源管理系统服务器内部子系统的使用。
规则处理器
规则处理器是一个关键的安全实施子系统。它检查特权规则,并且附加地,规则处理器还控制着到SQL语句的转换,以帮助E-PIA选择。特权规则的确认需要相当复杂的程序。在E-AutoPIA的情况下,特权规 则可以指“我自己”和“你自己”。每个特权规则都是一组规则对象。每个规则对象最初必须被分解为只包括“我自己”引用的子表达式。通过在处于当前环境下的E-AutoPIA上执行虚拟解释程序,可以立即使这些“只有我自己”的子表达式变成真(TRUE)或假(FALSE)。保持“你自己”子表达式与该结果结合来形成一个简化的表达式。这个保持简化的表达式然后被解析,并且被转换成SQLSELECT(选择)语句,如果规则语言提供的话,该SQLSELECT语句可以具有一个“ORDERBY”(排序)子句。该SELECT语句以后被用于收集至此被评价的、迄今为止满足所有规则的E-PIA。
因为每个E-PIA具有它自己的特权规则,用于与处于当前环境的E-AutoPIA交互,因此从上述SELECT收集的E-PIA必须进一步过滤。这是通过以下方式完成的:每次从收集的E-PIA集中取一个E-PIA,并且把当E-AutoPIA用作“你自己”以及把当前的E-PIA作为“我自己”来执行它们的特权规则。这个执行需要虚拟解释程序。注意这部分的特权检查可能由于数据库选择(SELECT)没有被使用而具有较差的性能。因此重要的是为E-AutoPIA构造特权规则,以便收集的E-PIA集尽可能的小。
虚拟解释程序
虚拟解释程序只是给电子都市的编程语言以动态特性的机构。这种编程语言可以是任何一种语言或者甚至是一种新的语言,但是建议它具有类似于Smalltalk(面向对象的编程环境语言)的特性。这种编程语言是必须用在特权规则和路线的脚本中的那种语言。
虚拟映象
虚拟映象是所有正在被处理的电子都市特殊的类和对象在RAM中被保存的地方。虚拟解释程序给这些对象以动态特性。如图10所示,作为一种性能技术,所有电子社区和电子经纪被保持在虚拟映象中,虽然它们每个都是持久地存储在对象存储库中。
当一个E-AutoPIA或E-PIA被处理时,它们和它们所拥有的对象都被导入虚拟映象中。然后特权规则使用虚拟解释程序去处理表达式。关于类EPIA的一种特殊的方法是能够检查一个特定的可信任令牌的存在。
电子经纪对象
每个电子经纪对象可以代表一个可执行程序,它实质上是在被传送的、以各种方式执行其交互协议的电子都市软件的外部。然而,如果所期望的只是在E-AutoPIA与E-PIA之间的信息共享,那么电子经纪就不需要外部的可执行程序。替代地,交互协议处理器将只知道如果遵守特权规则那么数据的交换将会发生。E-AutoPIA的交互指令应该被编辑,好像在与该E-AutoPIA的交互中只涉及一个E-PIA。交互处理器将自动地构造大小等于最大交互数(maximumInteractions)的输出参数集。
电子经纪适配器与电子经纪可执行程序
利用虚拟解释程序,使用一个统一的协议来访问所有的电子经纪对象。然而,每个电子经纪可执行程序可能是不同的。一个电子经纪可以是一个C或C++的可执行程序(EXE)、C或C++的动态连接库(DLL)、VisualBasic(可视化Basic)程序、OLE2(对象链接和嵌入)对象、SOM(系统对象模型),或者其他程序。在每种情况下,启动交互协议或服务的执行所需的程序可能有所不同。因此,各种新的可执行程序需要一个电子经纪适配器,该适配器把统一的协议调用转换成为实现与来自和到电子经纪可执行程序的必需信号与信息的通信所需的机制。
适配器总是一个动态加载的DLL,并且总是支持下列API(性能未定):
start()--在适配器DDL刚加载后被调用
stop()--在适配器DDL刚卸载后被调用
execute()--它是执行一个交互协议的主程序(main)入口点。该交互协议的名称以及连接的所有参数列表必需被传到execute()中。execute()的实现是重要的,因为它必定包含了一种代码,这种代码以某种方式把交互协议的名称结合到代表该交互协议执行的可执行代码体上。execute()然后调用该可执行程序代码体。
电子经纪服务API
如所述,电子经纪可执行程序可以是任何一种上述的可执行程序类型。为了方便写代码去执行电子经纪的开发者试图实现的服务/交互协议,一些API被提供。可执行程序必须能够从一个C的DDL中调用C程序去执行这些程序。
一些被确定有用的程序(性能未定)是:
collectTrustedEPIAs()--该API是唯一的、所有电子经纪可执行程序都必须调用的API。它是可执行程序要获得E-PIA的“应允的特权”集合的唯一方法。该API获取作为输入的、要被应用于E-PIA的收集的附加规则。利用规则处理器把输入的规则和先前形成的、进入到电子经纪中的SQL语句结合起来。这将产生最终的、要被使用的SQLSELECT语句。SELECT语句被执行以便获得符合该SELECT的E-PIA集合。然而,直到通过执行规则处理器检查了该集合中的E-PIA的单个特许规则,才返回该集合。
一旦整个“应允的特权”集合被返回,电子经纪可执行程序就可以在从交互作用中返回之前利用该集合做它想做的事。注意,在用于交互指令的最大交互数(maximumInteractions)的值较小的情况下,“orderby(排序)”规则可能很重要。processCreditCard()--在为购买等事务获得信用卡信息后与事务服务器交互。
billActivity()--与交易服务器交互以便根据一个活动的名字填写一个E-AutoPIA。
validateWithSecureCard()--需要一个要被输进一个读卡器中以便返回真(TRUE)的电子安全卡。这个特殊的安全卡由作为参数提供给这个API的信息和规则来识别。
元电子经纪
因为某些电子都市系统本身是由电子经纪实现的,这些特殊电子经纪被称为“元”电子经纪。迄今为止,仅两个已经被定义。可能需要更多的。
主电子经纪
这个电子经纪首先需要验证某个编辑或浏览一个特定的主E-PIA的信息资产的用户就是拥有该主E-PIA的人。虽然该特殊的电子经纪可能需要出现在多个电子社区中,但是其实现可以被重载。例如,某个“主”电子经纪实现可以提供严格的安全性以至于安全卡是绝对需要的。其他“主”电子经纪可能仅需要一个口令。一个松散的电子社区可能没有安全性。
目录服务电子经纪
这个电子经纪试图维持整个电子经纪世界的知识最新。每一个位于网站上的顶层主电子社区只需要一个目录服务电子经纪。尤其是,它始终监视每个在线电子都市可信任服务器子系统的公共密钥、所有的电子社区和这些电子社区位于的因特网地址,以及驻留在这些电子社区中的电子经纪,以及各个电子经纪拥有的交互协议的名称。该目录信息必须持久,因此它被存储在对象存储库中。
要保持目录信息最新,每个目录服务电子经纪周期地查看是否有任何电子社区或电子经纪配置发生了变化。如果有,该目录服务电子经纪发送一个带有一条路线的E-AutoPIA给每个和所有其他的目录服务电子经纪,以把这些变化通知给它们。因为这样的变化可能是相当少的,所以周期的频率可以是每天一次。注意一个新的电子都市站点刚一安装就必须获得整个当前电子都市目录的一个拷贝。
路线解释程序
路线解释程序懂得一条路线当选两种形式之一。路线或者具有脚本,或者没有脚本无论那种情况,路线必须有至少一个交互指令在指令订购集合中。在没有脚本的情况下,指令订购集合只是被顺序地执行。在有脚本的情况下,交互指令的参数必须被填写,因为脚本用这些参数执行调用。在这种情况下,交互指令的订购集合仅代表能够从该脚本中被调用的交互指令。对于存在脚本的情况,没有理由持有复制的交互指令。
对于没有脚本的情况,路线解释程序仅仅使E-AutoPIA中的指令指针增大,以便始终知道当前的交互指令是路线中的哪一条指令。当存在脚本时,路线解释程序必须能够编译和执行正本。它只是通过使用虚拟解释程序来实现脚本的编译和执行。每个脚本就象一种Smalltalk(面向对象的可编程环境语言)方法,在脚本中编程语言被用于执行任何普通的处理。在脚本中引用的变量结合到E-AutoPIA中的指定信息。在任何时候在一个脚本内,都可以通过引用这个特殊的变量“Instructions”来调用一个交互指令或者甚至整个路线。用于调用一个交互指令的句法将是“指令:aProtocolName(协议名称);performWith(实现的条件):aDictionaryOfParameters(参数列表)”。在这个例子中,aProtocolName(协议名称)是要执行的交互协议的名字,而aDictionaryOfParameters(参数列表)是在参数名上键入的和在参数的值上取值的一个列表。
对象存储库
对象存储库主要意指E-PIA被持久保留的地方。然而,电子社区和电子经纪也一样保存在这里。对象存储库在一个关系数据库的实现(即Oracle)上使用一个简单的面向对象的接口。对于关系表的行的设计,简单对象的一些特点如下:
OR1.每个对象用图11描述的行模式存储在一个数据库表的一行中。
OR2.对象标识符或者OID是一个因特网范围唯一的、可以用于解除对象参考的数字标识符。
OR3.每个对象被认为要存储在一个持久多关键字集合(PersistentMultiKeyedCollection)中,持久多关键字集合只是每个具有相同的集合OID(CollectionOID)的一组行。
OR4.这些关键字实际上是一个对象的“公开的”信息。当一个对象存储在一行中时,已经确定要公开的对象数据被复制到该行的合适列中。因为数据库引擎可以使用,所以只有这些被确定的关键字能够用于快速E-PIA选择和收集。
OR5.真正的对象本身被存储在一行的BLOB列中。
为驻留在电子都市服务器中的每个顶层电子社区安装一个对象存储库。该数据库模式只包括三个表,一个用于电子社区,一个用于电子经纪,以及一个用于E-PIA。用于电子社区、电子经纪以及E-PIA的持久多关键字集合模式分别如图11b、11c和11d所示。
在三个表格的每个中,集合OID(CollectionOID)涉及到一个不同的分组概念。在电子社区表中,父OID(ParentOID)是一个把父电子社区作为其子电子社区的集合的集合OID。在电子经纪和E-PIA的表中,电子社区OID是集合OID。这些关键字故意未确定。这是因为这些关键字应该由电子社区的需要来确定以及应该可以通过电子社区管理工具来配置。
重要的是要注意如何获得利用分层电子社区的访问。假设一个查询必须允许任何是一个电子社区的成员的E-PIA或者任何是该电子社区的子电子社区的成员的E-PIA在结果中。首先,在查询和收集前,必须先发现涉及到所有分层可达到的电子社区的OID。然后利用一串Ored“集合OID==X”的表达式构造SELECT(选择)查询。
记住决大多数电子社区和电子经纪处理只是打算直接在虚拟映象中的RAM中被完成。在对象存储库中只有E-PIA将被定期访问。
通信子系统
就交互处理器而言,通信子系统只是将要请求经纪代理服务的E-AutoPIA的一个源和宿。当一个E-AutoPIA的服务完成时,交互处理器把该E-AutoPIA提交给路线解释程序。这个路线解释程序解释当前的脚本,直到它能够到达恰好的下一条交互指令调用。如果没有正本而仅存在一条线性的交互指令的路线,这将是直接的。当路线解释程序被完成时,交互处理器使E-AutoPIA返回。目录服务电子经纪然后被比较,以查看该E-AutoPIA下一步需要去哪个网站。交互处理器然后提交该E-AutoPIA回到通信子系统以便该E-AutoPIA能够被传送到它的下一个目的地。通信子系统的细节在下一节介绍。
通信子系统
该通信子系统专门用于把E-AutoPIA从一个远程电子社区可靠地传输到另一个远程电子社区。图12中所描述的信息结构是非常简单的。该通信子系统主要依赖于:E-AutoPIA借助于外部FTP客户和FTP服务器到达消息队列和从消息队列被发出。E-AutoPIA调度器是对DORMS服务器的主要接口。然而,注意FTP不需要作为通信子系统实现。相反,任何用于发送信息的可靠手段都能够使用。这些子系统将在下边详细地描述。
E-AutoPIA发送调度器
当一个E-AutoPIA正在被发送给一个远程电子社区时,它的FTP因特网地址应该已经被交互处理器查找到。注意每个顶层电子社区都有一个因特网地址。交互处理器通过发出(handingoff)要与该地址一起发送的E-AutoPIA来调用E-AutoPIA发送调度器。
E-AutoPIA发送调度器把该E-AutoPIA放置到一个输出消息队列中,然后激活FTP客户去发送该E-AutoPIA给它的目的地。如果由于任何原因FTP客户不能立即发送该E-AutoPIA,则该FTP客户将在稍后从输出消息队列中读取该项,并且随后试图发送该输出的E-AutoPIA。
消息队列
消息队列实际上只是一个FTP文件系统。有一个唯一的输出消息队列和一个唯一的输入消息队列,它们可以是两个截然不同的FTP文件目录。
E-AutoPIA接收调度器
当E-AutoPIA接收调度器在输入消息队列中观察到一个到达的E-AutoPIA时,该接收调度器根据其文件格式解组(unmarshal)该E-AutoPIA,然后立即调用一个新的交互处理器过程去处理该E-AutoPIA。在输入消息队列中的E-AutoPIA文件直到该E-AutoPIA被提交给输出消息队列时才被删除。在DORMS服务器崩溃的情况下,需要进行恢复。因为只有这么多这样的服务器可以同时运行,所以一个E-AutoPIA的备份能够建立在输入消息队列中。如果输入消息队列空了,E-AutoPIA接收调度器可以周期地休眠和醒来,以检查是否有任何东西到达。如果FTP服务器处理有一种方法发信号给E-AutoPIA接收调度器,则根据需要可以异步唤醒休眠过程。
FTP客户
FTP客户处理实际需要执行的任务比一个vanillaFTP客户要稍多一些。一旦该FTP客户已经成功地把该E-AutoPIA文件传送给它的下一个目的地,它就必须从输出消息队列中删除该E-AutoPIA文件。再者,FTP被用于传输是因为它是可靠的。如果在传送期间发生了错误,该FTP客户将知道,因为传输是直接点对点的。该FTP客户将知道它必须保持失败的E-AutoPIA在输出消息队列中,并且稍后再试着传送该E-AutoPIA。FTP服务器
FTP服务器不需要做任何特殊的事。它只是存储进入的E-AutoPIA文件,并把该E-AutoPIA文件转发给被请求的目录。如上所述,被指定的FTP目录代表位于本地电子都市网站的顶层电子社区之一的消息队列。
对象模型概述
这一节描述一种基于计算机化社区的个人与私有信息保护的的对象模型和被称为“电子都市”的经纪代理系统。这种对象模型聚焦于用户对电子都市中对象的观点。这种对象模型提供了对象如何工作以及对象如何在用户级彼此相互关联的详细描述。在某些情况下,用户级的对象和类将不映射到对象编程语言中的另一个对象或类。然而,在极大程度上,从OOA(面向对象分析)对象到OOD(面向对象设计)对象的转变是非常平稳的。面向对象的Booch符号被用在该文档的图表中,作为一种在视觉上与对象的关系通信的手段。图23描述了使用的基本注释符号和它们的意思。“用于执行”的符号主要用于实例变量,以表示一个类需要在其执行中的对象。
基础对象
在电子都市对象模型的描述的最高层,有电子人、电子社区和电子经纪。电子人是以前所述的计算机化人概念。这就好象是一个虚拟的人,因为它被认为是要代表的人,但是在电脑空间里。电子人驻留在电子社区中是为了保持他们的信息资产的安全。同时电子经纪是所有电子人交互活动的实际媒介,以便保持由电子社区提供的安全性以及任何规定的(电子人特定的)个人安全措施。
电子社区是一个安全的和可信任的计算机化社区。电子社区保证了安全性,因为只有具有合适的电子社区特权的电子人可以进入或驻留该电子社区。也可在电子社区内保持安全性,因为驻留在其中的电子人的信息资产只能被那些具有合适的个人特权的电子人共享。电子社区是可信任的,是因为它保证了它所包含的电子人和来访的电子人将根据每个电子人建立的规则进行交互,因此保持“只有可信任的”的交互性。
每个电子社区至少存在一个电子经纪,其目的是作为特许的信息共享和交互的媒介。事实上,电子人信息共享和交互两者只能通过电子经纪发生。
作为个人信息代理的电子人
在电子都市中存在两个主要电子人子类,它们分别是电子个人信息代理(E-PIA)和电子自治个人信息代理(E-AutoPIA)。术语“个人信息代理”例举电子人的目的,因为它们管理着一个真实人的电子信息资产。代表一个真实合作的电子合作信息代理(ECIA)也是电子人的一个可能的子集,该E-CIA可能有用。
当E-PIA驻留在一个电子社区中的时候,正是该E-PIA共享它自己的信息。然而,这种“被动”的共享仅可能与一个更“主动”的、被称为E-AutoPIA的E-PIA一起出现。只有具有由该E-PIA建立的合适特权的E-AutoPIA才能与这个E-PIA交互以及享受信息共享。一个被分配给E-PIA37所驻留的电子社区35的电子经纪39作为该特许信息共享的媒介,如图5所示。注意,只有E-AutoPIA41才可以初始化一个活动。
如果一个E-AutoPIA期望初始化交互活动,例如参与与其他E-PIA的安全信息共享,向其他E-PIA请求安全服务,或者执行与其他E-PIA的安全交易,则该E-AutoPIA必须为每个特定的活动访问合适的电子经纪。一个E-AutoPIA要执行的交互的清单被称为它的路线。如驻留在电子社区的E-PIA一样,E-AutoPIA是由一个电子经纪的保护,并且只能通过一个电子经纪与其它的E-PIA或者E-AutoPIA交互。所有的信息共享和其他普通形式的交互总是通过交互协议出现。虽然图6中所示的E-AutoPIA访问每个位于不同的电子社区的几个电子经纪,但是有可能多个电子经纪存在于单一电子社区上,他们每个都被一个单个的E-AutoPIA根据其期望的活动访问。
信任的安全性和传输性
读者应该注意限定词“安全”的连续使用。安全性在电子都市中是关键的,它作为保持计划在由E-PIA代表的人之间进行的交互的完整性的主要手段。严格的安全性是必需的,以便确保预定的E-PIA相互关系以及保持电子都市用户的信息,使他们相信只有那些打算查看特定的信息的人才能够去实现。
当一个E-PIA把一些其个人信息给另一个E-PIA时,给出的个人信息还是由原始的E-PIA保护和所属。事实上,如果该接收E-PIA依次把另一个E-PIA的信息传递给第三E-PIA,电子都市仍然知道个人信息的原始拥有者并且继续根据原始E-PIA公布的传输特权规则来控制对该信息的访问。这个由电子都市创造的安全范例被称为信任的传输性。信任的传输性意思是:
如果A相信拥有信息A′的B,
而B相信拥有信息A′的C,
则A相信拥有信息A′的C。
根据对已经提交的数据声称的传输特权规则,这个重要的概念向A保证它的信息永远不会传输到一个不信任的实体。
对于电子都市来说,知道哪个E-PIA拥有该信息是容易的,因为信息总是作为一个提交其信息的E-PIA的一个版本被传输。例如,假设一个E-PIA包含一组丰富的信息,它包括出生日期、地址以及电话号码等等。更进一步,假设它希望在交互期间只提交它的电话号码给另一个E-PIA。接收E-PIA实际上将接收一个仅含电话号码的E-PIA对象。尤其是,收到的E-PIA对象是原始E-PIA的一个版本,它表示了提交E-PIA希望接收E-PIA怎样来理解它。图6描述了通过一个移动E-PIA41的E-PIA40的版本的“集合”。这些版本的E-PIA对象是信息由电子都市中的E-PIA保持的唯一方式。图6还描述了一个已经被给予电子社区之一中的非移动E-PIA39的移动E-AutoPIA的一个版本。
子系统模型
在介绍对象行为和关系的细节之前,理解当使用电子都市时各用户知道的子系统是重要的。这一节描述主要客户和服务器子系统的活动。
使用的模式
编写时间
E-PIA
E-PIA只有两个可编写的项:它们的信息资产和它们的交互协议。资产需要利用某种分层的GUI(图形用户接口)来编写。这个GUI必须考虑任何要进入一个字段的数据并且给这个字段一个名字。这个GUI还必须提供一种通过附加一个子文件夹的概念来创建分层结构的方法。有希望,这种分层表示可能与HTML格式协议的某些方面一起使用。
交互协议被严格地保护并且可能只有从驻留在被编写的E-PIA的同一电子社区中的电子经纪之一获得。某人可以浏览电子社区中的一个电子经纪以便获得它的HTML格式的协议目录。返回的HTML文本包括一个表示要请求获得被列出的交互协议的一个或多个的方法的HTML格式。实际上获得一个特定的协议可能要求一些批准和/或付一定费用。当交互协议实际已获得时,它被存储在E-PIA中。然而,交互协议具有特权规则和一个可以使用的或者通过HTML格式修改的缺省映像。
E-AutoPIA
E-AutoPIA只需要编辑的它们的路线。这是因为一个E-AutoPIA总是从一个E-PIA中例示出。要编辑一条路线,为交互协议浏览一个电子经纪是以与利用E-PIA相同的方式实现的。然而,不是检索一个交互协议,而是获得一个具有要填写的参数的交互指令。
格式存储库
因为E-PIA信息的结构可能要被反复地再用,为填写各种E-PIA结构的信息所需的HTML格式可以被存储在被称为格式或电子人存储库的共享区域中。这些存储库可以是简单的FTP网站或者甚至可能是网景服务器系统。还可能要存储与交互协议、交互指令以及路线相关的HTML格式。然而,如后面将要描述的,在运行期间使用这些对象的E-PIA必须具有与这些对象的每个相关的特定可信任令牌,以便实际执行它们的预定活动。
运行时间
在运行时间,拥有一个E-PIA或E-AutoPIA的人看不到任何事情发生,因为所有交互都是由电子都市服务器处理的。然而,要看交互的进展或最新的结果,一个拥有者可以检索其信息资产,核查包含在他的E-PIA(s)或E-AutoPIA(s)中的轨迹。注意一个人可能有多个E-PIA但是只有一个被指定为主E-PIA(关于主E-PIA的更多描述将在后面)。如任何时候,使用HTML文本来表示。在某些情况下,E-PIA的状态可能指示:某人在继续之前正在等待作用在拥有者角色上的活动发生。
电子社区管理时间
电子社区管理员需要保持、修复和升级一个电子社区中的电子经纪。电子社区管理员还需要能够对一个电子社区边界(即包含的电子社区)内的每件事情具有特权,以便保证每件事情平稳运行或者找出问题所在。备份与恢复功能也必须执行。
电子都市管理时间
一个由电子都市使用的、仅仅可以使用每件事的电子都市管理者是不存在的。每个电子社区根据该电子社区建立的规则自主地保持和管理他自己的资产。这是电子都市中的一个关键的主权概念。
客户与服务器子系统
用户的世界只是由属于他们的电子社区和电子经纪、格式存储库以及网景世界广域网络浏览器组成。用户明白所有电子社区通过因特网互连,以及可以通过一个“http://www.”地址能够连接到所有这些电子社区。在前一节提到电子都市中的所有数据是如何在被呈现给用户之前被变换成一种HTML格式。这种变换发生在服务器上,所以在客户工作站上只需要网景客户和一个现有的HTML相关的客户编程系统(例如,C++和NCAPI,或者JAVA)。注意分开的电子社区可以或可以不实际上位于相同的站点,但是其物理位置的考虑对用户是不相关的。
用户还可以希望使用一个电子都市安全卡来存储E-PIA信息资产。当使用某些服务时,用户验证需要用到该安全卡,但是它还可能是一个人希望存储其资产的另一种方法。在某一时刻,可能它是某人想要保持其资产的唯一地方--在什么地方、什么时间以及如何存储或共享信息资产完全是拥有该E-PIA信息资产的人的决定。
社区管理员的观点
电子社区管理员使用电子社区管理工具管理在单个电子都市万维网网服务器上的一个或者多个电子社区。在每个电子社区管理员知道他的电子社区和由电子社区开发组创建的电子社区相应的电子经纪同时,一个电子社区管理员规定的“电子社区网站管理员”还知道该电子都市和可能需要被监视与/或配置的网景服务器处理。由于电子都市中所需的严格安全措施,管理工具客户应用程序要求直接登录到电子都市服务器,而不是经过任何因特网协议。注意该限制不排除远程登录。如果希望的话,电子社区管理员还可以在服务器上安装一个表格存储库。
详细的对象模型
电子都市对象模型的一个主要特点是第一类对象即E-PIA不是类的实例(在用户级),而只是一些实例。代替地,通过协议分配在任何时候动态地为它们分配行动。这样方便了行动增量地加或减量地减。人们相信,对于期望去做或探索不同的活动的某人,这种方便性对于他每天变化的需要和期望是必需的。
电子人
B1.电子人的目的--一个电子人代表电子都市的计算机世界中的一个“生命”。这个生命或电子人必须有一个愿望或目的要与其他电子人交互,以便在线存在于电子都市中。
B2.一个电子人可以代表任何事情的生命--注意,计算机空间中的生命可以给予正常被认为不具有“生命”的对象。例如,能够表示死去的人。虽然电子都市的主要目的是使电子人表示真正活着的人,但是电子人还可以表示真实的动物、真实的公司、真实的组织、真实的无生命的对象,或者甚至表示在电子都市的外部以电子形式存储和保存的知识对象。电子还可以表示死亡以及所有上述对象的完全虚构(非真实的)模拟。
B3.一个电子人实质上是一个抽象的根类,不存在电子人的直接实例。
基本的信息对象
I1.基本的信息对象的目的--信息对象保持电子都市中的数据,并且是类的实例。因为用户与各种基本数据类型频繁地交互,所以提及基本数据是重要的。
I2.基类是:
类
整数
字符串
浮点
布尔值
订购集合
集
目录表
SQL语句
文件夹
可执行字符串
编译程序
I3.基类具有缺省协议--缺省协议对应于基类的方法。例如,获得订购集合、集和目录表的大小的方法象订购集合的特殊索引以及目录表的特定关键字一样,是必需的。
I4.一个可执行字符串表示可以作为对象在周围被传递、当需要时可以被解释和处理的一段代码--可执行字符串需要输入参数。零、一个及两个参数的可执行字符串都应该支持。每个可执行字符串确定其编译程序/解释程序的名字。这样允许在可执行字符串中引用的名字可以结合到由编译程序控制的不同环境中的信息中。
I5.SQL语句意图提供一种载体,用于在能够引用E-PIA信息时实现信息的快速查找--因为一个到E-PIA信息的引用是分层的和非SQL适用的,因此SQL语句对象不完全支持SQL。通过由电子都市提供的一个特殊编译程序来安排这些引用。
I6.文件夹能够使用分层排列的关键字来存储对象。
I7.一组扩展的类将必须被提供,以支持各种标准的对象协议--一些实例是OLEObject、OpenDocObject和SOMObject。这些是必要的,因为一些信息资产数据希望由人以这种格式来存储。
I8.一组扩展的类将必须被提供,以支持各种多媒体--一些实例是声音、视频和图象。
I9.非常重要的目录表对象只是作为键入的对象的一个列表被显示给目录表的客户--这些键入的对象通常被称为目录表的“值”。一个关键字被用于查找目录中的一个值或对象。这些关键字典型地为字符串或符号(如在Smalltalk中那样),并且作为这样键入的对象的名字。但是这些关键字可以时编程者看上去和一把钥匙一样有用的任何对象。这些值也可以是任何对象。一个目录表例子显示如下。
| 关键字 | 值 |
| “名” | 一个字符串对象 |
| “高度” | 一个浮点对象 |
| “街” | 一个字符串对象 |
电子个人信息代理(E-PIA)
PIA1.E-PIA的目的--一个电子人,它表示一个真实人并保持该真实人的信息资产,这些信息资产计划以一种安全的形式被共享。
PIA2.一个E-PIA可以存在于一个电子的电子都市安全卡上。
PIA3.每个E-PIA由一个在编写时被创建和编辑的、未组织的文件夹构成--该编辑要用由于电子都市客户子系统而变得方便的HTML格式来完成。
PIA4.每个E-PIA可以由E-PIA的拥有者在编写时间指定一个交互协议集--E-PIA在运行时间只通过一个交互协议并且每次只通过一个交互协议来共享信息。
PIA5.一个E-PIA包含一组在所有交互协议执行时必须被检查和满足的特权规则。
PIA6.一个E-PIA包含一组在编辑时间从电子经纪获得的可信任令牌--在E-PIA进行交互的任何时候都可以使用这些可信任令牌的一部分或全部。
PIA7.一个E-PIA包含一个对所有与它一起发生的交互的核查跟踪--每个记录事件(RecordedEvent)储存关于一个令人感兴趣的交互的信息(例如启动时间、完成时间以及任何访问违规等等)。
对于一个E-PIA,每当有一个交互协议在其上被执行时,一个记录事件对象就被附加到它的核查跟踪。对于一个E-AutoPIA,每当有一个交互协议在其路线中被执行时,一个记录事件对象就被附加到它的核查跟踪。记录事件对象的内容需要根据在电子都市开发期间的核查跟踪需要来确定。此外,为了性能或磁盘空间的原因,某些记录事件的筛选可能不希望被记录。最后,核查跟踪的要点是允许E-PIA或E-AutoPIA的拥有者能够回顾已经做过什么。
PIA8.一个E-PIA可以同时存在于多个电子社区中。
PIA9.如果对于一个特定的人存在多个E-PIA就必须指定一个主E-PIA--主E-PIA包含了其他E-PIA位于的电子社区的名字。
PIA10.只有主E-PIA可以在编写时间被修改。
PIA11.每个E-PIA包含一个具有该E-PIA代表的人的名字和这个人的公共密钥的证书--假设在任何时候一个处理能够通过查询适当的证书权限来验证名字和公共密钥对。
PIA12.当来自一个E-PIA的信息在一个信息交互中被提供时,一个E-PIA的版本在运行时间被构造--一个E-PIA版本只包含:
证书
资产
特权规则
应该考虑包括一个核查跟踪的可能性。注意E-PIA的版本一般表示实际被包含在源E-PIA内的信息的一个子集,所以资产可能是原始资源文件夹的一小部分的一个拷贝。证书帮助验证信息确实来自该证书中声明的名字所表示的E-PIA。这一点是重要的,因为信息能够以“传输可信任的”第三方信息共享的方式被传递。此外,在原始E-PIA资产文件夹中的每条单独的信息,当在该E-PIA的拥有者的个人工作站上被汇编时是用该E-PIA的私有密钥来加密的。利用E-PIA的版本中的证书中的公共密钥,另一个E-PIA可以使该数据被解密,并且确实知道该E-PIA版本实际上使由其所有者“签名”的。
可信任令牌
TT1.可信任令牌的目的--一个信任令牌是在编写时间从一个电子经纪与其他一些对象一起获得的,以便保护对象的使用,代表性的是由电子经纪所经纪的一个交互或服务。可信任令牌准予新的拥有者一个基本的和必需的特权(但是不必是足够的特权)去执行被保护的交互。
TT2.当一个可信任令牌被给予一个E-PIA作者时,在该E-PIA作者的本地机上利用该E-PIA作者的私有密钥加密该可信任令牌--然后电子经纪记住该E-PIA作者的公共密钥。
TT3.当一个安全的交互被请求时,必须把E-PIA的名字和加密的可信任令牌给电子经纪。由这个E-PIA名字和可信任令牌对,可信任令牌能够用从以前的编辑期间获得的公共密钥来解密--该电子经纪知道,只有当该可信任令牌能够被成功地解密时请求交互的该E-PIA才是可信任的。
交互协议
SP1.交互协议的目的--一个交互协议对象指定特殊命名的信息和为了要共享的特殊信息而必须是真的条件。该共享信息是以一个E-PIA的版本的形式打包的。该E-PIA的版本是由交互协议的输出特别定义的。
SP2.一个交互协议必须有名字。
SP3.一个交互协议对象由下面的内容的5个字节组(tuple)组成
1)输入参数集
2)用于确定什么信息要存储在将被共享的E-PIA的版本中的输出参数集
3)缺省参数映射
4)用于要发生的直接共享的特权规则集
5)用于要通过第三方(传输共享)发生的E-PIA版本的共享的传输特权规则集。在运行时,这些规则被复制,并且被放在将被共享的E-PIA版本的特权规则中。
6)启动布尔运算--一个交互可能被禁用。
SP4.一个交互协议的执行根据运行时间输出参数值创建E-PIA的一个版本。这个E-PIA版本是被给出的、以及与要与之交互的E-AutoPIA共享的E-PIA--然而,如果所有的输出参数值都是以前获得的E-PIA版本,则不生成一个E-PIA版本。代替地,该信息是以最初获得的E-PIA格式向前传输。
注意:应该研究以下考虑的事项:即,在某些情形下把数据作为原始的数据进行传递,而不总是把数据作为E-PIA的一个版本来传递。或许把数据作为一个E-PIA版本或原始数据来传递可能是在交互协议与交互指令编写期间的一个选择。
SP5.被共享的E-PIA版本,其基本信息的每一条都已经用该E-PIA的私有密钥加密了--当用于主E-PIA的信息被汇编时,这个加密在该E-PIA的个人客户工作站发生。随后,另外的E-PIA或处理能够利用在其证书中发现的E-PIA版本的公共密钥来解密该信息。
注意,因为私有密钥从来不在服务器上,被用于传递一个E-PIA版本中的数据的输入或输出参数可能要求被严格地限制在丰富的表达式中,因为通常一个表达式结果将需要用私有密钥再加密。
SP6.一个交互协议的缺省参数映射是一个目录表,该目录表显示零或多个参数的名字以及一个与每个所列参数相关的分层名字。
SP7.一个交互协议可以继承一个现有的交互协议--该子类交互协议继承了它可能增加更多参数和规则的4个数组。
SP8.一个E-PIA可以重写指定给它的任何或所有交互协议中的特权规则--编写时间E-PIA工具必须提供这种能力。
SP9.缺省映射有意于充当一个助手以协助一个相应的交互指令的构造--因为交互指令必须用表达式字符串填写一个交互协议的参数,用普遍期望的缺省值填写一些或所有参数可能是好的。下面表格显示一个缺省映射的例子。
| 参数名字 | 缺省值 |
| “名” | 名 |
| “高度” | 外形.物理属性.高度 |
| “街” | 地址.街 |
C/C++语言中的模拟应该是以下函数原型:
ProcessSuperficialInfo(String*FirstName(名),Float*Height(高度),String*Street(街)),将用以下缺省调用自动填写它:processSuperficialInfo(名,外形.物理属性.高度,地址.街)
认识到这些缺省参数引用了那些参考(然后结合到)E-AutoPIA的文件夹的变量。
参数
P1.参数的目的--一个参数是为一个或者要输入到一个交互或者要从一个交互输出的信息对象而指定的“通道”。
P2.每个参数是一个2字节组(名字,验证规则)--验证规则可以用于在运行时校验类型。例如,表达式“iskindof:aClass”确定运行时参数值是aClass的一个实例还是其子类的一个实例。一个更复杂的例子将是一个类型验证和一个一般表达式的结合如:(myselfisMemberOf:Float)&(myself>203500.00)。
规则
R1.规则的目的--规则被分配给一些活动,并且描述该活动要发生的条件。否则该活动就不发生。重要的是要注意规则语法必须是多方中心的(multiplepartycentric)。
R2.规则是一些代表计算为真(TRUE)或假(FALSE)的表达式的可执行字符串。
R3.规则表达式语法必须识别多种设备场境--在最令人感兴趣的情况下,两个E-PIA可能符合,因此我们对两个设备场境感兴趣,它们是共享者和被共享者。
R4.为了方便引用两个符合的对象,将在语法中建立关键字“我自己”和“你自己”--我自己指的是共享者(共享E-PIA),而你自己指的是被共享者(与共享者相遇的E-PIA)。
R5.为了方便引用多个符合的对象,应该在语法中建立关键字“你们自己”--你们自己指的是被共享者的集(与共享者相遇的E-PIA)。索引可以用于引用特定的被共享者。你自己总是与在索引0处的你们自己相同。
R6.引用被用于引用在对象中分层放置的一段数据--一个引用可以使用由空格分开的名字来表示分层访问。
例子:要把一个活动限制给只有那些身高超过6英尺的人,一个共享者的规则可能是:你自己(yourself)外形(profile)物理属性(physicalAttributes)高度(height)>6R7.这些规则有意要在运行时间被解释--因此,某些错误只期望在编写时被发现。
电子自治个人信息代理(E-AutoPIA)
APIA1.E-AutoPIA的目的--E-AutoPIA是代表一个E-PIA来完成工作的智能代理。一个E-AutoPIA是一个初始化期望与本地或远程的电子社区中的其他E-PIA交互的任务的E-PIA。
APIA2.一个E-AutoPIA是一个被分派了至少一条的路线的E-PIA。
APIA3.一个E-AutoPIA只能从一个主E-PIA被发送,即执行一条路线。
APIA4.一个主E-PIA可以发送多个E-AutoPIA。
路线
I1.路线的目的--一条路线由一列要执行的一些交互指令组成。
I2.一条路线必须有一个名字。
I3.一条路线包含一组特权规则--这些规则必须被所有交互指令满足,并且又是为E-AutoPIA而定义的特权规则。
I4.一条路线包含一组传输特权规则--这些规则管理着被路线中的交互指令共享的任何E-PIA版本(或者在这种情况下的E-AutoPIA文本)的传输共享。这些传输特权规则还是为单个交互指令本身而定义的任何传输特权规则。在运行时,这些规则被复制,并且被放在将要被共享的E-PIA版本的特权规则中。
I5.一个路线包含一组零个或多个脚本--一个脚本只是一个以某些编程语言编写的可执行字符串。脚本能够控制交互指令何时及如何被执行。因此,脚本只是去完成编程者想要完成的任何处理的编程代码。然而,一个脚本能够用它的名字调用一个交互指令,并且把任何变量作为范围中的参数传递给它。只有路线或者超类路线的交互指令才可以从附加到相同路线对象上的脚本中调用。净影响(netaffect)是指交互指令可以以任何顺序被调用。当路线中没有脚本时,交互指令只能被顺序地调用。
I6.一条路线由一个或更多的交互指令组成--如果没有脚本,交互指令就被顺序地执行。
I7.一条路线可以继承一条现有的路线--子类路线继承父路线的规则、脚本和路线。
交互指令
II1.交互指令的目的--交互指令是引起E-PIA(实际是E-AutoPIA和E-PIA)之间的交互发生的整个系统中的单一点。每条交互指令描述将要发生的交互和可以发生的规则。还有一点是重要的,注意交互指令的执行是交换信息资产的唯一方法。
II2.每个交互指令是由以下部分组成的5个字节组
1)电子社区名字
2)交互协议名字
3)参数分配
4)用于要发生的直接共享的特权规则的集
5)用于要通过第三方(传输共享)发生的E-AutoPIA版本的共享的传输特权规则集。
6)最大交互数
II3.一个交互协议的执行根据运行时的输入参数值创建E-AutoPIA的一个版本。这个E-AutoPIA版本是被给出的、以及与要与之交互的E-PIA共享的E-AutoPIA--然而,如果所有输入参数值都是以前获得的E-PIA版本,则不生成一个E-AutoPIA版本。代替地,该信息是以最初获得的E-PIA格式向前传输。
II4.被共享的E-AutoPIA版本,其基本信息的每一条都已经用该E-AutoPIA的私有密钥加密了--当用于主E-PIA的信息被汇编时,这个加密在该E-AutoPIA的个人客户工作站上发生。随后,另外的E-PIA或处理能够利用在其证书中发现的E-PIA版本的公共密钥来解密该信息。
注意因为私有密钥从来不在服务器上,常用以一个E-PIA文本传输数据的输入或输出参数可能要求被严格地限制在丰富的表达式中,因为通常,一个表达结果将需要用私有密钥再加密。
II5.特权规则必须被要执行的交互指令满足--他们还是用于路线的规则集以及用于执行E-AutoPIA的规则集。
II6.传输特权规则被复制并且被放在由于交互指令的执行变成被共享的E-PIA版本的特权规则中。
II7.只有E-PIA的最大交互数将参与一个交互指令的执行--这个数值可以是无穷大。
II8.一个交互协议必须能够产生一个表示具有准备被填写的参数的交互指令的HTML格式。
II9.有一个特殊的“更新主”交互指令,它把E-AutoPIA中的最新信息更新到其主E-PIA中--一个隐含的“更新主”交互指令在路线终端被执行。注意这个特殊的交互指令要求该E-AutoPIA物理地访问它的主E-PIA。
阐明交互协议与交互指令之间的关系
一个交互协议实质上对一个交互指令维持一个模板关系。一个交互协议由要“被填写”的参数的一个签字表示,而类似的交互指令除了具有“已填写”的参数之外与交互协议是相同的。
交互协议与交互指令都是编写时的实体。交互协议表示由一个电子经纪提供的服务,并且是与一个电子经纪一起被编写的。交互指令是在E-AutoPIA的路线的构造期间被编写的。每条交互指令表示一个“被请求的交互”或交互协议的调用。
还有,图19显示了作为部分交互协议的特权规则。每个特权规则是一组规则对象。如前所述,每个规则是一个使用规则编译程序去处理的表达式字符串。为了使交互协议被执行,特权规则中的所有规则必须为真。如前所述,规则能够引用我自己(交互协议交互的提供者)和你自己(请求交互的E-AutoPIA)。还显示了参数对象具有验证规则对象。这些规则只能应用于被传进的实际参数。
图18还显示一些如具有特权规则的交互指令。当E-AutoPIA编辑者建立一条路线并且已决定哪些规则应该保持而不管交互指令引用的交互协议的特权规则的时候,他可以增加这些规则集。
电子社区
C1.电子社区的目的--一个电子社区为E-PIA和其他电子社区提供一个分组的概念。在这点上,一个电子社区还为分组的对象提供安全。
C2.一个电子社区是一个电子人--一个电子社区保持一个生命概念的电子都市的见解,因为其目的是共享信息和与一般的电子人交互。
C3.一个电子社区必须有一个名字。
C4.一个电子社区包含零个或多个E-PIA--这些E-PIA驻留在一起,因为就共享信息而言,它们共有同一目的。因此,寻找特定的E-PIA的E-AutoPIA将知道要访问哪个电子社区。
C5.电子社区可以包含其他电子社区以便它们能够被分层安排--每个被包含的电子社区依次地又可以包含一个或多个电子社区。然而,这个分层必须是严谨的,因为一个电子社区不能被多个父电子社区包含。
C6.每个电子社区包括电子社区已经决定使其可利用的电子经纪。
C7.每个电子社区不包含交互协议,因为它们不可以交互。
电子经纪
BR1.电子经纪的目的--所有的PIA内的交互都需要电子经纪。电子经纪保证了在一个交互中涉及的所有E-PIA都具有根据交互协议以交互被执行的方式进行交互的权利
BR2.每个电子经纪拥有一个或多个交互协议。
BR3.一个电子经纪包含执行它拥有的交互协议的子系统。
BR4.一个E-AutoPIA只能与这样的一个电子社区中的E-PIA进行交互,这个电子社区包含一个具有被该E-AutoPIA的当前交互指令确认的交互协议的电子经纪。
BR5.一个电子经纪必须为其每个交互协议产生一个唯一的可信任令牌。
BR6.交互指令只能通过从一个电子经纪获得相应的交互协议被编写。
BR7.电子经纪作为E-PIA与E-AutoPIA之间的交互的媒介,如下:
1)验证E-AutoPIA满足电子社区的特权规则。
2)验证E-AutoPIA具有一个对应于正被执行的交互协议的可解密的可信任令牌。
3)验证E-AutoPIA的特权规则。
4)验证E-AutoPIA的路线特权规则。
5)验证E-AutoPIA的当前交互指令的特权规则。
6)验证任何被传输交换的、将被作为输入或输出参数传递的E-PIA版本的特权规则。
7)调用对应于交互协议的实现的电子经纪的入口点--只有通过了(6)中的E-AutoPIA交互指令的的验证的参数才被传进来。
8)确定在交互中涉及的特定E-PIA集合--这是基于以下三条的:
a)通过上面的5的验证任务3。
b)通过电子经纪可执行程序内的一个电子都市API调用提供的一个附加选择规则。
c)根据a)和b)选择的E-PIA的特权规则。
9)电子经纪的实现被执行--如果任何失败发生了,交互指令不被成功地完成。
10)只有通过了E-PIA的交互协议的验证的参数才被传出。
BR8.每个电子经纪提供一个“交互协议目录”服务--这个服务答复一个产生的、描述由电子经纪提供的所有交互协议的HTML文档。
BR9.每个电子经纪提供一个“获得权利给交互协议(getRightsToInteractProtocol)”服务--该服务用可信任令牌来答复交互协议。重要的是要注意这个服务可以由电子经纪以任何方式执行。例如,该服务可以是想要交互协议权利的某人必须验证他是谁以及/或支付费用以获得特权的地方。电子经纪可以为任何理由拒绝答复一个可信任令牌。
BR10.可以直接地与电子经纪交互而不管它们所属的电子社区的电子社区特权--然而,与一个电子经纪的交互确实需要服从任何父电子社区的特权。
已经参照一个优选实施例描述和举例说明了本发明的原理,显然,可以在配置和细节上修改本发明而不偏离这些原理。这样,应该认识到详细的实施例仅仅是说明性的并且不应被看成是限制本发明。更确切些,我们要求可能落在以下权利要求及其等同物的范围和精神内的、本发明的所有这样实施例。
Claims (29)
1.一种计算机实现系统,用于通过提供安全的存储以及经由可信任处理和加密机制提供安全的信息交换,来安全地声明和实施信息保密和信息自确定权以及一个实体的责任,该计算机实现系统包括:
用于以一个个人信息代理的形式安全地存储实体的个人信息以便它仅可以由该实体或者可信任处理所访问的装置,所述个人信息是以加密的方式存储的;
可信任处理装置,其用于以一种安全的方式在实体之间交换一些或所有个人信息,以便阻止其他处理访问正在被交换的信息以及不是正在被交换的信息;
其中,所述可信任处理装置基于有关每个实体的个人特权规则的个人信息的交换,以致当每个或每组个人特权规则被递增地满足时允许对那些存储在实体的个人信息代理中的个人信息进行递增交换;
其中所述可信任处理装置还保证:在一个交换中所涉及的实体不知道每个其它实体的身份,除非与它们的身份有关的信息有意地被交换,并且不知道特定的个人特权规则失效的原因;以及
用于保证任何交换的个人数据以一种接收实体能够处理只有个人特权规则允许它处理的数据方式安全地传递给接收实体的装置。
2.根据权利要求1所述的计算机实现系统,其特征在于该实体的个人信息是由一个被安全地存储的密钥加密的,所述计算机实现系统有专有权利访问所述密钥,因此,具有专有能力为一个可信任和安全的处理解密所述个人信息。
3.根据权利要求1所述的计算机实现系统,其特征在于个人信息的递增交换发生在实体之间的一个单一的连续交换对话中。
4.根据权利要求1所述的计算机实现系统,其特征在于个人信息的递增交换发生在由任意时间分开的多次对话中,每个所述交换对话独立地由交换实体之一初始化,并且每个交换对话都包括对一组一个或多个个人特权规则的满足。
5.根据权利要求1所述的计算机实现系统,其特征在于所述用于安全地在实体之间交换一些或所有个人信息的可信任处理装置还包括一种装置,该装置用于提供一个初始化实体的个人信息与另一个信任实体的交换,该信任实体被用来在以前的交互中建立信任以便在一个不同的地方或在下一次交换信息。
6.根据权利要求5所述的计算机实现系统,其特征在于,所述用于在下一次提供可信任交换的装置还包括用于信任实体去提供一个可信任令牌的装置,该可信任令牌表示在将来的信息交互和交换中对初始化实体的信任。
7.根据权利要求6所述的计算机实现系统,其特征在于所述可信任令牌是双重加密的,首先由初始化实体的一个私有密钥加密,然后用信任实体的一个公共密钥加密,以至于保证只有信任实体能够用其私有密钥解密该可信任令牌而后用初始化实体的公共密钥来验证该可信任令牌实际上较早以前就提供给它了。
8.根据权利要求1所述的计算机实现系统,其特征在于还包括用于实施管理被交换的个人信息的所述向前传递的传输特权规则的装置,所述用于实施传输特权规则的装置还包括以一个或多种版本去复制个人信息代理的装置,每个复制的版本封装个人信息和用于在交换事务期间管理对个人信息的访问的特权规则,并且每个复制的版本能够根据其个人特权规则利用正在进行的动态交互或协商自治地与其他实体交互,但是其代表起源的实体。
9.根据权利要求1所述的计算机实现系统,其特征在于所述特权规则能够执行一般的处理功能或要求什么标准应该被满足,所述一般的处理功能包括用于允许接收实体具有处理被传递的个人信息的特权的交换货币价值的能力。
10.根据权利要求1所述的计算机实现系统,其特征在于所述用于以一个个人信息代理的方式安全地存储实体的个人信息的装置包括:
用于电子地安全编辑与封装个人信息作为表示实体信息资产的安全个人信息的装置,该个人信息包括一个或多个信息对象和一个或多个用于管理每个信息对象的可信任经纪代理及其可信任的向前使用的个人特权规则,所述个人特权规则通过计算机可读程序代码来实现,并且共同地管理一个个人信息代理是否将允许与另一个个人信息代理的交互以及特定的个人信息是否要被与其他的个人信息代理交换;
用来与所述个人信息一起封装一个或多个数字证书以便建立起源的实体作为个人信息的一个无可争议的来源或确证个人信息对象的可靠性的装置。
11.根据权利要求10所述的计算机实现系统,其特征在于还包括用于声明传输特权规则以管理被交换的个人信息的向前传递的装置,所述用于声明传输特权规则的装置还包括以一个或多个版本复制所述个人信息代理的装置,每个复制的版本封装所述一个或多个数字证书、个人信息对象以及用于在交换事务期间管理对个人信息对象的访问的特权规则,而且每个复制的版本能够根据其个人特权规则利用正在进行的动态交互或协商自治地与其他实体交互,但是其代表起源的实体。
12.根据权利要求11所述的计算机实现系统,其特征在于还包括用于保持每个试图和实际的安全交互以及如果需要的话在每个交互中的信息交换的一个安全审核跟踪记录的装置。
13.根据权利要求11所述的计算机实现系统,其特征在于还包括用于安全地与负责地支配和控制个人信息代理的复制版本而无论这些个人信息代理位于何处的装置。
14.根据权利要求11所述的计算机实现系统,其特征在于所述个人信息代理还包括多个用于管理特定的安全个人行为或者与其他个人信息代理的交互的交互协议。
15.根据权利要求14所述的计算机实现系统,其特征在于所述交互协议每个通过
代表特定的个人行为的计算机可读程序代码来实现,并且还包括:
一个或多个安全的特权规则,用于确定所述个人信息代理是否具有要开始信息交换所必需的权利;以及
一个或多个传输特权规则,用于管理任何被安全与信任地交换的个人数据的所述向前传递,借此所述个人信息代理确定:如果其信息对象被传递给以原始个人信息代理的另一个版本的形式出现的另一个实体,则该信息对象必须维持什么条件,以保护和实施原始实体的支配和控制。
16.根据权利要求1所述的计算机实现系统,其特征在于所述个人信息代理还包括一条或多条路线,每条路线包括用于指导所述个人信息代理的活动的交互指令。
17.根据权利要求16所述的计算机实现系统,其特征在于所述交互指令包括:
一个用于交互的目标或目的地可信任网络社区的名字;
一个规定了交互的预定交互协议;
一个允许所述预定交互协议被调用的参数目录表;
在所有交互指令上必须被检验和被满足的特权规则;以及
与封装的信息对象有关的传输特权规则,所述传输特权规则为原始接收实体后面的用户处理所述信息对象确定必要条件。
18.根据权利要求11所述的计算机实现系统,其特征在于还包括用于建立一个可信任网络社区的装置,该可信任网络社区用于多个电子个人信息代理成员去有效地维持共享的信息保密和信息自确定权利与责任各自地和共同地作为一个组合,以便申明和实施该社区的信息保密和自确定权,所述可信任网络社区包括:
一个可信任网络社区的名字;
安全的持久存储库,用于存储该可信任网络社区成员的个人信息代理;
活动的电子个人信息代理,期望安全、秘密和可信任地与可信任网络社区的一个或多个成员进行交互;以及
活动的电子个人信息代理,其不属于该可信任网络社区,但是期望安全、秘密和可信任地与该可信任网络的一个或多个成员进行交互;
其中所述可信任处理装置包括一个电子经纪,所述电子经纪构成可信任网络社区的一个特殊可信任电子个人信息代理成员,所述电子经纪代表社区成员充当第三方,用于使请求交互的活动或来访的电子个人信息代理去安全、秘密和可信任地处理电子个人信息代理成员的特权规则与交互协议,所述电子经纪还包括:
来访的电子个人信息代理适合与所述可信任的网络社区进行交互的特权或交换规则;
用于执行交互协议的装置,其包括用于一旦活动的电子个人信息代理发出请求就根据以下规则去安全地与信任地搜索和收集电子个人信息代理的多个子集的装置:
a)所述可信任网络社区的交换规则;
b)来自每个活动的电子个人信息代理的个人特权规则;以及
c)来自电子信息代理成员的特权规则;
一个交互协议目录,其包括由社区提供的公开交互协议的一个清单;以及
用于保持一个安全的核查跟踪的装置,该核查跟踪记录发生在活动的电子个人信息代理之间的交互,不管是该可信任网络社区的成员还是来自其他可信任网络社区的访问者。
19.根据权利要求18所述的计算机实现系统,其特征在于还包括用于独立地校验所述安全核查跟踪的装置。
20.根据权利要求18所述的计算机实现系统,其特征在于还包括一个计算机网络服务器,所述计算机网络服务器连接到其他可信任计算机网络服务器以致形成一个计算机网络化系统,该计算机网络化系统包括用于电子个人信息代理的可信任和安全的交换的装置,所述可信任网络服务器每个包括:
用于安全地分派和打包包含有数字证书的电子个人信息代理的计算机实现装置,该数字证书代表原始计算机网络服务器允许确认该电子个人信息代理是来源于它的计算机网络服务器;以及
用于一旦验证了所述的电子个人信息代理满足目的社区网络交互规则就使用所述的电子经纪的计算机实现装置。
21.根据权利要求20所述的计算机实现系统,其特征在于所述计算机网络是从包括因特网、有线远程计算装置和无线远程计算装置的组合中选择的。
22.根据权利要求18所述的计算机实现系统,其特征在于所述可信任的网络社区包含多个被附加包含的可信任网络社区,其中:
所述可信任网络社区对于被包含的社区是一个父社区;
所述被包含的社区每一个都是子社区;
所述子社区可以包含他们自己的多个子社区,形成一个分层的可信任网络社区结构;
所述子社区的成员资格需要主社区中的成员资格;以及
在一个子社区中的电子个人信息代理之间的安全与可信任交互需要满足主社区的所有规则。
23.根据权利要求18所述的计算机实现系统,其特征在于所述可信任计算机网络还包括一个可信任网络工具,所述可信任网络工具包括:
用于允许实体去安全地编辑和封装个人信息对象和用于管理个人信息的交换与处理的处理规则的计算机实现装置;
用于管理个人信息和用于管理所述信息的规则的计算机实现装置;
用于授权实体去安全地和负责地支配与控制所有所述实体的个人信息代理而不管它们位于何处的计算机实现装置;以及
用于安全地浏览所述实体的任何或所有电子个人信息代理的核查跟踪而不管其位于何处的计算机实现装置。
24.根据权利要求23所述的计算机实现系统,其特征在于所述可信任网络工具还包括用来向创作者指出由特权规则暗示的一个特殊搜索是快还是慢的计算机实现装置,该搜索的快慢取决于该搜索是否能被映射为一个数据库查询。
25.根据权利要求11所述的计算机实现系统,其特征在于所述个人信息代理还包括一个或多个可信任令牌,该可信任令牌可以被传递给另一个实体作为为将来的交互而预先建立的信任的标志。
26.根据权利要求1所述的计算机实现系统,其特征在于,还包括用于存储多个信息对象模板和传输特权规则模板的格式存储库,每个传输特权规则模板包括一组缺省的规则并且对应于一个预先规定的行为类型。
27.根据权利要求1所述的计算机实现系统,其中所述系统实现一个电子集市,该电子集市用于当声明和实施参与的实体的数字权利与责任时通过拍卖或直接出价来进行电子交易,所述数字权利和责任包括信息保密和信息自确定权利和责任,该电子集市包括:
一个电子个人信息代理结构,用于为成员提供实体-卖者或实体-买者去搜索、交互或共同磋商在价值交换中的共同和各自的个人信息处理规则;
一个电子集市电子经纪,用于安全地处理交易以保证在一个交易被处理之前交换规则被满足,同时在处理交易期间保持封装在电子个人信息代理中的个人信息的保密性;
一个商业活动调度器,用于利用所述的电子集市电子经纪处理到来的交易请求;
一个公共产品数据库,用于持久存储由所述电子集市电子经纪处理的产品信息;
一个可信任令牌处理器,用于存储和处理来自所述电子个人信息代理的公共密钥并且发布和验证由所述电子个人信息代理呈现的可信任令牌;以及
一个广告客户目录,用于存储和处理定购、产品信息和作为由交易请求发起的定单;以及一个私人活动数据库,用于存储广告客户未决的定购、详细目录和为执行交易所需要的信息。
28.根据权利要求27所述的计算机实现系统,其特征在于电子集市基于一种半实时的方式工作。
29.根据权利要求28所述的计算机实现系统,其特征在于电子集市还包括一种计算机实现装置,该装置用来汇集对同一产品的单位数量的单个定购,以便单位数量的买者和卖者不必找到对应的单个单位数量的卖者或买者就能够交易。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US2203596P | 1996-07-22 | 1996-07-22 | |
| US60/022,035 | 1996-07-22 | ||
| PCT/US1997/013309 WO1998003927A2 (en) | 1996-07-22 | 1997-07-22 | Personal information security and exchange tool |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| HK04108379.0A Division HK1065616B (zh) | 1996-07-22 | 2000-03-23 | 個人信息安全與交換的工具 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| HK04108379.0A Addition HK1065616B (zh) | 1996-07-22 | 2000-03-23 | 個人信息安全與交換的工具 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| HK1022968A1 true HK1022968A1 (zh) | 2000-08-25 |
| HK1022968B HK1022968B (zh) | 2012-06-29 |
Family
ID=
Also Published As
| Publication number | Publication date |
|---|---|
| HK1065616A1 (zh) | 2005-02-25 |
| WO1998003927A3 (en) | 1998-03-12 |
| US7289971B1 (en) | 2007-10-30 |
| US8195569B2 (en) | 2012-06-05 |
| EP0912954B1 (en) | 2006-03-15 |
| CA2261262A1 (en) | 1998-01-29 |
| EP0912954B8 (en) | 2006-06-14 |
| IL148925A0 (en) | 2002-09-12 |
| CN100371914C (zh) | 2008-02-27 |
| WO1998003927A2 (en) | 1998-01-29 |
| DE69735486T2 (de) | 2006-12-14 |
| EP0912954A2 (en) | 1999-05-06 |
| DE69735486D1 (de) | 2006-05-11 |
| IL128099A0 (en) | 1999-11-30 |
| CN1497453A (zh) | 2004-05-19 |
| ATE320634T1 (de) | 2006-04-15 |
| CA2261262C (en) | 2007-08-21 |
| IL128099A (en) | 2004-05-12 |
| US5987440A (en) | 1999-11-16 |
| CN1231039B (zh) | 2011-08-24 |
| US20090119222A1 (en) | 2009-05-07 |
| CN1231039A (zh) | 1999-10-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1231039B (zh) | 个人信息安全与交换的工具 | |
| WO1998003927A9 (en) | Personal information security and exchange tool | |
| EP3864610B1 (en) | Data collection and pattern analysis in a decentralized network | |
| US7814025B2 (en) | Methods and apparatus for title protocol, authentication, and sharing | |
| US20050234860A1 (en) | User agent for facilitating transactions in networks | |
| US20050038707A1 (en) | Methods and apparatus for enabling transactions in networks | |
| CN103198393A (zh) | 展示过程流以及作为万维网服务的安排控制器 | |
| TW491972B (en) | System, method, and article of manufacture for electronic merchandising in an e-commerce application framework | |
| EP1512101A2 (en) | Methods and apparatus for a title transaction network | |
| WO2002073364A2 (en) | System and method for providing secure transactions | |
| Jeong et al. | A study of application platform for smart contract visualization based blockchain | |
| EP1170926A2 (en) | Personal information security and exchange tool | |
| Jacobsen et al. | Component leasing on the world wide web | |
| US8275670B2 (en) | Electronic sales and contracting | |
| HK1022968B (zh) | 個人信息安全與交換的工具 | |
| US7093281B2 (en) | Casual access application with context sensitive pin authentication | |
| HK1065616B (zh) | 個人信息安全與交換的工具 | |
| CA2593362A1 (en) | Personal information security and exchange tool | |
| IL148925A (en) | Personal information security and exchange tool | |
| Tarannum et al. | Ensure security in supply chain with blockchain technology | |
| CN121414488A (zh) | 虚拟资源产品的处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品 | |
| Chen | YAVO: on-line trading system using mobile agents. | |
| WO2001016843A2 (en) | System, method and article of manufacture for providing external agents in an e-commerce application framework | |
| Jacobsen | Software Leasing on the Internet | |
| Xie | A study of developing secure and scalable business-to-business electronic commerce systems |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PC | Patent ceased (i.e. patent has lapsed due to the failure to pay the renewal fee) |
Effective date: 20150722 |