CN107408267A - 访问控制装置、方法以及程序 - Google Patents

Abstract

对于在多个国家设置网点的银行而言，构建各网点的银行职员可共有各网点所具有的信息的系统非常有用。以往，在这样的所有网点的银行职员都可利用的系统中，不存在按国家来遵守不同的法规制度并且进行适当的访问控制并向适当的人公开适当的信息的系统。本发明提供一种多个国家的雇员遵守各国的法规制度并且能根据雇员的职务来访问共有的信息的系统、方法以及程序。

Description

访问控制装置、方法以及程序

技术领域

本发明涉及访问控制。更详细而言，涉及一种在多个国家具有营业网点的银行的各网点的银行职员之间共有信息时，按国家来遵守不同的法规制度，并且，根据其银行职员的职务来提供访问控制的技术。

背景技术

近年，伴随着经济的全球化，许多企业向海外发展。各银行为了支持向海外发展的企业而在亚洲、大洋洲、美洲、欧州等设有营业网点。

作为银行的融资方式，存在对特定的企业进行融资的公司融资(corporatefinance)、以及分析特定项目的现金流量(cash flow)来预测收益并将此项目的资产价值作为担保来进行融资的项目融资(project finance)。特别是，不仅国内的企业，对于涉及多个外国企业的项目融资，银行需要验证跨多个国家的债务人、资助人(sponsor)(对此项目的特定目标公司出资的企业)以及承购商(off-taker)(购入此项目的产物的企业)等(以下，统称为“相关当事人”)的信用风险，并进行信贷判断。此外，对在多个国家开展业务的全球性企业进行的融资的信贷判断中，银行内的多个网点的银行职员也需要共有信息。

但是，与顾客信息的处理有关的法规制度因国而异。在海外的分行，必须遵守这个国家的法规制度并且管理顾客信息。因此，所处理的信息大多按分行来进行管理，有时分行间的信息共有未充分进行。例如，在上述那样的信贷判断中需要基于顾客的管理层、业务内容、财务状况、信贷状况来综合地进行判断，但却存在跨多个国家的网点间信息共有未充分进行的案例。

而且，银行是公共性极高的企业，不仅要遵守营业上的法律、规则等法令，还要求遵守社会的规范、企业伦理。特别是在超大银行(megabank)中，要求对合规(compliance)格外重视，实效性高的合规组织体制的配备是必不可少的。例如，在日本，从内部统一管理以及个人信息保护的观点出发，在银行内部要求高度重视对机密性高的文件的处理。特别是，在上述那样在多个国家设置网点的超大银行中，由于按国家必须遵守的法律的内容、基准不同，因此，要求进一步重视合规。

而且，在银行所处理的信息中存在多种多样的信息，因此，需要重视对内部信息的访问。例如，如果M&A信息等在被公之于众之前就可被访问，则存在导致内部交易的危险。需要将共有的信息划分为各部分(parts)，并使信息的公开/非公开可设定。

对于在多个国家设置网点的银行而言，构建一种各网点的银行职员可共有各网点所具有的信息的系统是非常有用的。以往，在这样的所有网点的银行职员都可利用的系统中，并不存在一种按国家来遵守不同的法规制度并且进行适当的访问控制来向适当的人公开适当的信息的系统。

因此，本发明的目的在于，使在多个国家设置网点的银行的各网点的银行职员能共有信息，并且，防止没有权限的银行职员访问共有的信息而不会违反各国的法规制度。

发明内容

为了达到这样的目的，本发明的由全球信贷管理系统来执行的信息访问控制方法，具有：接收用户的登录ID的步骤；判定与所述登录ID建立关联的职务以及所述用户所属的实体的步骤；以及判定可否对所述用户所尝试访问的信息进行访问的步骤，其中所述可否访问的判定基于以下步骤来进行：a)判定管理所述用户所尝试访问的信息的实体的步骤；b)判定与管理所述用户所尝试访问的信息的实体建立关联的、基于法规制度的访问控制模式的步骤；c)基于所述用户所属的实体与管理所述用户所尝试访问的信息的实体的关系，判定是否满足基于所述法规制度的访问控制模式的步骤；d)判定以与所述登录ID建立关联的职务能否访问所述用户所尝试访问的信息的步骤。

根据本发明，多个国家的雇员能遵守各国的法规制度并且根据此雇员的职务来访问共有的信息。

附图说明

图1是对本发明的全球信贷管理系统与属于各实体组的各实体的关系进行概念性说明的图。

图2是本发明的一实施方式的全球信贷管理系统的功能框图。

图3是表示图3A与图3B的关系的图。

图3A是表示本发明的一实施方式的、关于银行内部的信贷业务的业务流程的图。

图3B是表示本发明的一实施方式的、关于银行内部的信贷业务的业务流程的图。

图4表示本发明的一实施方式的、关于登记至用户信息协同数据库的用户信息的数据结构的一例。

图5表示本发明的一实施方式的、关于登记至用户信息协同数据库(或其他数据库)的实体信息的数据结构的一例。

图6表示本发明的一实施方式的、关于登记至顾客信息管理数据库的顾客信息的数据结构的一例。

图7是表示图7A、图7B、图7C的关系的图。

图7A表示本发明的一实施方式的、关于登记至顾客信息管理数据库或其他数据库的按顾客信息的类别的访问权限表的数据结构的一例。

图7B表示本发明的一实施方式的、关于登记至顾客信息管理数据库或其他数据库的按顾客信息的类别的访问权限表的数据结构的一例。

