Security backbone business system and program

Abstract

To provide a security backbone business system that achieves alleviation of troubles and shortening of time required for system change work when providing new services or changing existing service contents.SOLUTION: In a security backbone business back system 10, transaction data (including transaction attribute information) is outputted as coordination data, according to a data format of a variable length composed of combinations of keys and values, from service units 20, 40 of a coordination source to coordination data storage means 72. Then, in the security backbone business back system, a service unit 40 of a coordination destination acquires the transaction data stored in the coordination data storage means 72, and data selection means 50 determines whether or not the acquired transaction data should be subjected to business processing handled by an own unit 40, by using the transaction attribute information contained in the transaction data. Accordingly, data coordination of loose coupling is implemented between the service units.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a securities backbone business system and program configured by a computer that executes business processing related to transaction data of clients' securities, and can be used, for example, to build a securities backbone business back-end system. [Background technology]

[0002] Conventional securities back-end systems were monolithic systems in which the entire system functioned as a single integrated entity. Therefore, conventional securities back-end systems were configured to execute various business processes through data linkage between multiple servers, each with different functions, but these functions (servers) were tightly coupled. In other words, when outputting linked data from one server to a subsequent server, the server (the source server) performed calculations taking into account the content of the business process being executed on the subsequent server, and output dedicated linked data for the subsequent server. Therefore, if the source server had multiple subsequent servers, it output dedicated linked data with different content to each of those multiple subsequent servers.

[0003] 17 shows a portion of a conventional securities core business back-end system 900. The securities core business back-end system 900 is provided with a money balance management server 910, a subsequent advance payment management server 920 and a security / margin balance management server 930, and an advance payment management linked data storage means 941 and a security / margin balance management linked data storage means 942, which are queues (QUEs) for data linkage between these servers.

[0004] The money balance management server 910 receives contract transaction data from an upstream server (not shown), executes processing related to updating the money balance using balance update means 911, and stores the updated data in a record in money details database 912. Furthermore, reimbursement calculation means 913 references the updated record stored in money details database 912 and executes processing to determine whether or not to perform reimbursement calculation, and if it is determined that reimbursement calculation should be performed, reimbursement management data selection and transmission means 914 executes processing to select data necessary for processing in the reimbursement management server 920 and stores the selected linked data dedicated to reimbursement management in reimbursement management linked data storage means 941. Thereafter, in the reimbursement management server 920, reimbursement update means 921 acquires the linked data dedicated to reimbursement management stored in reimbursement management linked data storage means 941, executes processing related to updating the reimbursement, and stores the updated data in a record in reimbursement balance database 922.

[0005] In addition, in the money balance management server 910, in parallel with the processing by the advance payment calculation means 913, the security deposit / margin calculation means 915 refers to the updated records stored in the money details database 912 and executes a decision process as to whether or not to perform a security deposit / margin calculation. If it is decided that a security deposit / margin calculation should be performed, the security deposit / margin balance management data selection / transmission means 916 executes a selection process of the data required for processing by the security deposit / margin balance management server 930, and stores the selected linked data dedicated to security deposit / margin balance management in the security deposit / margin balance management linked data storage means 942. Thereafter, the margin / margin balance management server 930 uses the margin / margin balance update means 931 to obtain linked data dedicated to margin / margin balance management stored in the margin / margin balance management linked data storage means 942, executes processing related to margin / margin balance updates, and stores the updated data in a record in the margin / margin details database 932.

[0006] Therefore, in the conventional securities core business back-end system 900 shown in Figure 17, the source of the linkage, the cash balance management server 910, outputs linked data with different contents to each of the subsequent advance payment management server 920 and margin / margin balance management server 930 in their respective dedicated queues (QUE).

[0007] The implementation of the securities backbone business system of the present invention employs container technology, as described below (see Figure 1). Furthermore, the present invention does not use the conventional monolithic structure (see Figure 17 above), nor the ambiguously defined microservices. Instead, it defines a unit called a Sustainable Loosely Coupled Unit (SLU), as described below, as an "implementation unit suitable for securities backbone business." Microservices (a type of microservice in the broad sense) are built using this SLU unit. In the present invention (the claimed invention), this SLU unit is called a service unit, and in the description and drawings of this application, the SLU is written alongside the service unit.

[0008] Examples of conventional technologies related to containers and microservices include the following: A method for deploying multiple container pods to multiple container nodes in a container environment is known (see Patent Document 1). Also, a method, system, and medium for providing an application programming interface (API) function for a registered service endpoint in a container environment are known (see Patent Document 2). Furthermore, a method for isolating tenants from each other using containers to service requests in a multi-tenant environment is known (see Patent Document 3). Also, a method for customizing the deployment and operation of services in a container environment is known (see Patent Document 4). Furthermore, a system and method for providing provenance assurance in a distributed transaction database are known (see Patent Document 5).

[0009] Furthermore, in the present invention, processing routes are divided within a service unit and distributed processing is performed, but a data processing path management system and method that ensures security in IoT systems, improves user convenience, and facilitates the management of large numbers of devices is known as a technology related to dividing processing paths (see Patent Document 6). [Prior art documents] [Patent documents]

[0010] [Patent Document 1] Japanese Patent Application Publication No. 2023-139086 [Patent Document 2] Japanese Patent Application Publication No. 2023-40001 [Patent Document 3] Japanese Patent Application Publication No. 2023-36828 [Patent Document 4] Japanese Patent Application Publication No. 2023-27098 [Patent Document 5] Special Publication No. 2018-530175 [Patent Document 6] Japanese Patent Application Publication No. 2024-8735 Summary of the Invention [Problem to be solved by the invention]

[0011] As mentioned above, in the case of a monolithic system such as the conventional securities core business back-end system 900 shown in Fig. 17, the functions (servers) of the link source and the link destination are tightly coupled, so when providing a new service, linked data tailored to the link destination's functions (server processing content) must be sent to the link destination, and a dedicated path to the link destination must be added. When adding this dedicated path to the link destination, the link source determines whether the linked data to be sent to the link destination is subject to processing at the link destination, so the link source is designed with the content of the link destination's business processing in mind.

[0012] For example, in Figure 17, two dedicated paths are provided, but dedicated paths will be added for new services. Therefore, each time a new service related to various products or businesses is added, a dedicated path is added, and the processing content of the linked server increases and becomes more complex, so the conventional securities core business back-end system 900 has become a complex and huge system. This has led to the problem that system modification work takes time and effort.

[0013] Furthermore, not only when providing a new service but also when making partial changes to the content of an existing service, the content of the subsequent business processing (functions of the linked destination) will change, which will change the content of the linked data sent from the linked source to the linked destination, and the content of the processing at the linked source (processing to determine whether it is subject to processing at the linked destination) will also change. Therefore, since it is necessary to change the design of not only the linked destination but also the linked source, there is a problem that the system modification work takes time and effort.

[0014] For these reasons, it has been desirable to build a system that has a configuration that allows system modification work to be carried out without much effort or time when providing a new service or changing the content of an existing service.

[0015] An object of the present invention is to provide a securities core business system and program that can reduce the effort and time required for system modification work when providing a new service or changing the content of an existing service. [Means for solving the problem]

[0016] The present invention is a securities backbone business system configured by a computer that executes business processing related to transaction data of customers' securities, A plurality of service units that execute business processes related to transaction data through data linkage; a linked data storage means for storing transaction data in a variable-length data format consisting of a combination of a key and a value as linked data for data linkage between the plurality of service units; The service unit from which the link originates is The transaction data after the business process in charge of the own unit is stored in a database provided in the own unit, The transaction attribute information for the transaction data to be sent to the linked service unit includes a money update flag added by the local unit indicating that the transaction involves an update of the customer's money balance or a securities update flag indicating that the transaction involves an update of the customer's securities balance, or a transaction attribute flag or transaction attribute classification of the transaction data specified by the external system, and the data for each item constituting the transaction data is stored in the linked data storage means in a variable-length data format consisting of a combination of a key and a value; The service unit to which you are linked is acquires transaction data stored in the linked data storage means, and executes a data selection process using transaction attribute information contained in the acquired transaction data to determine whether the acquired transaction data is transaction data that should be subjected to business processing handled by the own unit; When it is determined that the transaction data should be processed by the unit, the transaction data after the processing by the unit is stored in a database provided within the unit. It is characterized by the following.

[0017] Here, a "service unit" is a unit for dividing various business processes executed in a computer-based securities backbone business system into cohesive service content. In this invention, with an eye toward future sales expansion and scalability, a "sustainable and loosely coupled implementation unit" is newly defined as a strategic concept, named SLU (Sustainable Loosely Coupled Unit), and this is referred to as a "service unit" in the claims. In other words, a "service unit" can be said to be a unit for dividing various business processes related to the securities backbone business so that the loosely coupled data linkage method of this invention (the claimed invention) can be applied. Looking ahead to future sales expansion and scalability means facilitating system changes associated with new services and changes in service content that may arise in the future, as will be described later. Therefore, the "service unit" in this invention (claimed invention) is the above-mentioned SLU, which is an "implementation unit suitable for core securities business" that is neither a conventional monolithic structure (see Figure 17 mentioned above) nor a microservice with an ambiguous semantic definition, and in this invention, microservices (a type of microservice in a broad sense) are constructed on an SLU basis.

[0018] Furthermore, the "money update flag" and "securities update flag" of the "transaction attribute information" are information added by the local unit (the cooperating service unit itself), while the "transaction attribute flag" and "transaction attribute classification" are information specified by an external system (a system other than the securities backbone business system of the present invention) and are already included in the transaction data when the securities backbone business system of the present invention receives the transaction data from the external system. The purpose of the present invention is that the cooperating source and cooperating destination service units that perform data collaboration using any of the listed "transaction attribute information" ("money update flag," "securities update flag," "transaction attribute flag," and "transaction attribute classification") are included in the securities backbone business system of the present invention. Therefore, the securities backbone business system of the present invention may include cooperating source and cooperating destination service units that perform data collaboration using transaction attribute information other than the listed "transaction attribute information." For example, the securities backbone business system of the present invention may include cooperating source and cooperating destination service units that perform data collaboration using transaction attribute flags added by the local unit (the cooperating service unit) other than the "money update flag" and "securities update flag" rather than the "transaction attribute flag" specified by the external system. Furthermore, the securities backbone business system of the present invention may include a linked service unit that does not perform data selection processing (for example, a trade statement management SLU shown in FIG. 6, which will be described later).

[0019] In the securities backbone business system of the present invention, the linked service unit outputs transaction data as linked data to the linked data storage means in a variable-length data format consisting of a combination of a key and a value, and the output transaction data includes transaction attribute information for the transaction data.The linked service unit then acquires the transaction data including the transaction attribute information stored in the linked data storage means, and uses the transaction attribute information to execute a data selection process to determine whether the acquired transaction data is transaction data that should be subjected to the business processing handled by its own unit (the linked service unit).

[0020] Therefore, when the link source service unit outputs transaction data as link data to the link data storage means, the link data does not need to be link data dedicated to the link destination service unit, and can be link data that does not take into account the content of the business processing performed by the link destination service unit. Therefore, the link source service unit can be configured not to be aware of the link destination service unit. In other words, it is possible to realize loose coupling (loosely coupled data linkage method) between the link source service unit and the link destination service unit.

[0021] This eliminates the need to change the design of the source service unit when providing a new service (when a new partner service unit is added) or when changing the content of an existing service (when the business processing content of an existing partner service unit changes), thereby reducing the effort and time required for system modification. This allows for the realization of a new platform infrastructure that takes future sales expansion and scalability into consideration, and improves system maintainability. Therefore, realizing this type of loose coupling eliminates the problems associated with system complexity and size that arise in monolithic systems such as the conventional securities core business back-end system 900 shown in Figure 17, where the source service unit is tightly coupled with the partner service unit.

[0022] Furthermore, the transaction attribute information included in the transaction data output from the source service unit to the linked data storage means is transaction attribute information for the transaction data to be sent to the destination service unit, but it is not intended for a specific destination service unit; rather, it merely describes the content of the linked data (attributes of the transaction data) output by the source service unit so that it can be used in data selection processing at unspecified destination service units (including service units that will be added in the future and service units whose processing content will be changed in the future). In other words, this transaction attribute information is not included in the transaction data with any consideration of the content of the business processing performed by the destination service unit, but simply conveys the content of the linked data (attributes of the transaction data) output by the source service unit to the unspecified destination service unit that will receive the linked data. Therefore, loose coupling (a loosely coupled data linkage method) is realized.

[0023] Furthermore, as described above, the transaction data output as linked data from the linking service unit to the linked data storage means is not based on the content of the business processing performed by the linked service unit, but is output in the format of the linking service unit (the number of items, the content of each item, the order of each item, etc., determined by the linking service unit). Therefore, the linked service unit acquires the transaction data output in the format of the linking service unit from the linked data storage means and acquires transaction attribute information from it. However, when the linked service unit acquires the transaction data, the transaction data is not linked data dedicated to the linked service unit as in the past. Therefore, if it is unclear which part of the transaction data acquired by the linked service unit is transaction attribute information or which part is data for what item, the linked service unit will be unable to perform data selection processing or business processing.

[0024] In contrast, in the present invention, the linked data output to the linked data storage means is in a variable-length data format consisting of a combination of a key and a value, so the linked service unit can recognize where in the acquired transaction data the transaction attribute information is located, or what data items are located at what position. Even if the linking service unit makes a design change and the data location changes, the transaction attribute information and the data for each item can be recognized. Furthermore, even if the linking service unit makes a design change and the data length of the linked data changes, the linked data can be output to the linked data storage means in a variable-length data format consisting of a combination of a key and a value. This allows for changes in the data length of the output linked data, increasing the degree of freedom in the design of the linking service unit, thereby achieving the above-mentioned objective.

[0025] <Configuration in which a plurality of service units include service units as a source and destination of a data linkage method that uses a money update flag and / or a securities update flag>

[0026] In addition, in the above-described securities core business system of the present invention, Among the multiple service units, The service unit of the link source includes a service unit configured to store data of each item constituting the transaction data in a linked data storage means in a variable-length data format consisting of a combination of a key and a value, including a money update flag and / or a securities update flag added by the own unit, and It is desirable that the service unit to which the linkage is made include a service unit configured to acquire transaction data stored in the linked data storage means, and perform a data selection process using a money update flag and / or securities update flag added by the linkage source service unit contained in the acquired transaction data to determine whether the acquired transaction data is transaction data that should be subjected to the business processing that the linkage source service unit is responsible for.

[0027] In this manner, when multiple service units are configured to include a source and destination service unit of a data linkage system that utilizes a money update flag and / or a securities update flag, the source service unit uses the money update flag and / or the securities update flag added by the source service unit to perform data selection processing at the destination service unit. Therefore, a securities backbone business system with a loosely coupled data linkage system can be realized using transaction attribute information suitable for securities backbone business, such as a money update flag and / or a securities update flag. Furthermore, because the money update flag and / or the securities update flag added by the source service unit are used, a loosely coupled data linkage system can be realized even if transaction attribute information is not specified in an external system.

[0028] <Configuration in which data linkage between the reception service unit and the subsequent business service unit is performed using a money update flag and / or a securities update flag corresponding to a transaction code>

[0029] Furthermore, in the securities core business system of the present invention, Among the multiple service units, The service unit of the cooperation source includes a reception service unit that receives transaction data transmitted from an external system via a communication line, The service units to which the service reception unit is linked include the subsequent business service units of the reception service unit. The reception service unit Stores transaction data received from an external system in a reception database provided within the unit, It is desirable that the unit adds a predetermined money update flag and / or securities update flag corresponding to the transaction code included in the transaction data received from the external system as transaction attribute information for the transaction data to be sent to the subsequent business service unit, and that the data for each item that makes up the transaction data, including the added money update flag and / or securities update flag, is stored in the linked data storage means in a variable-length data format consisting of a combination of a key and a value.

[0030] Here, "external system" means a system other than the securities core business system of the present invention.

[0031] Furthermore, the "communication line" may be an external network such as the Internet, an internal network such as a company intranet or company LAN, or a combination of an external network and an internal network, depending on whether the "external system" is an internal consumer or an external consumer (see Figure 1).

[0032] Furthermore, the correspondence between the "money update flag and / or securities update flag predetermined in accordance with the transaction code," i.e., the "transaction code" and the "money update flag and / or securities update flag," may be written (coded) within the program or may be stored in an external database, etc.

[0033] In this manner, when data linkage between the reception service unit and the subsequent business service unit is performed using a money update flag and / or securities update flag corresponding to the transaction code, the linking reception service unit uses the transaction code included in the transaction data to determine the money update flag and / or securities update flag to be added to the transaction data, and stores the transaction data as linked data including the determined money update flag and / or securities update flag in the linked data storage means. Thereafter, the subsequent business service unit acquires the transaction data from the linked data storage means and performs data selection processing to determine whether the transaction data is necessary for business processing in its own unit (business service unit) using the money update flag and / or securities update flag included in the transaction data. Therefore, a loosely coupled data linkage type securities core business system can be realized using transaction attribute information suitable for securities core business, such as the money update flag and / or securities update flag.

[0034] <Configuration for distributed processing within a service unit>

