专利名称：个人信息验证程序、方法及装置的制作方法
技术领域：
本发明涉及一种具体用于电子商务交易的电子文档和个人信息验证程序、方法及装置，当通过多个实体(entity)分发电子文档时，其可以保证文档的原始性并可以验证对电子文档作出修正的人的身份。
背景技术：
已广泛采用电子结算系统，其中卖方在万维网上建立网站，用户通过选择期望购买的产品而后输入信用卡号和个人信息而进行结算。
万维网通常称为推式万维网，用户在没有访问目标地址时不能读取其内容。因此，即使实际上卖方建立了网站，如果期望购买产品的人不知道该网站的地址，则该人也不能购买虚拟商店中的所述产品。
因此，近年来，中间商(例如，负责中间商服务器的人或实体)建立网站，卖方与该中间商签定合同以在中间商的网站上开设各卖方的称为虚拟商店的网页。
由此，有购买愿望的人能够通过从他或她自己的终端(以下称为有购买愿望人的终端)访问中间商的网站，而访问期望中间商的虚拟商店。因此，有购买愿望的人可以访问各种虚拟商店。另外，卖方也可以享受的优点是即使在没有分发卖方的网站地址时，有购买愿望的人也可访问虚拟商店。
对于所述虚拟商店中的结算，通常使用信用卡。在使用信用卡结算的情况下，还需要访问信用卡公司的服务器。然而，为了简化购买手续，要求有购买愿望的人输入结算所需的个人信息，并添加电子签名以证明该有购买愿望的人在中间商的特定网页中进行的输入。接收到个人信息的中间商向结算有关的各交易人(例如，信用卡公司、卖方等)发送带有电子签名的个人信息。
另外，在结算之后，信用卡公司生成添加有该信用卡号和钱数的详细支付单，然后将该详细支付单发送给卖方。
这里，要求卖方将来自中间商的个人信息与从信用卡公司转来的钱数进行核对，并检查所存的钱是否正确。
传统上，可以这样进行核对将在从信用卡公司传送来的详细支付单中所记录的信用卡号和钱数与在结算时经由中间商获得的个人信息中包含的信用卡号和钱数进行核对。
然而，仅卖方和中间商彼此联系。中间商不能参与由卖方进行的对所传送的个人信息的管理。因此，恶意卖方泄漏个人信息是可能的。
具体地说，当个人信息包含诸如信用卡号的高风险信息时，信息泄漏的风险成为严重问题。
另一方面，传统上还在中间商服务器上从个人信息中删除信用卡号，然后添加代替卡号的个人号码。但是，由中间商修改信息是困难的，因为已向个人信息添加了电子签名而作为一整体，并且该电子签名表明个人信息是由有购买愿望的人他/她自己输入的。
作为克服所述困难的措施，需要有购买愿望的人在输入个人信息时添加期望号码。然而，有购买愿望的人并不知道由其它有购买愿望的人已经添加的其它号码。因此，有购买愿望的人可能添加与由另一有购买愿望的人所添加的相同的号码。因此，有购买愿望的人不能使用这种期望号码作为识别号码。
作为克服这种问题的措施，有购买愿望的人检查输入到中间商服务器的期望号码。然而，当有购买愿望的人输入了相同号码时，会增加要求有购买愿望的人再次输入号码的操作，从而有购买愿望的人的手续将增加。
发明内容
鉴于上述背景，本发明的目的是提供一种个人信息验证程序、方法和装置，如果中间商试图隐藏一部分数据，则所述程序、方法和装置可以验证隐藏数据的人和生成隐藏部分之外的其它部分的人，并且即使在卖方不使用信用卡时，所述程序、方法和装置也可以在各结算的钱数与使用信用卡所存的钱数之间进行核对。
根据本发明的一方面，为了解决上述问题，控制可以与安装在结算机构中的结算机构服务器进行通信并可以访问用于存储与结算有关的信息的存储设备的计算机，以执行将接收到的信息存储在所述存储设备中；当接收到第一版本的个人信息和第一版本的验证信息时，将所述信息传送给结算机构服务器，所述第一版本的个人信息包括表示购买愿望的信息、以及用于识别结算机构和识别有购买愿望的人的识别信息，所述第一版本的验证信息可以验证所述第一版本的个人信息的各项目的创建者。还控制所述计算机以执行将接收到的信息存储在所述存储设备中；在所述结算机构服务器传送了其中向所述第一版本的个人信息添加了结算号码的第二版本的个人信息、以及可以验证所述第二版本的个人信息的各项目的创建者的第二版本的验证信息之后，在从所述结算机构服务器接收到这些信息时，生成其中擦除了用于识别有购买愿望的人的所述结算机构的识别信息的第三版本的个人信息，并生成可以证明所述第三版本的个人信息的各项目的创建者的第三版本的验证信息，并且将所述第三版本的个人信息、以及存储在所述存储设备中的所述第一、第二和第三版本的验证信息传送给产品卖方的卖方装置。
图1是根据本发明实施例的个人信息验证系统的系统结构图。
图2是根据本发明实施例的验证机构服务器的结构图。
图3是根据本发明实施例的中间商服务器的结构图。
图4是根据本发明实施例的结算机构服务器的结构图。
图5是示出了根据本发明实施例的在验证机构与传送装置之间的公钥登记处理的流程图。
图6是示出了根据本发明实施例的添加电子签名的信息的传送和接收处理、以及接收装置的验证处理的流程图。
图7是示出了根据本发明实施例由所述系统进行的结算处理的流程图。
图8是示出了根据本发明实施例由所述系统进行的结算处理的流程图。
图9A和图9B是示出了根据本发明实施例的由有订货愿望的人的终端生成的订货单信息的第一版本的示意图。
图10是示出了根据本发明实施例的利用中间商服务器的在结算期间的订货单生成处理的流程图。
图11A和图11B是示出了根据本发明实施例的由中间商服务器生成的订货单信息的第二版本的示意图。
图12A、图12B和图12C是示出了根据本发明实施例的从中间商服务器传送至结算机构服务器的信息的示意图。
图13是示出了根据本发明实施例的由所述系统执行的结算处理的流程图。
图14A和图14B是示出了根据本发明实施例的利用结算机构服务器生成的订货单信息的第三版本的示意图。
图15是示出了根据本发明实施例的利用结算机构服务器生成的支付单信息的示意图。
图16是示出了根据本发明实施例的由所述系统进行的结算处理的流程图。
图17A和图17B是示出了根据本发明实施例的利用中间商服务器生成的订货单信息的第四版本的示意图。
图18A、图18B、图18C、图18D和图18E是示出了根据本发明实施例的从中间商服务器传送至卖方终端的信息的示意图。
图19是示出了根据本发明实施例的其中在卖方终端的存储设备(未示出)中预先存储有电子签名的项目的对应表的示意图。
图20是示出了根据本发明实施例的通过卖方终端进行的验证处理的流程图。
图21是示出了根据本发明实施例的其中利用卖方终端的验证处理生成电子签名的对应信息的数个版本的示意图。
图22是示出了根据本发明实施例的其中通过卖方终端的验证处理生成所述版本的项目的对应信息的数个版本的示意图。
图23是示出了根据本发明实施例的其中通过卖方终端的验证处理生成电子签名的项目的对应信息的示意图。
具体实施例方式
下面将参照附图详细地说明本发明的个人信息验证程序、方法及装置的优选实施例。
首先，将参照图1来说明本发明的个人信息验证系统的结构。
图1是根据本发明实施例的个人信息验证系统的系统结构图。
在图1中，附图标记1表示互联网，而附图标记2表示有购买愿望人的终端。有购买愿望的人通过操作该有购买愿望人的终端2而能够访问万维网并输入个人信息。
附图标记3表示用于管理电子签名信息的验证机构服务器。如所知道的，电子签名技术使得能够通过传送由传送人用私钥加密了的信息，并通过由接收人获知累积在验证机构服务器3中的传送人证书，使用该证书中所包含的公钥进行解码，而根据解码结果确定是否是合法的人进行了传送。由于该技术需要确保证书的合法性，因此存储有用户的公钥的验证机构服务器3通常以这种方式安装。如图2所示，该验证机构服务器3包括存储有各用户的公钥的公钥DB(数据库)31、响应于请求而发放证书的证书发放单元32以及用于通过互联网1进行通信的通信设备33。
附图标记4表示用于执行中间商的网站(未示出)中的处理的中间商服务器。如图3所示，该中间商服务器4包括存储网站处所显示的各页的数据的网站DB 41；文档管理DB 42，用于存储来自有购买愿望人的终端的个人信息以及与均将稍后说明的结算机构服务器6与卖方终端8之间传送和接收的信息；网站TB 43，其通过利用网站DB 41的信息而输出网站的信息；文档管理TB 44，用于文档管理DB 42的访问控制；添加中间商的电子签名的签名单元45；以及通过互联网1进行通信的通信设备47。
另外，附图标记5表示与中间商服务器4进行通信以允许中间商操作中间商服务器4的中间商终端。
附图标记6表示例如安装在作为结算机构的信用卡公司中的结算机构服务器。如图4所示，该结算机构服务器6包括存储有各种信息的文档管理DB 61、对文档管理DB 61进行访问的文档管理TB 62、验证添加到所传送信息的电子签名的验证单元64、以及通过互联网进行通信的通信设备65。
另外，附图标记7表示结算机构终端，负责结算机构的人通过该结算机构终端来操作结算机构服务器6。
附图标记8表示产品卖方的卖方终端。
下面将说明如上所述构成的个人信息验证系统的处理操作。
首先，在说明作为本发明的特征的结算处理之前，将说明在本实施例中在各装置中的电子签名处理。
电子签名是这样的技术在传送装置中预先存储有私钥、对应于该私钥的公钥被登记在公共验证机构服务器中、并且在使用私钥对信息进行加密而将信息传送至远方用户的情况下，当接收到该信息的远方用户从验证机构服务器获知传送装置的公钥并且能够使用相同的公钥而再现所述信息时，验证所述信息是从传送装置合法地传送的。
首先，将参照图5中的流程图来说明在验证机构与传送装置之间的公钥的登记。
在图1的实施例中，有购买愿望人的终端2、虚拟商店服务器4、结算机构服务器6和卖方终端8都被构成为电子签名的传送装置，并且均使用相同的程序来添加电子签名，但有购买愿望人的终端2和卖方终端8的用户直接执行所述程序，而虚拟商店服务器4和结算机构服务器6的用户通过虚拟商店终端5和结算机构终端7执行所述程序。因此，在所述程序的说明中，将这些装置统称为传送装置。
首先，当传送装置的用户通过操作传送装置而输入了证书发放请求信息时(S1001)，传送装置就传送输入给结算机构服务器3的证书发放请求信息(S1002)。
通过通信设备33接收到该信息(S1003)的验证机构服务器3的证书发放单元32生成私钥和与该私钥相对应的公钥(S1004)，并生成包括所生成的公钥的证书信息(S1005)，并且将所生成的证书信息存储至公钥DB31。
之后，证书发放单元32控制通信设备33，并通过互联网将所生成的私钥和证书传送至已传送了证书发放请求信息的传送装置(S1007)。
接收到该信息(S1008)的传送装置将所接收的私钥和证书存储至其存储设备(S1009)(在中间商服务器4的情况下为签名单元45中的存储区(如图3所示)，在结算机构服务器6的情况下为签名单元63中的存储区(如图4所示)，并且在有购买愿望人终端2和卖方终端8的情况下为未说明的存储区)，以完成其处理。
接下来，将参照图6来说明根据该实施例的添加有电子签名的信息的传送和接收处理、以及接收装置的验证处理。
由于有购买愿望人的终端2、虚拟商店服务器4、结算机构服务器6和卖方终端8也可以作为电子签名的接收装置使用，因而为便于说明，这里将实际传送所用的装置定义为传送装置，而将用于接收所述信息的装置定义为接收装置。
首先，当传送装置的用户向一定信息添加了电子签名后向传送装置输入了传送该信息的指示时(S2001)，传送装置使用存储在存储区中的私钥对所指示的信息进行加密(S2002)，然后将所述信息传送至接收装置(S2003)。
接收到该信息(S2004)的接收装置从验证机构服务器3获得发送者的证书(S2005)。接着，接收装置使用所获得的证书中包含的公钥，执行对从传送装置接收的信息的解码处理(S2006)。接收装置确定是否通过该解码处理对所述信息进行了解码(S2007)。当已对信息解码时，接收装置基于从传送装置传送的信息已经得到了证明(S2008)而对该信息进行存储(S2009)。
相反，当不能对所述信息进行解码时，接收装置确定所述信息不能被证明为从传送装置传送来的信息(S2010)，并且执行向其用户的通知处理，例如表示不能证明所述信息的显示(S2011)。
接下来，将说明通过该实施例的系统进行的结算处理。
对于电子签名的处理，假设各装置执行用于电子签名的程序。另外，还假设有购买愿望的人控制有购买愿望人的终端2以访问中间商的网站(即，服务器4)，并且在作为中间商服务器4的虚拟商店处发现了期望产品。
首先，在图7的流程图中，当有购买愿望的人向有购买愿望人的终端2发出指示以表明期望购买产品时(S3001)，有购买愿望人的终端2将购买愿望信息传送至中间商服务器(S3002)。通过通信设备47接收到该信息(S3003)的中间商服务器4的网站TB 45访问网站DB 41，提取购买表格信息(S3004)，并将所提取的信息传送至有购买愿望人的终端2(S3005)。
接收到(S3006)该信息的有购买愿望人的终端2显示该购买表格(S3007)。
当看到该购买表格的有购买愿望的人向该购买表格输入了个人信息时(图8S3008)，有购买愿望人的终端2对所输入的个人信息的各项目使用单向散列函数等而获得散列值(S3009)。有购买愿望人的终端2还针对所有个人信息添加有购买愿望的人的电子签名，并且还执行处理以针对在S3009中获得的各项目的散列值添加电子签名(S3010)。(通过前述处理执行电子签名处理。)在该实施例中，假设如图9A和图9B所示，通过前述的处理输入了“姓名”、“地址”、“产品名”、“钱数”和“卡号”作为有购买愿望的人的个人信息，则获得针对各项目的散列值(项目散列信息)，并且对于各条信息生成添加了电子签名“SUZUKI(购买者的姓名)”的信息。
有购买愿望人的终端2将添加有电子签名的个人信息和散列信息传送给中间商服务器4作为订货信息(S3011)。
已通过通信设备47接收到这些条信息(S3012)的中间商服务器4的文档TB将接收到的信息存储在文档管理DB 42中(S3013)，作为接收到的订货信息的订货信息的第一版本。之后，中间商服务器4的文档管理TB 44控制验证单元46，以执行添加在所存储的订货信息上的电子签名的验证处理(S3014)。如上所述，电子签名验证处理是这样的处理实际进行解码以验证是否可以使用发送者(即，有购买愿望的人)的公钥对所传送的信息进行解码。因此，当通过该处理已对个人信息进行解码时，可以确认从合法的人传送了个人信息并且也可以获得解码的个人信息和项目散列值信息。
当完成解码时，获得解码出的第一版本的个人信息的各项目的散列值，并且验证其是否与第一版本的项目散列值相同。由此，可以验证项散列信息和个人信息已经作为合法的对被传送。(这里，如果通过该处理不可能进行解码或者如果所获得的解码出的个人信息的第一版本的各项目的散列值与第一版本的项目散列值信息不同，则文档管理TB 44就向中间商终端5发送错误消息并中止该处理。另外，中间商终端5执行向中间商发送错误消息的处理，例如显示错误。)之后，文档管理TB 44执行处理，以基于解码出的个人信息生成用于结算机构的订货信息(S3015)。
下面将参照图10的流程图来说明该处理。
首先，文档管理TB 44向经解码的个人信息添加订货ID作为一项目(S4001)。该项目应该是不同于其它订货单的号码的期望号码。
接着，文档管理TB 44对在S4001中修改的个人信息中的“产品名”执行消隐处理(sanitizing process)(S4002)。然而，在该处理中，仅执行消隐以使得项目“产品名”的内容含糊，而并不执行删除该项目本身的处理。“消隐”是指遮掩文档中的信息块的操作(例如，针对秘密、国家机密等)。
接着，文档管理TB 44对在S4002中修改后的个人信息的各项目计算散列值(S4003)。
返回图8的流程图，当完成该处理时，文档管理TB 44执行这样的处理(S3016)，即，向经S4001和S4002中的处理修改过的个人信息以及在S4003中获得的散列值添加各中间商的签名，并且将该信息对作为第二版本进行存储。
在图11A和图11B中示出了在执行这些处理之后生成的第二版本的订货信息。
由于中间商服务器4执行了如上所述的处理，因此在第二版本的订货信息当中的个人信息包括添加到从有购买愿望人的终端2发送的图9的第一版本的订货信息中的订货ID。另外，将产品名从“红鞋”修改为“***”作为消隐信息。此外，向该个人信息添加中间商的电子签名。
另外，由于执行了上述添加和修改，因此获得的结果包括如图11B所示的订货ID的散列值，并且还包括不同于第一版本的散列值的产品名的散列值。相反，没有修改的各项目具有与第一版本的相同的散列值，这是因为获得了第一版本的散列值。另外，添加中间商的电子签名作为所述电子签名。
当这些处理完成时，中间商服务器4的文档管理TB 44向结算机构服务器6传送如图12A、图12B和图12C所示的一组三条信息第二版本的个人信息、第一版本的项目散列值和第二版本的项目散列信息(S3018)。
即，将已由中间商修改并给予了中间商的电子签名的个人信息和项目散列信息、以及在由中间商服务器4修改之前给予了有购买愿望的人的电子签名的项目散列信息作为一组多条信息传送给结算机构服务器6。
通过通信设备65接收到该信息(S3019)的结算机构服务器6的文档管理TB 62将所接收到的信息存储在文档管理DB 61中(图13S3020)。
文档管理TB 62指示验证单元64验证所接收到的信息。
验证单元64从认证机构服务器3获得有购买愿望的人和中间商的证书。该验证单元64根据电子签名认证处理的程序使用包含在有购买愿望的人的证书中的公钥对第一版本的项目散列信息进行解码，并且使用包含在中间商的证书中的公钥对第二版本的结算单信息(即，个人信息)和第二版本的项目散列信息进行比较。另外，在该处理的执行期间，获得第二版本的个人信息的散列值，并且验证其是否与第二版本的项目散列信息相同。
另外，将解码出的第一版本的项目散列信息与第二版本的项目散列信息进行比较，以验证订货ID的散列值被添加到第一版本的项目散列信息中，产品名的散列值在第一版本的项目散列信息与第二版本的项目散列信息之间不同，其它项目的散列值在第一版本的项目散列信息与第二版本的项目散列信息之间没有区别。并不添加上述之外的其它项目(S3021)。下面将进一步补充说明执行这些验证处理的原因。
如上所述，中间商服务器4传送三条信息(第一版本的项目散列信息、第二版本的个人信息和第二版本的项目散列信息)。由于第二版本的个人信息和第二版本的项目散列信息被给予了中间商的电子签名，因此存在的风险是，这些条信息对被中间商服务器4有意地改变。
为了验证对上述多项信息对的有意改变，通过利用对于特定值来说所确定的散列值几乎是唯一的这一事实，对已获得散列值的第二版本的各项个人信息与所传送的第二版本的各项项目散列信息进行核对以验证它们是否相同，而验证第二版本的个人信息和项目散列信息是否合法。
另外，在已执行了所述验证的前提下，即使订货单信息的第一版本的个人信息(即，订货单信息中的有购买愿望的人的个人信息)没有呈现给结算机构，由于结算机构可以通过对第一版本的项目散列信息(即，添加有购买愿望的人的电子签名的项目散列信息)与第二版本的各项目散列值进行比较，而证明由中间商修改的部分和由有购买愿望的人输入的部分，所以具有结算机构服务器6的结算机构也能够接受该信息作为来自有购买愿望的人的合法订货信息。
当验证单元64在S3021中利用验证信息验证了合法性时，文档管理TB 62执行这样的处理接下来向经解码的第二版本的个人信息添加结算ID，并生成添加有结算ID的个人信息的各项目的散列值(S3022)。(如果作为验证单元64在S3021中的验证处理的结果不能验证合法性，则文档管理TB 62就向结算机构终端7传送错误消息，并且该结算机构终端7执行向负责结算机构的人发送所述信息的处理(例如显示所述信息)，而后中断所述处理)。
文档管理TB 62指示签名单元64执行这样的处理向在S3022中修改过的个人信息和所生成的项目散列信息添加结算机构的电子签名(S3023)。
在完成S3023中的处理时，文档管理TB 62将在S3023中添加有结算机构的电子签名的个人信息和项目散列信息存储在文档管理DB 61中作为第三版本的订货单信息(S3024)。
在图14A和图14B中示出了在上述处理完成之后的订货单的第三版本。
如可以从图14A和图14B所理解的，对于图11中所示的第二版本的订货单信息(即，从中间商传送来的订货单信息)，将结算ID添加到个人信息中，还将与该结算ID相对应的散列值添加到项目散列信息中。在个人信息项目散列信息中的其它项目相对于第二版本的订货单信息没有变动。
另外，将结算机构的电子签名添加到该第三版本的个人信息项目散列信息上。
在完成了所述存储时，文档管理TB 62控制通信设备65，以将存储在文档管理DB 61中的第三版本的订货单信息传送给中间商服务器4(S3025)。
接着，文档管理TB 62向卖方生成添加有结算ID和支付数的支付单信息，如图15所示，并且还向该支付信息添加电子签名(S3026)，然后将该支付单信息传送给卖方终端8(S3027)。
另外，负责结算机构的人在完成所述结算时执行将相同数量的钱转到卖方帐户的手续(S3028)。
中间商服务器4的文档管理TB 44通过通信设备47接收在S3028中从结算机构服务器6传送的第三版本的订货单信息，并将该第三版本的订货信息存储在信息管理DB 42中(图16S3030)。
之后，文档管理TB 44向验证单元46请求对第三版本的订货信息的个人信息和项目散列信息进行解码处理和验证处理(S3031)。
验证单元46响应于该请求根据上述电子签名的验证程序而从认证机构服务器3获得结算机构服务器6的证书，并且利用包含在该证书中的公钥对由结算机构服务器6添加了电子签名的个人信息项目散列信息(即，第三版本的订货单信息)进行解码。
之后，验证单元46从文档管理DB 42获得解码出的个人信息的订货ID和包含相同订货ID的第三版本的订货单信息。
验证单元46获得解码出的各项个人信息的散列值，并将其与提取的第三版本的项目散列信息进行比较，以验证它们是否相同。
通过该处理，可以检查出包含在第三版本的订货单信息中的个人信息与项目散列信息形成了一对。
另外，将所累计的第二版本的项目散列信息与第三版本的项目散列信息进行比较，以验证除了结算ID之外的各项的散列是否有变动。由此，在结算机构服务器6的处理中证明，结算ID之外的各项的散列没有被中间商服务器4修改。
当通过该处理验证了合法性时，文档管理TB 44生成订货单信息(S3032)。(当作为验证单元46在S3031中的验证处理的结果不能检查出合法性时，文档管理TB 46向中间商终端5传送错误消息，从而中间商终端5例如通过显示该信息向中间商的负责人通知该处理，而中断该处理。)换言之，在S3032的处理中，文档管理TB 44从文档管理DB 42中提取第一版本的订货单信息的个人信息，对该个人信息进行解码，并将第三版本的个人信息中的项目信息产品名替换为第一版本的个人信息中的产品名。另外，同一文档管理TB 44对第三版本的个人信息卡号执行消隐处理，并且还获得了修改后的各项个人信息的散列值。
接着，文档管理TB 44控制签名单元45，使其执行向在S3032中修改过的个人信息和所生成的项目散列信息添加电子签名的处理(S3033)。
之后，文档管理TB 44利用在S3033的处理中添加了电子签名的个人信息和项目散列信息对而形成订货单信息的第四版本，然后将该订货单信息的第四版本存储在文档管理DB 42处(S3034)。
接着，如图18A、图18B、图18C、图18D和图18E所示，文档管理TB 44从文档管理DB 42提取第四版本的订货单信息以及带有电子签名的第一至第三版本的项目散列信息，然后一次将这些信息传送给卖方终端8(S3035)。
卖方终端8在接收到通过S3027中的处理从结算机构服务器6传送来的支付单信息(图13S3036)、和通过S3035中的处理从中间商传送来的信息(S3037)时，从认证机构服务器3获得有购买愿望的人、中间商和结算机构的证书信息，并且使用包含在各证书中的公钥对带有电子签名的传送的信息进行解码(S3038)。
接着，卖方终端8基于各条经解码的信息执行如下验证处理(S3039)。
对于该处理，假设卖方终端8在存储设备(未示出)中存储有图19中所示的、各项目和创建者(终端和服务器)的对应表。
在合法创建者已生成或修改各项目时，该对应表指示该创建者(终端和服务器)。
下面将基于图20中的流程图来说明该处理。
首先，卖方终端8获得解码出的第四版本的个人信息的各项目的散列值，并将其与解码出的第四版本的项目散列信息进行比较以验证它们是否相同(S5002)。
当在S5003中确定它们相同时，对添加到各版本的项目散列信息的电子签名信息进行验证而后将其存储在卖方终端8的存储设备(未示出)中。在图21中示出了所存储的信息。在该实施例中，由于图18中所示的项目散列信息被传送，因此如图21所示将其存储，从而向第一版本添加作为有购买愿望人的终端2的所有者的Suzuki的电子签名，向第二和第四版本添加“中间商”的电子签名，并且向第三版本添加“结算机构”的电子签名。
接着，将解码出的第一至第三版本的项目散列信息与第四版本的项目散列信息进行比较。然后检查各项目的散列值是否与项目散列信息的最旧版本相同。将检查结果存储在卖方终端8的存储设备(未示出)中(S5004)。
通过S5004中的处理，由于在该实施例中与S5003中的处理相似地传送如图18A至图18E中所示的项目散列信息，因此当执行处理S5004时，如图22所示，相应版本为对于“订货ID”为第二版本，对于“结算ID”为第三版本，对于“名称”、“地址”、“产品名”和“钱数”为第一版本，并且对于卡号为第四版本。因此，将该信息存储在卖方终端8的存储设备(未示出)中。
接着，卖方终端8根据存储在卖方终端8的存储设备(未示出)中的版本号与电子签名的对应信息(参照图21)和项目与版本号的对应信息(图22)生成对应于各项目的电子签名的对应表。即，由于版本信息号存储在项目与版本号的对应信息中(参照图22)，因此参考版本号与电子签名的对应信息(参照图21)来确定对应于该信息的电子签名。另外，将该处理的结果存储在卖方终端8中(S5005)。在图23中示出了通过该处理生成的项目与电子签名对应信息。
接着，卖方终端8将存储在卖方终端8的存储设备(未示出)中的项目与电子签名的对应信息(参照图23)与先前存储在卖方终端8的存储设备(未示出)中的各项目与创建者(终端和服务器)的对应表(参照图19)进行比较(S5006)。
这里，由于它们彼此匹配(S5007)，因此确定输入了合法文档(S5008)并且继续所述处理(S5009)。
另外，当S5002和S5007中的确定处理确定它们“不同”时，就发送错误消息(S5010)并完成所述处理(S5011)。
返回图16的流程图，卖方终端8在S5009中的处理之后，从卖方终端8的存储设备(未示出)提取支付单信息，该支付单信息包含与在S3039中证明为合法的第四版本的个人信息中所包含的相同的结算ID，并将所提取的支付单的钱数项目中的钱数与在第四版本的个人信息中所包含的钱数项目中记录的钱数进行比较，并且当这些钱数相同时就确定进行了正确的支付，并发送表示正确支付的消息，或者如果这些钱数不同，则发送表示不正确支付的消息(S3040)。
如上所述，根据本实施例，可以证明谁(或哪个终端和服务器)生成或修改了个人信息的哪些项。
因此，如果在所述处理的过程中通过中间商服务器对个人信息进行了消隐，则可以在修改后的个人信息中识别出未被有购买愿望人的终端2修改的区域。因此，利用结算机构服务器6识别出由有购买愿望人的终端2的用户使用的信息，依赖于该信息，可以接受经中间商服务器修改的订货单信息作为正式的订货单信息。
这对于卖方终端8在中间商服务器4和结算机构服务器7二者的修改之后接收订货单信息也是如此。
另外，通过采用记录有各项个人信息的散列值的项目散列信息，进行验证以证明合法性。
由于可以在隐藏内在的个人信息的同时，通过该信息识别输入到有购买愿望人的终端2的一部分(即从开始就未被修改的一部分)，因此可以将个人信息当中的、本来就不需要发送给相关公司或机构的项目在隐藏这些项目时发送给相关公司或机构。
另外，根据该实施例，通过利用在中间商服务器4中添加的订货ID和在结算机构服务器6中添加的ID，识别出相应的订货单信息并且通过卖方终端进行支付单信息与订货单信息之间的核对。由于还可以证明哪个服务器进行了这些项目的添加，因此这些项目也可以用作可靠ID。结果，可以在不使用个人信息当中的可能非法使用的号码(例如，信用卡号)的情况下实现核对和识别处理。
另外，本申请并不限于上述实施例，各种变动和修改对于本领域技术人员是显而易见的。可以在不脱离本发明的范围的情况下作出这些变动和修改，并且本发明旨在包括所述变动和修改。
相关申请的交叉参考本申请涉及并要求于2005年12月28日在日本提交的日本专利申请No.2005-377808的优先权的权益，通过引用将其内容并入这里。
权利要求
1.一种计算机可读存储介质，该计算机可读存储介质存储有个人信息验证程序，该个人信息验证程序控制可以与结算机构服务器进行通信并可以访问用于存储结算信息的存储设备的计算机，以执行将接收到的信息存储在所述存储设备中；当接收到第一版本的个人信息和第一版本的验证信息时，将所述接收到的信息传送给所述结算机构服务器，所述第一版本的个人信息包括表示购买愿望的信息、以及识别结算机构并识别有购买愿望的人的识别信息，所述第一版本的验证信息用于验证所述第一版本的个人信息的各项的创建者；以及在从所述结算机构服务器接收了向所述第一版本的个人信息添加了结算号码的第二版本的个人信息、以及用于验证所述第二版本的个人信息的各项目的创建者的第二版本的验证信息时，通过擦除所述结算机构的识别信息生成第三版本的个人信息，和用于验证所述第三版本的个人信息的各项目的创建者的第三版本的验证信息，并且将所述第三版本的个人信息、所述第三版本的验证信息以及所述第一版本的验证信息连同存储在所述存储设备中的所述第二版本的验证信息一起传送给产品卖方的卖方装置。
2.根据权利要求1所述的计算机可读存储介质，所述程序进一步控制所述计算机以执行当接收到所述第一版本的个人信息时，通过使所述第一版本的个人信息中的产品项目名隐藏并添加电子签名而生成所述第二版本的个人信息，并生成所述第二版本的验证信息，将所述第二版本的个人信息和所述第二版本的验证信息传送给所述结算机构服务器，并将所述第二版本的个人信息和所述第二版本的验证信息存储在所述存储设备中；以及当从所述结算机构服务器接收到向所述第二版本的个人信息添加了结算号码的所述第三版本的个人信息、以及所述第三版本的验证信息时，通过擦除所述结算机构的识别信息而生成第四版本的个人信息，并生成用于识别所述第四版本的个人信息的各项的创建者的第四版本的验证信息，并且将所述第四版本的个人信息和所述第四版本的验证信息连同存储在所述存储设备中的所述第一版本的验证信息、所述第二版本的验证信息和所述第三版本的验证信息一起传送给产品卖方的卖方装置。
3.根据权利要求1所述的计算机可读存储介质，所述程序进一步控制所述计算机以执行当接收到所述第一版本的个人信息、以及向所述第一版本的个人信息的各项目的散列值添加了电子签名的第一版本的项目散列信息时，将所述接收到的信息传送给所述结算机构服务器；以及当从所述结算信息服务器接收到向所述第一版本的个人信息添加了结算号码的所述第二版本的个人信息、以及向所述第二版本的个人信息的各项目的散列值添加了电子签名的所述第二版本的项目散列信息时，生成向所述第三版本的个人信息的各项目的散列值添加了电子签名的第三版本的项目散列信息，并将生成的所述第三版本的个人信息、所述第三版本的项目散列信息和所述第一版本的项目散列信息连同存储在所述存储设备中的所述第二版本的项目散列信息一起传送给产品卖方的卖方装置。
4.根据权利要求2所述的计算机可读存储介质，所述程序进一步控制所述计算机以执行当接收到所述第一版本的个人信息和所述第一版本的项目散列信息时，生成向所述第二版本的个人信息的各项目的散列值添加了电子签名的所述第二版本的项目散列信息，并且将所述第二版本的个人信息和所述第二版本的项目散列信息传送给所述结算机构服务器，并将所述第二版本的个人信息和所述第二版本的项目散列信息存储在所述存储设备中；以及当从所述结算机构服务器接收到向所述第二版本的个人信息添加了所述结算号码的所述第三版本的个人信息、以及向所述第三版本的个人信息的各项目的散列值添加了电子签名的所述第三版本的项目散列信息时，生成向所述第四版本的个人信息的各项目的散列值添加了电子签名的第四版本的项目散列信息，并将生成的所述第四版本的个人信息、所述第四版本的项目散列信息、所述第一版本的项目散列信息以及所述第二版本的项目散列信息和所述第三版本的项目散列信息传送给产品卖方的卖方装置。
5.一种个人信息验证方法，该个人信息验证方法用于控制可以与结算机构服务器进行通信并可以访问用于存储结算信息的存储设备的计算机，该方法包括将接收到的信息存储在所述存储设备中；当接收到第一版本的个人信息和第一版本的验证信息时，将所述接收到的信息传送给所述结算机构服务器，所述第一版本的个人信息包括表示购买愿望的信息、以及用于识别有购买愿望的人的结算机构的识别信息，所述第一版本的验证信息用于验证所述第一版本的个人信息的各项目的创建者；以及当从所述结算机构服务器接收到向所述第一版本的个人信息添加了结算号码的第二版本的个人信息、以及用于验证所述第二版本的个人信息的各项目的创建者的第二版本的验证信息时，通过擦除所述结算机构的识别信息而生成第三版本的个人信息，并生成用于验证所述第三版本的个人信息的各项的创建者的第三版本的验证信息，并且将生成的所述第三版本的个人信息、所述第三版本的验证信息和所述第一版本的验证信息连同存储在所述存储设备中的所述第二版本的验证信息一起传送给产品卖方的卖方装置。
6.根据权利要求5所述的方法，所述方法还包括当接收到所述第一版本的个人信息、以及用于验证所述第一版本的个人信息的各项目的创建者的所述第一版本的验证信息时，通过使所述第一版本的个人信息的产品项目名隐藏并向所述第一版本的个人信息添加电子签名而生成所述第二版本的个人信息，并生成用于验证所述第二版本的个人信息的各项目的创建者的所述第二版本的验证信息，并将所述第二版本的个人信息和添加了电子签名的所述第二版本的验证信息传送给所述结算机构服务器，并且将所述信息存储在所述存储设备中；以及当从所述结算机构服务器接收到向所述第二版本的个人信息添加了所述结算号码的所述第三版本的个人信息、以及用于验证所述第三版本的个人信息的各项目的创建者的所述第三版本的验证信息时，通过擦除所述结算机构的识别信息而生成第四版本的个人信息，生成用于识别所述第四版本的个人信息的各项目的创建者的第四版本的验证信息，并且将所述第四版本的个人信息和所述第四版本的验证信息连同存储在所述存储设备中的所述第一版本的验证信息、所述第二版本的验证信息和所述第三版本的验证信息一起传送给产品卖方的卖方装置。
7.一种个人信息验证装置，该个人信息验证装置包括用于存储结算信息的存储设备；结算机构服务器传送设备，该结算机构服务器传送设备用于当接收到第一版本的个人信息和第一版本的验证信息时，将接收到的信息存储在所述存储设备中并将所述接收到的信息传送给结算机构服务器，所述第一版本的个人信息包括表示购买愿望的信息、以及用于识别有购买愿望的人的结算机构的识别信息，所述第一版本的验证信息用于验证所述第一版本的个人信息的各项目的创建者；以及卖方传送设备，该卖方传送设备用于当从所述结算机构服务器接收到向所述第一版本的个人信息添加了结算号码的第二版本的个人信息、以及用于验证所述第二版本的个人信息的各项目的创建者的第二版本的验证信息时，通过擦除所述结算机构的识别信息而生成第三版本的个人信息，生成用于验证所述第三版本的个人信息的各项目的创建者的第三版本的验证信息，并且将生成的所述第三版本的个人信息、所述第三版本的验证信息和所述第一版本的验证信息连同存储在所述存储设备中的所述第二版本的验证信息一起进行传送。
8.根据权利要求7所述的装置，该装置还包括所述结算机构服务器传送设备还用于当接收到所述第一版本的个人信息时，通过使所述第一版本的个人信息的产品项目名隐藏并向所述第一版本的个人信息添加电子签名而生成所述第二版本的个人信息，生成用于验证所述第二版本的个人信息的各项目的创建者的所述第二版本的验证信息，并将所述第二版本的个人信息和所述第二版本的验证信息传送给结算机构服务器，并且将所述第二版本的个人信息和所述第二版本的验证信息存储于所述存储设备；以及所述卖方传送设备还用于当在传送了所述第二版本的个人信息之后，从所述结算机构服务器接收到向所述第二版本的个人信息添加了所述结算号码的所述第三版本的个人信息、以及用于验证所述第三版本的个人信息的各项目的创建者的所述第三版本的验证信息时，通过擦除所述识别信息而生成第四版本的个人信息，生成用于识别所述第四版本的个人信息的各项目的创建者的第四版本的提供信息，并且将所述第四版本的个人信息和所述第四版本的提供信息连同存储在所述存储设备中的所述第一版本的验证信息、所述第二版本的验证信息和所述第三版本的验证信息一起传送给产品卖方的卖方装置。
9.一种个人信息验证系统，该个人信息验证系统使用执行由卖方来卖产品的中间处理的中间商服务器、以及向卖方进行支付以作为结算的结算机构服务器，其中所述中间商服务器包括用于存储结算信息的存储设备；结算机构服务器传送设备，该结算机构服务器传送设备用于当接收到第一版本的个人信息和第一版本的验证信息时，将所述接收到的信息传送给所述结算机构服务器，所述第一版本的个人信息包括表示购买愿望的信息、以及用于识别有购买愿望的人的结算机构的识别信息，所述第一版本的验证信息用于验证所述第一版本的个人信息的各项目的创建者；以及卖方传送设备，该卖方传送设备用于当从所述结算机构服务器接收到向所述第一版本的个人信息添加了结算号码的第二版本的个人信息、以及用于验证所述第二版本的个人信息的各项目的创建者的第二版本的验证信息时，通过擦除所述识别信息而生成第三版本的个人信息，生成用于验证所述第三版本的个人信息的各项目的创建者的第三版本的验证信息，并且将所述第三版本的个人信息和所述第三版本的验证信息连同存储在所述存储设备中的所述第一版本的验证信息和所述第二版本的验证信息一起传送给产品卖方的卖方装置；并且所述结算机构服务器包括第二版本个人信息生成设备，用于在接收到来自中间商的信息时生成所述第二版本的个人信息，并用于向所述接收到的信息添加电子签名；第二版本验证信息生成设备，用于生成所述第二版本的验证信息；中间商服务器传送设备，用于将生成的并被给予电子签名的所述第二版本的个人信息、以及所述第二版本的验证信息传送给所述中间商服务器；以及支付设备，用于生成向所述第二版本的个人信息添加了所述结算号码的支付单，并将所述支付单传送给所述卖方。
10.一种用于验证个人信息的方法，该方法使用与结算机构服务器通信的计算机，该方法包括向所述结算机构服务器传送第一版本的个人信息和第一版本的验证信息；当从所述结算机构服务器接收到第二版本的个人信息和第二版本的验证信息时，将所述第二版本的验证信息传送给卖方装置；以及生成第三版本的个人信息和第三版本的验证信息，并将所述第三版本的个人信息和所述第三版本的验证信息连同所述第一版本的验证信息一起传送给卖方装置。
11.根据权利要求10所述的方法，所述第一版本的个人信息包括表示购买愿望的信息和用于识别有购买愿望的人的信息。
12.根据权利要求10所述的方法，所述第一版本的验证信息包括用于验证所述第一版本的个人信息的各项目的创建者的信息。
13.根据权利要求10所述的方法，所述第二版本的验证信息包括用于验证所述第二版本的个人信息的各项目的创建者的信息。
14.根据权利要求10所述的方法，所述第二版本的个人信息向所述第一版本的个人信息添加了结算号码。
15.根据权利要求11所述的方法，所述第三版本的个人信息擦除了用于识别有购买愿望的人的信息。
16.根据权利要求10所述的方法，所述第三版本的验证信息验证所述第三版本的个人信息的各项目。
全文摘要
本发明提供了一种个人信息验证程序、方法及装置。一种使用中间商服务器和结算机构服务器的个人信息验证系统，其中从个人终端接收带有电子签名并表示购买愿望的个人信息、以及第一版本的项目散列信息。然后，中间商服务器通过隐藏购买项目并添加电子签名而生成第二版本的项目散列信息，并将所述第二版本的项目散列信息传送给所述结算机构服务器。所述结算机构服务器向卖方发送支付单，生成第三版本的项目散列信息，并将所述第三版本的项目散列信息连同已修改的个人信息一起进行传送。所述中间商服务器生成第四版本的项目散列信息，并将个人信息和第一至第四版本的项目散列信息传送给卖方终端。
文档编号G06Q20/40GK1996360SQ200610171450
公开日2007年7月11日 申请日期2006年12月27日 优先权日2005年12月28日
发明者吉冈孝司 申请人:富士通株式会社