图7C表示本发明的一实施方式的、关于登记至顾客信息管理数据库或其他数据库的按顾客信息的类别的访问权限表的数据结构的一例。

图8表示本发明的一实施方式的、关于登记至顾客信息管理数据库或其他数据库的与顾客信息有关的各国法规制度的类型信息的数据结构的一例。

图9是对本发明的一实施方式的、各国法规制度的第一类型中的示例性的实施方式的全貌进行说明的图。

图10是对本发明的一实施方式的、在本发明的系统中所进行的处理的流程进行说明的流程图。

图11是说明本发明的一实施方式的、对图9的事例中的所属于第三国的审查部的用户进行访问控制处理的流程的流程图。

图12是对本发明的另一实施方式的、结构性融资(structured finance)中的示例性的实施方式的全貌进行说明的图。

图13是表示图13A与图13B的关系的图。

图13A是表示本发明的另一实施方式的、结构性融资中的示例性的业务流程的图。

图13B是表示本发明的另一实施方式的、结构性融资中的示例性的业务流程的图。

图14是对本发明的另一实施方式的、在本发明中所进行的处理的流程进行说明的流程图。

图15表示本发明的一实施方式的、金融机构系统和全球信贷管理系统的构成的一例。

具体实施方式

以下，参照附图对本发明的实施方式进行详细说明。

在本说明书中，实体组(entity group)是指属于某一银行的组织的组(例如，法人化的企业)。即，各实体组表示例如在日本法人化的银行、或者与此银行关联的其他法人(例如，当地法人)。对于在日本法人化的银行，存在独立经营、运营的在外国法人化的多个子公司。即使是相互关联的法人，也作为独立的法人来适用法规制度，因此，各法人需要使用不同的访问控制。所以，在本发明中，能识别多个实体组并按实体组带来适当的访问控制。此外，在本说明书中，实体是指属于实体组的营业网点(分行、办事处等)。

图1是对本发明的全球信贷管理系统1000与属于各实体组的各实体的关系进行概念性的说明的图。

顾客1101是设立在第一国1100的企业。在第一国1100存在属于实体组A 1110的实体A1 1111和实体A2 1112。实体A1 1111是从顾客1101接受融资的协商并管理顾客1101的信息的实体(以下，将管理顾客的信息的实体称为“管辖行”)。需要说明的是，在本说明书中，“管理顾客的信息”表示主要负责对储存在配置于任意的场所(既可以是管辖行的所在国，也可以是管辖行的所在国以外的国家)的服务器的顾客信息进行制作、更新，管辖行未必需要在管辖行的地界内配置用于储存顾客信息的服务器。而且，在第一国1100存在属于实体组B 1120(实体组B是与实体组A关联的法人，却与实体组A是不同的法人)的实体B11121。

第二国1200是与第一国1100不同的国家。在第二国1200存在属于实体组A 1110的实体A3 1113。而且，在第二国1200存在属于实体组B 1120的实体B2 1122。

如此，本发明控制来自所属于五种实体的银行职员对相同信息的访问。五种实体是：管理该信息的管辖行(即，实体A1 1111)、与管辖行属于相同的实体组的国内的其他实体(即，实体A2 1112)、与管辖行属于不同的实体组但与管辖行存在于相同的国家的实体(即，实体B1 1121)、与管辖行属于相同的实体组但与管辖行存在于不同的国家的实体(即，实体A3 1113)、以及与管辖行属于不同的实体组且与管辖行存在于不同的国家的实体(即，实体B2 1122)。

图2是本发明的一实施方式的全球信贷管理系统1000的功能框图。

全球信贷管理系统1000是用于按实体或实体组与不同的(或通用的)银行系统1500(将在后文参照图15加以记述)协同合作来进行全球性的信贷管理的系统。全球信贷管理系统1000具有：用户信息协同以及可否访问判定部210、顾客信息管理部220、案件信息管理部230、多个当事人案件信息管理部240、以及信贷事务管理部250。全球信贷管理系统1000为包含处理器以及存储器的计算机。此外，全球信贷管理系统1000包含存储介质，该存储介质储存用于使用户信息协同以及可否访问判定部210、顾客信息管理部220、案件信息管理部230、多个当事人案件信息管理部240、以及信贷事务管理部250工作的程序或用于执行后述的处理流程的程序。

用户信息协同以及可否访问判定部210担当将登录到银行系统1500的用户信息与在全球信贷管理系统1000内管理的用户信息关联起来的职能。本发明基于全世界统一的“职务”来对所属于世界范围内的实体的银行职员进行划分，并提供与此银行职员的“职务”对应的访问控制。列举一例，虽然不应被限定地解释，但例如，作为职务，包含前台(front)、前中台(front-middle)、中后台(middle-back)、后台(back)、审查部等类别。各职务的银行职员可访问对各职务而言允许访问的信息。用户信息协同以及可否访问判定部210能从用户信息协同数据库211内的用户信息400(将在后文加以记述)读出与登录到银行系统1500时所使用的用户ID建立关联的职务。此外，全球信贷管理系统1000能基于所读出的职务来判定此用户ID是否具有可访问信息的权限(详细内容将在后文加以记述)。