[0035] In addition, in the securities core business system of the present invention, The service unit to which you are linked is a distribution management database that stores the number of distributions for distributing transaction data acquired from the linked data storage means within its own unit, items that serve as distribution keys, and distribution IDs that indicate the base of the root process IDs after distribution within its own unit, in association with the root process IDs before distribution within its own unit; a distributed processing means for distributing transaction data acquired from the linked data storage means according to the number of distributions, for transaction data having the same data of items designated as distribution keys, while maintaining the processing order of the transaction data before distribution, using the information stored in the distribution management database, and for generating a new route process ID after distribution by adding identification information of a branch determined for each route after distribution to the distribution ID according to the number of distributions; In order to process the transaction data distributed by this distributed processing means in separate routes, post-distribution processing means are provided in the own unit in correspondence with the new route process ID after distribution, the number of which is equal to the number of distributions. It is desirable that the configuration be provided with the above.

[0036] When distributed processing is performed within a service unit in this way, the processing speed of the service unit can be improved. For example, if a service unit has a section with high processing performance and a section with low processing performance, applying distributed processing to the section with low processing performance can improve the processing speed of the entire service unit.

[0037] Furthermore, when performing distributed processing, the data is not simply distributed to multiple processing routes, but is distributed in such a way that the processing order of transaction data with the same data items set as distribution keys is maintained before distribution. Therefore, transaction data with the same data items set as distribution keys (for example, if the distribution key is an account number, it is transaction data for the same account number, and if the distribution key is a stock code, it is transaction data for the same stock code) is sent to the same processing route, so the processing order before distribution is maintained for transaction data with the same data items set as distribution keys. Note that if the data items set as distribution keys are not the same transaction data, the processing order may be reversed before and after distribution.

[0038] <Configuration for displaying trace information on a series of business processes executed through data integration>

[0039] Furthermore, in the securities core business system of the present invention, Each service unit has: a log data storage means for storing, as log data, input message information when transaction data is input into the service unit, insert information when the transaction data is registered in a database provided in the service unit, and subsequent link information when the transaction data is stored in a link data storage means for transmission to a subsequent service unit; The input message information, insert information, and subsequent link information stored in the log data storage means each include: A trace ID that is shared among multiple service units in a series of processes that are executed in cooperation with each other, a self-function ID for identifying each transaction processing function executed by each service unit; a requester function ID that identifies the transaction processing function of the requester that transitioned to the transaction processing related to this own function ID; A self-TX linking ID that is assigned when a transaction process related to the self-function ID is executed; The request source TX linking ID assigned at the time of execution of the transaction processing related to the request source function ID is included, a log data collection means for collecting log data stored in a log data storage means provided in each of the service units; a collected log database that stores the log data collected by the log data collecting means; a trace information display means for displaying the log data stored in the collected log database on a screen as trace information for tracing a series of processes executed in cooperation between a plurality of service units; It is desirable to have a configuration including the above.

[0040] When the trace information of a series of business processes executed through data linkage is displayed on the screen in this way, the content of each business process executed through data linkage by multiple service units can be confirmed and tracked on the screen, improving traceability and visibility. This makes it possible to quickly investigate the scope of the impact when a system failure occurs, for example.

[0041] <Program invention>

[0042] The program of the present invention is for causing a computer to function as the above-described securities backbone business system.

[0043] The above program or a portion thereof may be recorded on a recording medium such as a magneto-optical disk (MO), compact disk (CD), digital versatile disk (DVD), flexible disk (FD), magnetic tape, read-only memory (ROM), electrically erasable and programmable read-only memory (EEPROM), flash memory, random access memory (RAM), hard disk drive (HDD), solid-state drive (SSD), or flash disk, and may be transmitted using a transmission medium such as a local area network (LAN), metropolitan area network (MAN), wide area network (WAN), wired network such as the Internet, intranet, or extranet, or a wireless communication network, or a combination thereof, or may be carried on a carrier wave. Furthermore, the above program may be a portion of another program, or may be recorded on a recording medium together with a separate program. [Effects of the Invention]

[0044] As described above, according to the present invention, transaction data including transaction attribute information is output from the service unit that originates the link to the linked data storage means in a variable-length data format consisting of a combination of a key and a value, and the service unit that is the destination of the link acquires the transaction data stored in the linked data storage means and performs a data selection process using the transaction attribute information contained therein to determine whether the acquired transaction data is transaction data that should be used for the business processing that the unit (the service unit that is the destination of the link) is responsible for.This makes it possible to realize loosely coupled data linkage, which has the effect of reducing the effort and time required for system modification work when providing a new service or changing the content of an existing service. [Brief explanation of the drawings]

[0045] [Figure 1] 1 is a diagram showing the overall configuration of a securities core business back-office system, which is one embodiment of the securities core business system of the present invention; [Figure 2] FIG. 2 is another overall configuration diagram of the securities core business back-office system according to the embodiment. [Figure 3] FIG. 2 is a diagram showing a configuration when executing distributed processing according to the embodiment. [Figure 4] FIG. 10 is another configuration diagram for executing distributed processing according to the embodiment. [Figure 5] FIG. 3 is an explanatory diagram of the distributed processing according to the embodiment. [Figure 6] FIG. 2 is a diagram showing a specific example of the configuration of the securities core business back-office system according to the embodiment. [Figure 7] FIG. 3 is a diagram illustrating a specific example of data linkage in the securities core business back-end system according to the embodiment. [Figure 8] FIG. 10 is a diagram illustrating a data linkage method using a money update flag and a securities update flag according to the embodiment. [Figure 9] FIG. 10 is a diagram illustrating a data linkage method using transaction attribute classifications and transaction attribute flags according to the embodiment. [Figure 10] 5 is a diagram illustrating an example of trace information included in log data of each part of each service unit recorded in the securities core business back-end system of the embodiment. FIG. [Figure 11] FIG. 3 is an explanatory diagram of the collection of log data in the securities core business back-office system according to the embodiment. [Figure 12] FIG. 4 is a diagram showing an example (part 1) of a screen display by the trace information display means of the embodiment. [Figure 13] FIG. 10 is a diagram showing an example (part 2) of a screen display by the trace information display means of the embodiment. [Figure 14] FIG. 10 is a diagram showing a third example of a screen display by the trace information display means of the embodiment. [Figure 15] FIG. 10 is a diagram showing a fourth example of a screen display by the trace information display means of the embodiment. [Figure 16] FIG. 5 is a diagram showing an example (part 5) of a screen display by the trace information display means of the embodiment. [Figure 17] A diagram showing the configuration of a conventional securities back-office system. DETAILED DESCRIPTION OF THE INVENTION

[0046] A securities core business back-end system 10, which is one embodiment of the securities core business system of the present invention, will be described below with reference to the drawings. FIGS. 1 and 2 show the overall configuration of the securities core business back-end system 10 of this embodiment. This securities core business back-end system 10, together with a securities core business front-end system that handles order processing for securities trading, constitutes a securities core business system. FIGS. 3 and 4 show the configuration of a service unit 40 (40Y) when performing distributed processing, and FIG. 5 is an explanatory diagram of distributed processing. FIG. 6 shows a specific configuration example of the securities core business back-end system 10, FIG. 7 shows a specific example of data linkage in the securities core business back-end system 10, FIG. 8 shows an example of a data linkage method using a money update flag and a securities update flag, and FIG. 9 shows an example of a data linkage method using a transaction attribute classification and a transaction attribute flag. Furthermore, Figure 10 shows an example of trace information contained in the log data of each part of each service unit 20, 40 recorded in the securities core business back-end system 10, Figure 11 is an explanatory diagram of the collection of log data in the securities core business back-end system 10, and Figures 12 to 16 show examples (No. 1 to No. 5) of screen displays by the trace information display means 86.

[0047] <Overall configuration of securities back-office system 10>

[0048] 1 and 2, the securities core business back-end system 10 is configured with one or more computers, and includes one or more reception service units (reception SLUs) 20, one or more business service units (business SLUs) 40, and one or more data linkage containers (TOPICs) 70. A more specific configuration example is shown in FIG. 6. Note that the "service units" and "SLUs" have already been described in detail in [Means for Solving the Problems], so a detailed explanation will be omitted here.

[0049] The reception service unit (reception SLU) 20 includes a reception means 22 and a reception data registration means 23 configured by a reception container (APP container: application software container) 21, a post-registration data acquisition means 25 and a linked data transmission means 26 in the service unit configured by an linked data transmission container (MQS-based container: Message Queueing Send-based container) 24, and a reception database server (reception DB server) 30. The reception database server 30 is configured by one or more computers, and includes a reception database (reception DB) 31, a transaction attribute database (transaction attribute DB) 32, and a post-registration database (post-registration DB) 33.

[0050] Here, the receiving means 22, the received data registration means 23, the post-registration data acquisition means 25 within the service unit, and the linked data transmission means 26 are realized by a central processing unit (CPU) provided inside the computer constituting the securities core business back-office system 10, one or more programs that define the operating procedures of this CPU, and working memories such as main memory and cache memory. The details of each of these means 22, 23, 25, and 26 will be described later.

[0051] For convenience of explanation, the receiving means 22 and the received data registration means 23 are described as being configured by the receiving container 21, and the intra-service unit post-registration data acquisition means 25 and the linked data transmission means 26 are described as being configured by the linked data transmission container 24. In the illustration, the respective means 22, 23, 25, and 26 are shown as being included in the container, but because the container is a concept that does not include hardware (physical server equipment), an OS (operating system), or a container engine, the respective means 22, 23, 25, and 26 are not configured by the container alone, but are configured including the hardware, OS, and container engine. The same applies to other containers.

[0052] Furthermore, for example, nonvolatile memories such as hard disk drives (HDDs) and solid state drives (SSDs) can be used as the databases 31, 32, and 33 included in the reception database server 30. Details of the databases 31, 32, and 33 will be described later.

[0053] The business service unit (business SLU) 40 includes a linked data acquisition means 42, an acquired linked data registration means 43, and a distributed processing means 44, which are configured using a linked data acquisition container (MQR-based container: Message Queueing Receive-based container) 41; a pre-registration data acquisition means 46, a data selection API calling means 47, and a registration API calling means 48 within the service unit, which are configured using a pre-registration data acquisition container (DPP-based container: Derivation Processing Program-based container) 45; a data selection means 50 and a business data registration means 51, which are configured using a business container (APP container) 49; a post-registration data acquisition means 53 and a linked data transmission means 54 within the service unit, which are configured using a linked data transmission container (MQS-based container) 52; and a business database server (business DB server) 60. In addition, the business database server 60 is composed of one or more computers and includes a business database (business DB) 61, a transaction attribute database (transaction attribute DB) 62, a root process management database (root process management DB) 63, a distributed management database (distributed management DB) 64, a pre-registration database (pre-registration DB) 65, and a post-registration database (post-registration DB) 66.

[0054] Here, the linked data acquisition means 42, acquired linked data registration means 43, distributed processing means 44, intra-service-unit pre-registration data acquisition means 46, data selection API calling means 47, registration API calling means 48, data selection means 50, business data registration means 51, intra-service-unit post-registration data acquisition means 53, and inter-service-unit linked data transmission means 54 are realized by a central processing unit (CPU) provided inside a computer constituting the securities core business back-office system 10, one or more programs that define the operating procedures of this CPU, and working memory such as main memory and cache memory. Details of each of these means 42, 43, 44, 46, 47, 48, 50, 51, 53, and 54 will be described later.

[0055] Furthermore, for example, nonvolatile memories such as hard disk drives (HDDs) and solid state drives (SSDs) can be used as the databases 61 to 66 included in the business database server 60. Details of the databases 61 to 66 will be described later.

[0056] The data linkage container 70 includes a linkage data management means 71 and a linkage data storage means 72. The linkage data management means 71 stores linkage data received from a link source service unit (the reception service unit 20 or the business service unit 40) in the linkage data storage means 72, and executes processing to transmit the linkage data stored in the linkage data storage means 72 to a link destination service unit (the business service unit 40) in response to a linkage data acquisition request from the link destination service unit. The linkage data storage means 72 stores transaction data as linkage data in a variable-length data format (in this embodiment, JSON format) consisting of a combination of keys and values. In this embodiment, the data linkage container 70 uses AMQ Streams (Apache Active MQ Streams) as an example, and TOPIC is used as the product.

[0057] Here, the linked data management means 71 is realized by a central processing unit (CPU) provided inside a computer constituting the securities back-office system 10, one or more programs that define the operating procedures of this CPU, and working memory such as main memory and cache memory. The linked data storage means 72 is composed of non-volatile memory.

[0058] The securities core business back-office system 10 also includes log data storage means 80 (not shown in FIGS. 1 and 2) provided in each part of each service unit 20, 40 to store input / output log data (see FIGS. 10 and 11) of each part, log data collection means 82 configured by a log data collection container 81, a collected log database (collected log DB) 84 included in a log collection server 83, and trace information display means 86 configured by a display container 85. In this embodiment, a sidecar container is used as the log data collection container 81, as an example.

[0059] Here, the log data collection means 82 and the trace information display means 86 are realized by a central processing unit (CPU) provided inside a computer constituting the securities back-office system 10, one or more programs that define the operating procedures of this CPU, and working memories such as main memory and cache memory. Details of each of these means 82 and 86 will be described later.

[0060] Furthermore, for example, a nonvolatile memory such as a hard disk drive (HDD) or a solid state drive (SSD) can be used as the collected log database 84 included in the log collection server 83. The collected log database 84 will be described in detail later.

[0061] Furthermore, the securities core business back-end system 10 is connected to an internal API infrastructure system 91 for in-house consumers or an external API infrastructure system 92 for external consumers, as well as an external system 100 via a communication line (an internal network 1 such as an in-house intranet or in-house LAN, or an external network 2 such as the Internet). API stands for Application Programming Interface.

[0062] The external system 100 includes other internal systems 101 (such as a securities core business front system that processes orders) and internal user terminals 102 that are internal consumers, and external systems 103 (such as systems of other financial institutions) and external user terminals 104 that are external consumers.

[0063] When the external system 100 is an internal consumer, transaction data transmitted from the external system 100 via the internal network 1 passes through the internal API infrastructure system 91 and is received by the reception means 22, which serves as the API receiving port of the reception service unit 20, via the internal network 1. On the other hand, when the external system 100 is an external consumer, transaction data transmitted from the external system 100 via the external network 2 passes through the external API infrastructure system 92 and is received by the reception means 22, which serves as the API receiving port of the reception service unit 20, via the internal network 1.

[0064] Note that communication within the securities core business back-end system 10 is carried out via the internal network 1. Therefore, when there is no particular mention of the type of communication line for sending and receiving linked data within the securities core business back-end system 10, in this embodiment, communication is via the internal network 1, but in the present invention (the claimed invention), the type of communication line does not matter for communication within the securities core business system or communication between an external system and the securities core business system, so it may be an internal network, an external network, or a dedicated line.

[0065] <Configuration of Reception Service Unit (Reception SLU) 20 / Reception Container (APP Container) 21>

[0066] 2, the receiving means 22 executes a process of receiving transaction data (for example, transaction data of an agreement, etc.) transmitted from the external system 100 via the internal API-based system 91 or the external API-based system 92 and a communication line. That is, the receiving means 22 executes a process of acting as a receiving port for the API (in this embodiment, a public API) and passes the received transaction data to the received data registration means 23.

[0067] 2, the reception data registration means 23 performs the business processing for its own unit (here, the reception service unit 20), and then stores the transaction data after the business processing in a database (here, the reception database 31) provided in its own unit 20, and also stores the transaction data in the post-registration database 33. Note that in the case of the reception service unit 20, although it may perform a process to add transaction attribute information to the transaction data received from the external system 100 as described below, it stores the received transaction data almost as is in the reception database 31 and the post-registration database 33.

[0068] Furthermore, as shown in Figure 2, the reception data registration means 23 executes a process of storing the transaction data including the transaction attribute information (money update flag, securities update flag, transaction attribute flag, transaction attribute class) in the post-registration database 33 in order to store the data of each item constituting the transaction data in the associated data storage means 72 in a variable-length data format (in this embodiment, JSON format) consisting of a combination of key and value, with the transaction attribute information for the transaction data to be sent to the associated service unit 40 (however, the transaction data is intended for unspecified service unit 40 without being aware of which service unit 40 the transaction data is intended for).The transaction attribute information for the transaction data to be sent to the associated service unit 40 is the money update flag added by its own unit (here, the reception service unit 20), or the securities update flag added by its own unit 20, or the transaction attribute flag of the transaction data specified by the external system 100, or the transaction attribute class of the transaction data specified by the external system 100.

[0069] Here, the "money update flag" is a flag that indicates that the transaction involves updating the customer's money balance, and a value of "1" indicates that the transaction involves updating the customer's money balance, while a value of "0" indicates that the transaction does not. Specific examples of using this "money update flag" as transaction attribute information are shown in Figures 7 and 8.

[0070] Furthermore, the "securities update flag" is a flag indicating that the transaction involves updating the customer's securities balance, with a value of "1" indicating that the transaction involves updating the customer's securities balance, and a value of "0" indicating that the transaction does not. Specific examples of using this "securities update flag" as transaction attribute information are shown in Figures 7 and 8.

