谈判是多方之间为共同的利益所进行的互动。各方在有利益交换 的情况下才有谈判。交易可能是买卖一个公司、买卖一个机构部分的 资产、筹集资金、共同开发、合并等。
这种交易常规的做法通常涉及到面对面的谈判或经过中间商的 谈判。人工拍卖以及招标系统也成为了决定货品价格或商品交换的一 个手段。
不幸的是，这些常规的做法很难撮合买家和卖家。比方说，买家 可能并不知道在市场上有多少潜在的卖家。尤其是如果卖家和买家不 在同一个地理位置上。一个在加州的买家可能不知道有中东卖家的存 在。类似的道理，卖家也有寻找潜在买家的局限。
另外一个面对面谈判的困难是买家和卖家的身份都会暴露给对 方。这点常常影响到谈判的结果。比方说，如果卖家知道买家是一个 又大又有名的公司，卖价可能会受到影响。因此，我们可以认为一个 在交易谈判中匿名披露公司资料的系统和方法是市场的迫切需求。
这里介绍的发明将提供这个优势以及在以下的描述和相关的数 字中解释的其它优势。
附图说明
图1，是我们所描述的运用谈判系统时电脑网络的图表展示。
图2，是功能性板块图表。展示根据描述而设计的系统的具体模 式。
图3，是我们所描述的针对简单固定价格买卖的设计。
图4，是描述拍卖模式的图表。
图5，是普通谈判交易的图表展示。
图6，是与所介绍相应的单方分类图表。
图7，展示与所介绍相应的代理商系统注册互动过程图表。
图8，展示与所描述相应的代理商在进行交易，回应要求以及披 露信息时的互动过程。
图9，是与所描述相应的提供信息要求以及披露信息的说明图表。
图10，展示与所介绍相应的准入网站管理和身份信息共享模式。
图11，展示与所介绍相应的准入网站管理以及数据信息共享的模 式。
图12，展示与所描述相应的含信息披露的普通谈判模式图表。
图13，展示与所描述相应的初次上市的操作流程。
图14，展示与所描述相应的中介操作流程