顾客信息管理部220担当在网点间使用通用的表格(form)以及格式(format)来完善信贷管理过程中所需的顾客信息的职能。当在网点间未协同合作时，按网点以不同的规则(rule)来制作以及更新顾客信息，有时缺乏机密性、完整性、可用性。由于面向全球性企业等的信贷业务需要跨网点进行业务管理，因此，要求在通用的框架中管理顾客信息的结构。因此，顾客信息管理部220以全世界通用的格式管理在信贷判断中所需的关于顾客的所有数据。顾客信息管理部220也可以对从外部调查机构所获取的企业信息、从其他的系统所获取的顾客信息进行登记以及更新。顾客信息管理部220还储存并管理以下的企业信息：顾客的总公司所在国、行业种类信息等基本信息；债务人评级等监控信息；主要股东、企业变迁等经营信息；主要客户等营业信息。此外，顾客信息管理部220也可以具有以下功能：关于企业信息以及财务信息，显示集中在主要项目上的概要(summary)的功能；以可比较的形式来显示与顾客的竞争企业有关的主要的财务信息、行业种类固有的信息的功能。在财务信息的概要中可以以条款为单位来登记由负责人、信贷审查人所输入的评述(comment)和用于将各种条款关联起来的文字，并支持作为评述对象的条款的确定。顾客信息管理部220还对企业的借款提供登记并显示在任意的基准日期点的以借款人为单位的负债余额的功能。

上述所罗列的信息项目仅为一例而不应被限定，但顾客信息管理部220管理关于顾客的多种多样的应慎重处理的信息。因此，要求安装仅遵照各国的法规制度并且担任适当的职务的银行职员才能进行信息的阅览的访问控制。当从各网点接收到信贷判断所需的信息的参照要求时，顾客信息管理部220从顾客信息管理数据库221提取并提供与该参照要求有关的数据。

例如，关于对存在多个相关当事人的项目融资进行的融资判断，不仅参照债务人的信息，还可以假定利益相关者(stakeholder)、保证人等信息的参照要求。当接收到与该项目融资有关的关于利益相关者、保证人的顾客信息的参照要求时，顾客信息管理部220在与后述的多个当事人案件信息管理部240协同的基础上，从顾客信息管理数据库221提取并提供信息。此时，可以按利益相关者、保证人来分配不同的访问限制。例如，对关于利益相关者A的顾客信息，不指定依职务的访问限制，而是对任何职务的人都允许访问。另一方面，也可以构成为：对关于保证人B的顾客信息，指定允许访问的职务，仅允许指定职务的人访问。

此外，顾客信息管理部220也可以对信息项目进行细分并按各信息项目来分配不同的访问限制。例如，也可以构成为：在顾客的信息中，对交渉中的M&A等信息赋予最高等级的访问限制，仅对特定职务的人给予信息公开的许可。另一方面，对于顾客的基本信息，也可以指定宽泛的职务种类，并允许更宽泛的职务种类的人访问。而且，也可以对顾客的信息进行细分，将这些信息分别与多种多样的访问限制建立关联。

顾客信息管理部220在接收到参照要求而从顾客信息管理数据库221提取信息时，为了参照与该要求有关的信息，能从顾客信息管理数据库221读出必要的“职务”，并提供给用户信息协同以及可否访问判定部210。

案件信息管理部230担负按信贷的交易(案件)来管理信息的职能。案件信息管理数据库231保持与融资案件有关的简况(受理背景、资金筹措、辅助分担、贷款结构(structure)等)、信贷明细、极限额、担保明细等信息。例如，从顾客接收对某一特定的项目进行融资的协商的实体将与该项目有关的信息登记到案件信息管理数据库231。此后，在进行与该项目案件有关的信贷请示的制作、信贷请示的批准、融资执行等时，可参照登记到案件信息管理数据库231的案件信息来对该项目进行风险判断等。案件信息管理部230也可以具有在与顾客信息管理部220以及多个当事人案件信息管理部240协同的基础上，提供与案件信息建立关联的信息的功能。

多个当事人案件信息管理部240管理用于验证结构性融资案件等的资助人、承购商等相关当事人的信用风险并进行信贷判断的信息。关于对某一特定的项目进行的融资，在进行信贷判断时，验证参与项目的资助人、承购商等相关当事人的信用风险是非常重要的。但是，资助人、承购商等存在于不同的国家，有时管理各资助人、承购商的信息的网点不同。因此，需要以统一的方式保有各资助人、承购商的信息，并且进行与管理这些信息的网点(即，管辖行)对应的各自不同的访问控制。在多个当事人案件信息数据库241储存有项目的概要、结构、里程碑(milestone)这样的资产简况和相关当事人的信息。例如，如下表所示，多个当事人案件信息管理部240根据涉及此项目的职能来对信贷交易中的相关人员进行分类并管理。在本系统中，也可以采用基于下述相关人员的登记类别来进行访问控制的构成。

表1：相关人员登记类别

信贷事务管理部250担负在全世界通用的框架中高效地对银行内的信贷业务进行管理、运营的职能。

例如，图3是表示关于金融机构内部的信贷业务的业务流程的图。前台是“前台部门(front office)”的简称，主要与顾客直接联络等，确定融资交易的条件，(临时)签订合同，制作信贷请示书。前中台主要对关于顾客与前台之间所(临时)签订的合同的信贷请示书进行形式上的检查，并进行必要文件、手续等的内容确认。中后台主要进行已批准请示书和合同文件的确认等固定格式的核对作业。总部(审查部)批准信贷请示书或赋予条件等。当信贷请示书获得批准时，前台以及前中台制作合同书，中后台核对所制作的合同书，进行信用额度登记，进而，后台基于所签订的合同书来进行进款处理。