[0071] Furthermore, since the "transaction attribute flag" is a flag specified by the external system 100, it is a flag included in the transaction data received from the external system 100, and takes on the value "1" or "0," similarly to the "money update flag" and "securities update flag." Although specific examples are not shown, as explained below regarding the "transaction attribute classification," the "transaction attribute classification" can be broken down into multiple transaction attribute flags, and in that sense, it is information (transaction attribute information) that plays a similar role to the "transaction attribute classification." Note that, among the multiple reception service units 20 and multiple business service units 40, there may be a service unit that uses a transaction attribute flag added by itself (a flag other than the "money update flag" or the "securities update flag") rather than using the transaction attribute flag specified by the external system 100.

[0072] Furthermore, the "transaction attribute classification" is a classification (information for identifying two or more transaction attributes) specified by the external system 100, and is therefore a classification (transaction attribute identification information) included in the transaction data received from the external system 100. Specific examples are shown in FIGS. 7 and 9. Note that among the multiple reception service units 20 and multiple business service units 40, there may be a service unit that uses a transaction attribute classification added by itself, rather than using a transaction attribute classification specified by the external system 100. Furthermore, this "transaction attribute classification" can be broken down into multiple transaction attribute flags. For example, a transaction attribute flag indicating that the content of classification = 01 applies, and similarly, each transaction attribute flag indicating that the content of classification = 02, classification = 03, ... applies. In this sense, it is information (transaction attribute information) that plays a role similar to that of a "transaction attribute flag."

[0073] In this embodiment, the accepted data registration means 23 adds a "money update flag" and / or a "securities update flag" that is predetermined corresponding to the transaction code included in the transaction data received from the external system 100 (i.e., the transaction code specified by the external system 100) to the transaction data in its own unit (here, the acceptance service unit 20), and outputs the transaction data with the "money update flag" and / or "securities update flag" added to the post-registration database 33 so that it can be stored in the linked data storage means 72 (see FIG. 8). Note that the intention is that it is sufficient that acceptance service units 20 equipped with accepted data registration means 23 that executes such processing are present in the securities core business back-office system 10, and all acceptance service units 20 do not need to be service units equipped with accepted data registration means 23 that executes such processing.

[0074] Furthermore, as described above, when the received data registration means 23 performs a process of adding a "money update flag" and / or a "securities update flag" to the transaction data that is predetermined in correspondence with the transaction code contained in the transaction data, the correspondence between the "transaction code" and the "money update flag and / or securities update flag" may be written (coded) in the program that constitutes the received data registration means 23, or may be stored in an external transaction attribute database 32 (see Figure 8).

[0075] <Configuration of Reception Service Unit (Reception SLU) 20 / Association Data Transmission Container (MQS Infrastructure Container) 24>

[0076] As shown in Figure 2, the post-registration data acquisition means 25 in the service unit acquires transaction data stored in the post-registration database 33 and executes a process of passing the acquired transaction data to the associated data transmission means 26.

[0077] The linked data transmission means 26 outputs (transmits) the transaction data received from the data acquisition means 25 after registration within the service unit to the data linkage container 70 in a variable-length data format (in this embodiment, JSON format) consisting of a combination of key and value, and executes the process of storing it in the linked data storage means 72.

[0078] <Configuration of reception service unit (reception SLU) 20 / reception database server 30>

[0079] The reception database server 30 is equipped with a database management system (DBMS) and manages data input (new registration, updates) to each of the databases 31, 32, and 33 and data acquisition from each of the databases 31, 32, and 33.

[0080] The reception database 31 stores transaction data after the reception service unit 20 has performed the primary processing.

[0081] The transaction attribute database 32 stores the correspondence between the "transaction code" contained in the transaction data received from the external system 100 and the "money update flag and / or securities update flag." It is also possible to omit providing the transaction attribute database 32 and to code the above correspondence into the program constituting the received data registration means 23. However, it is preferable to provide the transaction attribute database 32 from the viewpoint of facilitating responses to cases where a new service emerges and the number of transaction codes increases.

[0082] As shown in FIG. 2, the post-registration database 33 is provided to pass transaction data from the reception container 21 to the linked data transmission container 24, and stores the transaction data.

[0083] <Configuration of Business Service Unit (Business SLU) 40 / Association Data Acquisition Container (MQR Infrastructure Container) 41>

[0084] 2, the linked data acquisition means 42 transmits a monitoring signal to the data linkage container 70 at predetermined time intervals (for example, every 1 second, every 10 seconds, etc.), acquires linked data (transaction data including transaction attribute information) stored in the linked data storage means 72, and executes a process of passing the acquired transaction data to the acquired linked data registration means 43. At the stage of acquiring transaction data by this linked data acquisition means 42, all of the linked data (transaction data) stored in the linked data storage means 72 is acquired, regardless of whether the transaction data is transaction data that needs to be processed by its own unit (here, the business service unit 40) (i.e., transaction data related to the business processing handled by its own unit 40) or not.

[0085] 2, the acquired linked data registration means 43 receives transaction data (transaction data acquired from the linked data storage means 72) from the linked data acquisition means 42. If the distributed processing means 44 indicated by the two-dot chain line in FIG. 2 is not provided, the acquired linked data registration means 43 executes a process of storing the transaction data received from the linked data acquisition means 42 in a single pre-registration database 65. On the other hand, if the distributed processing means 44 is provided, the acquired linked data registration means 43 requests distributed processing from the distributed processing means 44, receives the transaction data in a distributed state from the distributed processing means 44, and stores the distributed transaction data in multiple pre-registration databases 65 (see FIGS. 3 to 5) corresponding to the number of distributions. Note that the transaction data stored in the pre-registration database 65 is substantially the same in content as the transaction data received from the linked data acquisition means 42 (i.e., the transaction data acquired from the linked data storage means 72). However, there are differences, such as the addition of a status indicating the progress of processing to the transaction data record. Furthermore, the transaction data is naturally stored in a database format rather than a variable-length data format (in this embodiment, JSON format) consisting of a combination of keys and values.

[0086] As shown in Fig. 2, the distributed processing means 44 receives a request from the acquired linked data registration means 43, executes distributed processing using information stored in the distributed management database 64, and executes processing to pass the distributed transaction data to the acquired linked data registration means 43. This distributed processing means 44 is not provided in all business service units 40, and is therefore depicted by two-dot chain lines in Figs. 1 and 2. Details of the processing by the distributed processing means 44 will be described later using Figs. 3 to 5.

[0087] <Configuration of Business Service Unit (Business SLU) 40 / Pre-registration Data Acquisition Container (DPP Infrastructure Container) 45>

[0088] 2, the intra-service-unit pre-registration data acquisition means 46 executes a process of acquiring transaction data stored in the pre-registration database 65 and passing it to the data selection API calling means 47. Furthermore, as shown by the dotted line in FIG. 2, when the intra-service-unit pre-registration data acquisition means 46 receives information from the data selection API calling means 47 that a data selection API request has been accepted, it also executes a process of changing the status of the transaction data record stored in the pre-registration database 65 to processed.

[0089] 2, the data selection API calling means 47 receives transaction data (including transaction attribute information) acquired from the pre-registration database 65 from the pre-registration data acquisition means 46 in the service unit, sets the transaction data including the received transaction attribute information in a data selection API request, and transmits the data selection API request to the data selection means 50. In addition, the data selection API calling means 47 also receives information from the data selection means 50 that the data selection API request has been accepted, as indicated by the dotted line in FIG. 2, and passes the information to the pre-registration data acquisition means 46 in the service unit.

[0090] 2, when the data selection process of the data selection means 50 determines that the transaction data is transaction data (i.e., transaction data related to the business processing handled by the own unit 40) that should be processed by the own unit (here, the business service unit 40) and the registration API calling means 48 receives information to that effect (that the business processing will be executed by the own unit 40) from the data selection means 50, the registration API calling means 48 executes processing to send a registration API request to the business data registration means 51. Therefore, if the registration API calling means 48 does not receive information to the effect that the business processing will be executed by the own unit 40 from the data selection means 50, the processing to send a registration API request to the business data registration means 51 is not executed.

[0091] <Configuration of Business Service Unit (Business SLU) 40 / Business Container (APP Container) 49>

[0092] 2, the data selection means 50 receives a data selection API request sent from the data selection API calling means 47, and executes a data selection process using the transaction attribute information included in the transaction data set in the data selection API request to determine whether the transaction data set in the data selection API request (i.e., the transaction data obtained from the linked data storage means 72) is transaction data that should be processed by its own unit (here, the business service unit 40) for business processing.If it determines that the transaction data is transaction data that should be processed by its own unit 40 for business processing, it executes a process to send information to the registration API calling means 48 that indicates that the business processing will be performed by its own unit 40.On the other hand, if the data selection means 50 determines that the transaction data is not transaction data that should be processed by its own unit 40 for business processing, it does not perform the transmission process to the registration API calling means 48.

[0093] More specifically, when performing data selection processing using transaction attribute information, if the transaction data set in the data selection API request includes a "money update flag" as transaction attribute information, the data selection means 50 determines whether the value of the "money update flag" is "1," and if it is "1," determines that the transaction data set in the data selection API request is transaction data that should be processed by the business process handled by its own unit 40. A specific example is shown in FIG. 7.

[0094] Similarly, when the transaction data includes a "securities update flag" as transaction attribute information, the data selection means 50 determines whether the value of the "securities update flag" is "1," and if it is "1," determines that the transaction data set in the data selection API request is transaction data that should be processed by the own unit 40. A specific example is shown in FIG. 7.

[0095] In addition, if the transaction data contains a "transaction attribute flag" as transaction attribute information, the data selection means 50 determines whether the value of the "transaction attribute flag" is "1", and if it is "1", determines that the transaction data set in the data selection API request is transaction data that should be subjected to the business processing handled by its own unit 40.

[0096] Furthermore, if the transaction data includes a "transaction attribute classification" as transaction attribute information, the data selection means 50 determines whether the value of the "transaction attribute classification" is a predetermined value (a value written in the program constituting the data selection means 50 or a value stored in an external storage means for determining the appropriateness of the work handled by the data selection means 50), and if the value is a predetermined value, determines that the transaction data set in the data selection API request is transaction data that should be processed by the data selection means 40, or determines whether the transaction data includes a "transaction attribute classification," and if it determines that the transaction data includes a "transaction attribute classification," determines that the transaction data set in the data selection API request is transaction data that should be processed by the data selection means 40, regardless of the value of the "transaction attribute classification." A specific example is shown in FIG. 7.

[0097] Furthermore, when the data selection means 50 receives a data selection API request from the data selection API calling means 47, it also executes a process of sending information that the data selection API request has been accepted to the data selection API calling means 47, as shown by the dotted line in Fig. 2. Therefore, the information that the data selection API request has been accepted is transmitted in this order from the data selection means 50 to the data selection API calling means 47 and to the intra-service-unit pre-registration data acquisition means 46, as shown by the dotted line in Fig. 2, and is reflected in the status of the record of the transaction data stored in the pre-registration database 65 (changed to processed).

[0098] 2, when the business data registration means 51 receives a registration API request sent from the registration API calling means 48, it performs the business processing that is the responsibility of its own unit (here, the business service unit 40), and stores the transaction data after the business processing in a database (here, the business database 61) provided in its own unit 40, and also executes processing to store the transaction data in the post-registration database 66. Therefore, if the transaction data acquired from the linked data storage means 72 is transaction data that should be subjected to the business processing that is the responsibility of its own unit 40, the data selection means 50 makes a judgment result to that effect (that the business processing will be executed in its own unit 40), and this judgment result is transmitted to the registration API calling means 48 and further transmitted to the business data registration means 51 as a registration API request, and registration (new registration or update registration) is performed in the business database 61 and the post-registration database 66.

[0099] At this time, when the business data registration means 51 stores the transaction data in the post-registration database 66, it adds the transaction data registered in the business database 61 to the transaction data acquired from the associated data storage means 72 (transaction data set in the data selection API request received by the data selection means 50) and stores the result in the post-registration database 66. Note that the transaction data acquired from the associated data storage means 72 may be added to the transaction data registered in the business database 61, including data of items that overlap with the transaction data acquired from the associated data storage means 72 (transaction data set in the data selection API request received by the data selection means 50), and stored in the post-registration database 66. Alternatively, it may be possible to store only the data of items of the transaction data registered in the business database 61 that do not overlap with the transaction data acquired from the associated data storage means 72, in addition to the transaction data acquired from the associated data storage means 72, in the post-registration database 66.

[0100] In the above, the transaction data acquired from the associated data storage means 72 includes transaction attribute information (money update flag, securities update flag, transaction attribute flag, transaction attribute classification), and this transaction attribute information is stored as is in the post-registration database 66 for transmission to the business service unit 40 subsequent to the own unit 40. Furthermore, new transaction attribute information may be added in the own unit 40 (the business service unit 40 currently executing business processing using the business data registration means 51) for transmission to the business service unit 40 subsequent to the own unit 40. For this purpose, the transaction attribute database 62 is provided. In this case, the transaction attribute information included in the transaction data acquired from the associated data storage means 72 may be temporarily deleted, and new transaction attribute information may be added. Alternatively, the new transaction attribute information may be added in addition to the transaction attribute information included in the transaction data acquired from the associated data storage means 72.

[0101] If no subsequent business service unit 40 is installed after the own unit 40, the post-registration database 66 does not need to be installed, and is therefore indicated by a two-dot chain line in Fig. 1. Therefore, in this case, no output to the post-registration database 66 is performed.

[0102] <Configuration of Business Service Unit (Business SLU) 40 / Association Data Transmission Container (MQS Infrastructure Container) 52>

[0103] If there is no business service unit 40 subsequent to the own unit (here, business service unit 40) installed, the linked data transmission container (MQS infrastructure container) 52 does not need to be installed, and is therefore shown by a dotted line in Figure 1.

[0104] As shown in Figure 2, the post-registration data acquisition means 53 in the service unit acquires transaction data stored in the post-registration database 66 and executes a process of passing the acquired transaction data to the associated data transmission means 54.

[0105] The linked data transmission means 54 outputs (transmits) the transaction data received from the post-registration data acquisition means 53 within the service unit to the subsequent data linkage container 70 in a variable-length data format (in this embodiment, JSON format) consisting of a combination of key and value, and executes the process of storing it in the linked data storage means 72.

[0106] <Configuration of business service unit (business SLU) 40 / business database server 60>

[0107] The business database server 60 is equipped with a database management system (DBMS) and manages data input (new registration, updates) to each of the databases 61 to 66 and data acquisition from each of the databases 61 to 66 .

[0108] The business database 61 stores business data after the business processing handled by the business service unit 40 has been completed. A specific example is shown in FIG.

[0109] The transaction attribute database 62 stores the correspondence between the "transaction code" contained in the transaction data obtained from the linked data storage means 72 (transaction data set in the data selection API request received by the data selection means 50) and the "money update flag and / or securities update flag," and also stores transaction attribute information to be added to the transaction data to be sent to the subsequent business service unit 40 of its own unit 40.

[0110] As shown in FIG. 4, the root process management database 63 stores, in association with each other, the root process ID (RPID) for the processing route (processing route within the linked data acquisition container (MQR-based container) 41) where the first processing is performed within the business service unit 40, and the root process ID (APP-RPID) for the distribution business application on the processing route (processing route within the pre-registration data acquisition container (DPP-based container) 45) that is the target of distribution when distributed processing is performed. When distributed processing is performed, the former root process ID (RPID) is the root process ID for the processing route before distribution. On the other hand, the latter root process ID (APP-RPID) for the distribution business application is the root process ID for the processing route within the pre-registration data acquisition container (DPP-based container) 45 that is the destination when distributed processing fails, that is, the root process ID for that processing route when there is only one processing route within the pre-registration data acquisition container (DPP-based container) 45.

[0111] As shown in Figure 4, the distribution management database 64 stores the number of distributions for distributed processing of transaction data obtained from the linked data storage means 72 within its own unit 40, the distributed processing class name which is the name of the module that constitutes the distributed processing means 44, the constructor setting value indicating the item that will be the distribution key, and the distribution ID indicating the base of the root process ID for the processing route after distribution within its own unit 40, in association with the root process ID for the processing route before distribution within its own unit 40.

[0112] The pre-registration database 65 stores the transaction data to be sent from the linked data acquisition container (MQR-based container) 41 to the pre-registration data acquisition container (DPP-based container) 45 .

[0113] The post-registration database 66 stores the transaction data to be transmitted from the business container (APP container) 49 to the associated data transmission container (MQS-based container) 52 .

[0114] <Details of distributed processing by distributed processing means 44: Figures 3 to 5>

[0115] (Explanation of Figure 3)

[0116] 3 shows two types of root process configurations (arrangement of processing routes that connect a series of processes) when performing distributed processing. Distributed processing is performed to improve the processing speed of the entire system, for example, when part of the system configuration includes a part with low processing performance (in this embodiment, containers are used, so for example, the processing performance of some containers is low).

[0117] The upper part of Fig. 3 shows the form of the root process when the linked data that has been distributed by distributed processing within the linking source service unit (SLU) or within a service unit (SLU) further upstream is separately acquired and processed by the linked destination service unit (SLU). On the other hand, the lower part of Fig. 3 shows the form of the root process when distributed processing is performed using a distribution key within the linked destination service unit (SLU).