互联网为软件设计系统带来了新的机会，使买家和卖家以及仲裁 人能进行电子互动。为电子谈判而设计的软件的共同特点是他们能在 全球性的网络上展开对一个或多个谈判人，仲裁人以及中间商的支持 及协助。这里描述的发明是专注在商业交易特别是机构财政领域的交 易(合并、购置、投资以及资产剥离)，但是这里形容的技术也适用于 在网上进行的全球性的当身份及数据在交易中成为重要角色时的各种 商业交易。这里介绍的系统和方法描述了当潜在的买家和卖家能够实 行一种在不暴露各方真实身份的匿名的情况下逐步披露机构信息的技 术。那就是，各方能够在对方表达浓厚交易的兴趣的前提下逐步披露 机密信息。
图1展示了一个典型的与描述相应的实行谈判的系统网络100的 电脑网络。多方沟通是通过电脑网络102进行的。最著名的实行网络 是互联网。这里描述的技巧也适用于任何电脑网络。
图1演示了众多的卖家实体104的同时也演示了买家实体106。 在表1中还演示了中间商108。像在以下将作的详细解释中，一个卖 方实体104与中间方实体108在互联网上互动来设立卖方实体的帐户。 卖方实体104提供详细的有关该机构的信息。应该注意的是，不同的 多个卖方实体104事实上可以是各不相关的，并且不会涉及到同类的 交易。同样的道理，买方实体106通常也是没有关连并不会涉及到同 类的交易。卖方实体104及买方实体106可以是在不同的地理位置上， 涉及到不同的交易，拥有不同的组织结构(例如：合作关系、有限责 任公司、法人团体等等)。注册过程将会在以下作详细介绍。
“卖方实体”一词是用来指任何寻求出卖他们的部分或全部资 产；或寻求合并方的实体。在表1中演示的卖方实体104描述了一个 在卖方为达到进行电子交易的目的而操作的我们所指的电脑系统。为 方便的起见，系统被叫作卖方实体。类似的是，“买方实体”是指任何 寻求购买卖方实体的部分或全部资产，或者寻求与某个卖方实体合并。 在表1中演示的买方实体106表示了一个在买方为达到进行电子交易 的目的而操作的我们所指的电脑系统。“中间商”一词是用来指任何在 买方实体和卖方实体之间安排一个商业交易的实体。在房地产交易中， 房地产经纪人的操作就类似中间商一样，为卖家上市作准备或代表买 家审查卖家上市资料等。类似的形式，中间商108的作用就像中间人 一样，帮助卖方实体104准备上市或代表买方实体106审查上市资料。 具体来说，中间商108可指某个个体或公司的电脑系统。用另外一种 方式来表达，中间商108可指一个公司进行中间商操作的电脑软件编 程系统。受过使用系统100操作培训的个体也可实行像中间商108一 样进行有必要的上市数据的操作。这种操作将在以下的内容中作介绍。
选择的与卖方实体104有关的信息是放在一个被中间商108控制 的积极出售名单中。买方实体106可以搜寻积极出售名单来寻找可能 的购买机会。买方实体106可以使用搜寻选择标准来控制搜寻的结果。 比方说，买方实体106可以限定搜寻的标准为商业类型、某种商业规 模、地理位置限制等。某些关键字眼元标签可以与买家或卖家联系起 来来协助搜寻的过程。比方说，一个电子工厂可能有关键词元标签例 如CD，DVD，或类似的相关文档在搜寻的过程中协助潜在的买家。在 搜寻中使用关键词元标签是广为人知的技巧，在这里就不需要作详细 的解释。
买方实体106可以使用不同的文档名来储存搜寻结果。在另外的 一种情况下，一个买方实体106发出的搜寻要求可以被中间商108所 储存以便中间商以后继续作自动搜寻。如果一个新的卖方实体104的 条件与买方实体106选择的标准相匹配，中间商108可以自动给买方 实体寄一个匹配通知以显示符合条件的新卖方实体的存在。卖方实体 104也拥有类似的搜寻能力。
图2是一个功能性板块图表。展示中间商108的模式。中间商108 是在一个有着中央处理器120以及内存122的电脑系统里实施的。中 央处理器120可以和任何常规处理器配置，例如微处理器、微电脑等 等。中央处理器120的具体实施方法对操作系统100来说并不重要。
简单来说，内存122可以包括随机存取记忆体(RAM)、唯读记忆 体、快闪记忆体等等。内存122的具体实施方法对操作系统100来说 也不重要。通常说来，内存122包含了中央处理器120可执行的电脑 指南及数据。
中间商108也包含了一个网络接口控制器(NIC)124来控制与互 联网102的互动。NIC124可以会是任何一个常规接口，例如电话的调 制解调器、电缆调制解调器、DSL调制解调器、卫星调制解调器等等。 NIC 124的具体实施方法对操作系统100来说不重要。
中间商108也包括了数据储存结构128。128可能会是内存122 或单独装置的一部分，例如硬盘驱动器、光盘驱动器等等。数据储存 结构128可能会以常规数据库软件的形式而被安置在数据库中。
像我们在以下会详细介绍的一样，中间商108包括一个可以被买 方实体106搜寻到的，含有与卖方实体104相关信息(参见图一1) 的积极出售名单130。积极出售名单130可以是在内存122、数据储存 库128或单独的数据储存结构的一部分。
中间商108还包括含有卖方实体104以及买方实体106之间过往 交易详情的交易历史储存区域132。像在以下将作详细介绍的一样， 交易历史可能会在帮助正在进行的谈判取得像以往类似的成功、设立 价位参数等方面很有用处。
在图2中还显示了卖方代理134，买方代理136以及融资代理 138。代理关系是代理人受另一方的授权委托而代表后者。像在以下将 作详细介绍的一样，卖方代理134是作为一个软件模块来代表买方实 体104的。也就是，卖方代理134代表卖方实体104按照中间商108 以及卖方实体所设立的一系列规定来运作，以及向潜在的买家披露信 息。卖方实体104可以授权卖方代理134披露某些在谈判过程中与卖 方实体有关的信息。卖方代理134会只披露被卖方实体104许可披露 的信息。授权可能在买方提要求之前进行，或可能需要卖方实体104 的明确授权。卖方代理134在全过程都代表卖方实体104来运作。
买方代理136代表买方实体106进行类似的操作。也就是，买方 代理136代表买方实体106按照中间商108以及买方实体所设立的一 系列规定来运作，及向潜在的卖家披露信息。买方实体106可以授权 买方代理136披露某些在谈判过程中与买方实体有关的信息。买方代 理136会只披露被买方实体106许可披露的信息。授权可以在买方实 体106提要求之前进行，或在买方代理136的特别授权要求下进行。 买方代理136也可以运行于中间商108软件模块来执行。
应该注意的是，图2展示的是买方代理134以及买方代理136的 单例。单个卖方代理134可以为单个的卖方实体104或像图1所指的 多个卖方实体进行必要的代理工作。因为卖方代理134是一个软件模 块，无论一个或多个卖方实体104之间的竞争或内在的冲突，对中间 商来说都不存在利益冲突问题。另外，中间商108可以为卖方实体134 执行多项任务，例如卖方代理134和卖方实体104之间的一对一往来 信件。类似的是，单个买方代理买136可以代表一个或多个买方实体 106。因为买方代理136是一个软件模块，它可以在没有利益冲突的情 况下为多个买方实体106执行代理任务。虽然图2只展示单个买方代 理，那些技术也同样可以运用在多项买方代理事例中，也可以在中间 商108中运用。
融资代理138可以代表一方或多方金融机构(没有展示)在为交 易筹资方面进行代理工作。融资代理138的角色是代表金融机构为交 易筹资。金融机构可以是任何能够为交易出资的实体，例如银行、风 险投资组织、投资组织等等。系统100不限制融资代理138所代表的 金融机构的形式。
在图2中说明的各部分可以实施在多种不同的系统架构中。比方 说，卖方代理134、买方实体136和融资代理138可以是包含在内存 102中的模块。但是，在图2中，他们是被作为单独的功能板块图表 来显示的，因为每一个图表显示的是单个的功能。此外，虽然图2中 各要素是以中间商108的比例来演示的，那些分布式系统架构的技术 同样可以运用在系统100中。也就是，功能板块中的各个比例部分可 以具体地位于一个或多个包含中间人108的电脑系统中。另外，中间 人108中的多个实例可以与分布在多个实例中的各个部分的电脑模块 进行操作。
图2的各部分是被一个总线系统合并在一起的，可能是地址总线、 数据总线、电源总线、控制总线等等。为方便起见，在图2中的各个 总线称为总线系统140。
那些有关系统100的技术可以在分布式系统中实行，其中卖方代 理134可以在每个卖方实体104中实行。简单地说，一个单独的实例： 买方代理136可以在每个买方实体106中实行。在这样一个分布式的 系统里，每一个卖方代理134代表其卖方实体104操作，每个买方代 理136代表其买方实体106操作。与卖方实体104和买方实体106相 关的公司数据可以就地储存在卖方实体或买方实体里，或者储存在一 个共同的位置，例如中间商108。
那些熟悉电脑系统架构的人会知道多个其它的实施方案也是可 行的。系统100不受具体架构实施的局限。像在以下作的详细介绍中 所说的一样，无论具体系统架构是怎样，公司的信息仍然是只有在卖 方实体104或买方实体106的授权下才会披露。
目前的电子谈判模式概况
我们首先简单介绍一下电子谈判以及讨论摘要记载各方之间互 动情况的软件模式。关于假冒身份的概念将会在随后作介绍。系统100 包括一个可以寻找真实身份线索的机制，并且这个系统还可以在一个 多方谈判的情况下管理数据和身份的披露。
一直以来，研究人员都在研究促成商业谈判的系统。大多数的系 统将谈判的部分界定为可以由“参与方”在谈判中为了达成“最终交 易”或“买卖”而修改的“可磋商交易”。谈判过程中的五个关键因素 结果是：
1，一笔交易-可以是各个阶段的交易，例如谈判阶段、买家 或卖家的最后报价或是一个已经成交的交易。
2，参与方-例如买家、卖家、拍卖方、经纪人等等。
3，参与方发出的关于修改交易的信息。例如投标的信息、买 或卖的报价信息以及价格更改的信息等。
4，说明在参与方发送了信息后，每个阶段的交易是如何改变 的流程。
5，在交易改变时发送给参与方的信息。
像在这里详细说明的一样，中间商108提供一个交易的平台来执 行每一个步骤以促成商业交易。此外，平台是在交易各方的“交易规 则”范围内进行编码的。
谈判互动模式-限定阶段机器
谈判传统上被定型成为一个限定阶段机器(FSM)。FSM是指交易 的各个阶段。当“可磋商”或“不可磋商”算作交易的不同阶段时， 不同的投标或询问价格并不构成交易的不同阶段。他们只是在交易中 从现阶段转到另一阶段的企图。FSM的输入术语是一系列可能从参与 方处发出的信息，这些信息以成对的方式表达<参与方，输入-信息 >，而且参与方是发送信息方。比方说，一个买家投的标是被展示为，< 买家，投标>。一个卖家接受投标并结束拍卖是被展示为<卖家，结束 拍卖>。
FSM输出术语是一系列的发送给参与方的信息。这些信息也同样 以成对的方式表达《参与方，输出-信息》，在那里，参与方组成 一个所有参与方的子参与方来接受输出的信息(外向的信息会放在双 角括号来与输入信息相区别)。谈判过程的流程设计在FSM的阶段交易 规则里面。以下的部分描述了一项最简单的交易形式，一项没有各方 之间谈判的，固定价格的交易。
固定价格销售
图3展示了一个固定价格销售阶段的图表。在图3中展示的这些 阶段分别是：交易样板(DT)，出售要价(Offer)，谈判中断(NA) 以及成交(D)。出售要价的信息是卖家设立的一个能被买家接受以成 交或能被卖家抽回以中断谈判的信息。
拍卖销售
在拍卖中可以观察到一种比较复杂的谈判情形。图4显示了简单 公开呐喊和秘密投标拍卖的谈判过程。作为一个固定价格的出售，卖 家以设立一个招标来销售。但是，与固定价格销售模式不同的是，这 个招标不会立刻过渡到最后销售阶段(例如成交阶段)。当拍卖在招标 阶段时，买方可以输入投标价，结果仍然是过渡到招标阶段。
在一个公开呐喊的拍卖中，这个过渡会向所有买家发出包含了当 时最高投标的外向信息。而在秘密投标的拍卖中则没有这类回馈的信 息。谈判阶段以卖方结束拍卖而告终。结束拍卖前提是基于预先商定 的规则，例如预先商定的时间或在一定的时间内没有结果，又或者是 二者兼而有之。成交的前提是起码有一个投标者而且最高的投标价超 过底价(如果投标者有一个指定价)。
迈向一个更广义的谈判模式
在图3和图4中展示了一系列从简单到中度复杂的模式。从另一 个方面来说，真正的谈判更复杂。在图5中显示的两方谈判的模式基 本上是一个拍卖及固定价格销售的混合体。它是一个从拍卖开始，然 后要求报价(RFQ)的采购模式结合体。在那里，买家和卖家可以开始 一项可谈判的交易，也就是图5中的ND阶段。这个交易包含卖家要价 和卖家投标，并且各方都可以调整他们的位置。像前面讨论过的，要 价的改变或投标价格的改变并不会改变当时的谈判阶段。也就是，如 果没有哪一方作最终报价，该过程就一直保持在ND阶段。从这个阶段 开始，买家或卖家都可以设立他们的最后报价，B和S分别报价，类 似图3的报价阶段。在图3，如果卖家先作最后出价，他可以收回或 买家可以接受。如果买家先作最后报价，他可以收回或卖家可以接受。
以上介绍的广义上的谈判模式概括了商业互动中最为人所知的 过程，叫作定价。最终的目的是通过成功的谈判来制定双方都能接受 的价格。
在电子谈判中使用软件代理
迈向电子谈判模式的第一步是界定用于捕捉各方互动的要素。就 像电子代理人在真实世界实体中操作。这个过程是很容易通过使用塑 造各交易方的软件代理来理解的。
软件代理是能委派(方面)一项任务的程序或程序模块。他们与 传统的软件不同，因为他们是个人化的、不停运转的以及半自治的。 这些特点使软件代理对大量的信息以及过程管理工作来说很有用处。 软件代理构成了信息广、过程多的电子谈判系统的基础。我们专注在 两种类型的谈判代理方面-买方代理136(参见图2和卖方代理 134)。以下，我们将简单地讨论第三方代理的角色-融资代理138。 中间代理(买方和卖方的)主要是促成谈判中各方之间的合作。因此 基于他们代表方，他们被允许使用软件功能。比方说，买方代理136 (参见图2)可以使用使他们为买方实体106做代理工作的功能。
买方代理136在谈判中代表买方实体106提供以下的服务-
●    协助买方界定他的购买条件
●    运用数据库及其它的参考资源来建立潜在目标的名录。
●    代表买方接触目标公司以确定他们考虑被收购的诚意。
●    寻找协助买方分析目标公司的信息。
●    协助有关交易的融资安排。
●    协助评估、构建以及完成收购交易。
虽然在图2显示的是一个单独功能的模块，买方代理136可以包 括多个采集、精简和管理上述数据和服务的程序。每个登录到系统100 的买方实体106会从一群劳工线中被指派给一个买方代理136。劳工 线是指一个系列的同步进行的软件程序。劳工线同时服务于买家和/ 或卖家。除了管理方的数据结构(见下面的买方模式)外，这个买方 代理136可以进行以下的功能-
●    功能-搜索、浏览和比较收购对象
●    买方模式-数据结构采集
○    身份
○    买方信息
■    行业
■    规模
■    地点
■    融资能力
■    营销材料
■    公司财务报表
■    监管机构声明(法律文件)
■    人力资源
○    收购标准
○    公司搜索
卖方代理134(见图2)代表卖方实体104(见图1)在谈判中提 供以下的服务-
●    确定要出售公司的价值
●    准备描述要出售公司情况的资料袋
●    确定合格的准买家并将他们排名
●    代表卖方在保密的情况下接触准买家
●    协助卖方评估报价以及谈判交易条款
●    在卖方有关法律、地产及税务建议方面促成交易
卖方代理134和买方代理136在他们使用潜在的代理基础设施上 是类似的。不过，在功能上，他们的程序的编制是对卖方来说很重要 的采集、精简、管理数据和服务。例如以下-
●    功能-添加、更新上市资料和上传出售方抵押品
●    卖方模式-数据结构采集
○    身份
○    卖方上市资讯
■    营销材料
■    公司财务报表
■    监管机构声明(法律文件)
■    人力资源
■    排除买家的名单
融资软件代138(见图2)与买方代136在他们的基础设施 的使用方面以及他们的功能方面很接近。融资者通常是股权(公司的 股份)的买家，因此与买方代理有很多共同点。在作出投资决定时， 他们基本上是与买方代理人136使用相同的工具。
数据模型
数据模型试图采集所有的对评估至关重要的元素，公司以及其资 产的买进和卖出。图6展示了系统界定的各代理商之间的关系。应该 指出的是图6以及其它在目前介绍的图，都是使用统一模式语言(UML) 制作来展示操作系统100的。使用UML目的是帮助描述该系统。但是， 使用UML不是为了用来作为任何当前披露的局限范围。UML在名称上 是人所共知的，也不需要在此作详细讨论。
如图6所示，所有对买方实体106、卖方实体104、他们各自的 代理(例如买方代理136和卖方代理134)以及融资者(如地点、行 业、范围)的共同数据要素被概括为一个法律实体。因此，所有的代 理被界定为最高层的法人实体以及沿袭下来的所有数据要素和功能。
此外，数据模型允许采集每种具体类型代理的要素，买方和卖方 数据结构储存公司的详细信息，如财务、市场营销材料、知识产权和 人才信息。具体来说，卖方代理134(见图2)和买方代理136可能包 含内部数据结构来分别储存与卖方和买方有关的公司数据。另外，这 类数据可以被隔离并储存在中间商108里的数据储存结构128。数据 储存的具体物理位置对成功地操作系统100来说并不是至关重要。受 控的准入以及信息披露对成功的谈判来说是很重要的。以下将作详细 介绍。
如图6所示的互动要素控制买家和卖家之间的信息流动。互动标 识是一个由系统100生成的数字来识别某一特定的互动。要求提供信 息类型是指被一方请求的信息类型。这个要求可能包括需要不同类型 的企业数据，也可能包括需要一方身份信息的要求。该要求类型采集 的信息将其与某特定项的互动结合起来。数据类型是指数据可以被要 求提供或交付的形式。比方说，要求提供的数据可以是几种形式，如 音频、视频、文字媒体类型等。数据类型概括数据的特定形式。在具 体表达卖方实体104或买方实体106时，可以包含一个视频剪辑或其 它的多媒体演示。例如，卖方实体106可以包含一个制造设施、实验 室等以及介绍重点人物的视频剪辑。具体形式的视频剪辑或多媒体演 示可以因业务的类型而变动。
交易方身份以及在谈判中的披露
如前面指出的，代理商各自在谈判中执行一个特定的功能。代理 商在互动时代表他们的一方交换数据(见以上的数据模型)。在所有的 数据中，对谈判来说最重要的是身份资料。在互动中维护交易方的隐 私及安全是至关重要的。系统100中包含了指导在交易各方之间作这 种交换的规则以及包含了保持隐私及一个允许安全地共享身份信息机 制的过程。
真实身份在任何互动中都拥有战略价值。例如，在一个买方和卖 方的谈判中，知道买方身份可能会抬高东西的价格。因此，系统100 包含了一个在交易方做生意时，只披露交易时必需的信息过程。在所 有数据交换时，交易各方的身份是保密的。匿名是至关重要的，并且 身份只有在被要求提供以及有关方授权的情况下才做披露。
隔离身份和互动的机制是设立在系统里面的，在下面图7中，我 们将其称为身份控制系统150。身份系统控制150在交易方愿意透露 真实身份之前，用假身份来保护其真实身份。身份控制系统150的设 计也可以简化提供身份要求及身份透露。
当卖方实体(见图1)或买方实体106开始联系中间商108时， 就开始了一个注册过程。所有的卖方实体104和买方实体106都会被 要求用身份控制系统150来注册。这就启动了注册经理152来收集相 关数据，并指定卖方实体104或买方实体106设立卖方代理134和买 方代理136，以各自代表卖方实体和买方实体。注册经理152还指派 给所有的注册方一个系统界定的标识。在典型的情况下，标识包含与 注册方相关的字母数据。标识使系统以及所有的用户能识别每一个实 体。例如，标识的一个部分，如前缀MA，可以识别一个使用标识 MA-345534的合并/收购实体，因为MA是那种实体的标识(合并/收购 实体)。而数字部分的标识则可随机分配以保护实体的身份。从另外一 个角度来看，整个字母数字序列可随机产生或使用安全算法产生以保 护实体的真实身份。这些标识是公开的并可被所有各方看到。因此， 系统标识其实就是数字匿名。卖方代理134和买方代理136在所有的 互动中必须使用这些标识来认证及被系统认可。身份经理154进行假 名的编造及管理工作。
典型的互动，尤其是在谈判的早期阶段是以交易方的假名来进行 的。图8显示了身份身份控制系统在最初各方信息交换时的操作。图 8表明了两方代理，代理A和代理B之间的信息交换。图8中的代理A 可以理解为卖方代理134(见图2)或买方代理136。同样道理，代理 B的角色可以是卖方代理134或买方代理136。例如，图8展示通过交 易经纪160，买方代理136要求卖方代理134透露财政收入报表或人 事信息的互动。在这些互动的生命周期里，身份或代理的名称(如卖 方代理134和买方代理136)以及他们代表的各方(图1的卖方实体 104和买方实体106)都继续保持系统赋予他们的假名。在这个情况下， 交易也并不是完全匿名，因为无论是买方代理、卖方代理以及他们的 互动，都使用虽然假但是持续相同的身份。
正如前面所指出的，注册代理(无论是卖方代理人134或买方代 理人136)可以要求系统100提供与谈判有关的数据。所有这些要求 都被记录交易经纪160所记录并传送给披露及申请引擎162。披露引 擎162找到拥有数据(如财务报表)的代理，然后向核心数据服务器 提交“要求披露”申请。核心数据服务器进行进入含有被要求提供信 息的数据结构的操作。如前所述，包含所要求资料的数据结构可以被 作为卖方代理134(见图2)、买方代理136或中间商108的数据储存 结构128的一部分来储存。那个控制被要求提供的信息的代理可以被 指定为“拥有”代理。拥有代理可以接下来配置引擎以批准获取、披 露其中的一部分，或拒绝该项要求。因此披露引擎162基本上是要求 方和拥有方的中介。
如前所述，交易史记录130(见图2)储存所有与谈判过程有关 的数据。像上面提到的，交易经纪160记录所有对资料提供的要求。 对提供资料的要求的反应而获得的交换资料，可以作为交易史130的 一部分来储存。
在谈判周期的这段时间里，当交易方互换与交易有关的资料、所 有的条件逐渐吻合而谈判向前推进的时候，各方需要披露他们的真实 身份。披露引擎162也为中介代理(可以是卖方代理人134，买方代 理136，或两者兼而有之)提供一个机制，通过使用身份经理154来 询问各方的真实身份。根据要求提供资料类型的不同，核心数据披露 引擎162将该功能委派给身份经理154或核心数据服务器164。正如 先前讨论的，披露各方的真实身份需要各实体方的授权。
图9展示了披露引擎162在申请和披露阶段的图示。代理(无论 是卖方代理人134或买方代理人136)可以要求提供资料，这就将阶 段设置推进到了披露阶段。在披露阶段，任何一方可以披露他们自己 的信息(包括但不限于身份)，伴随着每次的信息披露，谈判逐步向成 交靠近。最后，如果双方都满意的话，设置转移到下一个阶段(阶段 N+1)。要注意的是，“N+1”和“N+2”阶段是用来笼统地指一系列的阶 段中的下一个阶段，基于某个阶段的图表不同，阶段也不同。(见图2 至图5)
披露过渡期可以发生在谈判的任何阶段。身份控制系统150使这 个披露可配置实行。以下的部分将对构成共享身份的基础规则作详细 介绍。
共享和指定披露权益
系统100为谈判代理(通常是中间人)界定了基本的“交往规则”。 以下的规则支配他们在要求披露资料和共享身份时的互动。
1，代理拥有与他代表的实体有关的数据(一个代理能取得其所 有资料信息)。其中包括身份信息。
2，代理可以被授权披露数据。但是，除非拥有方明确授权， 代理也可能不能披露数据。授权可能是允许一项或多项的数据元素。
3，买方和卖方代理通常在披露他们直接拥有的数据方面是受 到限制的。因此，买方代理136可能只能披露其代理的买方实体106 的数据。
4，代理可以要求其它的代理披露数据。
5，只有在数据的直接拥有人的允许下，代理才可以分享间接得 到的数据。例如，如果卖方代理134通过一个“合法披露”的途径得 到买方实体106的身份，他也许不可以将此信息与其他代理(如融资 代理138)分享，除非他从买方代理136处得到一个单独许可。换句 话说，数据共享政策的实施与身份控制系统150发号施令如下-只 有直接拥有者的中介可以披露或授权披露他们拥有的数据。
实施身份分享政策
正如上面所讨论的，每个法律实体(买方或卖方)与其安全数据 结构相联系来获得其真实身份以及信息往来系统制作的假身份。身份 控制系统150(见图7)也为所有已注册的实体保持着一份身份获取控 制清单(iACL)。对于任何特定的参加谈判的实体，其iACL其实就是 列举那些可以获得其真实身份代理的名单。中介都有权修改与他们代 表的交易方有关联的名单。
图10是一个采集法人实体及其iACL的模型。法律实体在谈判的 情况下只可以有一个iACL。如前所述，法人实体是指买方、卖方或融 资方。这些不同实体的真实身份和假身份在前面也讨论过。这里的证 书是指数码证书。这个行业的技术都承认，数码证书在交易中提供了 一个证明身份的方法。该证书将身份与一对可以用来作为在电子互动 中作事实上签名的电子按键相结合。像前面讨论过的，iACL确认实体 (例如卖方代理134)和列举哪些代理可以获得他们的真实身份。
实行数据获取控制
图10展示了一个操作系统100控制获取真实身份的模型。图11 表达类似控制获取其它类型的公司数据的功能。与身份获取控制名单 (见图10)不同，系统100包含了数据获取名单(dACL)，该名单控 制获取在授权的情况下可能以逐步的方式披露的公司详细资料。
在通常的交换情况下，卖方代理134或买方代理136扮演要求提 供资料的角色并以要求提供一个数据的形式启动互动。在图11要求者 的数据元素为已经注册了的买方实体106或卖方实体104储存一个记 录。这个要求由系统100传递到信息的拥有方。为了回应要求，拥有 者通过适当的修改其资料获取控制名单(如果还没有允许获取)来允 许或拒绝他方获取其公司详细资料。这个获取准入在交易完成前或直
●    作出初步调查
●    起草卖方上市文件
●    储存买方搜寻条件
●    起草买方上市文件
正如上面所讨论的，系统100提供搜寻功能来使中介人能够用电 子方式搜寻上市机构的资料以寻找匹配的目标。像上面描述的购买和 销售过程，系统提供的搜寻机制使搜索结果可以被搜寻方以相应的文 件名单独储存和提取。系统还允许持续自动地新上市公司与已存在的 搜寻标准相比较的搜寻。如果一个新上市的公司与搜寻标准匹配，一 个信息，如一封电邮，就可能自动地产生并寄送到发起搜寻方。
中间商108为上面描述的系统100和卖方实体104(见图1)及 买方实体106库存创建了各自的上市资料。这种技术可以叫作“推” 模式，因为卖方实体104“推”其数据给中间商108。同样，买方实 体106把其数据推给中间商108。但是系统100也包含一个“拉”的 模式以创造更多的机会。例如，一个交易专家能为其代表的实体感兴 趣的信息而监察积极出售名单130(见图2)。交易专家可以是个体或 公司实体的一部分。在一个实例中，交易专家代表卖方实体104并协 助起草上市销售文件。类似的交易专家可以代表买方实体106。在一 个拉的模式中，交易专家可以监察积极出售名单130来确认其所代表， 或想代表的公司的公司所感兴趣的上市出售信息。例如，一个买方实 体106可能会对收购一个加州的DVD工厂有兴趣。买方实体106可以 在积极出售名单130中直接输入数据或使用一个交易专家。
不同的交易专家搜寻积极出售名单130可以发现买方实体的上市 资料。在一个推的模式中，卖方实体104会已经在积极出售名单上登 记并与买方实体106的标准匹配。在一个拉的模式，交易专家可能会 发现符合买方实体条件但是还没有在积极出售名单上登记的DVD工 厂。在这个拉的模式里，交易专家可能会寻找符合买方实体条件的公 司并招聘一个卖方实体来使用系统100将其资料上市。因此，交易专 家“拉”卖方实体进入系统100。
到拥有者选择拒绝其未来的准入之前都保持活跃状态。图11展示了被 要求提供详细的公司数据获取控制的静态数据结构。每个互动都绝对 是在要求方和拥有方之间进行的。互动可以导致拥有方通过在数据获 取控制名单结构中设立一个准入来允许一项或多项资料的获取。
因此，该dACL的操作像是一个被信息拥有者雇佣的过滤器，允 许经过选择地获取其储存在公司详细资料结构中的信息。最后，图11 也展示了当交易完成时，系统可以选择提醒信息拥有者采取适当的行 动，例如拒绝要求者进一步的获取。所有上述行动是运用图11中一种 或一种以上的数据结构。在图11中介绍的数据结构支持数据获取控制 台，将所有的与获取控制和逐渐披露数据的行动结合起来，一起汇成 一个单一的用户界面。
在这一节中，我们将以前描述的广义谈判模式经修改后包括进了 披露阶段。我们运用这个模式来使合并、收购以及公司融资领域合理 化。
改良的广义谈判模式
图12显示了在图5中介绍的广义谈判模式中运用披露。在这个 例子中，披露是谈判过程中的最后阶段并且在达到“可能性定价”的 情况下发生。从这个阶段开始，买方或卖方可以要求另一方披露资料。 如果要求被允许并且有更多的披露要求，阶段设置回到披露阶段以允 许谈判在使用最新披露信息的情况下继续。当双方都满意披露的信息 时，阶段设置转移到下一个阶段，成交。但是，如果可能，在没有被 要求提供的信息的情况下，如果某一方拒绝披露，FSM转移到部分披 露(PD)阶段来允许谈判继续。
在这里描述了系统100使用前述的各种成份和模型简化一系列的 合并及收购(M&A)领域互动。在“交易”中使用一双图13和14描述 的UML需要遵循一系列的步骤。
图13描述了中间代理(如卖方代理134和买方代理136)在开始 和系统100互动来进行以下的活动时要遵循的步骤：
拉的模式也适用于买方实体。就是一个交易专家可能看到一个卖 方实体在积极出售名单130(见图2)上的上市资料，并试图招聘一个 还没有进入系统100的买方实体(例如，还没有上积极出售名单)。因 此，交易专家“拉”买方实体进入系统100。由此，系统100可以被 有效地利用以吸引买家和卖家进入市场。
一旦目标已经确定，谈判可以通过中介在各方之间展开。随后的 图14描述了双方代理(如卖方代134和买方代136)之间通过系 统100进行的谈判。以下是按顺序的描述：
●    作出初步调查
●    记录查询反应
●    第二轮调查
●    记录查询反应
●    提议阶段
●    接受提议阶段
●    获得初步协议
●    周密考虑阶段
图13至14的顺序图表描述了代理在单纯化的单个买家-单个 买方代理设置下的互动。这些特定的技术可以理解为身份控制系统 150(见图7)能够支持更复杂的与多方同时发生的买方-卖方互动。 这个可能包括，通过举例方式，多个买方实体106(见图1)追求一个 卖方实体104，或一个买方实体追求多个卖方实体。系统100也可以 允许多个买方实体106联合起来与一个或多个卖方实体104谈判。此 外，在图13至14里的步骤只是一个互动典型方案的大纲。例如，数 据和身份披露步骤可以在该排列组合中的任何阶段。
谈判达成交易及结束
成功的谈判导致成交并产生了在各方参与的互动中记录下来的 重要文件。最后的“结束”阶段是以谈判代理之间达成初步协议来体 现的。在这一节中，我们专注在身份控制系统150为采集这个初步协 议组成部分所拥有的各种形式。
初步协议组成部分
典型的协议囊括以下的信息
●    购买资产的文件
●    设定责任
●    商定的价格
●    结束交易
●    准入
●    非竞争条款
●    新闻稿
●    公开声明
●    专有期
●    接管
●    担保
●    意外事件
在谈判中迈向最后步骤-结案时，身份控制系统150(见图7) 包含了一个或多个能允许采集任何或所有上述元素的预先包装好的协 议范本。进入谈判最后阶段的各方将有能力将这些范本按照他们的谈 判情形来进行相应的设定。这些定制的范本可以与其中授权的各方共 享。
同样，范本也提供给谈判发起过程的第一步，即不披露协议。这 个协议指导授权代理如何共享信息。
跟进结案以及交易历史
在初步的协议达成后，各方将交易推入委托代管阶段。身份控制 系统150提供的数据结构收集里程碑以及在委托代管过程中定下的最 后结案日期。这使得交易能够被追踪到完成阶段。
交易完成后，谈判过程中产生的数据被交易系统删除并添加到交 易历史130(见图2)里。交易历史130像保险箱一样运作，采集的有 趣数据如买家和卖家以及中间商的评分等级。
因此，系统100允许多方之间的复杂谈判，包括必要的防范措施 管理数据和谈判进展的披露。使用自动软件代理(如卖方代理134和 买方代理136)适当地保护了谈判过程中的机密。系统100中的灵活 架构允许中央实施的运用，举例来说，中间商108(见图1)或分布实 施中的软件代理或部分软件代理居留在多个电脑系统中，例如与代理 方代表的实体有关系电脑系统中。
在谈判过程的每个点上，都可以保证各自代表实体们执行的代理 只进行经过他们授权的工作。这个由身份控制系统150提供的安全系 统保证各方在谈判过程中使用匿名。这个使用假身份追踪谈判的能力 允许各方之间的连续性的讨论。
前面介绍的范例描述了其中包含的或相连的，与其它组合不同的 不同组合。如此描述的架构被理解位只是示范性的，事实上，其它很 多能达到相同功能的架构都可以被采用。从概念上来说，任何为达到 同样功能的组合安排是有效地“联系着”来达到预期的功能。因此， 这里的任何两个组合结合起来以达到一个特定的功能，可以看成是与 其它的“有关联”以达到预期的功能、无关的架构或中间的组合。同 样地，任何相关的两个部分可以看作是互相“可联合操作”，或“可成 对操作”以达到预期的功能。
当这里呈现的发明被具体地描述和展示时，以下的情况对那些擅 长在这里介绍的技术的人来说是很明显的：改变或修改可以在不偏离 这项发明及其大方向的基础上进行，因此，附加权利要求是包含在它 们所有的改变和修改范围内，就像包含在发明里的真正精神及范围里 一样。此外，发明应该被理解成为是由附加的权利要求所单独界定的。 它将被那些行业中人在广义上、这里所用的术语方面所理解，特别是 附加权利要求(如附加权利要求主体)通常是试图使用“开放”术语 (如术语“在包括”应该被理解为“在包括但不限于”；术语“拥有” 应该理解为“起码拥有”；术语“包括”应该被理解为“包括但不限 于”等)。那些同业人员还应进一步理解，如果权利要求中具体数字意 图被复述的话，这个意图将在权利要求中被明确地详细复述，如果这 种意图不存在的话，复述也不存在。举例来说，为了帮助理解，以下 的权利要求可以包含使用介绍性的句子“至少一个”和“一个或一个 以上”来介绍权利要求的复述。但是，使用这类的句子应该不被解释 为意指权利要求的介绍被冠词“a”或“an”限制其只包含一个此类的 发明或任何具体权利要求。甚至当同样的权利要求包含介绍性句子“一 个或一个以上”或“起码一个”和冠词“a”或“an”(如“a”和/或 “an”应该被典型地理解为“起码一个”或“一个或一个以上”)；介 绍权利要求复述时使用的冠词也应被作同样的理解。另外，即使如果 介绍的权利要求复述中的一个具体数字被明确地复述，行业中人会认 识到这类复述应该典型地被理解为“起码那个复述的数字”(如直接的 “两个复述”的复述，如果没有其它修饰的话，典型的意义是起码两 个复述，或两个以上的复述)。
因此，除了权利要求，发明是不受限制的。
权利要求书(按照条约第19条的修改)
1. 直接的在卖方实体和买方实体之间的电子化财务数据逐渐交 换方法，包括：
接收卖方实体输入的数据来设立卖方实体账户，包括卖方实体 身份资料和卖方实体的联络信息；
起草卖方实体上市文件，卖方实体上市文件包括与卖方实体有 关的公司信息；
作为卖方实体上市资料的一部分，起草标准化的卖方实体公司 描述资料；
在积极出售名单上刊登卖方实体上市资料；
接收买方实体输入的数据来设立买方实体帐户，包括买方实体 身份资料和买方实体的联络信息；
接收买方实体关于对卖方实体上市资料查询的要求；
接收卖方实体有关对买方实体查询要求回应的决定；
如果卖方实体对买方实体查询要求的反应是认可的话，披露首 次为买方实体配置的一套卖方实体资料；
在以下的情况下重复披露一套配置的卖方实体资料：如果收到进 一步的买方实体要求，并且收到卖方实体对进一步买方实体要求作出 的回应，由此向买方实体逐步披露卖方实体在此之前没有披露给买方 实体的附加资料；
接收买方实体或卖方实体的提案；
接收对提案的反应；
如果对提案的反应表明了接受提案意向的话，为买方实体或卖方 实体起草一个初步的接受协议；并且
将卖方实体从积极出售名单上除名。
2. 权利要求条款1中，积极出售名单上不包含卖方实体的身份 资料，条款还包括在不需要向买方实体证实卖方实体的身份以及不需 要向卖方实体证实买方实体身份的情况下，自动将买方的查询要求转 送给卖方实体。
3. 权利要求条款1中的买方要求不包含买方实体身份资料，条 款还包括在不需要向卖方实体证实买方实体身份及向买方证实卖方实 体身份的情况下，向买方实体自动披露配置的数据集。
4. 权利要求条款3，还包括接收卖方实体选择的与卖方实体有关 部分的公司信息而组成的配置数据集。
5. 权利要求条款1，还包括一旦确定买方实体的身份，允许买方 实体进入积极出售名单。
6. 权利要求条款5里的积极出售名单包括相关的买方实体排除 数据，条款还包括：
包括买方实体的身份和买方实体的排除数据；以及
如果在比较买方实体身份和买方实体排除数据后，发现两者匹配 的话，禁止买方实体获取卖方实体在积极出售名单里的上市资料。
7. 权利要求条款1中接收卖方实体输入资料包括接收表明卖方 实体公司有权上市的授权声明。
8. 权利要求条款1中在准备积极出售名单的初期阶段，不包含 卖方实体身份数据。
9. 权利要求条款8，还包含接收卖方实体向买方实体披露卖方实 体身份资料的授权。
10. 权利要求条款1，还包含如果卖方实体对买方实体要求的决 定是回应的话，接收卖方实体针对买方实体需要而配置的数据选择集，
11. 权利要求条款1里，买方实体要求在最初阶段不包含买方 实体的身份资料。
12. 权利要求条款11，还包含接收买方实体向卖方实体披露买 方实体身份资料的授权。
13. 权利要求条款1，还包含接收买方实体向卖方实体披露的买 方实体数据选择，并向卖方实体披露经选择的买方实体数据。
14. 权利要求条款1，还包含接收卖方实体向买方实体披露的卖 方实体数据选择，并向买方实体披露经选择的卖方实体数据。
15. 权利要求条款1，还包含如果卖方实体的对买方实体要求回 应的话，买方实体的附加要求。附加的买方实体要求包括买方实体资 料披露给卖方实体以及来自卖方实体附加的要求。
16. 权利要求条款15，还包含接收在附加的买方实体资料提供 要求下，买方实体选择披露给卖方实体的买方实体资料。
17. 权利要求条款1，还包含披露卖方实体数据给买方实体以便 买方实体对卖方实体进行尽职评估，以及披露买方实体数据给卖方实 体以便卖方实体对买方实体进行尽职评估。
18. 权利要求条款1中的积极出售名单是一个包含了与卖方实 体和买方实体有关的数据结构。
19. 权利要求条款18中的数据结构包含所有的卖方实体输入数 据，而积极出售名单只包含卖方实体输入数据的一个有选择的部分。
20. 权利要求条款1中的买方实体包括两个买方实体共同协作 接收买方实体输入数据，其中包含接收为两方买方实体接收的买方输 入数据。
21. 权利要求条款21，还包含在交易历史储存结构中储存与卖 方实体、买方实体以及与卖方实体和买方实体之间交易有关的数据。
22. 权利要求条款21，还包含为进一步的交易所用，从交易历 史储存结构中调出的数据。
23. 销售一个或多个卖方实体给一个买方实体的电子交易条款， 包括：
从每个不同的卖方实体中调出卖方实体输入数据来为多元化的 卖方实体创建卖方实体帐户，每个卖方实体帐户各自包括卖方实体的 身份数据和卖方实体的联络信息；
为多元化的卖方实体起草卖方实体上市文件，每个卖方实体上市 资料包括与各自的卖方实体有关的公司信息；
为每个多元化的卖方实体创建作为卖方实体上市资料一部分的 标准化卖方实体公司描述数据。
为每个多元化的卖方实体在积极出售名单上刊登卖方实体的上 市资料；
接收买方实体输入数据，创建买方实体帐户，包括买方实体身份 数据和买方实体联系信息；
接收买方实体关于提供起码多元化卖方实体上市资料的要求；
如果起码一个卖方实体决定回应买方实体的要求，为起码一个卖 方实体披露给买方实体预定的卖方实体资料；
接收买方实体或起码一个卖方实体的提案；
接收对提案的反应；
如果对提案的反应是接受提案的话，为买方实体和起码一个卖方 实体起草接受的初步协议；并且
为起码一个上市的卖方实体从积极出售名单上除名。
24. 权利要求条款23中起码一个卖方实体包括两个卖方实体。
25. 卖方实体对一个或多个买方实体销售的电子交易条款，包 含：
储存来自卖方实体的卖方实体数据，卖方实体数据包括卖方实体 身份数据和卖方实体联系信息以及与卖方实体有关的公司信息。
作为卖方实体上市文件的一部分，为卖方实体起草标准化的卖方 实体公司描述文件。
在积极出售名单上刊登卖方实体的上市资料；
从多元化的买方实体处接收买方实体输入的数据，为各自的买方 实体创建买方实体帐户，包括各自的买方实体身份数据和买方实体联 系信息；
从起码一个买方实体处接收买方实体关于提供卖方实体上市资 料的要求；
从起码一个买方实体处接收卖方实体关于回应买方实体要求的 决定；
如果卖方实体回应起码一个买方实体要求的决定是允许的话，向 起码一个买方实体披露一套卖方实体的数据；
接收从起码一个买方实体或卖方实体的提案；
接收对提案的反应；
如果对提案的回应表明接收提案的话，为买方实体以及起码一个 卖方实体起草初步协议；并
将卖方实体从积极出售名单上除名。
26. 权利要求条款25中起码一个买方实体包含两个买方实体。
27. 卖方实体和买方实体电子交易条款，包含：
储存来自卖方实体的卖方实体数据，包括卖方实体身份数据和卖 方实体联系信息以及与卖方实体有关的公司信息；
储存来自买方实体的买方实体数据，包括买方实体身份数据和买 方实体联系信息；
接收买方实体关于对提供卖方实体上市资料的要求，卖方实体上 市资料包括卖方实体数据的一部分；
接收卖方实体关于回应买方实体要求的决定；
如果卖方实体回应买方实体要求的决定是允许的话，向买方实体 披露附加部分的卖方实体数据；
重复接收买方实体要求和接收卖方实体决定的步骤；并且
只要卖方实体对买方实体要求的决定是允许的话，向买方实体披 露附加部分的卖方实体数据。
28. 权利要求条款27，还包含接收来自买方实体或卖方实体的 提案以及接收对提案的回应。
29. 权利要求条款28中的回应是指对提案的接受，条款还包含：
起草买方实体和卖方实体接受提案的协议；并且
将上市的卖方实体从积极出售名单上除名。
30. 权利要求条款27中的电子交易是获得卖方实体以及与收购 卖方实体有关的卖方实体数据。
31. 权利要求条款27中的电子交易是为卖方实体融资以及与卖 方实体融资有关的卖方实体数据。
32. 权利要求条款27中电子交易是合并卖方实体与买方实体以 及合并有关的卖方实体数据。
33. 权利要求条款27中的电子交易是获得部分卖方实体以及与 收购卖方实体有关的卖方实体数据。
34. 权利要求条款27中的回应是指回绝提案，条款还包含结束 对披露附加的卖方实体数据的授权。
35. 权利要求条款27中卖方实体对上市时需要的标准化卖方实 体公司描述的数据部分有选择。
36. 权利要求条款35中起码一个部份的卖方实体数据包括视频 数据。
37. 权利要求条款27中卖方实体的决定是回应买方实体要求， 回应的决定是在收到买方实体要求提供有关卖方实体上市资料之前作 的，其中卖方实体数据的附加部份在收到买方实体的要求时自动地披 露给买方实体的。
38. 权利要求条款27中卖方实体选择披露给买方实体的卖方实 体数据的附加部份。
39. 权利要求条款38中卖方实体决定是对买方实体要求的回应， 并在收到买方实体关于要求提供卖方实体上市资料之前作的。其中卖 方实体数据的附加部份是在收到买方实体要求时自动地披露给买方实 体。
40. 权利要求条款27，还包含在审查卖方实体上市资料时储存 买方实体数据以作为对审查卖方实体上市资料的回应。
41. 权利要求条款40，还包含对审查卖方实体上市资料的回应 而招聘买方实体时储存买方实体数据以回应买方实体招聘行为。
42. 权利要求条款27，还包含审查买方实体上市资料时储存卖 方实体数据作为对审查买方实体资料的回应。
43.权利要求条款42，还包含了为回应审查买方实体上市资料 而招聘卖方实体时储存卖方实体数据作为对招聘卖方实体的回应。
44.销售卖方实体给买方实体的电子交易条款，包括：
向数据储存结构提供卖方实体数据以刊登在积极出售名单上，卖 方实体数据包括卖方实体的身份资料以及卖方实体联系信息和与卖方 实体有关的公司信息；
接收买方实体关于卖方实体上市资料查询的要求；
向买方实体的要求提供回应以授权披露卖方实体数据中的附加 部份给买方实体或禁止披露卖方实体数据的附加部份给买方实体；
重复接收买方实体要求和接收卖方实体回应的步骤；并且
只要卖方实体回应是授权披露卖方实体数据的附加部份给买方 实体的话，向方买实体披露卖方实体数据中的附加部份。
45. 权利要求条款44中起码一个部份的卖方实体数据包括视频 数据。
46. 销售卖方实体给买方实体的电子交易条款，包括：
监察卖方实体刊登在积极出售名单上的数据，刊登的卖方实体数 据包括储存部份的卖方实体数据以及包括与卖方实体有关的公司信 息；
发出买方实体关于提供卖方实体上市资料的要求；
如果卖方实体授权的话，接收储存卖方实体数据的附加部份；并 且
在卖方实体授权披露储存的卖方实体的附加部份数据给买方实 体时，重复发出买方实体要求和接收储存的卖方实体数据附加部份的 步骤。
47. 权利要求条款46中起码一个部份的卖方实体数据包括视频 数据。
48. 控制向买方实体销售卖方实体的电子交易内容的电脑可读媒 体，被处理器造成：
储存来自卖方实体的卖方实体数据，包括卖方实体身份数据和卖 方实体联系信息以及与卖方实体有关的公司信息；
储存来自买方实体的买方实体数据，包括买方实体身份数据和买 方实体联系信息；
接收买方实体关于提供卖方实体上市资料的要求，卖方实体上市 资料包括部分的卖方实体数据；
接收卖方实体关于回应买方实体要求的决定；
如果卖方实体回应买方实体要求的决定是允许的话，向买方实体 披露附加部份的卖方实体数据；
重复接收买方实体要求和接收卖方实体决定的步骤；并且
在卖方实体对买方实体要求的回应是允许的情况下，向买方实体 披露附加部份的卖方实体数据。
49. 条款48的电脑可读媒体，还包括导致处理器接收来自买方 实体或卖方实体提案的说明以及接收对提案的回应。
50. 条款49的电脑可读媒体中的回应是指接受提案，电脑可读 媒体还包括导致处理器运行的说明，对
为买方实体或卖方实体起草接受协议；并且
除去卖方实体上市资料。
51. 条款49的电脑可读媒体里的回应指对提案的拒绝，电脑可 读媒体还包括导致处理器结束授权披露卖方实体数据附加部份的说 明。
52. 条款48的电脑可读媒体里的卖方实体选择为卖方的上市而 提供的标准化的卖方实体公司描述数据部份。
53. 条款52的电脑可读媒体里的卖方实体决定是对买方实体要 求的回应并是在收到买方实体关于提供卖方实体上市资料的要求前作 出的，电脑可读媒体还包括更多的导致处理器在收到买方实体要求时 自动披露附加部份的卖方实体数据给买方实体的说明。
54. 条款48的电脑可读媒体中卖方实体选择披露给买方实体的 卖方实体数据附加部份。
55. 条款54的电脑可读媒体中的卖方实体决定是对买方实体要 求的回应，并且是在收到买方实体关于提供卖方实体上市资料的要求 之前作出的，电脑可读媒体包含更多的导致处理器应买方实体要求自 动向买方实体披露附加部份的卖方实体数据。
56. 卖方实体和买方实体之间的交易使用的电子交易系统包括：
最初的数据结构配置来接收和储存信息；以及
卖方代理模块配置给：
储存与在第一数据结构中的卖方实体信息；
在积极出售名单上刊登卖方实体上市资料，卖方实体上市资料包 括来自第一数据结构中卖方实体信息的一部份；
接收买方实体关于提供卖方实体上市资料的要求；
如果回应买方实体的授权是允许的化，披露在第一数据结构中附 加部份的卖方实体信息作为回应买方实体的要求；并且
重复接收买方实体要求并向买方实体披露第一数据结构中的附 加部份的卖方实体信息的步骤，前提是卖方代理要获得回应买方实体 要求的授权。
57. 系统条款56中的卖方代理在收到买方实体要求之前被授 权披露附加部份的卖方实体信息，卖方代理应收到的买方实体要求自 动披露附加部份的卖方实体信息。
58. 系统条款56中的卖方代理在接收买方实体要求时经过进 一步配置来与卖方实体沟通，由此获得卖方实体授权来披露附加部份 的卖方实体信息。
59. 系统条款56中买方实体要求包括卖方实体身份提供的要 求，卖方代理在收到买方实体要求时被进一步配置来与卖方实体沟通， 由此获得卖方实体的授权披露卖方实体的身份。
60. 系统条款56，还包含：
第二数据结构；和
买方代理项目模块，配置给：
储存在第二数据结构中的与卖方实体有关的信息；
查询积极出售名单来确认卖方实体的上市资料；
发出有关卖方实体上市资料的买方实体查询要求；
如果卖方代理被授权回应买方实体要求的话，从第一数据结 构中接收附加部份的卖方实体数据以回应买方实体的要求；
如果买方代理被授权回应卖方实体要求的话，接收卖方实体 有关买方实体的要求，并披露来自第二数据结构中的买方实体数据部 份以回应卖方实体要求。
61. 系统条款60中买方代理在收到卖方实体要求之前被授权 披露部份的买方实体信息，买方代理在收到卖方实体要求时自动披露 买方实体部份的信息。
62. 系统条款60中的买方代理在收到卖方实体要求时被进一步 配置与买方实体进行沟通，由此获得买方实体授权来披露买方实体的 部份信息。
63. 系统条款60中的卖方要求包括要求提供买方实体的身份， 在收到卖方实体要求时买方实体代理被进一步配置来与买方实体沟 通，由此获得买方实体授权披露买方实体的身份。
64. 系统条款60中的第一和第二数据结构是单一数据结构的 一部份。
65. 系统条款60里的买方代理查询积极出售名单后产生一个 搜寻结果，系统还包含储存搜寻数据结构配置来接收和储存搜寻结果。
66. 卖方实体和买方实体之间的电子交易系统包含：
接收和储存信息的第一数据结构配置；以及
买方代理项目模块配置给：
储存与在第一数据结构中买方实体有关的信息；
查询积极出售名单来确认与买方选择的搜寻条件相配排名 第一的卖方实体上市资料。
发出买方实体要求提供有关排名第一的卖方实体上市资料 的附加数据；
如果排名第一的卖方实体代理被授权回应买方实体要求的 话，接收附加的卖方实体数据以回应买方实体的要求；
接收卖方实体关于提供买方实体数据的要求；并且
如果买方代理被授权回应卖方实体的要求的话，披露来自第 一数据结构的买方实体数据的一部分以回应卖方实体的要求；
67. 系统条款66中的买方选择搜寻标准是从一组搜寻标准中 选择出来的，包括卖方的地理位置，卖方的规模或卖方的行业类型。
68. 系统条款66中的买方选择的搜寻标准包含关键词搜寻术 语。
69. 系统条款66中买方代理查询积极出售名单产生搜寻结果， 系统还包含搜寻储存数据结构配置来接收和储存搜寻结果。
70. 系统条款69中的第一数据结枸和搜寻储存数据结果是单 一数据结构的一部分。
71. 系统条款66中的买方代理被配置以预定的时间间隔重复查 询来确认额外的与买方选择的搜寻标准相配的卖方实体。
72. 系统条款71中的买方实体被进一步配置以查询积极出售 名单来寻找符合买方选择的搜寻标准的额外的卖方实体，并向买方实 体发出自动通知。