如此，涉及一项信贷业务的业务被细化，多个岗位参与到被细化的业务中，这多个岗位有可能跨多个国以及/或者多个实体组。银行内的信贷业务通过跨各网点、各岗位以及/或者多个实体组而进一步复杂化。因此，通过信贷事务管理部250来提供用于使各网点以及各岗位的职能分担明确化并在通用的框架中以通用的格式来执行这些职能的结构。信贷业务所需的信息以全世界通用的格式被储存在信贷事务管理数据库251，在各业务过程的执行时被各网点访问。以全世界通用的格式使信贷业务管理标准化、可视化，由此，明确了某一信贷业务处于哪一阶段、责任落在哪一岗位。在信贷事务管理部250中，主要分为签约前的准备、执行准备、期限内管理这三大过程来进行管理。

在信贷事务管理数据库251储存有用于执行上述三个过程所需的信息。例如，在签约前的准备过程中，核对并储存关于合同内容检查(签字前的检查)、签字前所需的征收物(各种证件)/附带过程、审查部条件、签字前的担保/保证的补充等的信息。在执行准备过程中，核对并储存关于事后征收物(各种文件)、事后的担保/保证的补充等的信息。在期限内管理过程中，核对并储存关于可结账状态下的事后征收物(各种文件)、审查部条件、可结账状态下的事后的担保/保证的补充等的信息。

图4表示本发明的一实施方式的、与登记至用户信息协同数据库211的用户信息400有关的数据结构的一例。用户信息400包含：表示用户的登录ID的用户ID、用户的所属实体组ID、所属实体ID以及职务等。“用户ID”是银行职员登录到银行系统1500时所使用的登录ID。“所属实体组ID”是此银行职员所属的实体所属于的实体组的ID。实体组ID是用于唯一地识别实体组的ID。“所属实体ID”是此银行职员所属的实体的ID。实体ID是用于唯一地识别属于某一实体组的实体(例如，分行或办事处)的ID。“职务”是用于识别全世界统一的“职务”(前台(F)、前中台(FM)、中后台(MB)、后台(B)等)的类别的ID。为了使全球信贷管理系统1000与按网点而不同的(或通用的)银行系统1500协同，用户信息400与在银行系统1500所使用的用户ID建立关联，包含所属实体组ID、所属实体ID以及职务的信息。

图5表示本发明的一实施方式的、与登记至用户信息协同数据库211(或其他数据库)的实体信息500有关的数据结构的一例。关于配置于世界各国的实体，实体信息500包含实体名、实体ID、所属实体组ID以及所在国等。“实体名”是此实体的分行名、办事处名等。“实体ID”是此实体的ID。“所属实体组ID”是此实体所属的实体组的ID。“所在国”表示此实体所在的国家。

图6表示本发明的一实施方式的、与登记至顾客信息管理数据库221的顾客信息600有关的数据结构的一例。顾客信息600包含顾客ID、管理顾客信息的实体(即，管辖行)的实体ID、信息类别、信息项目ID、信息类别明细、信息、有无顾客同意等信息。“顾客ID”是用于唯一地识别顾客的ID。“管辖行实体ID”是管理与此顾客有关的信息的实体的实体ID。“信息类别”是顾客信息的种类。“信息项目ID”、“信息类别明细”、“信息”是将各信息类别进一步详细划分而成的。信息类别在图6中举出三个例子(基本信息、交易系数、营业信息)来作为一例进行了说明，但当然也可以使用更细化的信息类别。“顾客同意”表示顾客是否同意将其信息公开到被管辖行所在的国家的法律允许的可共有信息的范围(例如，可在国内的相同法人内共有，或者，可在国内外的相同法人内共有)之外。

图7表示本发明的一实施方式的、与登记至顾客信息管理数据库221或其他数据库的与按顾客信息的类别的访问权限表700有关的数据结构的一例。为了按顾客信息的类别并基于阅览者(即，使用用户ID登录并访问信息的银行职员)的所属实体与管理顾客信息的实体的关系来判定能访问顾客信息的职务，而参照访问权限表700。在访问权限表700中，“本行”意味着由阅览者所属的实体来管理顾客的信息，“他行”意味着由与阅览者属于相同实体组的其他实体来管理顾客的信息。例如，基本信息中，对关于顾客名、顾客的国家的信息而言，如果是所属于管理顾客信息的实体的银行职员中职务为F(前台)、MB(中后台)、后台(B)的银行职员，则表示允许阅览。而且，也可以根据顾客在项目中发挥作用的不同来赋予不同的访问权限。例如，对于参与结构性融资的顾客，也可以使用以债务人、实质相同债务人、关联借款人、相关当事人、其他等来分类的相关人员的登记类别来识别顾客，通过顾客在项目中担当职能的不同来进行不同的访问控制。

图8表示本发明的一实施方式的、与登记至顾客信息管理数据库221或其他数据库的与关于顾客信息的各国法规制度的类型信息800相关的数据结构的一例。在本实施方式中，作为一例，将各国的法规制度分为三类。例如，在类型一中，即使要求访问的用户(即，阅览信息的银行职员)所属的实体和管理顾客信息的实体属于相同实体组(例如，相同法人)，在各实体的所在国不同的实体之间共有信息也需要顾客的同意。在类型二中，即使要求访问的用户所属的实体和管理顾客信息的实体的所在国不同，但如果属于相同的实体组，则可在所在国不同的实体之间共有信息(无需顾客同意)。在类型三中，不存在信息共有的法规制度，即使要求访问的用户所属的实体和管理顾客信息的实体不属于相同实体组、所在国不同，也准许共有。此外，按类型来登记采用此类型的法规制度的国家名(未图示)。此外，各类型适用所阅览的顾客信息的管辖行的所在国的法规制度。