[0118] More specifically, a securities backbone business back-end system 10 (see FIGS. 1 and 2) according to this embodiment, which is an embodiment of the securities backbone business system of the present invention, can employ a configuration such as that shown in FIG. 6. In FIG. 3, the service unit from which the link is established is denoted by the reference numeral 20X or 40X for convenience of explanation, with the intention that it does not specify whether the service unit is one of the various reception service units 20 (20A, 20B, 20C, 20D, 20E, or a new reception service unit 20 established thereafter) or one of the various business service units 40 (40A, 40B, 40C, 40D, 40E, 40F, 40G, 40H, 40J, ..., or a new business service unit established thereafter) shown in FIG. 6 (meaning that either is acceptable).

[0119] Similarly, the service unit to be linked is denoted by the symbol 40Y for ease of explanation, without specifying which of the various business service units 40 (40A, 40B, 40C, 40D, 40E, 40F, 40G, 40H, 40J, ..., or a new business service unit to be newly established later) shown in Fig. 6 it is. Similarly, the data linkage container 70 is denoted by the symbols 70X and 70Y, without specifying which of the data linkage containers 70A, 70B, 70C, 70D, 70E, 70F, 70G, ... shown in Fig. 6 it is.

[0120] The problem of the overall system processing speed not increasing due to the presence of areas with low processing performance can also be solved by performing the distributed processing shown in the upper part of Fig. 3. However, when multiple processing routes extending from upstream to downstream are constructed, for example, when two processing routes are constructed to perform two types of distributed processing, a configuration is required in which linked data storage means 72-1 and linked data storage means 72-2 are provided for both data linkage containers 70X and 70Y.

[0121] On the other hand, as shown in the lower part of Figure 3, if there are some parts with low processing performance and you want to avoid the impact of this by using distributed processing, you can perform distributed processing within the service unit (SLU) where the part with low processing performance is located. With a configuration like the lower part of Figure 3, even if transaction data is not sent in a distributed state from the collaboration source or an upstream service unit, distributed processing can be performed within the local unit 40Y, thereby improving processing speed. For example, in the case of two-way distributed processing, one processing route with a root process ID (RPID) = RPID1 is branched into two processing routes, one with RPID1 and one with RPID2, and multiplexed. In this example, the linked data acquisition container (MQR-based container) 41Y has one processing route MQR (RPID1), which branches off to multiplex the processing routes, resulting in DPP (RPID1) and DPP (RPID2) in the pre-registration data acquisition container (DPP-based container) 45Y, and APP (RPID1) and APP (RPID2) in the business container (APP container) 49Y, which then merge again to form one processing route MQS (RPID1) in the linked data transmission container (MQS-based container) 52Y. This is shown in detail in Figure 4.

[0122] (Explanation of the first half of Figure 4)

[0123] 4, the following distributed processing is performed inside the business service unit 40 (40Y). Hereinafter, for the purposes of space, the letter "Y" may not be attached to the reference numerals for the processing within this unit 40 (40Y), but even if the reference numeral does not have the letter "Y", it is still a component of 40Y.

[0124] First, the linked data acquisition means 42 sends a monitoring signal to the data linkage container 70X at a predetermined time interval, acquires the linked data (transaction data including transaction attribute information, in a variable-length data format (JSON format in this embodiment) consisting of a combination of key and value) stored in the linked data storage means 72X, and passes the acquired transaction data to the acquired linked data registration means 43. The transaction data acquired here is all of the transaction data newly stored in the linked data storage means 72X since the last acquisition, regardless of whether it is transaction data related to business processing handled by the business service unit 40Y.

[0125] Next, the acquired linked data registration means 43 receives the transaction data from the linked data acquisition means 42 and passes the transaction data to the distributed processing means 44 to request distributed processing. In the example of Figure 4, the distributed processing means 44 is provided in the business service unit 40Y, and the number of distributions stored in the distribution management database 64 is "2", so two pre-registration databases 65-1 and 65-2 are provided.

[0126] Then, the distributed processing means 44 executes a process of distributing the transaction data received from the acquired linked data registration means 43 by the number of shares stored in the distributed management database 64, using the item (constructor setting value) that serves as the distribution key stored in the distributed management database 64. In Fig. 4, as an example, the number of shares = 2, and the item (constructor setting value) that serves as the distribution key is the account number (AccountIdentificationNumber), which is customer identification information.

[0127] (Explanation of Figure 5)

[0128] As shown in FIG. 5, the distributed processing means 44 distributes the transaction data received from the acquired linked data registration means 43 into two databases because the distribution number is two. In this case, the distribution into two does not simply mean distributing the data alternately to the two pre-registration databases 65-1 and 65-2. Because the item designated as the distribution key is the account number, transaction data containing the same account number is distributed so that it is output to the same pre-registration database of the two pre-registration databases 65-1 and 65-2. The same applies when the distribution number is three or more; transaction data containing the same account number is output to the same pre-registration database (one of the pre-registration databases 65-1, 65-2, 65-3, ..., 65-N, where N = the number of divisions). Therefore, when performing distributed processing, the distributed processing means 44 determines which pre-registration database the data should be output to, and returns the transaction data to the acquired linked data registration means 43 along with information on the determination result (information indicating the processing route after distribution).

[0129] As a result, transaction data containing the same account number is output to each of the two pre-registration databases 65-1 and 65-2 while maintaining the processing order before distribution. The processing order before distribution is the order in which the distributed processing means 44 receives the transaction data to be distributed from the acquired linked data registration means 43, and is the same as the order in which the linked data acquisition means 42 acquires the transaction data from the linked data storage means 72X (TOPIC in this embodiment).

[0130] In the example of FIG. 5, the distributed processing means 44 attaches determination result information indicating that transaction data whose account numbers end with odd numbers should be output to pre-registration database 65-1, and that transaction data whose account numbers end with even numbers should be output to pre-registration database 65-2, and returns the information to the acquired linked data registration means 43. At this time, the determination result information may be returned together with the transaction data to the acquired linked data registration means 43, which is the source of the distributed processing request, or the determination result information alone may be returned. Note that the distribution conditions are not limited to whether the account number ends with an even or odd number. For example, in the case of distribution by 3, distribution may be performed according to the remainder when the end of the account number is divided by 3, or distributed processing may be performed in accordance with a distribution condition table (which may be written in a program constituting the distributed processing means 44 or may be stored in an external distribution condition table storage means).

[0131] 5, for example, assume that transaction data including contract numbers Y000001 to Y000008 are acquired in this order from the associated data storage means 72X. At this time, among these eight transaction data, the transaction data including account number K000003 are two transaction data including contract numbers Y000001 and Y000004, but the order in which these transaction data are output to the pre-registration database 65-1 maintains the order before distribution (the order in which they were acquired from the associated data storage means 72X by the associated data acquisition means 42). Similarly, among the eight transaction data, the transaction data including account number K000004 are two transaction data including contract numbers Y000003 and Y000008, but the order in which these transaction data are output to the pre-registration database 65-2 also maintains the order before distribution (the order in which they were acquired from the associated data storage means 72X by the associated data acquisition means 42).

[0132] (Explanation of the second half of Figure 4)

[0133] 4, if the identification information of business service unit 40Y is "ZS101," then root process management database 63 stores "ZS101R001001" as the root process ID (RPID1) indicating the processing route before distribution, and since this is before distribution, it is the root process ID of the linked data acquisition container (MQR infrastructure container) 41Y. Also, distribution management database 64 stores "ZS101D001" as the distribution ID in association with this root process ID (RPID1) indicating the processing route before distribution, and this distribution ID is the base portion (RPID excluding the last three digits) of the root process ID of the pre-registration data acquisition container (DPP infrastructure container) 45 indicating the processing route after distribution.

[0134] The distributed processing means 44 automatically generates "001" and "002" as branch parts of the root process ID indicating the distributed processing route according to the distribution number (in the example of FIG. 4, the distribution number = 2) stored in the distribution management database 64 in association with "ZS101R001001," which is the root process ID (RPID1) indicating the processing route before distribution. By adding these branch parts to the end of the base distribution ID = "ZS101D001," the distributed processing means 44 automatically generates "ZS101D001001," which is the root process ID (RPID1) indicating the first distributed processing route, and "ZS101D001002," which is the root process ID (RPID2) indicating the second distributed processing route. Note that if the distribution number is three or more, the branch parts "003," "004," ... are added to the base distribution ID, and the distributed processing means 44 automatically generates root process IDs (RPID3, RPID4, ...) indicating the third, fourth, ... processing routes after distribution. These automatically generated route process IDs (RPID1, RPID2, ...) indicating the post-distribution processing routes are common to the pre-registration data acquisition container (DPP infrastructure container) 45 part and the business container (APP container) 49 part.

[0135] Therefore, pre-registration database 65-1 is a pre-registration DB corresponding to "ZS101D001001," which is a root process ID (RPID1) indicating the first processing route after distribution, and pre-registration database 65-2 is a pre-registration DB corresponding to "ZS101D001002," which is a root process ID (RPID2) indicating the second processing route after distribution. Distributed processing means 44 returns information indicating either the first or second processing route after distribution ("ZS101D001001" or "ZS101D001002") to acquired linked data registration means 43 as determination result information regarding which pre-registration database to output to.

[0136] The pre-registration data acquisition container (DPP base container) 45Y is provided with a first processing means 45-1 and a second processing means 45-2 corresponding to two processing routes (RPID1, RPID2), and these first and second processing means 45-1, 45-2 are each configured to include a pre-registration data acquisition means 46 within the service unit, a data selection API calling means 47, and a registration API calling means 48.

[0137] In addition, the business container (APP container) 49Y is also provided with a first processing means 49-1 and a second processing means 49-2 corresponding to two processing routes (RPID1, RPID2), and these first and second processing means 49-1, 49-2 are both configured to include a data selection means 50 and a business data registration means 51.

[0138] These pre-registration data acquisition containers (DPP-based containers) 45Y and business containers (APP containers) 49Y have lower processing performance than the linked data acquisition containers (MQR-based containers) 41Y and linked data transmission containers (MQS-based containers) 52Y, so the processing routes are multiplexed (dualized in this embodiment) only for these containers 45Y and 49Y, thereby improving the overall processing speed.

[0139] Therefore, as processing of the first processing route (RPID1), the pre-registration data acquisition means 46 in the service unit of the first processing means 45-1 acquires the transaction data stored in the pre-registration database 65-1, then the data selection API calling means 47 of the first processing means 45-1 creates and sends a data selection API request using the transaction data received from the pre-registration data acquisition means 46 in the service unit, and the data selection means 50 of the first processing means 49-1 accepts this data selection API request and executes data selection processing, and if it determines that the transaction data is related to the business processing responsible for its own unit 40Y, it sends this to the registration API calling means 48 of the first processing means 45-1, and this registration API calling means 48 sends a registration API request (including the transaction data), and the business data registration means 51 of the first processing means 49-1 accepts this registration API request and stores the transaction data in the business database 61 and the post-registration database 66.

[0140] On the other hand, as processing of the second processing route (RPID2), the pre-registration data acquisition means 46 in the service unit of the second processing means 45-2 acquires the transaction data stored in the pre-registration database 65-2, and then, in the same flow as in the case of the first processing route (RPID1) described above, the transaction data passes through the data selection API calling means 47 of the second processing means 45-2, the data selection means 50 of the second processing means 49-2, and the registration API calling means 48 of the second processing means 45-2 in this order, and the business data registration means 51 of the second processing means 49-2 stores the transaction data in the business database 61 and the post-registration database 66.

[0141] In this case, since there is only one business database 61 and one post-registration database 66 and they are not multiplexed (dualized in this embodiment), the first processing route (RPID1) and the second processing route (RPID2) merge here. Even if the first and second processing routes (RPID1, RPID2) merge here, as shown in Figure 5, the order in which transaction data containing the same account number is stored in the business database 61 and the post-registration database 66 remains the same as the processing order in the processing route (RPID1) before distribution. That is, even if a difference in processing speed between the first processing route (RPID1) and the second processing route (RPID2) after distribution occurs due to, for example, uneven distribution, and the order in which transaction data is registered in the business database 61 and the post-registration database 66 does not maintain the processing order (retrieval order from the associated data storage means 72X) in the processing route (RPID1) before distribution, transaction data containing the same account number is processed in the same processing route, as shown in Figure 5, so the processing order is always maintained, and therefore no inconvenience occurs due to the reversal of the registration order of transaction data containing the same account number. For example, inconvenience does not occur, such as registration of transaction data for a correction to an order before registration of transaction data for that new order, or registration of correction transaction data after registration of transaction data for a cancellation.

[0142] After that, after merging and returning to one processing route (RPID1), the post-registration data acquisition means 53 in the service unit acquires the transaction data stored in the post-registration database 66 and passes the transaction data to the associated data transmission means 54, which then stores the transaction data in the associated data storage means 72Y in a variable-length data format (in this embodiment, JSON format) consisting of a combination of a key and a value.

[0143] <Specific example of the configuration of the securities back-office system 10: Figure 6>

[0144] Fig. 6 shows a specific example of the configuration of the securities core business back-office system 10. The configurations shown in Fig. 1 and Fig. 2 above are detailed descriptions of the contents common to the service units 20, 40 shown in Fig. 6. Due to space limitations, Fig. 6 omits the reference numerals for the reception means 22, reception database (reception DB) 31, data selection means 50, and business database (business DB) 61, but these are the same reference numerals as Figs. 1 and 2.

[0145] In addition, in this invention (claimed invention), the reason why the source and destination of the link are described as "service units" without specifying whether they are the reception service unit 20 or the business service unit 40 is because the data linkage method of the present invention is applicable to both data linkage from the reception service unit 20 to the business service unit 40 and data linkage from the business service unit 40 to the subsequent business service unit 40. The reason why the term "database" is used without specifying whether it is the reception database (reception DB) 31 or the business database (business DB) 61 is also the same.

[0146] (Explanation of Figure 6 / Configuration of reception layer)

[0147] In Figure 6, the securities core business back-office system 10 is provided with reception service units (reception SLUs) 20, including a balance update reception / simple deposit / withdrawal service unit (SLU) 20A, a balance update reception / transfer deposit / withdrawal service unit (SLU) 20B, a balance update reception / contract service unit (SLU) 20C, a balance update reception / simple deposit / withdrawal service unit (SLU) 20D, and a balance update reception / transfer deposit / withdrawal service unit (SLU) 20E.

[0148] The balance update reception / simple inventory / shipping service unit 20A includes a simple inventory / shipping API reception means (22A, although the symbol is omitted in the illustration) which is a reception means 22 that receives simple inventory / shipping data sent from the external system 100, and a reception database 31 (31A, although the symbol is omitted in the illustration) that stores the received simple inventory / shipping data.

[0149] The balance update reception / transfer / in / out service unit 20B is equipped with a transfer / in / out API reception means 22B (symbol omitted), which is a reception means 22 that receives transfer / in / out data sent from the external system 100, and a reception database 31 (31B, symbol omitted) that stores the received transfer / in / out data.

[0150] The balance update reception and contract service unit 20C is equipped with reception means 22 that receives domestic stock contract data, investment trust contract data, domestic bond contract data, foreign stock contract data (not shown), futures / OP (option) settlement data (not shown), foreign bond contract data (not shown), foreign exchange contract data (not shown), etc. sent from the external system 100, such as domestic stock contract API reception means, investment trust contract API reception means, domestic bond contract API reception means, foreign stock contract API reception means (not shown), futures / OP (option) contract API reception means (not shown), foreign bond contract API reception means (not shown), foreign exchange contract API reception means (not shown), etc. (each reception means can be assigned the symbol 22C), and a reception database 31 (31C, symbols not shown) that stores the received data.

[0151] The balance update reception / simple deposit / withdrawal service unit 20D is equipped with a simple deposit / withdrawal API reception means 22D (symbol omitted), which is a reception means 22 that receives simple deposit / withdrawal data sent from the external system 100, and a reception database 31 (31D, symbol omitted) that stores the received simple deposit / withdrawal data.

[0152] The balance update reception / transfer deposit / withdrawal service unit 20E includes a transfer deposit / withdrawal API reception means 22E (symbol omitted), which is a reception means 22 that receives transfer deposit / withdrawal data sent from the external system 100, and a reception database 31 (31E, symbol omitted) that stores the received transfer deposit / withdrawal data.

[0153] (Explanation of Figure 6: The first-level data integration container that connects the reception layer and the business layer)

[0154] The securities back-office system 10 also includes data linkage containers 70 (70A, 70B, 70C, 70D, 70E) having linked data storage means 72 that stores transaction data as linked data output from each reception service unit 20 (20A, 20B, 20C, 20D, 20E) in a variable-length data format (JSON format in this embodiment) consisting of a combination of key and value. In this embodiment, TOPIC is used for these containers 70.

[0155] (Explanation of Figure 6 / Configuration of the first business layer)

[0156] Downstream of each data integration container 70 (70A, 70B, 70C, 70D, 70E), business service units (business SLUs) 40 are provided, including a Financial Instruments and Exchange Act customer securities balance management service unit (SLU) 40A, a deemed securities balance management service unit (SLU) 40B, an individual settlement money management service unit (SLU) 40C, a transaction details management service unit (SLU) 40D, and a Financial Instruments and Exchange Act customer money balance management service unit (SLU) 40E.

[0157] The Financial Instruments and Exchange Act customer securities balance management service unit 40A is equipped with a data selection means 50 (50A, although the symbol is omitted in the illustration) that determines whether the linked data (transaction data) obtained from the data linkage container 70 upstream of its own unit 40A is transaction data related to the business processing that its own unit 40A is responsible for, and a securities details database (61A, although the symbol is omitted in the illustration) that is a business database 61 that stores the transaction data after the business processing that its own unit 40A is responsible for has been performed.

