一种信用担保系统的制作方法

本发明涉及一种信用担保系统。

背景技术：

随着互联网社会的发展，互联网上的诸如交流和交易等已经成为社会生活的基础，并且已经做出了一些报告，例如基于个人信息的泄露等的事例，对互联网用户的匿名性相关的意识调查、以及在互联网上保持匿名交易时，需要探讨的制度性事项的整理等的报告(参照非专利文献1)。

现有技术文献

非专利文献

非专利文献1：

总务省信息通信政策研究所(调查研究部)，“互联网与匿名性”，[online，2008年3月，[2018年6月23日检索]，网址<url：http://www.soumu.go.jp/iicp/chousakenkyu/data/research/survey/telecom/2008/2008-1-01.pdff>]。

技术实现要素：

发明所要解决的问题

有时，当互联网用户不希望公开个人信息的情况时，他们使用网名等代替真实姓名，并且，通过不公开诸如地址、电话号码和电子邮件地址等的可能识别个人的信息，从而采取措施来防止个人信息被知晓。

然而，例如，在互联网上进行的销售和购买等的商业交易等中，仅凭网名无法获取信用，即使进行该商业交易等的用户不希望公开个人信息，但实际上，个人信息(真实姓名、地址、电话号码、电子邮件地址等)也经常被公开。

此外，即使在社交互联网服务和社交互联网游戏中，也存在使用匿名的交流问题和类似于犯罪的事例等，因此，人们期望在可信赖的网名之间进行交流。

本发明是鉴于上述情况而完成的，其目的在于提供一种信用担保系统，其对利用互联网的用户的化名给与信用，从而能够抑制必须公开个人信息等的情况。

用于解决问题的手段

为了实现上述目的，可以通过以下的构成理解本发明。

(1)本发明的信用担保系统是一种向化名给与信用的信用担保系统，其具备：用户设备，其能够连接到互联网，是希望利用化名的用户的设备；以及运营商设备，其能够连接到所述互联网，其中注册有已完成信用验证的所述用户的所述化名，是担保所述化名的信用的运营商的设备；以及第三方设备，其能够连接到所述互联网，并且能够与所述用户设备、以及所述运营商设备通信；当所述运营商设备从所述用户设备接收到需要担保信用的担保联络的所述第三方设备的联络时，向所述第三方设备进行所述化名为已完成信用验证的内容的担保通知。

(2)在上述(1)的构成中，其中，所述化名包括由所述运营商为每个所述用户指定的独特的第一特定信息。

(3)在上述(1)或者(2)的构成中，其中，所述化名包括由所述运营商为每个所述用户指定的独特的第二特定信息。

(4)在上述(1)-(3)的任意一个的构成中，其中，所述用户设备中具有未公开的独特的识别信息，并且安装有由所述运营商提供的用于利用所述信用担保系统的应用程序；当向所述运营商设备进行所述担保联络时，所述用户设备将包括所述识别信息的认证信息向所述运营商设备进行联络，在进行所述担保联络时，当基于从所述用户设备所联络的所述认证信息和包括注册在所述运营商设备中的所述识别信息的认证信息的认证通过的情况时，所述运营商设备向所述第三方设备进行所述担保通知。

(5)在上述(1)-(4)的任意一个的构成中，其中，所述信用验证的内容包括所述用户的地址验证，所述担保通知为利用所述化名的用户的地址已完成验证的通知。

(6)在上述(1)-(5)的任意一个的构成中，其中，所述信用验证的内容包括所述用户的身份验证，所述担保通知为利用所述化名的用户的身份已完成验证的通知。

(7)在上述(1)-(6)的任意一个的构成中，其中，在所述运营商设备中，注册有所述用户的姓名、地址、邮件地址以及电话号码，在进行所述担保通知时，当所述担保联络中包含向所述第三方设备出示所述用户的姓名、地址、邮件地址以及电话号码中的任意一个的指令的情况时，所述运营商设备出示所述用户的姓名、地址、邮件地址以及电话号码中的被指定的内容。

(8)在上述(1)-(7)的任意一个的构成中，其中，所述运营商设备被设置在所规定的每个地域，所述化名包括执行了注册所述化名的处理的所述运营商设备中固有的独特的第三特定信息。

(9)在上述(1)-(8)的任意一个的构成中，在所述担保通知之后，当已完成信用验证的内容中发生变更的情况时，则所述运营商设备向已进行了所述担保通知的所述第三方设备进行已完成信用验证的内容中发生了变更的内容的通知。

发明效果

根据本发明，能够提供一种信用担保系统，其对利用互联网的用户的化名给与信用，从而能够抑制必须公开个人信息等的情况。

附图说明

图1是表示用于说明本发明所涉及的第一实施方式的信用担保系统的示图。

图2是表示本发明所涉及的第一实施方式的运营商设备的方框图。

图3是表示用于说明本发明所涉及的第一实施方式的运营商设备的存储单元中所存储的用户信息文件的示图。

图4是表示用于说明本发明所涉及的第一实施方式的运营商设备的主要处理的示图。

图5是表示执行本发明所涉及的第一实施方式的初次注册处理时，运营商设备使用户设备的显示单元上显示的内容的示例的示图。

图6是表示执行本发明所涉及的第一实施方式的第一特定信息共通注册处理时，运营商设备使用户设备的显示单元上显示的内容的示例的示图。

图7是表示本发明所涉及的第一实施方式的以不公开诸如真实姓名或者当前地址的个人信息的形式，执行担保化名为确实具有真实地址的用户使用的化名的担保通知的示例的示图。

图8是表示执行本发明所涉及的第一实施方式的注册内容变更处理时，运营商设备使用户设备的显示单元上显示的内容的示例的示图。

图9是表示用于说明本发明所涉及的第二实施方式的信用担保系统的示图。

图10是表示用于说明本发明所涉及的第二实施方式的运营商设备的存储单元中所存储的用户信息文件的示图。

图11是表示用于说明本发明所涉及的第三实施方式的信用担保系统的示图。

图12是表示用于说明本发明所涉及的第三实施方式的辅助运营商设备的主要处理的示图。

图13是表示用于说明本发明所涉及的第三实施方式的主运营商设备的主要处理的示图。

具体实施方式

(第一实施方式)

以下，参照附图，对用于实施本发明的方式(以下，简称为实施方式)进行详细说明。

另外，在整个实施方式的说明中，相同的要素赋予相同的附图标记。

(第一实施方式)

图1是表示用于说明本发明所涉及的第一实施方式的信用担保系统1的示图。

如图1所示，信用担保系统1具备用户设备10、运营商设备20以及第三方设备30。

如图1所示，用户设备10是诸如台式电脑、笔记本电脑以及智能手机等的能够连接到互联网的设备，其是希望利用化名的用户(自然人的个人或者法人等)使用的设备。

然而，图1中示出的用户设备10仅是一个示例，例如还可以是平板终端等。

如图1所示，运营商设备20是台式电脑等的能够连接到互联网的设备，是向用户使用的化名给与信用的信用担保系统1的运营商使用的设备，更具体而言，信用担保系统1用于向用户使用的化名给与信用，其目的在于运营商仅通过验证使用化名的用户的个人信息从而担保化名是已完成信用验证的化名。

也就是说，信用担保系统1不应该干预在用户和第三方之间的商业交易等中发生的商业内容，例如货币转移、付与具有现金价值的积分、商品的交付等。

然而，图1中示出的运营商设备20仅是示例，例如，还可以是商业服务器等，并且可以是以下说明的处理的任何设备。

此外，运营商也可以是提供信用担保系统1的单个法人，但也可以是包括具有合伙关系的两个以上的法人，用于提供信用担保系统1。

如图1所示，第三方设备30是台式电脑等的能够连接到互联网的、且能够与用户设备10以及运营商设备20通信的设备，并且是用户和运营商以外的第三方使用的设备，例如，作为第三方的示例，可以是与用户进行商业交易等的另一方等。

另外，图1中示出的第三方设备30仅是示例，也可以是与用户设备10一样的笔记本电脑、智能手机、平板终端等。

接下来，参照图1至图3，对运营商设备20进行更详细的说明，并且对信用担保系统1的操作等进行说明。

图2是本发明所涉及的第一实施方式的运营商设备20的方框图，图3是用于说明本发明所涉及的第一实施方式的运营商设备20的存储单元21a中所存储的用户信息文件的示图。

如图1和图2所示，运营商设备20具备：主体单元21，用于执行各种处理；以及显示单元22，其可通信地连接到主体单元21，用于进行各种显示；以及操作单元23，用于进行各种操作。

例如，如图1所示，显示单元22是液晶显示器等，操作单元23是键盘、或者鼠标(图中未示出)等。

另一方面，如图2所示，主体单元21具备：存储单元21a，其例如由rom(只读存储器)、ram(随机存储器)等所构成，用于存储诸如程序、或者数据等；以及cpu21b，其根据存储在存储单元21a中的程序执行各种处理，并且作为控制整体的控制单元；以及通信单元21c，用于经由互联网执行通信；以及总线21d，用于可通信地连接存储单元21a、cpu21b以及通信单元21c。

另外，通过将显示单元22以及操作单元23也连接到主体单元21的图中未示出的连接端口上，从而经由总线21d可通信地连接到主体单元21的构成部件(存储单元21a，cpu21b以及通信单元21c等)。

如图2所示，存储单元21a具备：程序存储区域21aa、用户信息存储区域21ab、临时存储区域21ac以及其他存储区域21ad。

程序存储区域21aa是用于存储各种程序的区域，例如可以存储用于使运营商设备20实现作为信用担保系统1的操作的程序。

用户信息存储区域21ab如稍后将进行说明的那样，用于存储希望利用进行了信用验证并已完成信用验证的化名的用户的用户信息文件。

具体而言，用户信息文件是每次注册化名时所创建的文件，所述化名为进行了信用验证并已完成信用验证的用户的化名，如图3所示，用户信息文件具备：化名信息a、用户真实信息b、担保通知发行履历c以及信用验证文档数据d。

化名信息a包括第一特定信息、第二特定信息和网名。

第一特定信息是运营商(运营商设备20)用于识别用户(更准确的说，是识别用户设备10)的识别信息，在稍后将进行说明的注册用户的化名时，由运营商为每个用户(用户设备10)指定的独特的信息(号码、代码等)。

例如，在第一特定信息中，可以使用向每个可通信设备给与的mac地址等，并且通过由运营商将用户设备10的mac地址指定为第一特定信息，从而可以提供用于识别每个用户的信息(更确切地说，识别每个用户设备10)。

该第一特定信息是当同一用户希望注册两个以上的化名时，运营商(运营商设备20)为了能够识别这些两个以上的化名属于同一个用户而设置的。

然而，第一特定信息不限于mac地址，可以是运营商自己向每个用户(更确切地说，用户设备10)发行的独特的类似于id的信息。

第二特定信息是由运营商指定的独特信息，其用于信用担保系统1上的用户的化名中，并且在稍后将进行说明的注册用户的化名时注册。

如上所述，网名不是必须的条件，其给与使用了第二特定信息的化名的用户，用作在信用担保系统1上变为真实姓名的名称。

然而，由于第二特定信息是独特信息，其不像人名，其由诸如字母或者数字等排列而组成，例如，其被提供给在与运营商交互等的情况时，希望使用类似人名的昵称称呼的用户。

因此，由于网名不是用于信用担保系统1上的每个用户的识别等的信息，所以即使存在具有两个以上相同网名的用户，信用担保系统1上也没有问题，因此网名可以根据用户的希望，被注册为用户喜欢的昵称。

用户真实信息b是对应于化名的用户的真实信息，如图3所示，其包括真实姓名、当前地址、电子邮件地址以及电话号码等。

然而，并非一定要求包括所有这些项目，例如，可能存在不包括电话号码的情况，相反，也可以是包括除此之外的其他项目(例如，出生日期等)的情况。

另外，如果用户不是自然人而是法人的情况时，则用户真实信息b包括该法人的名称、真实姓名表示法人的负责人的姓名(代表者姓名)、当前地址是指在工商局的注册表等中注册的法人的所在地(住所)、电话号码是指法人的代表电话号码等。

该用户真实信息b中注册的项目是基于信用验证文档验证的项目，该信用验证文档是用户在注册的化名时，为了由运营商进行信用验证而提交给运营商的，这将在稍后进行说明。

如稍后将进行说明的那样，担保通知发行履历c为当运营商接收到来自用户的通知，向用户期望的第三方通知担保通知以担保该用户是已完成信用验证的用户的化名的情况时注册的履历，从而可以知道其发行担保通知的第三方。

因此，每次向第三方进行担保通知时，运营商都会发行作为该担保通知的号码的发行管理号码、作为发行担保通知的日期的发行日期、担保通知的内容(担保通知内容)、用于联系已发行担保通知的第三方的第三方设备的联系地址等作为一系列的注册内容，该一系列的注册内容在发行担保通知时被注册，并且成为累计履历记录。

信用验证文档数据d是在稍后将要说明的用户在注册用户的化名时，用户提交给运营商的文档(包括文档的副本)，以便运营商验证在用户真实信息b中注册的内容没有错误，换言之，其是运营商用于进行用户的信用验证的信用验证文档的数据。

作为信用验证文档，例如可以列举：驾驶执照、健康保险卡、养老金手册、护照、居民卡、户籍副本、个人号码卡等，并且信用验证文档数据d如图3所示，是将用于用户的信用验证的诸如驾驶执照、护照、居民卡、户籍副本、个人号码卡等的文档进行电子化(例如，转换为pdf)并被转换成数据。

然而，信用验证文档不必限于上述文件，也可以是公共费合同、邮局邮件或者快递接收收据等。

但是，信用验证文档优选是由公共机关发行的能够准确地进行用户的身份可验证文档(例如，驾驶执照、驾驶履历证明、健康保险卡(公共医疗保险的参保卡/被保险者证书)、身体残疾手册、居留卡、特别永久居留证、儿童抚养津贴证明、特殊儿童抚养津贴证明、养老金手册、护照(护照)、居民卡、户籍副本、个人号码卡等)，并且，信用验证文档数据d优选用于用户的信用验证的由公共机关发行的身份可验证文档的副本(驾驶执照、护照、居民卡、户籍副本、个人号码卡等的pdf文件等的副本)。

另外，在日本，作为身份可验证文档，一般情况下，可以列举驾驶执照、健康保险卡、养老金手册、护照、居民卡、户籍副本、个人号码卡等，在许多情况下，信用验证文档数据d也被认为是用于用户信用验证的驾驶执照、护照、居民卡、户籍副本、个人号码卡等的pdf文件中的副本。

然而，由于考虑到一些用户可能是居住在日本以外的地区的用户，因此，这些在日本以外具有地址的用户通常可以提交在该地址所在的国家的用作身份可验证文档的文档，需要注意的是，所述信用验证文档(包括身份可验证文档)仅仅所以一个例子。

此外，在上述说明的图3所示的用户信息文件也可以包括图中未示出的其他的信息。

例如，如稍后将说明的，在本实施方式中，在稍后将要说明的用户在注册化名时，由运营商提供的用于利用信用担保系统1的专用应用程序被安装在用户设备10中。

另外，该应用程序通过公钥加密方法(使用公钥/密钥加密的方法)进行用户设备10和运营商设备20之间的通信，从而防止信息泄露等。

并且，该应用程序具有独特的识别信息(也称为应用识别信息)，除了给与每个应用程序的运营商之外，该信息不会向任何人公开，并且尽管在图3中未示出，但是该应用识别信息也被注册在用户信息中。

另外，稍后将说明运营商如何使用该应用识别信息。

图2所示的临时存储区域21ac用作当执行存储在程序存储区域21aa中的各种程序时的程序扩展区域，并且，用作临时存储在执行程序时产生的数据等的区域。

图2中所示的其他存储区域21ad是存储除了上述说明的以外的需要存储在运营商设备20中的存储区域的区域。

另外，尽管在上文中说明了存储单元21a内置于运营商设备20的主体单元21中，但是存储单元21a也可以是包括连接到运营商设备20的外部存储设备。

另外，存储单元21a也可以包括安装在远离运营商设备20的位置的外部存储设备，使得运营商设备20可以经由互联网访问存储单元21a。

如上所述，由于存储单元21a为包括外部存储设备的存储单元，所以通过将存储在预期数据容量增加的用户信息存储区域21ab中的内容提供给具有大存储容量的外部存储设备，从而可以提高运营商设备20的操作速度。

另外，当使用外部存储设备的情况时，外部存储设备的数量不必是一个，也可以使用两个以上的外部存储设备。

接下来，将主要参考图4对信用担保系统1的整体流程等进行说明。

图4是表示用于说明本发明所涉及的第一实施方式的运营商设备20的主要处理的示图。

当运营商设备20通过运营商的操作接收到作为信用担保系统1的操作指令时，开始进行图4所示的处理。

另外，由于图4所示的处理是由作为控制单元的运营商设备20的cpu21b与程序协作执行的，因此执行处理的主体是cpu21b，然而，由于作为运营商设备20的功能执行的处理是不变的，因此，在下文中，将运营商设备20作为该处理的主体进行说明。

如图4所示，当运营商设备20接收到作为信用担保系统1的操作指令并开始处理时，执行监视循环处理，对步骤s10、步骤s20、步骤s30、步骤s40以及步骤s50中的任意一个步骤是否变为是(yes)进行监视。

然后，当运营商设备20通过运营商的操作接收到运营商设备停止的处理时(步骤s10：是(yes))，终止该处理。

例如，作为运营商执行步骤s10为是(yes)的操作的情况，可能存在需要停止作为用于维护工作等的信用担保系统1的运营商设备20的处理，或者存在作为信用担保系统11的受理时间外的情况。

另外，作为例子，虽然列举了作为信用担保系统1的受理时间外的情况，然而，也可以不设置受理时间，并且除了维护工作外，系统可以处于24小时365天运转的状态。

另一方面，当用户操作用户设备10，例如，访问由运营商设备20运营的信用担保系统1的站点或者直接访问服务器，进行注册化名的申请，并且当运营商设备20受理注册化名的申请时(步骤s20：是(yes))，处理进行到步骤s21，运营商设备20对该用户是否是具有化名注册记录的用户进行判定。

该判定是由于在本实施方式的信用担保系统1中，由于同一用户可以注册两个以上化名，所以在已经具有化名注册记录的用户的情况时，由于注册时的信用验证已经完成，因此，可以执行与其对应的注册处理(稍后将进行说明的步骤s23)即可，另一方面，如果是新用户的情况时，则将执行与其对应的注册处理(稍后将进行说明的步骤s22)。

具体而言，对确认在步骤21中是否具有注册记录的判定进行说明，首先，如上参照图3所述的那样，作为用于识别用户设备10的信息的第一特定别信息被注册在用户信息文件中。

例如，如上所述，当运营商在第一特定信息中指定mac地址的情况时，在可通信的设备中，由于在数据分组通信时，mac地址始终包括在分组中，因此使得运营商设备20将包括在接收受理的(接收的)化名注册申请中的mac地址(也称为发送mac地址)，与存储在用户信息存储区域21ab中的用户信息文件中注册的mac地址(也称为运营商设备的mac地址)进行核对。

然后，在用户信息存储区域21ab中，如果存在与发送的mac地址相同的注册mac地址的用户信息文件时，则运营商设备20判定存在注册记录(步骤s21：是(yes))，然后，进行步骤s23的处理。

与此相反，在用户信息存储区域21ab中，如果不存在与发送的mac地址相同的注册mac地址的用户信息文件时，则运营商设备20判定不存在注册记录(步骤s21：否(no))，然后，进行步骤s22的处理。

另外，如前所述，在本实施方式中，在稍后将进行说明的用户的化名注册时，由运营商提供的利用信用担保系统1的专用应用程序被安装在用户设备10中。并且，该应用程序是在与运营商设备20通信时将应用识别信息发送到运营商设备20的应用程序。

然后，当希望新注册另一个化名时，该应用程序也能够执行操作，在利用该应用程序进行化名注册申请的情况时，由于运营商设备20接收应用识别信息，因此还可以基于存储在用户信息存储区域21ab中的用户信息文件中是否存在已注册了相同的应用识别信息的用户信息文件，来进行步骤s21的判定。

然而，即使利用应用程序已经进行了化名注册申请的情况时，由于运营商设备20可以接收mac地址，因此无需多言，即使利用应用程序已经进行了化名注册申请的情况时，也可以在步骤s21中进行基于mac地址的判定。

然后，如果步骤s21的判定为否(no)的情况时，则运营商设备20进行到步骤s22，并执行对第一用户进行的初次注册处理。

图5示出的是在执行初次注册处理(步骤s22)时，运营商设备20使用户设备10的显示单元11(屏幕)上所显示的内容的示例的示图。

另外，在图5中，示出了用户设备10是可以用作网络摄像机12的智能手机的情况的示例。

也就是说，假设已经在智能手机上安装了可以与远程设备之间交换视频的应用程序。

然而，由于最近的个人电脑从一开始就具备网络摄像机12，因此可以认为假设这样的用户设备10。

如果步骤s21的判定为否(no)的情况时，则如图5所示，运营商设备20使用户设备10的显示单元11(屏幕)显示用于进行新注册化名的指导画面。

并且，在图5中，由于是以用户设备10可以利用网络摄像机12的智能手机为例的情况，因此当用户在用户设备10的显示单元11上执行点击(触摸)“是(yes)”的操作时，网络摄像机12连接到受理负责人(担保太郎)。

更准确地说，显示用于查询为了连接的ip地址等的画面等，并且当这些输入等完成时，网络摄像机12连接到受理负责人(担保太郎)。

另外，如果用户设备10不能用作网络摄像机12，并且用户选择“否(no)”的情况时，则在用户设备10的显示单元11上，显示不使用网络摄像机12来执行化名的新注册的方法。

作为不使用网络摄像机12进行化名的新注册的方法，例如，可以考虑介绍最近的进行化名的新注册的店铺(包括当前项目的商业合作伙伴的申请处理店铺)，或者，可以考虑受理负责人(担保太郎)来到用户的家中进行指导。

另外，作为不使用网络摄像机12进行化名的新注册的方法，例如，如果当前项目的商业合作伙伴包括邮政服务或者快递运营商的情况时，该运营商(邮政服务件或者快递运营商)来到用户的家中进行指导。

再返回刚才，当受理负责人和网络摄像机12连接时，例如，根据受理负责人的指令，进行化名的新注册。

首先，受理负责人确认用户想要制作什么样的担保内容。

然后，如果用户希望运营商向第三方担保的内容中具有真实地址，则受理负责人指令至少将可以证明该真实地址的文档(信用验证文档)显示在网络摄像机12上，并且进行在网络摄像机12上获取文档(信用验证文档)作为信用验证文档的数据(例如，pdf)的处理。

此外，此时，也可以进行在网络摄像机12上获取用户的照片的处理。

然而，在本实施方式中，尽管受理负责人通过网络摄像机12指令用户，但是，也可以代替受理负责人，通过解析网络摄像机12上捕获的画像的画像分析程序(面部认证程序等)和语音引导等无人值守进行。

另外，当信用验证文档中不包括用户的照片的情况时，为了担保文档的可靠性，也可以进行获取两个以上的不同文档的处理。

例如，当信用验证文档是居民卡的情况时，可以另外获取健康保险卡作为除了居民卡之外的文档，其可以确认与居民卡中所记载的用户的真实姓名相同的真实姓名。

此外，如果用户希望运营商向第三方担保的内容为能够验证身份，则受理负责人至少指令以将能够验证身份的文档(例如，驾驶执照、驾驶履历证明书、护照(passport)、个人号码卡、残疾人手册、居留卡、特别永久居留证、工作证、学生证、健康保险卡(公共医疗保险的参保卡/被保险者证书)、养老金手册、儿童抚养津贴证明、特殊儿童抚养津贴证明等的任意一个文档)作为身份可验证文档，显示在网络摄像机12上，并且进行用于在网络摄像机12上获取文档(信用验证文档)作为信用验证文档的数据(例如，pdf)处理。

另外，在这种情况下，当可验证本人的身份的文档中没有照片的情况时，为了确保文档的可信度，可以进行以获取两个以上的不同的文档的处理。

如上所述，当获取信用验证文档的数据，并且用户的信用验证已经完成时，受理负责人操作运营商设备20发送用于在用户设备10中利用信用担保系统1的专用应用程序，并且进行将该用户的用户信息文件存储在用户信息存储区域21ab中的操作，并且进一步进行发送与在用户信息文件中注册的用户个人信息相关的运营商的服务条款的操作。

据此，当初次注册处理(步骤s22)结束时，运营商设备20再次执行监视循环处理。

另外，尽管在图4中未示出，但是在初次注册处理(步骤s22)结束，并且处理返回到监视循环处理之前，运营商设备20向用户设备10发送用于验证用户所注册的用户信息文件的内容的数据。

例如，运营商设备20向用户设备10发送作为用户信息文件的化名信息a的第二特定信息、网名的内容、用户真实信息b的内容、以及信用验证文档数据d所保管(注册)的文档的文档名称等。

另外，当受理负责人确认到用户想要使用何种类型的担保内容时，如果用户希望注册网名，则网名被注册在用户信息文件中，如果不希望，则网名不被注册。

此外，在初次注册处理(步骤s22)时，受理负责人可以通过网络摄像机12向用户简要说明专用的应用程序的安装方法和使用方法，或者也可以进行关于用户信息文件中所注册的用户的个人信息的运营商的服务条款的口头说明。

另一方面，如果在步骤s21的判定为是(yes)的情况时，则运营商设备20进行步骤s23，执行针对先前有化名的注册记录的用户所进行的第一特定信息共通注册处理，然后，再次执行监视循环过程。

图6是表示当执行第一特定信息共通注册处理(步骤s23)时，运营商设备20使用户设备10的显示单元11(屏幕)上显示的内容的示例的示图。

如果步骤s21中的判定为是(yes)的情况时，如图6所示，则运营商设备20使先前有化名的注册记录的用户的引导画面显示在用户设备10的显示单元11(屏幕)。

然后，当用户执行点击(触摸)用户设备10的显示单元11的“是(yes)”操作时，运营商设备20将化名信息a的第一特定信息、网名、用户真实信息b、以及信用验证文档数据d设置为与先前注册的内容相同的内容，并且将注册了新的第二特定信息的用户信息文件存储在用户信息存储区域21ab中，然后，再次返回到监视循环处理。

另外，在这种情况下，由于担保通知还没有使用新的第二特定信息以化名发送给第三方，因此担保通知发行履历c为空栏状态。

此外，与先前的初次注册处理(步骤s22)中说明的相同，尽管在图4中未示出，但是在第一特定信息共通注册处理(步骤s23)结束，并且处理返回到监视循环处理之前，运营商设备20向用户设备10发送用于验证用户所注册的用户信息文件的内容的数据。

也就是说，例如，运营商设备20将用户信息文件的化名信息a的第二特定信息信息、网名的内容以及用户真实信息b的内容作为信用验证文档数据d保管(注册)的文档的文档名称等发送给用户设备10。

此外，在第一特定信息共通注册处理(步骤s23)的情况时，由于在用户设备10中已经安装了由运营商提供的用于利用信用担保系统1的专用应用程序，所以不进行应用程序的发送。

另一方面，在图6所示的画面的显示中，当用户在用户设备10的显示单元11上执行点击(触摸)“否(no)”的操作时，如与先前的图5中示出的相同，运营商设备20执行在网络摄像机12可用的设备的情况下点击“是(yes)”，以及在网络摄像机12不可用的设备的情况下，在用户设备10的显示单元11上执行点击“否(no)”的画面显示处理。

然后，例如，当用户点击“是(yes)”的情况时，与先前所述的相同，网络摄像机12连接到受理负责人，并且受理负责人向用户询问来自先前注册的内容的变更等，根据该变更内容的内容，将具有新的第二特定信息的用户信息文件存储在用户信息存储区域21ab中。

然而，在这种情况下，由于化名信息a的第一特定信息是用于识别用户设备10的信息，所以先前注册的内容按原样注册而不被改变。

另外，当变更内容涉及额外注册或者删除信用验证文档的数据时，该处理也被执行。

另一方面，当用户点击“否(no)”的情况时，与初次注册处理(步骤s22)的时候相同，执行不使用网络摄像机12注册化名的方法，例如，可以考虑介绍最近的进行化名的新注册的店铺(包括当前项目的商业合作伙伴的申请处理店铺)，或者，可以考虑受理负责人(担保太郎)来到用户的家中进行指导。

如上所述，已完成信用验证的用户的化名被注册到运营商设备20中。

接下来，当用户操作用户设备10，例如，当向运营商设备20进行用于确认用户信息文件的注册内容的注册内容查询申请(步骤s30)时，(步骤s30：是(yes))，已经接收到注册内容查询申请的运营商设备20如图4所示的那样，首先，执行用户设备10的认证判定(步骤s31)。

该注册内容查询申请(步骤s30)由安装在用户设备10中的应用程序执行，当该申请被执行时，从该应用程序向运营商设备20发送包括独特识别信息(应用识别信息)的认证信息，该独特识别信息(应用识别信息)仅对给与每个应用程序的运营商公开。

因此，运营商设备20基于认证信息进行认证，该认证信息包括当用户设备10(已安装了应用程序)在运营商设备20上进行注册内容查询申请(步骤s30)时联络的应用识别信息、还包括注册在运营商设备20上的应用识别信息，当认证通过(步骤s31：是(yes))的情况时进行步骤s32，执行用于向用户设备10通知注册内容的注册内容通知处理(步骤s32)，然后，再次返回监视循环处理。

具体而言，当从用户设备10向运营商设备20执行注册内容查询申请(步骤s30)的情况时，用户设备10将上述说明的应用识别信息和第二特定信息作为认证信息发送给运营商设备20，接收到该认证信息的运营商设备20参照用户信息存储区域21ab中的第二特定信息中所注册的用户信息文件，验证该用户信息文件中所注册的应用识别信息和发送来的应用识别信息是否一致，当一致的情况时，判定为通过认证(步骤s31：是(yes))，当不一致的情况时，判定为认证没有通过(步骤s31：否(no))。

另外，在数据包通信时，由于包括在数据包中的用户设备10的mac地址(发送mac地址)也从用户设备10发送，例如，所以，运营商设备20可以通过使用应用识别信息和传输mac地址作为认证信息，来参考用户信息存储区域21ab中的传输mac地址中所注册的用户信息文件，验证注册在用户信息文件中的应用识别信息是否与所传输来的应用识别信息一致。

然而，在这种情况下，在用户注册了两个以上的化名的情况时，由于会发现两个以上的用户信息文件，所以当发现两个以上的用户信息文件的情况时，运营商设备20利用第二特定信息向用户信息文件进行筛选，并基于与筛选到的用户信息文件的应用识别信息的一致或者不一致从而进行认证判定。

然后，当判定为没有通过认证(步骤s31：否(no))的情况时，尽管图4中未示出，但是运营商设备20将运营商的负责人的联系地址(例如，咨询电话号码)发送到用户设备10，以促使用户联系运营商负责人，另一方面，当通过认证(步骤s31：是(yes))的情况时，由于已经验证查询请求来自授权用户，因此执行用于将注册内容通知给用户设备10的注册内容通知处理(步骤s32)，然后，再次返回到监视循环处理。

这里，所执行的用于将注册内容通知给用户设备10的注册内容通知处理(步骤s32)被执行为根据来自用户设备10的请求的内容。

例如，如果是请求查询所有注册内容时，则经由互联网向用户设备10发送化名信息a的第二特定信息、网名、用户真实信息b的所有内容、担保通知发行履历c的所有内容，以及所有信用验证文档数据d。

另外，不发送化名信息a的第一特定信息的原因在于它可能被用作如上所述的与安全性有关的信息。

另一方面，在仅查询化名信息a的请求时，则化名信息a的第二特定信息和网名经由互联网被发送到用户设备10，在仅查询用户真实信息b的请求时，则用户真实信息b的全部内容经由互联网被发送到用户设备10。

此外，如果是仅查询用户真实信息b的电话号码或者电子邮件地址的查询请求时，则用户真实信息b的电话号码或电子邮件地址经由互联网被送发送到用户设备10。

接下来，如果用户操作用户设备10，例如在运营商设备20上接收到担保联络申请(步骤s40)时，则步骤s40变为“是(yes)”，并且运营商设备20进行到步骤s41。

也就是说，当运营商设备20从用户设备10接收到需要担保信用的担保联络的第三方设备30的联络(接收到第三方设备30的联系方式)时，运营商设备20执行担保通知处理(步骤s42)，用于向第三方设备30通知用户的化名为已完成信用验证的内容的担保通知，但是此处，与上述情况一样，运营商设备20首先执行认证以验证担保联络的请求是否来自授权用户，并且当认证通过(步骤s41：是(yes))的情况时，执行担保通知处理(步骤s42)。

由于此处的认证也与上述认证相同，因此仅简单地进行说明，但是担保联络申请(步骤s40)将由安装在用户设备10中的应用程序执行，当该申请被执行时，从该应用程序向运营商设备20发送包括独特识别信息(应用识别信息)的认证信息，该独特识别信息(应用识别信息)仅对给与每个应用程序的运营商公开。

因此，运营商设备20基于认证信息进行认证，该认证信息包括当用户设备10(已安装了应用程序)在运营商设备20上进行担保联络申请(步骤s40)时联络的应用识别信息、还包括注册在运营商设备20上的应用识别信息，当认证通过(步骤s41：是(yes))的情况时、执行担保通知处理(步骤s42)，进行用于向第三方设备30发送用户的化名为已完成信用验证的内容的担保通知，然后，再次返回监视循环处理。

具体而言，当从用户设备10向运营商设备20执行担保联络申请(步骤s40)的情况时，用户设备10将上述说明的应用识别信息和第二特定信息作为认证信息发送给运营商设备20，接收到该认证信息的运营商设备20参照用户信息存储区域21ab中的第二特定信息中所注册的用户信息文件，验证该用户信息文件中所注册的应用识别信息和发送来的应用识别信息是否一致，当一致的情况时，判定为通过认证(步骤s41：是(yes))，当不一致的情况时，判定为认证没有通过(步骤s41：否(no))。

然后，当判定为没有通过认证(步骤s41：否(no))的情况时，尽管图4中未示出，但是运营商设备20将运营商的负责人的联系地址(例如，咨询电话号码)发送到用户设备10，以促使用户联系运营商负责人，另一方面，当通过认证(步骤s41：是(yes))的情况时，由于已经验证担保联络请求来自授权用户，因此执行用于向第三方设备30进行担保通知的担保通知处理(步骤s42)，然后，再次返回到监视循环处理。

另外，这里所执行的用于将担保通知通知给第三方设备30的担保通知处理(步骤s42)被执行为根据来自用户设备10的请求的内容。

例如，在来自用户设备10的请求仅仅是担保通知的情况时，响应于注册时的信用验证的内容是用户地址的验证这一事实，向第三方设备担保用户使用的化名为确实具有真实地址的用户使用的化名的担保通知，担保通知以不公开诸如真实姓名或者当前地址的个人信息的形式进行。

图7示出的是以不公开诸如真实姓名或者当前地址的个人信息的形式，执行担保化名为确实具有真实地址的用户使用的化名的担保通知的示例的示图，并且是由运营商设备20经由互联网向第三方设备30通知的担保通知中所附带的担保通知书的示例。

然而，由于担保通知本身并没有文本等，仅是一种发送担保通知书的处理的情况，所以担保通知仅仅意味着发送担保通知书的情况。

另外，在图7中，使用第三方设备30的“株式会社ttt”被称为“rrr”。

此外，该担保通知书可以由运营商设备20根据运营商设备20中预先准备的模板而发行。

如图7所示，在这种情况时，用户的地址被作为运营商的信用验证内容进行验证，并且担保地址可验证文档是保管在运营商中的用户使用的化名的担保通知被发送到第三方设备30。

另外，担保通知书上具有电子签名，该电子签名是作为运营商的化名信用担保株式会社的担保印章。

此外，图7示出了在化名信息a中注册了网名的用户的情况。然而，当未注册网名的情况时，则成为删除“网名的”部分。

然而，图7仅是示例，例如，文本部分(“使用化名(第二特定信息)的网名的用户为我们已经完成当前地址验证的用户，并且，我们担保能够验证该当前地址的地址可验证文档保管在我们会社。”)可以是运营商用于显示担保的设计(图标)，并且在这种情况下，担保通知书上也可以具有电子签名，该电子签名是作为运营商的化名信用担保株式会社的担保印章。

另一方面，例如，在来自用户设备10的请求仅仅是担保通知的情况时，响应于注册时的信用验证的内容是用户身份的认证这一事实，向第三方设备30担保用户使用的化名确实是由运营商完成身份验证的用户使用的化名的担保通知，担保通知以不公开诸如真实姓名或者当前地址的个人信息的形式进行。

在这种情况下，例如，图7中的进行担保的文本部分成为“使用化名(第二特定信息)的网名的用户是我们完成身份验证的用户，并且，我们担保能够验证该身份验证的身份可验证文档保管在我们会社。”等。

另外，在这种情况下，文本部分(“使用化名(第二特定信息)的网名的用户是我们完成身份验证的用户，并且，我们担保能够验证该身份验证的身份可验证文档保管在我们会社。”)可以是运营商用于显示担保的设计(图标)。

另外，考虑到一些第三方会要求出示地址可验证文档和身份可验证文档，例如，当来自用户设备10的请求(担保联络)是向第三方设备30通知利用化名的用户的地址已完成验证的担保通知的请求时，并且，该请求(担保联络)中还包括出示地址可验证文档的指令的情况时，该地址可验证文档是运营商(运营商设备20)向第三方设备30进行担保通知时，由用户提供，并被注册在运营商设备20上，在运营商的信用验证时用于进行地址验证；在运营商设备20发送担保通知时，除了图7中示出的担保通知书之外，还一起发送并出示由用户设备10的请求(担保联络)指定的地址可验证文档。

此外，类似地，当来自用户设备10的请求(担保联络)是向第三方设备30通知利用化名的用户的身份已完成验证的担保通知的请求时，并且，该请求(担保联络)中还包括出示身份可验证文档的指令的情况时，该身份可验证文档是运营商(运营商设备20)向第三方设备30进行担保通知时，由用户提供，并被注册在运营商设备20上，在运营商的信用验证时用于进行身份验证；在运营商设备20发送担保通知时，除了图7中示出的担保通知书之外，还一起发送并出示由用户设备10的请求(担保联络)指定的身份可验证文档。

进一步，来自用户设备10的请求(担保联络)包括在担保联络中将用户的姓名(真实姓名)、地址、电子邮件地址以及电话号码中的任意一个出示给第三方设备30的指令的情况时，则在通知用户的化名(第二特定信息)为已完成信用验证的内容的担保通知时，出示用户姓名(真实姓名)、地址、电子邮件地址和电话号码中的被指定的内容。

在这种情况下，例如，如图7所示的担保通知书的一部分中，可以追加被指定的内容(用户的姓名(真实姓名)、地址、电子邮件地址和电话号码)。

如上所述，当运营商设备20执行向第三方设备30进行担保通知的担保通知处理(步骤s42)时，尽管处理再次返回到监视循环处理，然而，在返回到监视循环处理之前，尽管在图4中省略了图示，但如上所述，运营商设备20将进行担保通知的履历记录到用户信息文件的担保通知发行履历c中。

接下来，当用户操作用户设备10，例如当运营商设备20上出现注册内容变更申请(步骤s50)时，则步骤s50变为是(yes)，并且运营商设备20进行到步骤s51。

另外，当运营商设备20从用户设备10接收到注册内容变更申请(步骤s50)时，则运营商设备20执行进行变更用户信息文件的注册内容的注册内容变更处理(步骤s52)，但是此处，与上述情况一样，运营商设备20首先执行认证以验证注册内容变更的请求是否来自授权用户，并且当认证通过(步骤s51：是(yes))的情况时，执行注册内容变更申请处理(步骤s52)。

由于此处的认证也与上述认证相同，因此仅简单地进行说明，注册内容变更申请(步骤s50)将由安装在用户设备10中的应用程序执行，当该申请被执行时，从应用程序向运营商设备20发送包括独特识别信息(应用识别信息)的认证信息，该独特识别信息(应用识别信息)仅对给与每个应用程序的运营商公开。

因此，运营商设备20基于认证信息进行认证，该认证信息包括当用户设备10(已安装了应用程序)在运营商设备20上进行注册内容变更申请(步骤s50)时联络的应用识别信息、还包括注册在运营商设备20上的应用识别信息，当认证通过(步骤s51：是(yes))的情况时，执行注册内容变更申请(步骤s52)。

具体而言，当从用户设备10向运营商设备20执行注册内容变更申请(步骤s50)的情况时，用户设备10将上述说明的应用识别信息和第二特定信息作为认证信息发送给运营商设备20，接收到该认证信息的运营商设备20参照用户信息存储区域21ab中的第二特定信息中所注册的用户信息文件，验证该用户信息文件中所注册的应用识别信息和发送来的应用识别信息是否一致，当一致的情况时，判定为通过认证(步骤s51：是(yes))，当不一致的情况时，判定为认证没有通过(步骤s51：否(no))。

然后，当判定为没有通过认证(步骤s51：否(no))的情况时，尽管图4中未示出，但是运营商设备20将运营商的负责人的联系地址(例如，咨询电话号码)发送到用户设备10，以促使用户联系运营商负责人，另一方面，当通过认证(步骤s51：是(yes))的情况时，由于已经验证注册内容变更来自授权用户，因此执行注册内容变更处理(步骤s52)。

图8示出了当执行注册内容变更处理(步骤s52)时，运营商设备20使用户设备10的显示单元11(屏幕)显示的内容的示例的示图。

当步骤s51的判定为是(yes)的情况时，则如图8所示，运营商设备20使用户设备10的显示单元11(屏幕)显示注册内容变更的情况的引导画面。

然后，当用户执行点击(触摸)用户设备10的显示单元11的“是(yes)”的操作时，和上述相同，网络摄像机12连接到受理负责人，并且受理负责人向用户询问注册内容的变更点等，受理负责人将该变更点反映在用户信息存储区域21ab中所注册的用户信息文件中。

另外，随着变更内容，如果需要，还可以进行信用验证文档的数据的变更等。

另一方面，当用户点击“否(no)”的情况时，和上述相同，执行不使用网络摄像机12变更注册内容的方法，例如，可以考虑介绍最近的能够进行注册内容变更的店铺(包括当前项目的商业合作伙伴的申请处理店铺)，或者，可以考虑受理负责人(担保太郎)来到用户的家中进行指导。

据此，当注册内容变更处理(步骤s52)完了时，运营商设备20接下来对第三方设备30执行注册内容变更通知处理(步骤s53)，然后，再次返回监视循环处理。

该注册内容变更通知处理(步骤s53)是运营商设备20参照用户信息文件的担保通知发行履历c，向先前已经通知过的第三方设备进行如下内容的联络处理，所述内容为担保通知内容中包括与当前的变更点相关的内容的担保通知。

例如，如果当前的变更点是电话号码的变更，并且电话号码被注册在先前已经向第三方设备30通知过的担保通知(担保通知中添附的担保通知书)中，或者，根据用户的希望进行出示电话号码的情况时，运营商设备20向所述第三方设备30通知电话号码发生了的变更的内容的注册内容变更通知。

另外，该注册内容变更通知不是公开与个人信息相对应的变更后的电话号码的通知，其仅是注册了不同于先前的担保通知时的电话号码的电话号码的通知，并且第三方提示用户要求运营商重新通知担保通知。

据此，当在向第三方设备30的担保通知之后，用户的已完成信用验证的内容中发生变更的情况时，作为注册内容变更通知处理(步骤s53)，运营商设备20向第三方设备30通知担保通知，担保通知的内容为已完成信用验证的内容中发生了变更，然后，再次返回监视循环处理。

根据如上所述的本实施方式的信用担保系统1，当运营商仅需要向化名进行信用担保的情况时，用户可以与第三方进行商业交易，而不公开诸如真实姓名等的个人信息。

此外，当用户要求的情况时，由用户指定的个人信息等被出示给第三方，从而可以平稳地推进商业交易等。

另外，尽管上述的说明主要是针对商业交易而进行的，然而，在商业交易以外的情况时，同样，也有需要向化名的信用担保的情况，因此，信用担保系统1并非仅适用于商业交易。

第二实施方式

接下来，对本发明所涉及的第二实施方式的信用担保系统1进行说明。

图9是表示用于说明本发明所涉及的第二实施方式的信用担保系统1的示图。

另外，第二实施方式的信用担保系统1在许多方面类似于第一实施方式的信用担保系统1，并且在下文的说明中，主要对与第一实施方式不同的部分进行说明，并且在一些情况下省略对相同的部分的说明。

如图9所示，本实施方式的信用担保系统1包括两个以上的运营商设备20，并且为每个所规定的区域设置运营商设备20。

在图9中，作为所规定的区域，虽然可以列举：欧洲(例如，欧盟(eu))、中国(cn)、日本(jp)以及美国(us)等被假定为所规定的区域，但是并不仅限于此。例如，还可以在欧洲的每个所规定的区域设置运营商设备20，或者也可以通过将us划分为两个以上的区域，在每个所规定的区域设置运营商设备20。

并且，设置在每个区域的运营商设备20作为该区域的责任者，执行与第一实施方式中所述的相同的处理。

另外，每个运营商设备20的配置本身与参照图2所说明的第一实施方式的运营商设备20的配置相同。

另一方面，由于存在两个以上的运营商设备20，所以本实施方式具有添加到第一实施方式中所说明的用户信息文件的项目。

图10是表示用于说明本发明所涉及的第二实施方式的运营商设备20的存储单元21a中所存储的用户信息文件的示图。

从图3和图10之间的对比可以看出，在图10所示的第二实施方式的用户信息文件中，第三特定信息被添加到化名信息a。

该第三特定信息是运营商设备20中特有的独特信息，由于图10所示的用户信息文件由执行注册化名处理的运营商设备20创建的，所以，已经执行注册化名处理的运营商设备20中特有的独特第三特定信息被注册在用户信息文件中。

并且，该第三特定信息被用作在运营商设备20之间需要识别化名的情况时的化名。

具体而言，在第一实施方式中，化名按原样用作第二特定信息，然而，在本实施方式中，在同一运营商设备20中处理化名时，第二特定信息被用作化名，并且，在运营商设备20之间处理化名的情况时，将第三特定信息作为化名添加到第二特定信息的头部，所以化名不仅包括第二特定信息，还包括第三特定信息。

另外，不言而喻的是，即使是在同一运营商设备20中的化名的处理，也可以作为包括第二特定信息和第三特定信息的化名来处理。

这样，第三特定信息是信用担保系统1上的用户的化名中使用的附加信息，据此，在运营商设备20之间查看时，即使存在相同的化名(第二特定信息)，也可以通过将第三特定信息添加到化名，从而确保化名的独特性。

然而，当存在两个以上的运营商设备20时，第三特定信息不是不可缺少的条件。

例如，当执行注册化名的处理时，如果第二特定信息被给与为独特的信息的情况时，则第三特定信息是不必要的，即使当在运营商设备20之间查看到。

并且，在如上所述的本实施方式的信用担保系统1中，也可以实现与第一实施方式相同的效果。

此外，在本实施方式的信用担保系统1中，由于为每个所规定的区域设置了运营商设备20，因此，不仅容易对每个区域提供周到的支持，而且在任意一个运营商设备20由于维护等原因停止服务时，可以使其他的运营商设备20暂时执行处理。

第三实施方式

接下来，对本发明所涉及的第三实施方式的信用担保系统1进行说明。

图11是表示用于说明本发明所涉及的第三实施方式的信用担保系统1的示图。

另外，第三实施方式的信用担保系统1在许多方面也类似于第二实施方式的信用担保系统1，并且在下文的说明中，主要对与第二实施方式不同的部分进行说明，并且在一些情况下省略对相同的部分的说明。

如图11所示，在本实施方式中，也与第二实施方式相同，信用担保系统1包括两个以上运营商设备20，然而，在本实施方式中，以运营商设备20中的一个作为主运营商设备20，而将除此以外的运营商设备20作为辅助运营商设备20。

并且，当辅助运营商设备20执行某些处理的情况时，该处理内容从辅助运营商设备20被发送到主运营商设备20，并且主运营商设备20将由其他辅助运营商设备20执行的所有处理内容作为副本。

另外，辅助运营商设备20以及主运营商设备20的配置本身与参照图2所说明的第一实施方式的运营商设备20相同。

但是，在主运营商设备20的用户信息存储区域21ab中，存储了各辅助运营商设备20的用户信息存储区域21ab中所存储的用户信息文件。

更详细地，参照图12和图13，对本实施方式中的辅助运营商设备20和主运营商设备20的主要处理进行说明。

图12是表示用于说明本发明所涉及的第三实施方式的辅助运营商设备20的主要处理的示图。图13是表示用于说明本发明所涉及的第三实施方式的主运营商设备20的主要处理的示图。

首先，参考图12，对辅助运营商设备20的主要处理的流程进行说明。

然而，从图4和图12之间的对比可以看出，由于辅助运营商设备20的处理在许多方面与第一实施方式中说明的运营商设备20的处理相同，所以在下文中，仅对主要的不同之处进行说明，并且，可以省略与第一实施方式中说明的内容相同的点的说明。

在第一实施方式中，运营商设备20是一种在执行初次注册处理(步骤s22)，第一特定信息共通注册处理(步骤s23)，担保通知处理(步骤s42)以及注册内容变更通知处理(步骤s53)之后，再次返回监视循环处理的设备。

另一方面，本实施方式的辅助运营商设备20在执行初次注册处理(步骤s22)，第一特定信息共通注册处理(步骤s23)，担保通知处理(步骤s42)以及注册内容变更通知处理(步骤s53)之后，在向主运营商设备20进行处理内容的通知(步骤s24，步骤s43以及步骤s54)之后，返回监视循环处理。

因此，当各辅助运营商设备20进行与用户信息文件相关的处理(用户信息文件的新注册、用户信息文件的内容变更等)时，主运营商设备20接收来自该各辅助运营商设备20的与用户信息文件相关的处理(用户信息文件的新注册、用户信息文件的内容变更等)的内容的通知，通过将这些通知反映在主运营商设备20的用户信息存储区域21ab中，使所有的辅助运营商设备20的用户信息存储区域21ab中所存储的用户信息文件存储在主运营商设备20中。

另一方面，基本上，如果辅助运营商设备20执行与用户信息文件相关的处理(用户信息文件的新注册、用户信息文件的内容变更等)时，如上所述，由于该处理内容反映到主运营商设备20上，使得注册在主运营商设备20中的用户信息文件成为最新状态。

然而，在本实施方式中，为了谨慎起见，仅在主运营商设备20周期性地向辅助运营商设备20发送查询用户信息文件的请求时，才从辅助运营商设备20通知最新的用户信息文件的内容的通知。

另外，该查询请求不仅可以是针对所有用户信息文件的查询请求，还可以是仅针对在特定时段中所注册的用户信息文件的查询请求。

因此，如图12所示，在辅助运营商设备20的处理中，添加了用于判定是否存在来自主运营商设备20的查询请求的步骤s60(来自主运营商设备20的查询请求)，并且当存在来自主运营商设备20的查询请求(步骤s60：是(yes))的情况时，则处理进行到步骤s61，其中，将根据来自主运营商设备20的查询请求的数据(用户信息文件的数据)，通知给主运营商设备20，然后，再次返回监视循环过程。

另外，如果步骤s60为否(no)的情况时，则不进行到步骤s61而继续监视循环过程。

接下来，参照图13对主运营商设备20的主要处理的流程进行说明。

如图13所示，当主运营商设备20开始处理时，主运营商设备20执行监视循环处理以监视步骤s10，s70和s80中的任意一个变为“是(yes)”。

然后，当主运营商设备20通过运营商的操作接收到运营商设备停止处理时(步骤s10：是(yes))，处理结束，这一点与上述相同。

另一方面，当主运营商设备20接收到在辅助运营商设备20执行处理之后通知的辅助运营商设备20的处理内容通知时(步骤s70：是(yes))，反映该所通知的处理内容通知的内容(步骤s71)，然后，再次返回到监视循环处理。

例如，作为一个示例可以列举：当辅助运营商设备20进行了新用户的用户信息文件的注册的情况时，由于从辅助运营商设备20通知新用户的用户信息文件的内容被作为处理内容通知，所以使得在步骤s71中，主运营商设备20将该新用户信息文件反映在主运营商设备20的用户信息存储区域21ab的存储中，然后，再次返回到监视循环处理。

此外，当对辅助运营商设备20的定期查询的时点到来时(步骤s80：是(yes))，主运营商设备20进行到步骤s81，对辅助运营商设备20进行查询请求的通知。

然后，主运营商设备20监视是否已经接收到根据查询请求来自辅助运营商设备20的数据的通知(步骤s82)，并且当已经接收到根据查询请求来自辅助运营商设备20的数据的通知时(步骤s82：是(yes))，将从辅助运营商设备20所通知的数据(用户信息文件的数据)的内容反映在主运营商设备20的用户信息存储区域21ab(用户信息存储区域21ab的用户信息文件)的存储中(步骤s83)，然后，再次返回到监视循环处理。

如上所述，第三实施方式的信用担保系统1构成为，如图11所示，以运营商设备20中的一个作为主运营商设备20，剩余的运营商设备20作为辅助运营商设备20，并且在主运营商设备20和辅助运营商设备20之间进行数据共享(参照图11中的粗箭头)，使得主运营商设备20可以根据需要，集中进行管理用户信息文件。

另外，在本实施方式中，主运营商设备20保留整个信用担保系统1的用户信息文件，并且如果需要，可以仅恢复辅助运营商设备20的用户信息文件等，然而，主运营商设备20也可以执行与辅助运营商设备20相同的处理。

在这种情况时，可以将图4所示的处理添加到图13所示的主运营商设备20的处理中。

也就是说，监视循环处理可以被配置为包括步骤s10、步骤s70、步骤s80、步骤s20、步骤s30、步骤s40以及步骤s50，并且可以执行上述的处理。

以上，尽管基于具体实施方式对本发明进行了说明，但是本发明并不限于上述具体的实施方式。

例如，尽管在上述实施方式中对运营商是诸如株式会社等的法人的情况进行了说明，但是并不仅限于此，还可以是国家政府或者地方政府等、国家政府和地方政府可以合作配置运营商、或者两个以上的国家可以合作配置运营商。

此外，与运营商合作的企业(例如银行)或者政府行政办事机构可以实施用户的信用验证，并且在完成信用验证之后，可以从与运营商合作的企业(例如银行)或者政府行政办事机构等接收信用验证文档的数据(例如，pdf)，并且希望利用已经进行了信用验证的已完成信用验证的化名的用户的用户信息文件可以存储在用户信息存储区域21ab中。

进一步，在上述实施方式中，虽然对第三方是诸如用户的两个交易的伙伴的情况进行了说明，然而，例如，第三方也可以是通过社交互联网服务或社交互联网游戏与用户交流的伙伴。

在这种情况下，第三方也可能希望用化名与用户交流，而不透露个人信息，因此，第三方的第三方设备30可以成为希望利用化名的用户的用户设备10。

在这种情况下，一个用户让另一个用户给出化名为运营商已完成信用验证的内容的担保通知，并且，另一个用户同样让对方给出化名为运营商已完成信用验证的内容的担保通知，但上述的内容并无特别不同。

也就是说，当一个用户单独查看该状态时，如果一个用户让另一个用户给出化名为运营商已完成信用验证的内容的担保通知的情况时，则一个用户的设备成为用户设备10，另一个用户的设备成为第三方设备30，与此相反，如果另一个用户同样让对方给出化名为运营商已完成信用验证的内容的担保通知的情况时，另一用户的设备成为用户设备10，并且一个用户的设备成为第三方设备30，并且上述的内容完全没有变化。

在上述实施方式中，虽然示出的是每个用户的用户信息文件存储在用户信息存储区域21ab中，然而，每个用户的信息也可以是用户信息数据库。

如上所述，本发明并不限于所述的具体实施方式，对于本领域的技术人员来说，从权利要求的记载中显而易见的是，进行适当修改或改进的内容也包括在本发明的技术范围内。

附图标记说明

1…信用担保系统；

10…用户设备；

11…显示单元；

12…网络摄像机；

20…运营商设备；

21…主体单元；

21a…存储单元；

21aa…程序存储区域；

21ab…用户信息存储区域；

21ac…临时存储区域；

21ad…其他存储区域；

21b…cpu；

21c…通信单元；

21d…总线；

22…显示单元；

23…操作单元；

30…第三方设备；

a…化名信息；

b…用户真实信息；

c…担保通知发行履历；

d…信用验证文档数据。