图9是对本发明的一实施方式的、各国法规制度的第一类型中的示例性的实施方式的全貌进行说明的图。在本实施方式中，以对将总公司设在第一国9100、将分公司设在第二国9200的顾客(事业公司X)执行融资为例进行说明。事业公司X希望在总公司9110所在的第一国9100和分公司9210所在的第二国9200分别执行融资。因此，顾客(总公司)9110与配置于第一国的第一国实体9101进行融资的协商。此外，顾客(分公司)9210与配置于第二国的第二国实体9201(第二国实体9201与第一国实体9101属于相同的实体组)进行融资的协商。需要说明的是，事业公司X的顾客信息由配置于第一国的第一国实体9101来管理(即，第一国实体9101为管辖行)。就是说，第一国实体9101制作或更新事业公司X的顾客信息，制作案件信息以及信贷请示书，并进行风险登记等手续。然后，第二国实体9201参照在第一国实体9101制作或更新的事业公司X的顾客信息、案件信息以及信贷请示书。

在第一国实体9101和第二国实体9201，产生沿图3的业务流程的、与各职务对应的业务。由具有前台职能的人来制作顾客的顾客信息以及请示书，在位于第三国9300的实体(审查部)9103完成请示书的裁决。此后，在第一国实体9101和第二国实体9201，由前台来完成合同书的制作，由中后台来进行征求书类的核对以及信用额度的登记，如果所有的手续进展顺利，则由后台来最后进行贷款的执行处理。此时，具有与各职务对应的权限的人在履行所分配的职务时，需要参照案件信息、事业公司X的顾客信息。由于事业公司X的顾客信息由第一国实体9101来管理，因此，需要进行遵循管辖行所在的第一国9100的法规制度(设为第一类型)的访问控制。例如，以对属于第二国实体9201且职务为前台的用户的访问控制为例并通过如下的图进行说明。

图10是对本发明的一实施方式的、在本发明的系统中所进行的处理的流程进行说明的流程图。如上述所说明的，基于图9的事例，以属于配置于第二国的第二国实体9201且职务为前台的用户(用户ID：U0001)访问配置于第一国的第一国实体9101所管理的顾客信息时的访问控制为例进行说明。

在步骤1001中，用户登录自身所属的实体组的银行系统1500。例如，只要与全球信贷管理系统1000协同，则所登录的银行系统1500可以是在所有的实体组通用的系统，也可以是按国家或按实体组而分离的系统。

在步骤1002中，用户信息协同以及可否访问判定部210参照用户信息400，判定与登录所使用的用户ID对应的职务、所属实体ID、所属实体组ID。在本例中，基于用户信息400，用户(用户ID：U0001)被判定为所属于实体组ID：OG001下属的实体ID：OG0001-0003的负责前台职务的用户。

在步骤1003中，用户(用户ID：U0001)判断信贷条件等，并为了制作信贷请示书而访问顾客信息(本例中为事业公司X的信息)。在本步骤中，用户信息协同以及可否访问判定部210参照顾客信息600来判定管理被要求访问的顾客信息的实体。在本例中，参照顾客信息600，实体ID：OG001-002被判定为管理该访问所涉及的顾客信息的实体。而且，在本步骤中，用户信息协同以及可否访问判定部210参照顾客信息600来判定被要求访问的顾客信息的信息类别以及信息项目ID。需要说明的是，在本步骤或以下的步骤中，也可以不采用由用户信息协同以及可否访问判定部210来参照顾客信息600等的构成，而是采用向顾客信息管理部220提出要求，由顾客信息管理部220来参照顾客信息600等的构成。

在步骤1004中，用户信息协同以及可否访问判定部210参照各国法规制度的类型信息800以及实体信息500来判定管理顾客信息的实体的所在国的法规制度类型。在本例中，设管理该被要求访问的顾客信息的实体的法规制度的类型为类型一。

在步骤1005中，用户信息协同以及可否访问判定部210基于尝试访问的用户(用户ID：U0001)所属的实体与管理顾客信息的实体的关系，判定是否满足各国法规制度的要求。在本例中，根据在步骤1004中所判定出的法规制度类型，要求登录用户所属的实体和管理顾客信息的实体i)属于相同的实体组，并且ii)在相同的国家。虽然用户(用户ID：U0001)所属的第二国实体9201和管理顾客信息的第一国实体9101属于相同的实体组(满足上述条件i))，但另一方面，不属于相同的国家(不满足上述条件ii))。因此，进入“否”的分支，移至步骤1006。

在步骤1006中，用户信息协同以及可否访问判定部210判定是否从事业公司X取得了对事业公司X的顾客信息的公开的同意。对于顾客同意，也可以在收集顾客信息时预先向顾客确认，并将有无同意的情况储存在顾客信息600。关于顾客的同意，可以是该顾客对所有的顾客信息的总括性的同意，当然也可以是按信息类别的同意、或按信息项目的同意。在未取得同意的情况下，在步骤1007作出拒绝访问的判定，处理结束。

在步骤1008中，用户信息协同以及可否访问判定部210参照按顾客信息类别的访问权限表700来判定以与用户的登录ID建立关联的职务能否访问顾客信息。在本例中，尝试访问的用户(用户ID：U0001)所属的第二国实体9201和管理顾客信息的第一国实体9101属于相同的实体组。然后，例如，设为：尝试访问的信息类别为基本信息(信息项目ID：B0003)，且对于第二国实体9201而言，事业公司X为其他实体所管理的客户(他行)。用户信息协同以及可否访问判定部210参照访问权限表700来判定具有前台职务的用户(用户ID：U0001)的访问(在相关人员的职能为“债务人”的情况下)是否被允许。