[0158] The deemed securities balance management service unit 40B is equipped with a data selection means 50 (50B, symbol omitted) that determines whether the linked data (transaction data) obtained from the data linkage container 70 upstream of its own unit 40B is transaction data related to the business processing that its own unit 40B is responsible for, and a deemed securities detail database (61B, symbol omitted) that is a business database 61 that stores the transaction data after the business processing that its own unit 40B is responsible for has been performed.

[0159] The individual payment money management service unit 40C is equipped with a data selection means 50 (50C, symbol omitted) that determines whether the linked data (transaction data) obtained from the data linkage container 70 upstream of its own unit 40C is transaction data related to the business processing that its own unit 40C is responsible for, and an individual payment money details database (61C, symbol omitted) that is a business database 61 that stores the transaction data after the business processing that its own unit 40C is responsible for has been performed.

[0160] Transaction details management service unit 40D is provided with a transaction details database (61D, reference numeral not shown), which is a business database 61 that stores transaction data after the business processing for which unit 40D is responsible has been performed. Note that this transaction details management service unit 40D does not have data selection means 50, and therefore all of the linked data (transaction data) acquired from data linkage container 70 upstream of unit 40D is transaction data related to the business processing for which unit 40D is responsible.

[0161] The Financial Instruments and Exchange Act customer money balance management service unit 40E is equipped with a data selection means 50 (50E, symbol omitted) that determines whether the linked data (transaction data) obtained from the data linkage container 70 upstream of its own unit 40E is transaction data related to the business processing that its own unit 40E is responsible for, and a money details database (61E, symbol omitted) that is a business database 61 that stores the transaction data after the business processing that its own unit 40E is responsible for has been performed.

[0162] (Explanation of Figure 6 / Relationship between the first-level data integration container and the first-level business layer)

[0163] As shown in Figure 6, when looking mainly at the data integration container 70 side, it is the business service units 40A, 40B, and 40D that monitor and acquire the integration data (transaction data stored in a variable-length data format consisting of a combination of keys and values ​​(in this embodiment, JSON format)) stored in the data integration container 70A.

[0164] Furthermore, it is the business service units 40A and 40D that monitor and acquire the linked data (transaction data) stored in the data association container 70B. Similarly, it is the business service units 40A, 40C, 40D, and 40E that monitor and acquire the linked data (transaction data) stored in the data association container 70C. It is the business service units 40C, 40D, and 40E that monitor and acquire the linked data (transaction data) stored in the data association container 70D. It is the business service units 40D and 40E that monitor and acquire the linked data (transaction data) stored in the data association container 70E.

[0165] Meanwhile, looking primarily at the business service unit 40 side, the Financial Instruments and Exchange Act customer securities balance management service unit 40A monitors and acquires the linked data (transaction data) stored in the linked data storage means 72 of the data linkage containers 70A, 70B, and 70C. Therefore, the linked data acquisition means 42 (see Figures 1 and 2) of this Financial Instruments and Exchange Act customer securities balance management service unit 40A stores information on which data linkage containers 70 its own unit 40A should monitor, and this information may be written within the program that constitutes the linked data acquisition means 42, or may be stored in an external storage means. The other business service units 40 are similar, and store information on which data linkage containers 70 its own unit 40 should monitor.

[0166] In addition, the deemed securities balance management service unit 40B monitors and acquires the linked data (transaction data) stored in the linked data storage means 72 of the data linkage container 70A. Similarly, the individual settlement money management service unit 40C monitors and acquires the linked data (transaction data) stored in the linked data storage means 72 of the data linkage containers 70C and 70D. The transaction details management service unit 40D monitors and acquires the linked data (transaction data) stored in the linked data storage means 72 of the data linkage containers 70A, 70B, 70C, 70D, and 70E. The Financial Instruments and Exchange Act customer money balance management service unit 40E monitors and acquires the linked data (transaction data) stored in the linked data storage means 72 of the data linkage containers 70C, 70D, and 70E.

[0167] In this way, in the data linkage method of the present invention, the relationship between the data linkage container 70 (here, the first-stage data linkage containers 70A, 70B, 70C, 70D, and 70E that link the reception layer and the business layer) and the subsequent linked business service unit 40 (here, the first-stage business service units 40A, 40B, 40C, 40D, and 40E in the business layer) is not a one-to-one relationship like the conventional securities core business back-end system 900 (see Figure 17) (although there may be some parts where the relationship is one-to-one), but rather allows for a many-to-many, one-to-many, or many-to-one relationship. As described above, the relationship between the "linked data storage means" and the "linked service unit" in this invention allows all relationships, such as many-to-many, one-to-many, many-to-one, and one-to-one, and the relationship between the "linked service unit" and the "linked data storage means" can, in principle, be one-to-one as shown in Figure 6 of this embodiment, and by making it one-to-one, loosely coupled data linkage can be realized. However, the relationship between the "linked service unit" and the "linked data storage means" can also be one-to-many, and in that case loosely coupled data linkage can still be realized.

[0168] (Explanation of Figure 6 / Second-level data integration container in the business layer)

[0169] Furthermore, the securities back-office system 10 is provided with data linkage containers 70 (70F, 70G) having linked data storage means 72 that stores transaction data as linked data output from each business service unit 40 (40A, 40E) in a variable-length data format (JSON format in this embodiment) consisting of a combination of key and value. In this embodiment, TOPIC is used for these containers 70.

[0170] (Explanation of Figure 6 / Configuration of the second business layer)

[0171] Downstream of each data integration container 70 (70F, 70G), business service units (business SLUs) 40 are provided, such as investment trust customer securities balance management service unit (SLU) 40F, domestic bond customer securities balance management service unit (SLU) 40G, advance payment management service unit (SLU) 40H, and margin / margin balance management service unit (SLU) 40J.

[0172] The investment trust customer securities balance management service unit 40F is equipped with a data selection means 50 (50F, although the symbol is omitted in the illustration) that determines whether the linked data (transaction data) obtained from the data linkage container 70 upstream of its own unit 40F is transaction data related to the business processing that its own unit 40F is responsible for, and an investment trust customer securities balance and securities details database (61F, although the symbol is omitted in the illustration) that is a business database 61 that stores the transaction data after the business processing that its own unit 40F is responsible for has been performed.

[0173] The domestic bond customer securities balance management service unit 40G is equipped with a data selection means 50 (50G, symbol omitted) that determines whether the linked data (transaction data) obtained from the data linkage container 70 upstream of its own unit 40G is transaction data related to the business processing that its own unit 40G is responsible for, and a domestic bond customer securities balance and securities details database (61G, symbol omitted) that is a business database 61 that stores transaction data after the business processing that its own unit 40G is responsible for has been performed.

[0174] The advance payment management service unit 40H is equipped with a data selection means 50 (50H, symbol omitted) that determines whether the linked data (transaction data) obtained from the data linkage container 70 upstream of its own unit 40H is transaction data related to the business processing that its own unit 40H is responsible for, and an advance payment balance database (61H, symbol omitted) that is a business database 61 that stores transaction data after the business processing that its own unit 40H is responsible for has been performed.

[0175] The margin / margin balance management service unit 40J is equipped with a data selection means 50 (50J, symbol omitted) that determines whether the linked data (transaction data) obtained from the data linkage container 70 upstream of its own unit 40J is transaction data related to the business processing that its own unit 40J is responsible for, and a margin / margin details database (61J, symbol omitted) that is a business database 61 that stores the transaction data after the business processing that its own unit 40J is responsible for has been performed.

[0176] (Explanation of Figure 6 / Relationship between the second-level data integration container and the second-level business layer)

[0177] The relationship between the data linkage container 70 (here, the second-level data linkage containers 70F, 70G provided in the business layer) and its subsequent linked business service unit 40 (here, the second-level business service units 40F, 40G, 40H, 40J in the business layer) is as follows, which is a one-to-many relationship rather than a one-to-one relationship like the conventional securities core business back-end system 900 (see Figure 17). Note that here too, many-to-many and many-to-one relationships are permitted, and some one-to-one relationships may also be included.

[0178] In other words, when looking primarily at the data association container 70, it is the business service units 40F and 40G that monitor and acquire the associated data (transaction data stored in a variable-length data format consisting of a combination of keys and values ​​(in this embodiment, JSON format)) stored in the associated data storage means 72 of the data association container 70F. Also, it is the business service units 40H and 40J that monitor and acquire the associated data (transaction data) stored in the associated data storage means 72 of the data association container 70G.

[0179] On the other hand, looking mainly at the business service unit 40 side, the investment trust customer securities balance management service unit 40F and the domestic bond customer securities balance management service unit 40G monitor and acquire the linked data (transaction data) stored in the linked data storage means 72 of the data linkage container 70F. Also, the advance payment management service unit 40H and the security deposit / margin balance management service unit 40J monitor and acquire the linked data (transaction data) stored in the linked data storage means 72 of the data linkage container 70G.

[0180] <Examples of data integration: Figures 7, 8, and 9>

[0181] In order to explain the data linkage method using transaction attribute information, Fig. 7 shows an extracted portion of a specific example configuration of the securities core business back-office system 10 shown in Fig. 6. Due to space limitations, Fig. 7 omits the detailed configuration of each service unit 20, 40, but since these detailed configurations are the same as those shown in Fig. 1 and Fig. 2, the same names and symbols as in Fig. 1 and Fig. 2 will be used where appropriate.

[0182] (Explanation of the first half of Figure 7 / Balance update reception and contract service unit 20C)

[0183] As shown in Figure 7, the balance update reception and contract service unit (SLU) 20C receives domestic stock contract data (transaction data) from the external system 100 via the domestic stock contract API reception means 22C. This domestic stock contract data includes a transaction code, which may be either a (regular transaction) or b (margin spot settlement transaction). Note that b (margin spot settlement transaction) is a settlement that fills (closes out) a margin transaction with spot delivery, and for example, when filling a short position in a margin transaction, the settlement is to use the held spot stocks for repayment, rather than purchasing the same securities to fill the short position.

[0184] The reception data registration means 23 (see Figure 2) of the balance update reception / settlement service unit 20C stores domestic stock settlement data (transaction data) in the reception database 31C, and uses information in the transaction attribute database 32 (see Figures 2 and 8) to determine the transaction attribute information to be added to the transaction data, and stores the transaction data with the transaction attribute information added in the post-registration database 33 (see Figure 2).

[0185] 7, if the transaction code included in the transaction data received from the external system 100 is a (regular transaction), the accepted data registration means 23 includes a money update flag = "1" and a securities update flag = "1" in the transaction data as transaction attribute information and stores the transaction data in the post-registration database 33. On the other hand, if the transaction code included in the transaction data received from the external system 100 is b (margin spot settlement transaction), the transaction is a spot delivery settlement, so the accepted data registration means 23 includes a money update flag = "0" and a securities update flag = "1" in the transaction data as transaction attribute information and stores the transaction data in the post-registration database 33.

[0186] Then, the transaction data (including a money update flag and a securities update flag as transaction attribute information) stored in the post-registration database 33 (see Figure 2) is stored in the linked data storage means 72 of the data linkage container 70C via the post-registration data acquisition means 26 and linked data transmission means 27 (see Figure 2) within the service unit.

[0187] (Explanation of Figure 8)

[0188] 8, the domestic stock contract data (transaction data set in the body of a request for the domestic stock contract API, which is a public API) sent from the external system 100 (consumer) includes, for example, contract number = Y000001, account number = K000003, transaction code = a, delivery date = YY / MM / DD, stock code = Company α stock, trading category = buy, delivery amount = XXXX yen, contract quantity = XXXX shares, contract price = XXXX yen, contract amount = XXXX yen, etc. By including the transaction code in the request using the public API in this way, it becomes possible to use this transaction code to determine the transaction attribute information (money update flag, securities update flag) to be added to the transaction data.

[0189] As shown in FIG. 8, the transaction data (the transaction data stored in the records constituting the table of the reception database 31C) registered in the reception database 31C provided in the balance update reception and contract service unit (SLU) 20C, which is the reception service unit 20, includes the above-mentioned contract number, account number, transaction code (=a), delivery date, stock code, trading category, delivery amount, contract quantity, contract unit price, contract amount, etc., as well as the record registration trace ID code (the trace ID issued by the balance update reception and contract service unit 20C at the time of new registration), record registration transaction number, record update function ID code (own TX linking ID at the time of new registration of balance update reception / contract service unit 20C), record registration function ID code (own function ID at the time of new registration of balance update reception / contract service unit 20C), record update trace ID code (trace ID at the time of update issued by balance update reception / contract service unit 20C), record update transaction ID code (own TX linking ID at the time of update of balance update reception / contract service unit 20C), record update function ID code (own function ID at the time of update of balance update reception / contract service unit 20C).

[0190] Here, the six codes, namely, record registration trace ID code, record registration transaction ID code, record registration function ID code, record update trace ID code, record update transaction ID code, and record update function ID code, are information added by the reception data registration means 23 (see FIG. 2) of the balance update reception and contract service unit 20C when storing domestic stock contract data (transaction data) in the reception database 31C. These six codes are also added in the same way when storing transaction data in other reception databases 31 and business database 61.

[0191] When new transaction data is registered, the same information is stored in the three codes related to record registration (record registration trace ID code, record registration transaction ID code, record registration function ID code) and the three codes related to record update (record update trace ID code, record update transaction ID code, record update function ID code) out of the six codes above.

[0192] On the other hand, when updating transaction data, of the six codes above, the three codes related to record registration remain unchanged (the codes already in the record are maintained as they are), and only the three codes related to record updating are changed.

[0193] Furthermore, as shown in Figure 8, the transaction data (JSON format) as linked data stored in the linked data storage means 72 of the data linkage container 70C (TOPIC) includes, in addition to the above-mentioned contract number, account number, transaction code (= a), delivery date, stock code, buy / sell classification, delivery amount, contract quantity, contract unit price, contract amount, etc., trace information such as a trace ID (ID issued by the balance update reception / contract service unit 20C), own TX linking ID (ID indicating the balance update reception / contract service unit 20C), requester TX linking ID (however, since the requester is the external system 100, this ID does not exist; enter 0), own function ID (ID indicating the function of the balance update reception / contract service unit 20C), requester function ID (however, since the requester is the external system 100, this ID does not exist; enter 0), and transaction attribute information such as a money update flag (= 1) and a securities update flag (= 1).

[0194] At this time, since the transaction code is a (regular transaction), the accepted data registration means 23 (see FIG. 2) obtains the money update flag = 1 and the securities update flag = 1 corresponding to the transaction code = a (regular transaction) from the transaction attribute database 32 provided in the balance update acceptance / contract service unit 20C, and adds them to the transaction data. Details of the trace information will be described later using FIGS. 10 to 16.

[0195] (Explanation of the second half of Figure 7 / Financial Instruments and Exchange Act Customer Securities Balance Management Service Unit 40A)

[0196] In the Financial Instruments and Exchange Act customer securities balance management service unit (SLU) 40A, the linked data acquisition means 42 (see FIG. 2) acquires transaction data (JSON format) as linked data stored in the linked data storage means 72 of the data linkage container 70C (TOPIC), and the data selection means 50A executes data selection processing. At this time, the data selection means 50A determines that, among the acquired transaction data, transaction data whose securities update flag is "1" is to be processed by its own unit 40A.

[0197] Then, the transaction data after the transaction processing is stored by the transaction data registration means 51 (see FIG. 2) in the securities statement database 61A, which is the transaction database 61. At this time, the transaction code remains included in the transaction data.

[0198] The business data registration means 51 also stores the transaction data after business processing in the post-registration database 66. At this time, the transaction data retains the cash update flag and securities update flag that were included in the transaction data acquired from the associated data storage means 72 of the data association container 70C. The cash update flag and securities update flag may be temporarily canceled by the business data registration means 51 and then newly added as a process unique to the Financial Instruments and Exchange Act customer securities balance management service unit 40A. The transaction code also remains included in the transaction data. The transaction data stored in the post-registration database 66 is then stored in the associated data storage means 72 of the data association container 70F via the post-registration data acquisition means 53 and associated data transmission means 54 (see FIG. 2) within the service unit.

[0199] (Explanation of the latter half of Figure 7 / Balance update reception and simple deposit / withdrawal service unit 20D)

[0200] The balance update reception / simple deposit / withdrawal service unit (SLU) 20D receives simple deposit / withdrawal data (transaction data) from the external system 100 via the simple deposit / withdrawal API reception means 22D, and this simple deposit / withdrawal data includes transaction code = c (simple deposit / withdrawal).

[0201] The reception data registration means 23 (see Figure 2) of the balance update reception / simple deposit / withdrawal service unit 20D stores simple deposit / withdrawal data (transaction data) in the reception database 31D, and uses information in the transaction attribute database 32 (see Figure 2) to determine and decide the transaction attribute information to be added to the transaction data, and stores the transaction data with the transaction attribute information added in the post-registration database 33 (see Figure 2).

[0202] At this time, since the transaction code included in the transaction data received from the external system 100 is c (simple deposit / withdrawal), as shown in FIG. 7, the reception data registration means 23 (see FIG. 2) includes the money update flag = "1" in the transaction data as transaction attribute information and stores it in the database 33 after registration.

[0203] Then, the transaction data (including a money update flag of 1 as transaction attribute information) stored in the post-registration database 33 (see FIG. 2) is stored in the linked data storage means 72 of the data linkage container 70D via the post-registration data acquisition means 26 in the service unit and the linked data transmission means 27 (see FIG. 2). As a result, the linked data storage means 72 of the data linkage container 70D stores transaction data including a transaction code of c (simple deposit / withdrawal) and a money update flag of 1.

[0204] (Explanation of the latter half of Figure 7 / Balance update reception and transfer deposit / withdrawal service unit 20E)

[0205] The balance update reception / transfer deposit / withdrawal service unit (SLU) 20E receives transfer deposit / withdrawal data (transaction data) from the external system 100 via the transfer deposit / withdrawal API reception means 22E, and this transfer deposit / withdrawal data includes transaction code = d (margin transfer).

[0206] The reception data registration means 23 (see Figure 2) of the balance update reception / transfer deposit / withdrawal service unit 20E stores transfer deposit / withdrawal data (transaction data) in the reception database 31E, and uses information in the transaction attribute database 32 (see Figure 2) to determine and decide the transaction attribute information to be added to the transaction data, and stores the transaction data with the transaction attribute information added in the post-registration database 33 (see Figure 2).

[0207] At this time, since the transaction code included in the transaction data received from the external system 100 is d (deposit transfer), as shown in FIG. 7, the reception data registration means 23 (see FIG. 2) includes the money update flag = "1" in the transaction data as transaction attribute information and stores it in the post-registration database 33.

[0208] Then, the transaction data (including a money update flag of 1 as transaction attribute information) stored in the post-registration database 33 (see FIG. 2) is stored in the linked data storage means 72 of the data linkage container 70E via the post-registration data acquisition means 26 in the service unit and the linked data transmission means 27 (see FIG. 2). As a result, the linked data storage means 72 of the data linkage container 70E stores transaction data including a transaction code of d (deposit transfer) and a money update flag of 1.

[0209] (Explanation of the second half of Figure 7 / Financial Instruments and Exchange Act Customer Balance Management Service Unit 40E)

[0210] In the Financial Instruments and Exchange Act customer balance management service unit (SLU) 40E, the linked data acquisition means 42 (see FIG. 2) acquires transaction data (JSON format) as linked data stored in each linked data storage means 72 of the data linkage containers 70C, 70D, and 70E (each TOPIC), and the data selection means 50E executes data selection processing. At this time, the data selection means 50E determines that, among the acquired transaction data, transaction data whose money update flag is "1" is to be processed by its own unit 40E.

[0211] Then, the business data registration means 51 (see FIG. 2) stores the transaction data after business processing in the financial details database 61E, which is the business database 61. At this time, the transaction code remains included in the transaction data. Therefore, the transaction code included in the transaction data stored in the financial details database 61E is one of a (regular transaction), c (simple deposit / withdrawal), and d (margin transfer). Note that if the transaction code is b (margin spot settlement transaction), the balance update reception / contract service unit 20C adds a financial update flag of "0" to the transaction data as transaction attribute information, and transaction data including the financial update flag of "0" is stored in the linked data storage means 72 of the data linkage container 70C. Therefore, the data selection process by the data selection means 50E of the Financial Instruments and Exchange Act customer financial balance management service unit 40E determines that the transaction data is not subject to business processing by its own unit 40E, and the transaction data is not stored in the financial details database 61E.

[0212] The business data registration means 51 stores the transaction data after business processing in the post-registration database 66. At this time, the transaction data retains the money update flag and securities update flag contained in the transaction data acquired from the associated data storage means 72 of each of the data association containers 70C, 70D, and 70E. The money update flag and securities update flag may be temporarily canceled by the business data registration means 51 and newly added as a process unique to the Financial Instruments and Exchange Act customer money balance management service unit 40E. The transaction code also remains included in the transaction data. Furthermore, if the transaction data received from the external system 100 includes a margin / margin type classification of "01 (credit)," the margin / margin type classification of "01 (credit)" will also be included in the transaction data stored in the post-registration database 66. The transaction data stored in the post-registration database 66 is then stored in the linked data storage means 72 of the data linking container 70G via the post-registration data acquisition means 53 and linked data transmission means 54 (see FIG. 2) in the service unit.

[0213] As a result, the transaction data stored in the linked data storage means 72 of the data linkage container 70G includes one of the transaction codes a (regular transaction), c (simple deposit / withdrawal), or d (margin transfer). As shown in FIG. 9, some transaction data includes transaction data = d (margin transfer) and margin / margin type classification = "01 (credit)." The margin / margin type classification is information specified by the external system 100 and corresponds to the "transaction attribute classification" of the present invention. As shown in FIG. 9, examples include 01 (credit), 02 (settlement when issued), 03 (futures / options), 04 (over-the-counter FX), and 05 (market FX). If these 01 (credit), 02 (settlement when issued), etc. were individually divided and flagged, they would correspond to the "transaction attribute flag" of the present invention.

[0214] (Explanation of the second half of Figure 7 / Expense Management Service Unit 40H)

[0215] In the reimbursement management service unit (SLU) 40H, the linked data acquisition means 42 (see FIG. 2) acquires transaction data (JSON format) as linked data stored in the linked data storage means 72 of the data linkage container 70G (TOPIC), and the data selection means 50H executes data selection processing. At this time, the data selection means 50H determines that, among the acquired transaction data, all transaction data for which the money update flag is set to "1", i.e., all transaction data related to money registration, are to be processed by its own unit 40H.

[0216] Then, the business data registration means 51 (see FIG. 2) stores the transaction data after business processing in the reimbursement balance database 61H, which is the business database 61. At this time, the transaction code remains included in the transaction data. Therefore, the transaction code included in the transaction data stored in the reimbursement balance database 61H is one of a (ordinary transaction), c (simple deposit / withdrawal), and d (margin transfer). Note that, as mentioned above, transaction data with the transaction code b (margin spot settlement transaction) is no longer available for processing in the cooperating Financial Instruments and Exchange Act customer money balance management service unit 40E.

[0217] In addition, since the advance payment management service unit 40H does not have a subsequent business service unit 40, nor is it provided with a subsequent data integration container 70, output processing to the database 66 after registration by the business data registration means 51 is not performed.

[0218] (Explanation of the second half of Figure 7 / Margin and margin balance management service unit 40J)

[0219] In the margin / margin balance management service unit (SLU) 40J, the associated data acquisition means 42 (see FIG. 2) acquires transaction data (JSON format) as associated data stored in the associated data storage means 72 of the data association container 70G (TOPIC), and executes data selection processing using the data selection means 50J. At this time, the data selection means 50J determines that, among the acquired transaction data, data containing information on margin / margin type classification is subject to business processing by its own unit 40J.

[0220] Then, the business data registration means 51 (see FIG. 2) stores the transaction data after business processing in the margin and margin details database 61J, which is the business database 61. At this time, the transaction code remains included in the transaction data. Therefore, the transaction code included in the transaction data stored in the margin and margin details database 61J is d (margin transfer). The reason the margin and margin type classification is included in the transaction data is because the transaction code is d (margin transfer).

[0221] In addition, since the margin / margin balance management service unit 40J does not have a subsequent business service unit 40, nor is it provided with a subsequent data integration container 70, output processing to the database 66 is not performed after registration by the business data registration means 51.

[0222] <Tracing the series of processes executed during data integration: Figures 10 to 16>

[0223] (Explanation of Figure 10)

[0224] Fig. 10 shows a recording format of trace information for tracing the content of a series of processes executed in data linkage between the service units 20 and 40. In Fig. 10, the business service units 40 are denoted by symbols 40U and 40V, but these symbols do not refer to specific units among the specific business service units 40 (40A, 40B, 40C, ...) shown in Fig. 6 above, but are used with the intention that any of the business service units 40 may be used.

[0225] The trace information includes a trace ID, a self function ID, a request source function ID, a self TX linking ID, and a request source TX linking ID.

[0226] The trace ID is an ID that is commonly passed among a series of processes executed in cooperation between a plurality of service units 20 and 40.

[0227] The own function ID is an ID for identifying the function of each transaction process executed by each of the service units 20 and 40.

[0228] The requester function ID is an ID that identifies the transaction processing function of the requester that has made the transition to the transaction processing associated with the above-mentioned own function ID.

[0229] The self-TX linked ID is an ID that is assigned when a transaction process related to the self-function ID is executed. Since the self-function ID identifies the content of the process, the self-function ID remains the same no matter how many times the process with that content is executed. In contrast, since the self-TX linked ID identifies the transaction process, the self-TX linked ID will be different even for processes with the same content if they are executed at different times. For example, if the same process is executed multiple times in a day, the self-function ID will remain the same, but the self-TX linked ID will be different each time.

[0230] The request source TX linking ID is an ID assigned when a transaction process related to the above request source function ID is executed. Since the request source function ID identifies the content of the process, the request source function ID remains the same no matter how many times the process with that content is executed. In contrast, since the request source TX linking ID identifies the transaction process, the request source TX linking ID will be different even for processes with the same content if they are executed at different times. For example, if the same process is executed multiple times in a day, the request source function ID will remain the same, but the request source TX linking ID will be different each time.

[0231] (Explanation of FIG. 10 / Reception service unit 20)

[0232] The reception service unit 20 is provided with a log data storage means 80 (not shown) that stores log data of (1) input message information when transaction data transmitted from the external system 100 (consumer) is received by the reception means 22. This log data of (1) input message information is saved as an input message information log file.

[0233] The reception service unit 20 is also provided with a log data storage means 80 (not shown) that stores (2) insert information when the reception data registration means 23 stores the received transaction data in the reception database 31. The log data of this (2) insert information is saved as an insert information log file.

[0234] Furthermore, the reception service unit 20 is provided with a log data storage means 80 (not shown) for storing log data of (3) subsequent linkage information when the received transaction data is output to the post-registration database 33 (see FIG. 2) by the reception data registration means 23 to be stored as linked data in the linked data storage means 72M. This log data of (3) subsequent linkage information is saved as a subsequent linkage information log file.

[0235] The log data of the input and output of each part in the reception service unit 20 ((1) input message information, (2) insert information, (3) subsequent linkage information) includes trace information such as trace ID, own TX linkage ID (reception service unit 20), requester TX linkage ID (none), own function ID (reception service unit 20), and requester function ID (none). There is no service unit that can be a linkage source upstream of the reception service unit 20, so there is no request source. Note that the external system 100 cannot be a request source.

[0236] (Explanation of Figure 10 / Business Service Unit 40U)

[0237] The business service unit 40U is provided with log data storage means 80 (not shown) that stores log data of (1A) input message information when the data selection means 50U receives a data selection API request from the data selection API calling means 47 (see FIG. 2), and also with log data storage means 80 (not shown) that stores log data of (1B) input message information when the business data registration means 51U receives a registration API request from the registration API calling means 48U. These two log data of (1A) and (1B) input message information are saved as input message information log files.

[0238] The business service unit 40U is also provided with a log data storage means 80 (not shown) for storing (2) insert information when the business data registration means 51U stores transaction data after business processing in the business database 61U. The log data of this (2) insert information is saved as an insert information log file.

[0239] Furthermore, the business service unit 40U is provided with a log data storage means 80 (not shown) for storing log data of (3) subsequent linked information when the business data registration means 51U outputs the transaction data after business processing to the post-registration database 66 (see FIG. 2) for storage as linked data in the linked data storage means 72N. This log data of (3) subsequent linked information is saved as a subsequent linked information log file.

[0240] Of the log data of the input and output of each part of the business service unit 40U (two points of (1A) and (1B) input message information, (2) insert information, and (3) subsequent linkage information), the log data of the (1A) input message information at the time of receiving a data selection API request by the data selection means 50U includes trace information such as a trace ID, its own TX linking ID (business service unit 40U), the requesting TX linking ID (reception service unit 20), its own function ID (business service unit 40U), and the requesting function ID (reception service unit 20).

[0241] Meanwhile, the log data of (1B) input message information, as well as the log data of (2) insert information and (3) subsequent linkage information when the business data registration means 51U receives a registration API request, includes a trace ID, a self-TX linking ID (business service unit 40U), a request source TX linking ID (business service unit 40U), a self-function ID (business service unit 40U), and a request source function ID (business service unit 40U). Therefore, since all trace information is information related to the business service unit 40U, processing has shifted from the self unit to the self unit within the business service unit 40U. This is because the self function, the request source function, and their transaction processing are recorded on an API basis, not on a service unit basis.

[0242] (Explanation of Figure 10 / Business Service Unit 40V)

[0243] The business service unit 40V is provided with log data storage means 80 (not shown) that stores log data of (1A) input message information when the data selection means 50V receives a data selection API request from the data selection API calling means 47 (see FIG. 2), and also with log data storage means 80 (not shown) that stores log data of (1B) input message information when the business data registration means 51V receives a registration API request from the registration API calling means 48V. The log data of these two (1A) and (1B) input message information is saved as an input message information log file.

[0244] The business service unit 40V is also provided with a log data storage means 80 (not shown) for storing (2) insert information when the business data registration means 51V stores transaction data after business processing in the business database 61V. The log data of this (2) insert information is saved as an insert information log file.

[0245] In addition, since the business service unit 40V does not have a subsequent business service unit 40 and does not have a subsequent linked data storage means 72, (3) a log data storage means 80 for storing log data of subsequent linked information is not provided.

[0246] Of the log data of the input and output of each part of the business service unit 40V (two points of (1A) and (1B) input message information, and (2) insert information), the log data of the (1A) input message information when the data selection means 50V receives a data selection API request includes trace information such as a trace ID, its own TX linking ID (business service unit 40V), the requester's TX linking ID (business service unit 40U), its own function ID (business service unit 40V), and the requester's function ID (business service unit 40U). Therefore, for itself, the information is about the business service unit 40V, and for the requester, the information is about the business service unit 40U.

[0247] On the other hand, the log data of (1B) input message information and (2) insert information when the business data registration means 51V receives a registration API request include the trace ID, the self TX linking ID (business service unit 40V), the request source TX linking ID (business service unit 40V), the self function ID (business service unit 40V), and the request source function ID (business service unit 40V). Therefore, since all trace information is information related to the business service unit 40V, processing has shifted from the self unit to the self unit within the business service unit 40V. This is because the self function, the request source function, and their transaction processing are recorded on an API basis, not on a service unit basis.

[0248] (Explanation of Figures 11 to 16)

[0249] Figure 11 shows a specific example of the recording format of trace information shown in Figure 10 above, and shows the recording format of trace information in the balance update reception and settlement service unit 20C, which is the reception service unit 20, as well as the recording format of trace information in the Financial Instruments and Exchange Act customer securities balance management service unit 40A, transaction detail management service unit 40D, reference function customer securities service unit 40K, and domestic bond customer securities balance management service unit 40G, which are business service units 40.

[0250] In addition, Figure 12 shows an example of a screen display of trace information in the balance update reception and settlement service unit 20C, Figure 13 shows an example of a screen display of trace information in the Financial Instruments and Exchange Act customer securities balance management service unit 40A, Figure 14 shows an example of a screen display of trace information in the transaction details management service unit 40D, Figure 15 shows an example of a screen display of trace information in the reference function customer securities service unit 40K, and Figure 16 shows an example of a screen display of trace information in the domestic bond customer securities balance management service unit 40G.

[0251] 11 to 16, the log data of input message information including trace information, insert information, and subsequent linkage information, and the log files storing these log data, are not particularly distinguished from one another and are denoted by the same reference numerals (1-1), (1-2), (1-3), etc. Each log data (input message information, insert information, subsequent linkage information) is stored in each log file and saved in the form of a file in log data storage means 80 (not shown) of each part realized by nonvolatile memory, and further collected by log data collection means 82 and stored in collected log database 84 (see FIGS. 1 and 2).

[0252] (Explanation of Figures 11 and 12 / Balance Update Reception and Agreement Service Unit 20C)

[0253] 11, the balance update reception / contract service unit 20C stores (records in a log file) in a log data storage means 80 (not shown) the following log data: (1-1) input message information log data when the domestic stock contract API reception means 22C receives transaction data (domestic stock contract data) transmitted from the external system 100 (consumer); (1-2) insert information log data when the received data registration means 23C stores the transaction data in the reception database 31C; and (1-3) subsequent linkage information log data when the received data registration means 23C outputs the transaction data to the post-registration database 33C for storage in the linkage data storage means 72C. These log data are collected by a log data collection means 82 and accumulated and stored in a collection log database 84 (see FIGS. 1 and 2).

[0254] As shown in Fig. 12, the trace information display means 86 accepts a search for log data stored in the collected log database 84 (see Figs. 1 and 2), and displays the trace information contained in the searched log data on the screen of a user terminal (not shown) operated by an employee of the securities company, etc. The search conditions include, for example, date and time, and keys and messages related to the balance update reception and contract service unit 20C. The identification information of the balance update reception and contract service unit 20C is UK201.

[0255] In Figure 12 (1-1), the input message information to the balance update reception and contract service unit 20C, i.e., the information recorded in the input message information log file (1-1), is displayed on screen 8611. The (1-1) input message information displayed on screen 8611 includes a trace ID of UK2015011XXXXXXXXXXXXXXXX. This trace ID is assigned by the balance update reception and contract service unit 20C (UK201), and therefore begins with an ID indicating the function of that unit 20C, "UK2015011," followed by an automatically assigned complex character and symbol string, XXXX.... Note that the number of digits in XXXX... in Figure 12 is shown to convey the image of a long and complex character and symbol string and is not the actual number of digits. The same applies to YYYY..., ZZZZ..., etc. below.