在步骤1009中，当在步骤1008判定为允许访问时，顾客信息被公开，处理结束。

图11是对本发明的一实施方式的、对图9的事例中的属于第三国的审查部的用户(用户ID：U0002)进行的访问控制处理的流程进行说明的流程图。

在步骤1101中，属于配置于第三国9300的审查部且负责职务以及权限为审查部的用户(用户ID：U0002)进行登录。

在步骤1102中，用户信息协同以及可否访问判定部210参照用户信息400来判定与登录所使用的用户ID对应的职务、所属实体ID、所属实体组ID。在本例中，基于用户信息400，用户(用户ID：U0002)被判定为所属于实体组ID：OG001下属的实体ID：OG0001-0004的负责审查部(EX)的职务的用户。

在步骤1103中，用户(用户ID：U0002)为了判断信贷条件等而访问顾客信息(在本例中为事业公司X的信息)。在本步骤中，用户信息协同以及可否访问判定部210参照顾客信息600来判定主要管理被要求访问的顾客信息的实体。而且，在本步骤中，用户信息协同以及可否访问判定部210参照顾客信息600来判定被要求访问的顾客信息的信息类别以及信息项目ID。需要说明的是，在本步骤或以下的步骤中，也可以不采用由用户信息协同以及可否访问判定部210来参照顾客信息600等的构成，而是采用向顾客信息管理部220提出要求，由顾客信息管理部220来参照顾客信息600等的构成。

在步骤1104中，用户信息协同以及可否访问判定部210判定管理顾客信息的实体和尝试访问的用户(用户ID：U0002)所属的实体是否所属于相同实体组。在本例中，当管理该访问所涉及的顾客信息的第一国实体9101和用户(用户ID：U0002)所属的第三国的实体9103的实体组相同时，移至步骤1106。需要说明的是，在本实施方式中，将管理顾客信息的实体和尝试访问的用户所属的实体属于相同实体组作为必要条件来进行说明。但是，也可以将管理顾客信息的实体和尝试访问的用户所属的实体属于相同地域(例如，亚洲、欧州等)、或具有相同的法规制度的类型等作为必要条件。

在步骤1104中，当判定为不满足必要条件时，移至步骤1105，用户信息协同以及可否访问判定部210判定是否从事业公司X取得了对事业公司X的顾客信息的公开的同意。在未得到同意的情况下，在步骤1108中作出拒绝访问的判定，处理结束。

在步骤1105中，当用户信息协同以及可否访问判定部210确认已有顾客的同意时，移至步骤1106。

在步骤1106中，用户信息协同以及可否访问判定部210参照按顾客信息类别的访问权限表700，判定以与登录用户的ID建立关联的职务能否访问顾客信息。在本例中，尝试访问的用户(用户ID：U0002)所属的实体属于相同的实体组。然后，例如，设为：尝试访问的顾客信息的类别为基本信息，且对于其他实体而言，事业公司X为管理信息的他行。用户信息协同以及可否访问判定部210参照按顾客信息类别的访问权限表700，判定具有审查部的负责职务以及权限的用户(用户ID：U0002)的访问是否被允许(所属于审查部的银行职员可阅览除内部信息以外的所有信息)。

在步骤1107中，当在步骤1106判定为访问被允许时，顾客信息被公开，处理结束。

图12是对本发明的另一实施方式的结构性融资中的示例性的实施方式的全貌进行说明的图。在本实施方式中，以包含下述的关联当事人的项目融资的执行为例进行说明。

债务人：将总公司设在伦敦的特定目的公司A1201

资助人(出资比率50％以上：实质相同债务人)：将总公司设在纽约的B公司1202

建筑承包商(关联借款人)：将总公司设在东京的C公司1203

经销商(关联借款人)：将总公司设在新德里的D公司1204

通过作为债务人的A公司1201来向配置于作为第一国的英国的第一国的实体1210进行融资的协商。需要说明的是，将总公司设在纽约的B公司1202的顾客信息由配置于作为第二国的美国的第二国实体1240来管理。C公司1203的顾客信息由配置于作为第三国的日本的第三国第二实体1230来管理。然后，D公司1204的顾客信息由配置于作为第四国的印度的第四国实体1250来管理。然后，请示书的裁决由配置于作为第三国的日本的第三国第一实体1220来进行。

图13是表示本发明的另一实施方式的、结构性融资中的示例性的业务流程的图。

在第一国的实体1210、第二国实体1240、第三国第二实体1230、第四国实体1250，产生沿图12的业务流程的、与各职能对应的业务。由第一国的实体1210的具有前台职能的人进行特定目的公司A1201的顾客信息的制作或更新、案件信息以及多个当事人案件信息的制作、风险因素登记以及请示书的制作，并在第三国第一实体1220进行请示书的裁决。此后，在第一国的实体1210进行合同书的制作，由具有中后台职能的人来进行征求书类的核对以及信用额度的登记，如果所有的手续开展顺利，则由具有后台职能的人最后执行贷款。此时，具有与各职务对应的权限的人在履行所分配的职务时，需要参照顾客信息。对于某一结构性融资型的融资，在进行信贷判断时，各网点的具有前台、中后台等负责职务以及权限的人需要参照登记在案件信息管理数据库231的案件信息，进而参照与该案件信息关联的相关当事人信息。