[0256] Also, the (1-1) input message information displayed on screen 8611 includes own function ID = UK2015011 (balance update registration acceptance / contract) and requestor function ID = 0 (none as it is external system 100). Furthermore, own TX linking ID = YYYYYYYYYYYYYYYYYYY and requestor TX linking ID = 0 (none as it is external system 100) are included.

[0257] In (1-2) of Figure 12, the insert information to the balance update reception and contract service unit 20C, i.e., the information recorded in the insert information log file (1-2), is displayed on a screen 8612. The (1-2) insert information displayed on this screen 8612 includes a trace ID = UK2015011XXXXXXXXXXXXXXXX. This trace ID is the same as that displayed on the screen 8611 of (1-1) of Figure 12 described above.

[0258] Also, the (1-2) insert information displayed on screen 8612 includes own function ID = UK2015011 (balance update registration acceptance / contract) and requesting function ID = 0 (none as it is external system 100). Furthermore, own TX linking ID = YYYYYYYYYYYYYYYYYYY and requesting TX linking ID = 0 (none as it is external system 100) are included.

[0259] The (1-2) insert information displayed on screen 8612 includes the contents of the transaction data stored in the reception database 31 (the contents also shown in Figure 8 mentioned above) in parentheses following "VALUES", and the data following "VALUES" includes record registration trace ID code = UK2015011XXXXXXXXXXXXXXXX, record registration transaction ID code = YYYYYYYYYYYYYYYYYYY, record registration function ID code = UK2015011, record update trace ID code = UK2015011XXXXXXXXXXXXXXXX, record update transaction ID code = YYYYYYYYYYYYYYYYYYYY, and record update function ID code = UK2015011.

[0260] Here, since this is a case of newly registered transaction data, the same data is stored in the record registration trace ID code and the record update trace ID code, both of which are the same data as the trace ID.

[0261] Also, since this is newly registered transaction data, the same data is stored in the record registration transaction ID code and record update transaction ID code, both of which are the same data as the own TX linking ID.

[0262] Furthermore, since this is a case of newly registered transaction data, the same data is stored in the record registration function ID code and record update function ID code, both of which are the same data as the own function ID.

[0263] In (1-3) of Figure 12, the subsequent linkage information of the balance update reception and contract service unit 20C, i.e., the information recorded in the subsequent linkage information log file (1-3), is displayed on a screen 8613. The (1-3) subsequent linkage information displayed on this screen 8613 includes a trace ID = UK2015011XXXXXXXXXXXXXXXX. This trace ID is the same as that displayed on the screen 8611 of (1-1) and the screen 8612 of (1-2) of Figure 12 described above.

[0264] Also, the subsequent linkage information (1-3) displayed on screen 8613 includes own function ID = UK2015011 (balance update registration acceptance / contract) and requestor function ID = 0 (none as it is external system 100). Furthermore, own TX linking ID = YYYYYYYYYYYYYYYYYYY and requestor TX linking ID = 0 (none as it is external system 100). These own function ID, requestor function ID, own TX linking ID, and requestor TX linking ID are the same as the respective IDs displayed on screen 8612 above.

[0265] (Explanation of Figures 11 and 13 / Financial Instruments and Exchange Act Customer Securities Balance Management Service Unit 40A)

[0266] As shown in Fig. 11, the Financial Instruments and Exchange Act customer securities balance management service unit 40A stores (records in a log file) the following log data in log data storage means 80 (not shown): (2-1A) input message information log data when the data selection means 50A receives a data selection API request transmitted from the data selection API calling means 47 (see Fig. 2); (2-1B) input message information log data when the business data registration means 51A receives a registration API request transmitted from the registration API calling means 48A; (2-2) insert information log data when the business data registration means 51A stores transaction data in the securities statement database 61A, which is a business database; and (2-3) subsequent linkage information log data when the business data registration means 51A outputs the transaction data to the post-registration database 66A for storage in the linkage data storage means 72F. These log data are collected by log data collection means 82 and accumulated and stored in a collection log database 84 (see Figs. 1 and 2).

[0267] As shown in Fig. 13, the trace information display means 86 accepts a search for log data stored in the collected log database 84 (see Figs. 1 and 2), and displays the trace information contained in the searched log data on the screen of a user terminal (not shown) operated by an employee of the securities company, etc. The identification information of the Financial Instruments and Exchange Act customer securities balance management service unit 40A is ZS102, and the identification information of its linked balance update reception and contract service unit 20C is UK201.

[0268] In Figure 13 (2-1), the input message information to the Financial Instruments and Exchange Act customer securities balance management service unit 40A, i.e., the information recorded in the input message information log files (2-1A) and (2-1B), is displayed on screens 8621A and 8621B.

[0269] The input message information (2-1A) displayed on the screen 8621A includes a trace ID = UK2015011XXXXXXXXXXXXXXXX. This trace ID is assigned by the cooperating balance update reception and contract service unit 20C (UK201).

[0270] Furthermore, the input message information (2-1A) displayed on screen 8621A includes the self function ID = ZS1025071 (FIEA customer securities balance data selection / contract) and the requester function ID = UK2015011 (balance update registration acceptance / contract). It also includes the self TX linking ID = PPPPPPPPPPPPPPPPPPPPPP and the requester TX linking ID = QQQQQQQQQQQQQQQQQQQQ. Therefore, for the self function, the information is about the FIEA customer securities balance management service unit 40A (ZS102), and for the requester, the information is about the linked balance update acceptance / contract service unit 20C (UK201).

[0271] On the other hand, the (2-1B) input message information displayed on screen 8621B also contains the same trace ID = UK2015011XXXXXXXXXXXXXXXX as in the (2-1A) input message information above. This trace ID is an ID assigned by the cooperating balance update reception and contract service unit 20C (UK201).

[0272] Furthermore, the input message information (2-1B) displayed on screen 8621B includes the self-function ID = ZS1025051 (FIEA customer securities balance registration) and the requester function ID = ZS1025071 (FIEA customer securities balance data selection and contract). Furthermore, the self-TX linking ID = RRRRRRRRRRRRRRRRRRRRRR and the requester TX linking ID = PPPPPPPPPPPPPPPPPPPPPP. Therefore, within the FIEA customer securities balance management service unit 40A (ZS102), processing has shifted from one self-unit to another, but this is because the information is traced on an API-by-API basis. Therefore, the requester function ID on screen 8621B is the same as the self-function ID on screen 8621A, both of which are ZS1025071 (FIEA customer securities balance data selection and contract). Furthermore, the request source TX linked ID on screen 8621B is the same as the own TX linked ID on screen 8621A, and both are PPPPPPPPPPPPPPPPPPPPPP.

[0273] In (2-2) of Figure 13, the insert information to the Financial Instruments and Exchange Act customer securities balance management service unit 40A, i.e., the information recorded in the insert information log file (2-2), is displayed on screen 8622. The (2-2) insert information displayed on this screen 8622 includes a trace ID = UK2015011XXXXXXXXXXXXXXXX. This trace ID is the same as that displayed on screen 8621A of (2-1A) of Figure 13 described above.

[0274] Additionally, the (2-2) insert information displayed on screen 8622 includes own function ID = ZS1025051 (FIEA customer securities balance registration) and requestor function ID = ZS1025071 (FIEA customer securities balance data selection and contract). It also includes own TX linking ID = RRRRRRRRRRRRRRRRRRRRRR and requestor TX linking ID = PPPPPPPPPPPPPPPPPPPPPP. These own function ID, requestor function ID, own TX linking ID, and requestor TX linking ID are the same as the IDs displayed on screen 8621B above.

[0275] The (2-2) insert information displayed on screen 8622 contains the contents of the transaction data stored in the securities detail database 61A, which is the business database, in parentheses following "VALUES," and the data following "VALUES" includes record registration trace ID code = UK2015011XXXXXXXXXXXXXXXX, record registration transaction ID code = RRRRRRRRRRRRRRRRRRRRRR, record registration function ID code = ZS1025051, record update trace ID code = UK2015011XXXXXXXXXXXXXXXX, record update transaction ID code = RRRRRRRRRRRRRRRRRRRRRR, and record update function ID code = ZS1025051.

[0276] Here, since this is a case of newly registered transaction data, the same data is stored in the record registration trace ID code and the record update trace ID code, both of which are the same data as the trace ID.

[0277] Also, since this is newly registered transaction data, the same data is stored in the record registration transaction ID code and record update transaction ID code, both of which are the same data as the own TX linking ID.

[0278] Furthermore, since this is a case of newly registered transaction data, the same data is stored in the record registration function ID code and record update function ID code, both of which are the same data as the own function ID.

[0279] In (2-3) of Figure 13, the subsequent linkage information of the Financial Instruments and Exchange Act customer securities balance management service unit 40A, i.e., the information recorded in the subsequent linkage information log file (2-3), is displayed on screen 8623. The (2-3) subsequent linkage information displayed on this screen 8623 includes trace ID = UK2015011XXXXXXXXXXXXXXXX. This trace ID is the same as that displayed on screens 8621A and 8621B of (2-1A) and (2-1B) of Figure 13 described above and screen 8622 of (2-2).

[0280] Furthermore, the subsequent linkage information (2-3) displayed on screen 8623 includes own function ID = ZS1025051 (FIEA customer securities balance registration) and requestor function ID = ZS1025071 (FIEA customer securities balance data selection and contract). Furthermore, own TX linking ID = RRRRRRRRRRRRRRRRRRRRRR and requestor TX linking ID = PPPPPPPPPPPPPPPPPPPPPP. These own function ID, requestor function ID, own TX linking ID, and requestor TX linking ID are the same as the respective IDs displayed on screen 8622 above.

[0281] (Description of Figures 11 and 14 / Transaction Detail Management Service Unit 40D)

[0282] 11, transaction details management service unit 40D stores (records in a log file) in log data storage means 80 (not shown) log data of (3-1) input message information when business data registration means 51D receives a registration API request sent from registration API calling means 48D, and log data of (3-2) insert information when business data registration means 51D stores transaction data in transaction details database 61D, which is a business database. These log data are collected by log data collection means 82 and accumulated and stored in collection log database 84 (see FIGS. 1 and 2).

[0283] Furthermore, since transaction details management service unit 40D does not have data selection means 50 (see FIG. 2) (see FIG. 6), there is no log data of input message information when data selection means 50 receives a data selection API request sent from data selection API calling means 47 (see FIG. 2). Furthermore, since transaction details management service unit 40D does not have a subsequent business service unit 40 or a subsequent linked data storage means 72, there is no log data of (3-3) subsequent linked information.

[0284] 14, the trace information display means 86 receives a search for log data stored in the collected log database 84 (see FIGS. 1 and 2), and displays the trace information contained in the searched log data on the screen of a user terminal (not shown) operated by an employee of the securities company, etc. The identification information of the transaction details management service unit 40D is GK108, and the identification information of its linked balance update reception and contract service unit 20C is UK201.

[0285] In (3-1) of Figure 14, the input message information to the transaction detail management service unit 40D, i.e., the information recorded in the input message information log file (3-1), is displayed on a screen 8631. The (3-1) input message information displayed on this screen 8631 includes a trace ID = UK2015011XXXXXXXXXXXXXXXX. This trace ID is an ID assigned by the cooperating balance update reception and contract service unit 20C (UK201).

[0286] Furthermore, the (3-1) input message information displayed on screen 8631 includes the self function ID = GK1085061 (transaction detail registration (internal occurrence detail registration)) and the requester function ID = UK2015011 (balance update registration acceptance / contract). Furthermore, the self TX linking ID = SSSSSSSSSSSSSSSSSSSS and the requester TX linking ID = YYYYYYYYYYYYYYYYYYYYY. Therefore, for the self, the information is about the transaction detail management service unit 40D (GK108), and for the requester, the information is about the linked balance update acceptance / contract service unit 20C (UK201).

[0287] In Figure 14 (3-2), the insert information into the transaction statement management service unit 40D, i.e., the information recorded in the insert information log file (3-2), is displayed on screen 8632. The (3-2) insert information displayed on this screen 8632 includes a trace ID = UK2015011XXXXXXXXXXXXXXXX. This trace ID is the same as that displayed on screen 8631 in Figure 14 (3-1) described above.

[0288] Additionally, the (3-2) insert information displayed on screen 8632 includes the own function ID = GK1085061 (transaction detail registration (internal occurrence detail registration)) and requestor function ID = UK2015011 (balance update registration acceptance / contract). Furthermore, the own TX linking ID = SSSSSSSSSSSSSSSSSSSSSS and requestor TX linking ID = YYYYYYYYYYYYYYYYYYYY. These own function ID, requestor function ID, own TX linking ID, and requestor TX linking ID are the same as the respective IDs displayed on screen 8631 above.

[0289] The (3-2) insert information displayed on screen 8632 contains the contents of the transaction data stored in the transaction details database 61D, which is a business database, in parentheses following "VALUES," and the data following "VALUES" includes record registration trace ID code = UK2015011XXXXXXXXXXXXXXXX, record registration transaction ID code = SSSSSSSSSSSSSSSSSS, record registration function ID code = GK1085061, record update trace ID code = UK2015011XXXXXXXXXXXXXXXX, record update transaction ID code = SSSSSSSSSSSSSSSSSS, and record update function ID code = GK1085061.

[0290] Here, since this is a case of newly registered transaction data, the same data is stored in the record registration trace ID code and the record update trace ID code, both of which are the same data as the trace ID.

[0291] Also, since this is newly registered transaction data, the same data is stored in the record registration transaction ID code and record update transaction ID code, both of which are the same data as the own TX linking ID.

[0292] Furthermore, since this is a case of newly registered transaction data, the same data is stored in the record registration function ID code and record update function ID code, both of which are the same data as the own function ID.

[0293] (Figure 11, Figure 15 Description / Reference Function Customer Securities Service Unit 40K)

[0294] 11, the reference function customer securities service unit 40K stores (records in a log file) in a log data storage means 80 (not shown) the following log data: (4-1A) input message information log data when the data selection means 50K receives a data selection API request sent from the data selection API calling means 47 (see FIG. 2); (4-1B) input message information log data when the business data registration means 51K receives a registration API request sent from the registration API calling means 48K; and (4-2) insert information log data when the business data registration means 51K stores transaction data in the investment trust customer securities balance and securities details database 61K, which is a business database. These log data are collected by a log data collection means 82 and stored in a collection log database 84 (see FIGS. 1 and 2).

[0295] It should be noted that the reference function customer securities service unit 40K does not have the subsequent business service unit 40 or subsequent linked data storage means 72, and therefore (4-3) there is no log data of subsequent linked information.

[0296] 15, the trace information display means 86 accepts a search for log data stored in the collected log database 84 (see FIGS. 1 and 2), and displays the trace information contained in the searched log data on the screen of a user terminal (not shown) operated by an employee of the securities company, etc. The identification information of the reference function customer securities service unit 40K is ZS301, and the identification information of its associated Financial Instruments and Exchange Act customer securities balance management service unit 40A is ZS102.

[0297] In FIG. 15 (4-1), input message information to the reference function customer securities service unit 40K, that is, information recorded in the input message information log files (4-1A) and (4-1B), is displayed on screens 8641A and 8641B.

[0298] The input message information (4-1A) displayed on screen 8641A includes a trace ID = UK2015011XXXXXXXXXXXXXXXX. This trace ID is assigned by the balance update reception and contract service unit 20C (UK201) of the cooperating source.

[0299] Furthermore, the input message information (4-1A) displayed on screen 8641A includes the self function ID = ZS3015011 (reference function customer securities balance data selection - Financial Instruments and Exchange Act customer securities details) and the requester function ID = ZS1025051 (Financial Instruments and Exchange Act customer securities balance registration). Furthermore, the self TX linking ID = TTTTTTTTTTTTTTTTTTTTTT and the requester TX linking ID = RRRRRRRRRRRRRRRRRRRRRRRR. Therefore, for the self, the information is about the reference function customer securities service unit 40K (ZS301), and for the requester, the information is about the linked Financial Instruments and Exchange Act customer securities balance management service unit 40A (ZS102).

[0300] On the other hand, the (4-1B) input message information displayed on screen 8641B also contains the same trace ID = UK2015011XXXXXXXXXXXXXXXX as in the (4-1A) input message information above. This trace ID is an ID assigned by the balance update reception and contract service unit 20C (UK201) of the cooperating source.

[0301] Additionally, the input message information (4-1B) displayed on screen 8641B includes the self-function ID = ZS3015021 (reference function: customer securities statement registration) and the requesting function ID = ZS3015011 (reference function: customer securities balance data selection - Financial Instruments and Exchange Act customer securities statement). Furthermore, the self-TX linking ID = UUUUUUUUUUUUUUUUUUUU and the requesting function linking ID = TTTTTTTTTTTTTTTTTTTTTT. Therefore, within the reference function customer securities service unit 40K (ZS301), processing has shifted from one self-unit to another, but this is because the trace information is on an API-by-API basis. Therefore, the requesting function ID on screen 8641B is the same as the self-function ID on screen 8641A, and both are ZS3015011 (reference function: customer securities balance data selection - Financial Instruments and Exchange Act customer securities statement). Also, the request source TX linked ID on screen 8641B is the same as the request source TX linked ID on screen 8641A, and both are TTTTTTTTTTTTTTTTTTTTTT.