在本例中，从A公司到D公司的顾客的信息分别由第一国的实体1210、第二国实体1240、第三国第二实体1230、第四国实体1250来管理。因此，所属于第一国的实体1210的前台职位的用户必须在核对由其他行(第二国实体1240、第三国第二实体1230、以及第四国实体1250)来管理的顾客信息(在本例中为相关当事人信息)的基础上，进行请示书等的制作。另一方面，所属于第二国实体1240、第三国第二实体1230、以及第四国实体1250的前台职位的用户必须更新各顾客信息并将此信息反映在关联当事人登记中。由于相关当事人信息与顾客信息取得协同，因此，当通过各实体来更新顾客信息时，相关当事人信息也被更新。反之，当通过各实体来更新相关当事人信息时，对应的顾客信息也被更新。

以对属于第一国的实体1210并具有前台职位的用户进行的访问控制流程为例并通过如下的图来进行说明。

图14是对本发明的另一实施方式的、在本发明中所进行的处理的流程进行说明的流程图。如前所述，基于图12的事例，以所属于配置在第一国的第一国的实体1210且具有前台职位的用户访问由其他行(第二国实体1240、第三国第二实体1230、以及第四国实体1250)来管理的顾客信息时的访问控制流程为例进行说明。

在步骤1401中，用户登录到自身所属的实体组的银行系统1500。例如，只要与全球信贷管理系统1000协同，则所登录的银行系统1500可以是在所有的实体组通用的系统，也可以是按国家、按实体组而分离的系统。

在步骤1402中，用户信息协同以及可否访问判定部210参照用户信息400来判定与登录所使用的用户ID对应的职务、所属实体ID、所属实体组ID。

在步骤1403中，用户判断信贷条件等，并为了制作信贷请示书而访问登记在案件信息管理数据库231的案件信息、与该案件信息建立关联的相关当事人信息(在本例中为从A公司到D公司的信息)。在本步骤中，用户信息协同以及可否访问判定部210与顾客信息管理部220、案件信息管理部230、多个当事人案件信息管理部240协同，判定主要管理该顾客信息(从A公司到D公司的信息)的实体以及相关人员的登记类别。在本例中，例如，参照D公司1204的顾客信息来进行说明。用户信息协同以及可否访问判定部210参照顾客信息600来判定管理该访问所涉及的顾客信息的实体。此外，用户信息协同以及可否访问判定部210判定相关人员的登记类别(在本例中为关联借款人)。而且，用户信息协同以及可否访问判定部210参照顾客信息600来判定被要求访问的顾客信息的信息类别以及信息项目ID。需要说明的是，在本步骤或以下的步骤中，也可以不采用由用户信息协同以及可否访问判定部210来参照顾客信息600等的构成，而是采用向顾客信息管理部220等提出要求，由顾客信息管理部220等来参照顾客信息600等的构成。

在步骤1404中，用户信息协同以及可否访问判定部210参照各国法规制度的类型信息800以及实体信息500来判定管理顾客信息的实体的法规制度类型。在本例中，设管理该被要求访问的顾客信息的实体的法规制度的类型为类型一。

在步骤1405中，基于尝试访问的用户所属的实体与管理顾客信息的实体的关系来判定是否满足各国法规制度的要求。在本例中，根据在步骤1404中所判定出的法规制度类型，要求登录用户所属的实体和管理顾客信息的实体i)属于相同的实体组，并且ii)在相同的国家。虽然用户所属的第一国第一实体1210和管理顾客信息第四国实体1250属于相同的实体组(满足上述条件i))，但另一方面，不属于相同的国家(不满足上述条件ii))。因此，移至步骤1406。

在步骤1406中，用户信息协同以及可否访问判定部210判定是否从顾客D1204取得对顾客信息的公开的同意。关于顾客的同意，可以是对所有顾客信息的总括性的同意，当然也可以是按信息类别的同意、或按信息项目的同意。在未取得同意的情况下，在步骤1407作出拒绝访问的判定，处理结束。

在步骤1408中，用户信息协同以及可否访问判定部210参照按顾客信息类别的访问权限表700来判定以与登录用户ID建立关联的职务能否访问顾客信息。在本例中，尝试访问的用户所属的第一国的实体1210和管理顾客信息的第四国实体1250属于相同的实体组。然后，例如，设为：尝试访问的顾客信息类别为基本信息(信息项目ID：B0001)，顾客D1204的关联人员的登记类别为关联借款人。用户信息协同以及可否访问判定部210参照按顾客信息类别的访问权限表700中的相同实体组的他行的相关借款人栏。然后，用户信息协同以及可否访问判定部210判定具有前台职务的用户的访问是否被允许。

在步骤1409中，当步骤1408判定为访问被允许时，顾客信息被公开，处理结束。

而且，作为变形例，进一步对用户参照顾客B公司1202(相关当事人信息)的例子进行说明。步骤1403之前都相同。在步骤1404中，设用户信息协同以及可否访问判定部210参照各国法规制度的类型信息800以及实体信息500判定为管理顾客B公司1202的顾客信息的第二国实体1240的所在国的法规制度的类型为类型三。

在步骤1405中，用户信息协同以及可否访问判定部210基于尝试访问的用户所属的实体与管理顾客信息的实体的关系，判定是否满足各国法规制度的要求。在本例中，根据在步骤1404中所判定出的法规制度类型，可跨实体组以及跨国地进行共有，因此，移至步骤1408。

在步骤1408中，用户信息协同以及可否访问判定部210参照按顾客信息类别的访问权限表700来判定以与登录用户ID建立关联的职务能否访问顾客信息。在本例中，尝试访问的用户所属的第一国的实体1210和管理顾客信息的第二国实体1240属于相同的实体组。然后，例如，尝试访问的顾客信息类别为基本信息(信息项目ID：B0001)，顾客B公司1202在该项目中的相关人员的登记类别为实质相同债务人。因此，用户信息协同以及可否访问判定部210参照按顾客信息类别的访问权限表700的相同实体组客户的他行的实质相同债务人栏。然后，用户信息协同以及可否访问判定部210判定具有前台职务的用户的访问是否被允许。

如此，本发明不限于阅览按顾客来管理的顾客信息时的访问控制，也可以应用于阅览按案件来管理的案件信息时的访问控制。

图15表示本发明的一实施方式的、银行系统1500和全球信贷管理系统1000的构成的一例。

各网点的银行系统1500具有认证服务器1530、业务服务器1520、银行职员在各业务中所使用的终端1540等。这些服务器以及终端是举例示出的，当然也可以存在其他多种多样的服务器、终端群。银行系统1500可以按国家、按实体组而不同，也可以是统一的系统。此外，在本例中，将银行系统1500和全球信贷管理系统1000设为独立的系统进行说明，但当然也可以设计为统一的相同系统。银行系统1500和全球信贷管理系统1000经由行内网络或互联网1550来连接。全球信贷管理系统1000由一个或多个服务器计算机以及数据库等构成。

构成银行系统1500以及全球信贷管理系统1000的各终端1540、服务器计算机具备：ROM1501、RAM1502、存储部1503(磁性存储设备或其他一切介质、用于保存信息并且可访问的介质)、通信部1504、输入部1505、显示部1506、以及CPU1507等。不限于此，可以内置或者连接本技术领域公知的各种硬件。此外，在终端1540、各种服务器安装有OS(OperatingSystem：操作系统)、各种驱动器或应用程序，作为整体来执行本发明中的实施方式的各种处理。

本说明书以及附图中所公开的实施方式仅为一例，在确定本发明的技术范围时，不应限定于本公开的内容来进行解释。为了便于说明，分别将各处理部分开记载，但也可以使各自的功能统一协同，也可以使另一方具有各自所具有的功能的一部分或全部。对本实施方式所公开的数据库群而言，也可以使另一方具有各自所具有的数据的一部分或全部，并使它们统一协同。

如以上所说明，根据本发明，在所有网点的银行职员可共同利用的系统中，能在通用的框架中使信息协同，按国家而遵守不同的法规制度，并且，进行适当的访问控制来向适当的人公开适当的信息。

Claims (8)

1.一种信息访问控制方法，由全球信贷管理系统来执行，具有以下步骤：

接收用户的登录ID的步骤；

判定与所述登录ID建立关联的职务以及所述用户所属的实体的步骤；以及

判定可否对所述用户所尝试访问的信息进行访问的步骤，其中所述可否访问的判定基于以下步骤来进行：

a)判定管理所述用户所尝试访问的信息的实体的步骤；

b)判定与管理所述用户所尝试访问的信息的实体建立关联的、基于法规制度的访问控制模式的步骤；

c)基于所述用户所属的实体与管理所述用户所尝试访问的信息的实体的关系，判定是否满足基于所述法规制度的访问控制模式的步骤；

d)判定以与所述登录ID建立关联的职务能否访问所述用户所尝试访问的信息的步骤。

2.根据权利要求1所述的访问控制方法，其中，

所述信息基于所述信息的内容来划分，并按所述所划分出的信息来分配能进行访问的职务。

3.根据权利要求1或2所述的访问控制方法，其中，

基于所述用户所属的实体与管理所述信息的实体的关系，判定是否满足基于所述法规制度的访问控制模式的所述步骤c)具有以下任一项情形：

c-1)仅在所述用户所属的实体和管理所述信息的实体属于相同的实体组并且所在相同的国家的情况下，判定为能进行访问；

c-2)仅在所述用户所属的实体和管理所述信息的实体属于相同的实体组的情况下，判定为能进行访问；以及

c-3)即使符合所述c-1)至c-2)中任一情形，也要顾客同意才判定为能进行访问。

4.根据权利要求1至3中任一项所述的访问控制方法，其中，

所述信息包含顾客的顾客信息以及与所述顾客有关的信贷的案件信息中的至少一方。

5.根据权利要求1所述的访问控制方法，其中，

在对结构性融资型融资进行信贷判断时，

所述用户所尝试访问的信息是进行了所述结构性融资型融资的相关人员登记的顾客信息，

在判定可否对所述用户所尝试访问的顾客信息进行访问的步骤中，还具有以下步骤：

判定所述用户所尝试访问的顾客信息的、所述结构性融资型融资的相关人员登记类别的步骤；

判定分配给所述所判定出的相关人员登记类别的职务的步骤；以及

判定与所述登录ID关联的职务是否满足分配给所述所判断出的相关人员登记类别的职务的步骤。

6.根据权利要求5所述的访问控制方法，其中，

所述相关人员的登记类别至少由债务人、实质相同债务人、关联借款人、以及关联当事人构成。

7.一种全球信贷管理系统，具备执行权利要求1至6中任一项所述的方法的服务器计算机。

8.一种程序存储介质，在全球信贷管理系统的服务器计算机中具有用于使权利要求1至6中任一项所述的方法执行的程序。