[0302] In (4-2) of Figure 15, the insert information into the reference function customer securities service unit 40K, i.e., the information recorded in the insert information log file (4-2), is displayed on screen 8642. The (4-2) insert information displayed on this screen 8642 includes trace ID = UK2015011XXXXXXXXXXXXXXXX. This trace ID is the same as that displayed on screens 8641A and 8641B of (4-1A) and (4-1B) of Figure 15 described above.

[0303] Additionally, the (4-2) insert information displayed on screen 8642 includes own function ID = ZS3015021 (reference function: customer securities statement registration) and requestor function ID = ZS3015011 (reference function: customer securities balance data selection - Financial Instruments and Exchange Act customer securities statement). Furthermore, own TX linking ID = UUUUUUUUUUUUUUUUUUUU and requestor TX linking ID = TTTTTTTTTTTTTTTTTTTT. These own function ID, requestor function ID, own TX linking ID, and requestor TX linking ID are the same as the respective IDs displayed on screen 8641B above.

[0304] The (4-2) insert information displayed on screen 8642 contains the contents of the transaction data stored in the investment trust customer securities balance and securities details database 61K, which is the business database, in the parentheses following "VALUES," and the data following "VALUES" includes record registration trace ID code = UK2015011XXXXXXXXXXXXXXXX, record registration transaction ID code = UUUUUUUUUUUUUUUUUUUU, record registration function ID code = ZS3015021, record update trace ID code = UK2015011XXXXXXXXXXXXXXXX, record update transaction ID code = UUUUUUUUUUUUUUUUUUUUU, and record update function ID code = ZS3015021.

[0305] Here, since this is a case of newly registered transaction data, the same data is stored in the record registration trace ID code and the record update trace ID code, both of which are the same data as the trace ID.

[0306] Also, since this is newly registered transaction data, the same data is stored in the record registration transaction ID code and record update transaction ID code, both of which are the same data as the own TX linking ID.

[0307] Furthermore, since this is a case of newly registered transaction data, the same data is stored in the record registration function ID code and record update function ID code, both of which are the same data as the own function ID.

[0308] (Explanation of Figures 11 and 16 / Domestic Bond Customer Securities Balance Management Service Unit 40G)

[0309] As shown in Fig. 11, the domestic bond customer securities balance management service unit 40G stores (records in a log file) in log data storage means 80 (not shown) the following log data: (5-1) input message information log data when the data selection means 50G receives a data selection API request transmitted from the data selection API calling means 47 (see Fig. 2); (5-2) input message information log data (not shown in Fig. 16) when the business data registration means 51G receives a registration API request transmitted from the registration API calling means 48K (see Fig. 2); and (5-2) insert information log data (not shown in Fig. 16) when the business data registration means 51G stores transaction data in the domestic bond customer securities balance and securities detail database 61G, which is a business database. These log data are collected by log data collection means 82 and accumulated and stored in a collection log database 84 (see Figs. 1 and 2).

[0310] Note that the domestic bond customer securities balance management service unit 40G does not have a subsequent business service unit 40 or a subsequent linked data storage means 72, and therefore there is no log data of (5-3) subsequent linked information. Also, Fig. 16 shows a display example in which the data selection means 50G has determined that the transaction data is not related to the business processing handled by its own unit 40G, and therefore there is no log data of the input message information when the business data registration means 51G receives a registration API request, and furthermore, there is no registration processing in the domestic bond customer securities balance and securities detail database 61G, and therefore there is no log data of (5-2) insert information.

[0311] 16, the trace information display means 86 accepts a search for log data stored in the collected log database 84 (see FIGS. 1 and 2), and displays the trace information contained in the searched log data on the screen of a user terminal (not shown) operated by an employee of the securities company, etc. The identification information of the domestic bond customer securities balance management service unit 40G is ZS110, and the identification information of its associated Financial Instruments and Exchange Act customer securities balance management service unit 40A is ZS102.

[0312] In (5-1) of Figure 16, the input message information to the domestic bond customer securities balance management service unit 40G, i.e., the information recorded in the input message information log file (5-1), is displayed on a screen 8651. The (5-1) input message information displayed on this screen 8651 includes a trace ID = UK2015011XXXXXXXXXXXXXXXX. This trace ID is an ID assigned by the balance update reception and contract service unit 20C (UK201) of the cooperating source, which is yet another cooperating source.

[0313] Furthermore, the (5-1) input message information displayed on screen 8651 includes self function ID = ZS1105011 (domestic bond customer securities balance data selection - FIEA customer securities details) and requestor function ID = ZS1025051 (FIEA customer securities balance registration). Furthermore, it includes self TX linking ID = VVVVVVVVVVVVVVVVVVVVV and requestor TX linking ID = RRRRRRRRRRRRRRRRRRRRRR. Therefore, for self, the information is about the domestic bond customer securities balance management service unit 40G (ZS110), and for the requestor, the information is about the FIEA customer securities balance management service unit 40A (ZS102).

[0314] <Effects of this embodiment>

[0315] According to this embodiment, the following effect is achieved: In the securities core business back-end system 10, the service unit of the cooperation source (the reception service unit 20 or the business service unit 40) outputs transaction data (including transaction attribute information) as linked data to the linked data storage means 72 in a variable-length data format (JSON format in this embodiment) consisting of a combination of a key and a value, while the service unit of the cooperation destination (the business service unit 40) acquires the transaction data stored in the linked data storage means 72 and executes a data selection process using the transaction attribute information included in the acquired transaction data, by the data selection means 50, to determine whether the acquired transaction data is transaction data for which the cooperation destination unit (the cooperation destination business service unit 40) is responsible for the business processing.

[0316] Therefore, when the cooperation source service units 20, 40 output transaction data as cooperation data to the cooperation data storage means 72, the cooperation data does not need to be cooperation data dedicated to the cooperation destination service unit 40, and can be cooperation data that does not take into account the content of the business processing performed in the cooperation destination service unit 40. In other words, the cooperation source service units 20, 40 can be configured not to be aware of the cooperation destination service unit 40. Therefore, it is possible to realize loose coupling (loosely coupled data cooperation method) between the cooperation source service units 20, 40 and the cooperation destination service unit 40.

[0317] This eliminates the need to redesign the source service units 20 and 40 when providing a new service (when a new partner service unit 40 is added) or when changing the content of an existing service (when the business processing content of an existing partner service unit 40 changes), thereby reducing the effort and time required for system modification. This allows for the realization of a new platform infrastructure that takes future sales expansion and scalability into account and improves system maintainability. Therefore, this loose coupling eliminates the problems associated with system complexity and size that arise in a monolithic system such as the conventional securities back-office system 900 shown in FIG. 17, where the source service units 20 and 40 are tightly coupled with the partner service unit 40.

[0318] Furthermore, the transaction attribute information included in the transaction data output from the cooperating service units 20, 40 to the linked data storage means 72 is transaction attribute information about the transaction data to be sent to the cooperating service unit 40, but is not intended for a specific cooperating service unit 40, but merely describes the content of the linked data (attributes of the transaction data) output by the cooperating service units 20, 40 so that it can be used in data selection processing at unspecified cooperating service units 40 (including service units 40 that will be added in the future and service units 40 whose processing content will be changed in the future). In other words, this transaction attribute information is not included in the transaction data with any consideration of the content of the business processing performed by the cooperating service unit 40, but simply conveys the content of the linked data (attributes of the transaction data) output by the cooperating service units 20, 40 to the unspecified cooperating service unit 40 that will receive the linked data. Therefore, since loose coupling (loosely coupled data linkage method) can be realized, the relationship between the linked data storage means 72 and the linked service unit 40 that obtains transaction data from it can be a many-to-many relationship as shown in Figure 6, and all relationships such as one-to-many, many-to-one, and one-to-one can be allowed.

[0319] Furthermore, since the linked data storage means 72 stores the transaction data as linked data in a variable-length data format (JSON format in this embodiment) consisting of a combination of keys and values, the linked service unit 40 can acquire transaction attribute information from the transaction data acquired from the linked data storage means 72, even if the transaction data is output in the format of the linking service unit 20, 40 (the number of items, the content of each item, the order of each item, etc.) specified by the linking service unit 20, 40. In other words, the linked service unit 40 can recognize the location of the transaction attribute information in the transaction data acquired from the linked data storage means 72, or the location of the data items. Therefore, the linked service unit 40 can execute the data selection process using the data selection means 50, even if the output format specified by the linking service unit 20, 40 (the number of items, the content of each item, the order of each item, etc.) is unknown.

[0320] In the securities core business back-end system 10, the data selection process is performed by the data selection means 50 in the linked business service unit 40 using the money update flag and / or securities update flag added by the linking reception service unit 20 (see FIG. 7), so a loosely coupled data linkage type securities core business system can be realized using transaction attribute information suitable for the securities core business, such as the money update flag and / or securities update flag. Also, because the money update flag and / or securities update flag added by the linking reception service unit 20 is used, a loosely coupled data linkage type can be realized even if transaction attribute information is not specified in the external system 100.

[0321] Furthermore, in the securities core business back system 10, since the transaction data sent from the external system 100 contains a transaction code, the reception service unit 20 of the linking source can use this transaction code to determine the money update flag and / or securities update flag to be added to the transaction data as linked data to be output to the linked data storage means 72.

[0322] Furthermore, since the securities core business back-end system 10 is equipped with the distributed processing means 44 and the distributed management database 64, it is possible to perform distributed processing within the business service unit 40. This makes it possible to improve the processing speed of the business service unit 40. For example, if the business service unit 40 has parts with high processing performance and parts with low processing performance, the overall processing speed of the business service unit 40 can be improved by applying distributed processing to the parts with low processing performance.

[0323] Furthermore, when performing distributed processing, the distributed processing means 44 does not simply distribute to multiple processing routes, but can distribute transaction data with the same data in an item set as a distribution key (in this embodiment, an account number as an example) in a manner that maintains the processing order of the transaction data before distribution, as shown in Figure 5. This makes it possible to avoid inconveniences caused by reversing the processing order for transaction data with the same data in an item set as a distribution key.

[0324] Furthermore, the distributed processing means 44 and distributed management database 64 need only be provided in the business service unit 40 that requires distributed processing, and the distributed processing can be completed within that business service unit 40, so the required distributed processing can be achieved without affecting the configuration of the reception service unit 20 that is the source of the collaboration or other business service units 40.

[0325] Furthermore, since the number of shares and the share key can be freely set in the distribution management database 64, the degree of multiplicity of processing within the business service unit 40 can be freely set.

[0326] Furthermore, the securities backbone business system 10 includes a trace information display unit 86 (see FIGS. 1 and 2), which allows for on-screen display of trace information for a series of business processes executed through data linkage (see FIGS. 10 to 16). This allows users, such as securities company employees, to view and track the details of each business process executed through data linkage between multiple service units 20 and 40 on the screen, thereby improving traceability and visibility. This allows for quick identification of which service unit 20 or 40 issued which function of the trace information, thereby compensating for the drawbacks of microservices. This system is suitable for use in mission-critical securities backbone business systems where failures and malfunctions are unacceptable, achieving high maintainability. For example, users of this system can quickly investigate the scope of impact when a system failure occurs.

[0327] <Transformation Form>

[0328] The present invention is not limited to the above-described embodiment, and modifications within the scope of the present invention are included in the present invention.

[0329] For example, in the above embodiment, the item set as the distributed key is the account number (customer identification information) as shown in Fig. 5, but it is not limited to this and may be, for example, a stock code (stock identification information), etc. If the stock code is used, distributed processing can be performed such that stocks α, β, and γ are sent to a first processing route, stocks δ, ε, and ζ are sent to a second processing route, and stocks η, θ, and σ are sent to a third processing route.

[0330] In the above embodiment, the securities core business system of the present invention is applied to the securities core business back-end system 10, but it may also be applied to a securities core business front-end system that handles orders and the like.

[0331] Furthermore, in the above embodiment, each of the service units 20 and 40 is configured by a container, but this is not limiting, and the service units may be configured by a normal server integrated with hardware. [Industrial Applicability]

[0332] As described above, the securities backbone business system and program of the present invention are suitable for use in, for example, building a securities backbone business back-end system. [Explanation of symbols]

[0333] 10. Securities core business back-office system that constitutes the securities core business system 20 Reception Service Unit 31 Reception database 40 Business Service Unit 44 Distributed Processing Means 49-1, 52-1 First processing means which is a processing means after dispersion 49-2, 52-2 Second processing means, which are post-dispersion processing means 50 Data Selection Methods 61 Business Database 64 Distributed Management Database 72 Linked data storage means 82 Log data collection methods 84 Collected Log Database 86 Trace information display means

Claims

1. A securities core business system configured by a computer that executes business processing related to transaction data of customers' securities, a plurality of service units that execute business processes related to the transaction data in a data linkage manner; a linked data storage means for storing the transaction data in a variable-length data format consisting of a combination of a key and a value as linked data for data linkage between the plurality of service units; The service unit of the collaboration source is The transaction data after the business process in charge of the own unit is performed is stored in a database provided in the own unit, The transaction attribute information for the transaction data to be sent to the linked service unit includes a money update flag added by the local unit indicating that the transaction involves updating the customer's money balance or a securities update flag indicating that the transaction involves updating the customer's securities balance, or a transaction attribute flag or transaction attribute classification of the transaction data specified by an external system, and the data for each item constituting the transaction data is stored in the linked data storage means in a variable-length data format consisting of a combination of the key and value, The service unit of the cooperation destination is acquires the transaction data stored in the linked data storage means, and executes a data selection process using the transaction attribute information included in the acquired transaction data to determine whether the acquired transaction data is transaction data that should be subjected to business processing that is the responsibility of the own unit; When it is determined that the transaction data is to be processed by the unit, the transaction data after the processing by the unit is stored in a database provided within the unit. A securities core business system characterized by:

2. Among the plurality of service units: The service unit of the link source includes the service unit configured to store data of each item constituting the transaction data in the linked data storage means in a variable-length data format consisting of a combination of the key and value, including the money update flag and / or the securities update flag added by its own unit, and The service unit to which the transaction data is linked includes a service unit configured to acquire the transaction data stored in the linked data storage means, and execute a data selection process to determine whether the acquired transaction data is transaction data for which the service unit is responsible for business processing, using the money update flag and / or the securities update flag added by the service unit from which the transaction data is linked and included in the acquired transaction data.

2. The securities backbone business system according to claim 1.

3. Among the plurality of service units: The service unit of the cooperation source includes a reception service unit that receives the transaction data transmitted from an external system via a communication line, The service units to which the communication is to be performed include a subsequent business service unit of the reception service unit, The reception service unit: The transaction data received from the external system is stored in a reception database provided in the own unit, The transaction attribute information for the transaction data to be transmitted to the subsequent business service unit is configured to add the money update flag and / or the securities update flag, which are predetermined in accordance with the transaction code included in the transaction data received from the external system, in its own unit, and to store the data of each item constituting the transaction data in a variable-length data format consisting of a combination of the key and value in the linked data storage means, with the added money update flag and / or the securities update flag included.

2. The securities backbone business system according to claim 1.

4. The service unit of the cooperation destination is a distribution management database that stores the number of distributions for distributing the transaction data acquired from the linked data storage means within its own unit, items that serve as distribution keys, and distribution IDs that indicate the base of the root process IDs after distribution within its own unit, in association with the root process IDs before distribution within its own unit; a distributed processing means for distributing the transaction data acquired from the linked data storage means in accordance with the distribution number using the information stored in the distribution management database, for the transaction data having the same data of the item designated as the distribution key, while maintaining the processing order of the transaction data before distribution, and for generating a new route process ID after distribution by adding identification information of a branch determined for each route after distribution according to the distribution number to the distribution ID; In order to process the transaction data distributed by this distributed processing means in separate routes, post-distribution processing means are provided in the own unit in the same number as the number of distributions, corresponding to new route process IDs after distribution.

2. The securities backbone business system according to claim 1, further comprising:

5. Each of the service units includes: a log data storage means for storing, as log data, input message information when the transaction data is input into the service unit, insert information when the transaction data is registered in the database provided in the service unit, and subsequent link information when the transaction data is stored in the link data storage means for transmission to the subsequent service unit; The input message information, the insert information, and the subsequent link information stored in the log data storage means each include the following: a trace ID that is commonly passed among a series of processes executed in cooperation among the plurality of service units; a self-function ID for identifying a function of each transaction processing executed by each of the service units; a requester function ID that identifies the transaction processing function of the requester that has transitioned to the transaction processing associated with this function ID; A self-TX-linked ID that is assigned when a transaction process related to the self-function ID is executed; a request source TX matching ID assigned at the time of execution of a transaction process related to the request source function ID, a log data collection means for collecting the log data stored in the log data storage means provided in each of the service units; a collected log database that stores the log data collected by the log data collecting means; a trace information display means for displaying the log data stored in the collected log database on a screen as trace information for tracing a series of processes executed in cooperation between the plurality of service units; 2. The securities backbone business system according to claim 1, further comprising:

6. A program for causing a computer to function as the securities backbone business system according to any one of claims 1 to 5.

Images