Securities core business systems and programs

Abstract

To provide a securities core business system capable of reducing the time and effort required for system modification work when providing a new service or modifying the contents of an existing service. [Solution] In the securities core business back system 10, the service unit 20, 40 that originates the link outputs transaction data (including transaction attribute information) to the linked data storage means 72 in a variable-length data format consisting of a combination of a key and a value, and the linked service unit 40 acquires the transaction data stored in the linked data storage means 72 and, using the transaction attribute information contained in the transaction data, determines, via a data selection means 50, whether the acquired transaction data is transaction data that should be used for the business processing that the service unit 40 is responsible for, thereby realizing loosely coupled data linkage between the service units.

Description

[Technical field]

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

[0002] Conventional securities back-end systems were monolithic systems in which the entire system functioned as one integrated block. Conventional securities back-end systems were configured to execute various business processes by linking data between multiple servers with different functions, but the 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 executed by the subsequent server, and output dedicated linked data for the subsequent server. Therefore, if there were multiple subsequent servers, the source server output dedicated linked data with different content to each of the multiple subsequent servers.

[0003] 17 shows a part 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 deposit / margin balance management server 930, and an advance payment management linked data storage means 941 and a security deposit / margin balance management linked data storage means 942, which are queues (QUE) for data linking 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 by the balance update means 911, and stores the updated data in a record of the money details database 912. Furthermore, the advance payment calculation means 913 refers to the updated record stored in the money details database 912 and executes processing to determine whether or not to perform an advance payment calculation, and if it is determined that an advance payment calculation is to be performed, the advance payment management data selection and transmission means 914 executes processing to select data required for processing in the advance payment management server 920, and stores the selected linked data dedicated to advance payment management in the advance payment management linked data storage means 941. Thereafter, the advance payment management server 920 acquires the linked data dedicated to advance payment management stored in the advance payment management linked data storage means 941 by the advance payment update means 921, executes processing related to updating the advance payment, and stores the updated data in a record of the advance payment 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, and if it is decided that a security deposit / margin calculation should be performed, the security deposit / margin balance management data selection and 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 associated data dedicated to security deposit / margin balance management in the security deposit / margin balance management associated data storage means 942. Thereafter, the margin and margin balance management server 930 uses the margin and margin balance update means 931 to obtain linked data dedicated to margin and margin balance management stored in the margin and margin balance management linked data storage means 942, executes processing related to the margin and margin balance update, and stores the updated data in a record in the margin and margin detail database 932.

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

[0007] In addition, the implementation of the securities core business system of the present invention employs container technology as described later (see FIG. 1). In addition, in the present invention, unlike the conventional monolithic structure (see FIG. 17 above) and also unlike microservices with an ambiguous definition, a unit called SLU (Sustainable Loose Coupled Unit) is defined as an "implementation unit suitable for securities core business", as described later, and microservices (a type of microservices in a broad sense) are built on this SLU unit. In the present invention (invention related to claims), this unit called SLU is called a service unit, and in the present specification and drawings, the description is given with SLU written alongside the service unit.

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

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

[0010] [Patent Document 1] JP 2023-139086 A [Patent Document 2] Patent Publication No. 2023-40001 [Patent Document 3] JP 2023-36828 A [Patent Document 4] JP 2023-27098 A [Patent Document 5] Special Publication No. 2018-530175 [Patent Document 6] JP 2024-8735 A 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 link destination are tightly coupled, so when providing a new service, link data tailored to the link destination's functions (processing contents of the server) is sent to the link destination, so a dedicated path to the link destination is added. In addition, when adding this dedicated path to the link destination, the link source determines whether the link data to be sent to the link destination is subject to processing at the link destination, so the link source is designed with the contents of the business processing at the link destination in mind.

[0012] For example, in Fig. 17, two dedicated paths are provided, but a dedicated path for a new service will be added. Therefore, every time a new service related to various products or businesses is added, a dedicated path is added, and the processing contents of the linked server increase and become complicated, so that the conventional securities core business back-end system 900 has become a complex and huge system. For this reason, there was a problem that the work of changing the system 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 process (function of the linking destination) will change, so the content of the linking data sent from the linking source to the linking destination will also change, and the content of the processing at the linking source (processing to determine whether it is subject to processing at the linking destination) will also change. Therefore, since it is necessary to change the design of not only the linking destination but also the linking source, there is a problem that the work to change the system 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 performed 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 core business system configured by a computer that executes business processing related to transaction data of clients' securities, A plurality of service units that execute business processes related to transaction data through data integration; a linkage data storage means for storing transaction data in a variable-length data format consisting of a combination of a key and a value as linkage data for data linkage between the plurality of service units; The service unit from which the link originates is Store the transaction data after the business process in charge of the own unit in a database provided in the own unit, The transaction attribute information for the transaction data to be transmitted to the associated service unit includes a money update flag added by the associated 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 category of the transaction data specified by the external system, and the data for each item constituting the transaction data is stored in the associated data storage means in a variable-length data format consisting of a combination of a key and a value; The partner service unit is acquires transaction data stored in the associated data storage means, and executes a data selection process to determine whether the acquired transaction data is transaction data for which the transaction processing in charge of the own unit is to be performed, using transaction attribute information included in the acquired transaction data; When it is determined that the transaction data should be subjected to the business process for which the unit is responsible, the transaction data after the business process for which the unit is responsible is stored in a database provided in the unit. It is characterized by the above.

[0017] Here, a "service unit" is a unit for dividing various business processes executed in a securities backbone business system configured by a computer into cohesive service contents, but in this invention, with an eye on future sales expansion and scalability, a "sustainable and loosely coupled implementation unit" is newly defined as a strategic concept with the name of SLU (Sustainable Loose Coupled Unit), and this is called a "service unit" in the claims. In other words, it can be said that a "service unit" is a unit that divides various business processes related to securities backbone business so that the loosely coupled data linkage method in this invention (invention related to claims) can be applied, and with an eye on future sales expansion and scalability, it means that the system change work associated with new services and changes in service contents that will occur in the future will be made easier, as will be described later. Therefore, the "service unit" in this invention (claimed invention) refers to the above-mentioned SLU, which is an "implementation unit suitable for core securities operations" that is neither a conventional monolithic structure (see Figure 17 described above) nor a microservice with an ambiguous definition. In this invention, microservices (a type of microservice in a broad sense) are constructed on an SLU basis.

[0018] In addition, the "money update flag" and "securities update flag" in the "transaction attribute information" are information added by the own unit (the service unit itself that is the source of cooperation), and the "transaction attribute flag" and "transaction attribute category" are information specified by an external system (a system other than the securities backbone business system of the present invention), and are information 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 is that the service units of the source and destination of cooperation that perform data cooperation using any of the "transaction attribute information" listed here ("money update flag", "securities update flag", "transaction attribute flag", "transaction attribute category") are included in the securities backbone business system of the present invention. Therefore, the securities backbone business system of the present invention may include service units of the source and destination of cooperation that perform data cooperation using transaction attribute information other than the listed "transaction attribute information", and may include service units of the source and destination of cooperation that perform data cooperation using transaction attribute flags added by the own unit (the service unit that is the source of cooperation) other than the "money update flag" and "securities update flag" instead of the "transaction attribute flag" specified by the external system. Furthermore, the securities core 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 such a securities backbone business system of the present invention, the service unit that is the link source 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.Then, the linked service unit acquires the transaction data including the transaction attribute information stored in the linked data storage means, and executes a data selection process using the transaction attribute information 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 in 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 a loose coupling (loosely coupled data linkage method) between the link source service unit and the link destination service unit.

[0021] As a result, when providing a new service (when a new linked service unit is added) or when changing the contents of an existing service (when the contents of the business processing of an existing linked service unit change), there is no need to change the design of the linked service unit, so the effort and time required for system change work can be reduced. This makes it possible to realize a new platform infrastructure that takes into account future sales expansion and scalability, and improves the maintainability of the system. Therefore, by realizing such loose coupling, problems associated with the complexity and enlargement of the system that occurred in the case of a monolithic system such as the conventional securities core business back-end system 900 shown in FIG. 17 described above, that is, when the linked service unit was tightly coupled with the linked service unit, can be eliminated.

[0022] Furthermore, the transaction attribute information included in the transaction data output from the service unit of the link source to the link data storage means is transaction attribute information about the transaction data to be sent to the service unit of the link destination, but is not intended for a specific service unit of the link destination, but merely describes the contents of the linked data (attributes of the transaction data) output by the service unit of the link source so that it can be used in data selection processing at unspecified service units of the link destination (including service units that will be added in the future and service units whose processing contents 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 contents of the business processing performed by the service unit of the link destination, but merely transmits the contents of the linked data (attributes of the transaction data) output by the service unit of the link source to the unspecified service unit of the link destination that will acquire the linked data. Thus, loose coupling (loosely coupled data linkage method) is realized.

[0023] Furthermore, as described above, the transaction data output from the linking service unit to the linking data storage means as linked data is not based on the content of the business process performed by the linking 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 linking service unit acquires the transaction data output in the format of the linking service unit from the linking data storage means, and acquires the transaction attribute information from the transaction data. However, when the linking service unit acquires the transaction data, the transaction data is not linked data dedicated to the linking service unit as in the past. Therefore, if it is unclear which part of the transaction data acquired by the linking service unit is the transaction attribute information, or which part is the data of what item, the data selection process or business process cannot be performed in the linking service unit.

[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 exists, or what item of data exists at what position. Even if the link source service unit makes a design change and the data position changes, the transaction attribute information and the data of each item can be recognized. Even if the link source 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, so that changes in the data length of the output linked data are permitted, and the degree of freedom in designing the link source service unit is increased, thereby achieving the above-mentioned object.

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

[0026] In addition, in the above-mentioned securities core business system of the present invention, Among the multiple service units, The service unit 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 service unit itself as a link source, and It is desirable for the linked service unit to include a service unit configured to acquire transaction data stored in a linked data storage means, and execute a data selection process using a money update flag and / or a securities update flag added by the linked 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 handled by the linked service unit.

[0027] In this manner, when a configuration is adopted in which a source and destination service unit of a data linkage method using a money update flag and / or a securities update flag are included among the multiple service units, the money update flag and / or the securities update flag added by the source service unit are used to execute data selection processing in the destination service unit. Therefore, a securities core business system of a loosely coupled data linkage method can be realized by transaction attribute information suitable for securities core business, such as the money update flag and / or the securities update flag. In addition, since the money update flag and / or the securities update flag added by the source service unit are used, a loosely coupled data linkage method can be realized even if transaction attribute information is not specified in an external system.

[0028] <Configuration for linking data between a reception service unit and a subsequent business service unit using a money update flag and / or a securities update flag corresponding to a transaction code>

[0029] Furthermore, in the above-mentioned 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 is Stores transaction data received from an external system in a reception database provided in the unit; It is desirable that the unit adds a predetermined money update flag and / or securities update flag corresponding to the transaction code contained in the transaction data received from the external system as transaction attribute information for the transaction data to be sent to a subsequent business service unit, and that the data for each item constituting the transaction data, including the added money update flag and / or securities update flag, is stored in the associated data storage means in a variable-length data format consisting of a combination of a key and a value.

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

[0031] In addition, 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 "money update flag and / or securities update flag that are predetermined in accordance with the transaction code", i.e., the correspondence between 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 configured to be performed using a money update flag and / or a securities update flag corresponding to the transaction code, the reception service unit that originates the linkage determines the money update flag and / or the securities update flag to be added to the transaction data using the transaction code included in the transaction data, stores the transaction data as linked data including the determined money update flag and / or the securities update flag in the linked data storage means, and then the subsequent business service unit acquires the transaction data from the linked data storage means, and uses the money update flag and / or the securities update flag included in the transaction data to execute data selection processing to determine whether the transaction data is necessary for business processing in its own unit (business service unit). Therefore, a securities core business system with a loosely coupled data linkage method can be realized by transaction attribute information suitable for the securities core business, namely the money update flag and / or the securities update flag.

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

[0035] In addition, in the above-mentioned securities core business system of the present invention, The partner service unit is a distribution management database that stores a distribution number for distributing the transaction data acquired from the linked data storage means within its own unit, an item serving as a distribution key, and a distribution ID indicating a base of a root process ID after distribution within its own unit, in association with a root process ID before distribution within its own unit; a distribution processing means for distributing transaction data acquired from the linked data storage means according to a distribution number using information stored in the distribution management database, while maintaining the processing order of transaction data having the same data of items designated as distribution keys before distribution, and for generating a new root process ID after distribution by adding identification information of a branch part determined for each route after distribution according to the distribution number to the distribution ID; In order to process the transaction data distributed by the distributed processing means in separate routes, a post-distribution processing means is provided in the own unit in accordance with the new route process ID after distribution, the number of which is equal to the number of distributions. It is preferable that the configuration include the following:

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

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

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

[0039] Furthermore, in the above-mentioned securities core business system of the present invention, Each service unit has: a log data storage means is provided 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, the insert information, and the subsequent link information stored in the log data storage means each include the following: A trace ID that is shared among multiple service units in a series of processes that are executed in cooperation with each other, a function ID for identifying a function of each transaction processing executed by each service unit; a requester function ID that identifies the function of the transaction processing of the requester that has made the transition to the transaction processing related to the own function ID; A self-TX pegging ID that is assigned when a transaction process related to the self-function ID is executed; The request source TX pegging ID assigned at the time of execution of the transaction processing related to the request source function ID is included, a log data collecting means for collecting log data stored in a log data storage means provided in each of the service units; a collected log database for storing 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 preferable to have a configuration including the above.

[0040] In this way, when the trace information of a series of business processes executed through data linkage is displayed on the screen, the contents 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-mentioned securities backbone business system.

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

[0044] As described above, according to the present invention, transaction data including transaction attribute information is output from the source service unit to the linked data storage means in a variable-length data format consisting of a combination of a key and a value, and the destination service unit 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 handled by its own unit (the destination service unit).This makes it possible to realize loosely coupled data integration, thereby having 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 description of the drawings]

[0045] [Figure 1] 1 is a diagram showing the overall configuration of a securities core business back-end system which is one embodiment of the securities core business system of the present invention; [Diagram 2] FIG. 2 is another overall configuration diagram of the securities core business back-end system according to the embodiment. [Diagram 3] FIG. 4 is a configuration diagram for executing distributed processing according to the embodiment. [Figure 4] FIG. 4 is another configuration diagram for executing the distributed processing of the embodiment. [Diagram 5] FIG. 4 is an explanatory diagram of the distribution process according to the embodiment. [Figure 6] FIG. 2 is a diagram showing a specific example of the configuration of the securities core business back-end system according to the embodiment. [Figure 7] FIG. 4 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. 13 is a diagram illustrating a data linkage method using a money update flag and a securities update flag in the embodiment. [Figure 9] FIG. 13 is an exemplary diagram showing a data linkage method using transaction attribute classifications and transaction attribute flags in the embodiment. [Figure 10] 5 is a diagram showing 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. 4 is an explanatory diagram of the collection of log data in the securities core business back-end 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. 4 is a diagram showing a second example of a screen display by the trace information display means of the embodiment. [Figure 14] FIG. 11 is a diagram showing a third example of a screen display by the trace information display means of the embodiment. [Figure 15] FIG. 11 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 a fifth example of a screen display by the trace information display means of the embodiment. [Figure 17] FIG. 1 is a diagram showing the configuration of a conventional securities core business back-end system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0046] The following describes a securities core business back system 10, which is an embodiment of the securities core business system of the present invention, with reference to the drawings. FIGS. 1 and 2 show the overall configuration of the securities core business back system 10 of this embodiment. This securities core business back system 10 constitutes the securities core business system together with a securities core business front system that handles order processing for securities trading. FIGS. 3 and 4 are configuration diagrams 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 system 10, FIG. 7 shows a specific example of data linkage in the securities core business back 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 system 10, Figure 11 is an explanatory diagram of the collection of log data in the securities core business back 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 core business back-end system 10>

[0048] 1 and 2, the securities core business back-end system 10 is made up of one or more computers, and has one or more reception service units (reception SLU) 20, one or more business service units (business SLU) 40, and one or more data linkage containers (TOPIC) 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 problem], so a detailed description will be omitted here.

[0049] The reception service unit (reception SLU) 20 includes a reception means 22 and a reception data registration means 23, which are configured with 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, which are configured with an associated 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 with 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 service unit post-registration data acquisition means 25, and the linked data transmission means 26 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 operation 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 the sake of convenience, the reception means 22 and reception data registration means 23 are described as being configured by the reception container 21, and the intra-service unit post-registration data acquisition means 25 and the associated data transmission means 26 are described as being configured by the associated data transmission container 24. In the drawings, the means 22, 23, 25, and 26 are illustrated as being included in the container, but since a container is a concept that does not include hardware (physical server equipment), an OS (operating system), or a container engine, these means 22, 23, 25, and 26 are not configured only by the container, but are configured including the hardware, the OS, and the container engine. The same applies to other containers.

[0052] Furthermore, for example, non-volatile memory such as a hard disk drive (HDD) or a solid state drive (SSD) may be used as each of the databases 31, 32, and 33 included in the reception database server 30. The details of each of these 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, the acquired linked data registration means 43, the distributed processing means 44, the service unit pre-registration data acquisition means 46, the data selection API calling means 47, the registration API calling means 48, the data selection means 50, the business data registration means 51, the service unit post-registration data acquisition means 53, and the linked data transmission means 54 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 operation procedures of this CPU, and a working memory such as a main memory or a cache memory. The 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, non-volatile memories such as hard disk drives (HDDs) and solid state drives (SSDs) can be used as each of the databases 61 to 66 included in the business database server 60. The details of each 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 linkage source service unit (the reception service unit 20 or the business service unit 40) in the linkage data storage means 72, and executes a process of transmitting the linkage data stored in the linkage data storage means 72 to a linkage destination service unit in response to a linkage data acquisition request from the linkage destination service unit (the business service unit 40). 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 a key and a value. In this embodiment, the data linkage container 70 adopts AMQ Streams (Apache Active MQ Streams) as an example, and TOPIC as a 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-end system 10, one or more programs that define the operation procedures of this CPU, and working memories such as main memory and cache memory. Also, the linked data storage means 72 is composed of a non-volatile memory.

[0058] The securities core business back-end 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), log data collection means 82 configured by a log data collection container 81, a collection log database (collection 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-end system 10, one or more programs that define the operation procedures of this CPU, and working memories such as main memory and cache memory. The details of each of these means 82 and 86 will be described later.

[0060] Furthermore, for example, a non-volatile 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, an internal API base system 91 for in-house consumers or an external API base system 92 for external consumers, as well as an external system 100 are connected to the securities core business back-end system 10 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) that are internal consumers and internal user terminals 102, and external systems 103 (such as systems of other financial institutions) that are external consumers and external user terminals 104.

[0063] When the external system 100 is an in-house 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 an 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 an API receiving port of the reception service unit 20, via the internal network 1.

[0064] Incidentally, communication within the securities core business back-end system 10 is carried out via the internal network 1. Therefore, in this embodiment, 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, communication is via the internal network 1, but in this 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 (e.g., 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 receiving an 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 executes a process for storing the transaction data after the process has been completed in a database (reception database 31 in this case) provided in the own unit 20, and also executes a process for storing the transaction data in the post-registration database 33 after the process has been completed for its own unit (reception service unit 20 in this case), as shown in FIG. 2. Note that the reception service unit 20 may perform a process for adding transaction attribute information to the transaction data received from the external system 100 as described below, but 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 FIG. 2, the received 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 each item constituting the transaction data includes the money update flag added by its own unit (here, the receiving 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 indicating that the transaction involves an update of the customer's money balance, and a value of "1" indicates that the transaction involves an update of the customer's money balance, and 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 an update of the customer's securities balance, with a value of "1" indicating that the transaction involves an update of 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 the value "1" or "0" in the same manner as the "money update flag" and the "securities update flag". Although a specific example is not shown, as explained in the "transaction attribute category" below, the "transaction attribute category" can be decomposed into multiple transaction attribute flags, so in that sense it is information (transaction attribute information) that plays a similar role to the "transaction attribute category". 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 a transaction attribute flag specified by the external system 100.

[0072] Furthermore, the "transaction attribute category" is a category (information for identifying two or more transaction attributes) specified by the external system 100, and is therefore a category (identification information of the transaction attribute) 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 category added by the unit itself, rather than using a transaction attribute category specified by the external system 100. Furthermore, this "transaction attribute category" can be decomposed into multiple transaction attribute flags, for example, a transaction attribute flag indicating that the content corresponds to category = 01, and similarly, each transaction attribute flag indicating that the content corresponds to each of category = 02, category = 03, ..., and in that sense, it is information (transaction attribute information) that plays a similar role to the "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 (i.e., the transaction code specified by the external system 100) included in the transaction data received from the external system 100 in its own unit (here, the acceptance service unit 20), and outputs the transaction data with the "money update flag" and / or the "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 the acceptance service unit 20 equipped with the accepted data registration means 23 that executes such processing may exist in the securities core business back system 10, and all the acceptance service units 20 do not need to be service units equipped with the accepted data registration means 23 that executes such processing.

[0074] Furthermore, as described above, when the received data registration means 23 performs the process of adding a "money update flag" and / or a "securities update flag" that is predetermined in correspondence with the transaction code contained in the transaction data to the transaction data, the correspondence between the "transaction code" and the "money update flag and / or securities update flag" may be described (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 Base Container) 24>

[0076] As shown in FIG. 2, the post-registration data acquisition means 25 in the service unit acquires the 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 post-registration data acquisition means 25 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 keys and values, and executes a process of storing the data 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." The transaction attribute database 32 may be omitted and the above correspondence may be written (coded) in the program constituting the received data registration means 23. However, from the viewpoint of facilitating the response to cases where a new service is generated and the number of transaction codes increases, it is preferable to provide the transaction attribute database 32.

[0082] As shown in FIG. 2, the post-registration database 33 is provided to pass the transaction data from the reception container 21 to the associated 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 a predetermined time interval (e.g., 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, and executes a process of storing the transaction data received from the linked data acquisition means 42 in one pre-registration database 65 when the distributed processing means 44 indicated by the two-dot chain line in FIG. 2 is not provided, while executing a process of requesting distributed processing from the distributed processing means 44 to receive transaction data in a distributed state from the distributed processing means 44 and storing the transaction data received in a distributed state in a plurality of pre-registration databases 65 (see FIGS. 3 to 5) according to the number of distributions. 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), but there are differences such as, for example, the addition of a status indicating the progress of processing to the record of the transaction data, and of course, the transaction data is stored in a database format rather than a variable-length data format (in this embodiment, JSON format) consisting of a combination of a key and a value.

[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 indicated by two-dot chain lines in Figs. 1 and 2. Details of the processing by the distributed processing means 44 will be described later with reference to 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, the intra-service-unit pre-registration data acquisition means 46 also executes a process of changing the status of the record of the transaction data stored in the pre-registration database 65 to "processed."

[0089] 2, the data selection API calling means 47 executes a process of receiving transaction data (including transaction attribute information) obtained from the pre-registration database 65 from the pre-registration data obtaining means 46 in the service unit, setting the transaction data including the received transaction attribute information in a data selection API request, and transmitting the data selection API request to the data selection means 50. The data selection API calling means 47 also executes a process of receiving information that a data selection API request has been received from the data selection means 50, as indicated by the dotted line in FIG. 2, and passing the information to the pre-registration data obtaining 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 that should 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) and the registration API call means 48 receives information to that effect (that the business processing will be executed by its own unit 40) from the data selection means 50, the registration API call means 48 executes a process of sending a registration API request to the business data registration means 51. Therefore, if information to the effect that the business processing will be executed by its own unit 40 is not received from the data selection means 50, the process of sending 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 acquired from the linked data storage means 72) is transaction data for which the business processing handled by the own unit (here, the business service unit 40) is to be performed. If it is determined that the transaction data is transaction data for which the business processing handled by the own unit 40 is to be performed, it executes a process of transmitting information to the registration API calling means 48 that the business processing will be performed by the own unit 40. On the other hand, if the data selection means 50 determines that the transaction data is not transaction data for which the business processing handled by the own unit 40 is to be performed, 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 contains a "money update flag" as transaction attribute information, the data selection means 50 determines whether the value of the "money update flag" is "1" or not, and if it is "1", determines that the transaction data set in the data selection API request is transaction data for which the business processing handled by its own unit 40 should be performed. 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 judges whether the value of the "securities update flag" is "1" or not, and if it is "1", judges that the transaction data set in the data selection API request is transaction data for which the business processing handled by the own unit 40 should be performed. 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, when the transaction data includes a "transaction attribute category" as transaction attribute information, the data selection means 50 judges whether the value of the "transaction attribute category" is a predetermined value (a value written in the program constituting the data selection means 50, or a value stored in the external storage means for determining whether the transaction attribute category is the responsibility of the own unit 40), and when the value is the predetermined value, judges that the transaction data set in the data selection API request is transaction data for which the own unit 40 should carry out the business processing in charge of, or judges whether the transaction data includes a "transaction attribute category", and when it is determined that the "transaction attribute category" is included, judges that the transaction data set in the data selection API request is transaction data for which the own unit 40 should carry out the business processing in charge of, based on the inclusion of the "transaction attribute category", that is, regardless of the value of the "transaction attribute category". 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 transmitting 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 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 for 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 a process of storing the transaction data in the post-registration database 66. Therefore, when the transaction data acquired from the linked data storage means 72 is the transaction data for which the business processing for its own unit 40 should be performed, the data selection means 50 makes a judgment result to that effect (to the effect that the business processing is to be performed in its own unit 40), and the 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, the business data registration means 51 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 transaction data in the post-registration database 66. Note that the transaction data acquired from the associated data storage means 72, 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), may be added to the transaction data acquired from the associated data storage means 72 and stored in the post-registration database 66, or only data of items that do not overlap with the transaction data acquired from the associated data storage means 72 may be stored in the post-registration database 66 in addition to the transaction data acquired from the associated data storage means 72.

[0100] In the above, the transaction data acquired from the linked 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 in the post-registration database 66 as is in order to be handed over to and transmitted to the business service unit 40 subsequent to the own unit 40. In addition, new transaction attribute information may be added in the own unit 40 (the business service unit 40 currently executing the business process by the business data registration means 51) in order to be transmitted to the business service unit 40 subsequent to the own unit 40. For this reason, the transaction attribute database 62 is provided. In this case, the transaction attribute information included in the transaction data acquired from the linked data storage means 72 may be temporarily canceled and new transaction attribute information may be added, or new transaction attribute information may be added in addition to the transaction attribute information included in the transaction data acquired from the linked 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 that 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, the business service unit 40), there is no need to install the associated data transmission container (MQS infrastructure container) 52, so it is shown by a dotted line in Figure 1.

[0104] The post-registration data acquisition means 53 in the service unit acquires the transaction data stored in the post-registration database 66, as shown in FIG. 2, 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 keys and values, 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 includes a database management system (DBMS) and manages data input (new registration, updates) to each of the databases 61-66 and data acquisition from each of the databases 61-66.

[0108] The business database 61 stores business data after the business service unit 40 has performed business processing in charge of the business database 61. 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 associated 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 from its own unit 40 to the subsequent business service unit 40.

[0110] As shown in FIG. 4, the root process management database 63 stores, in association with each other, a root process ID (RPID) for the processing route (processing route in the linked data acquisition container (MQR-based container) 41) on which the first processing is performed in the business service unit 40, and a root process ID (APP-RPID) for the distribution business application on the processing route (processing route in 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 in 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 the processing route when there is only one processing route in 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 distributing the 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, a constructor setting value indicating the item that will be the distribution key, and a 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 transmitted 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: Figs. 3 to 5>

[0115] (Explanation of Figure 3)

[0116] 3 shows two types of root process forms (arrangement forms 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 a part of the system configuration includes a part with low processing performance (for example, when the processing performance of some containers is low, since containers are used in this embodiment).

[0117] The upper part of Fig. 3 shows the form of the root process when the federated data that has been distributed by distributed processing in the source service unit (SLU) or in a service unit (SLU) further upstream is separately acquired and processed in the 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 in the destination service unit (SLU).

[0118] More specifically, the securities backbone business back-end system 10 (see Figs. 1 and 2) of the present embodiment, which is an embodiment of the securities backbone business system of the present invention, may have a configuration as shown in Fig. 6. In Fig. 3, the service unit of the link source is designated by the symbol 20X or 40X for convenience of explanation, with the intention of not specifying which of the various reception service units 20 (20A, 20B, 20C, 20D, 20E, or a new reception service unit 20 newly established thereafter) or the various business service units 40 (40A, 40B, 40C, 40D, 40E, 40F, 40G, 40H, 40J, ..., or a new business service unit newly established thereafter) shown in Fig. 6, respectively (meaning that it may be either).

[0119] Similarly, the service unit to be linked is denoted by the symbol 40Y for convenience 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 thereafter) shown in Fig. 6 is linked to. 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 is linked to.

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

[0121] On the other hand, as shown in the lower part of Fig. 3, when there is a part with low processing performance and it is desired to avoid the influence of the low processing performance by performing distributed processing, the distributed processing can be performed in the service unit (SLU) in which the low processing performance is located. With the configuration as shown in the lower part of Fig. 3, even if transaction data is not transmitted in a distributed state from the cooperation source or further upstream service units, the distributed processing can be performed in the own unit 40Y to improve the processing speed. For example, in the case of two-way distributed processing, one processing route with a route process ID (RPID) = RPID1 is branched into two processing routes, RPID1 and 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 also merges into one processing route MQS (RPID1) again 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] In Fig. 4, the following distributed processing is performed inside the business service unit 40 (40Y). Hereinafter, for the processing within this unit 40 (40Y), the letter "Y" may not be added to the reference numeral due to space limitations, 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 a key and a 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 the transaction data is related to the 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 Fig. 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 that two pre-registration databases 65-1, 65-2 are provided.

[0126] Then, the distribution processing means 44 executes a process of distributing the transaction data received from the acquired linked data registration means 43 by the distribution number stored in the distribution management database 64, using the item (constructor setting value) that serves as the distribution key stored in the distribution management database 64. In Fig. 4, as an example, the distribution number = 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 because the distribution number is 2. In this case, even though the distribution is into two, the transaction data is not simply distributed alternately to the two pre-registration databases 65-1 and 65-2. Since the item set as the distribution key is the account number, the transaction data including 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. Note that the same applies when the distribution number is 3 or more, and the transaction data including the same account number is output to the same pre-registration database (any 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 judges which pre-registration database to output to, and returns the transaction data to the acquired linked data registration means 43 together with the judgment result information (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, 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 associated data acquisition means 42 acquires the transaction data from the associated data storage means 72X (TOPIC in this embodiment).

[0130] In the example of FIG. 5, the distributed processing means 44 attaches judgment result information indicating that the transaction data whose account number ends in an odd number should be output to the pre-registration database 65-1, and that the transaction data whose account number ends in an even number should be output to the pre-registration database 65-2, and returns the judgment result information to the acquired linked data registration means 43. At this time, the judgment 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 judgment result information alone may be returned. Note that the distribution conditions are not limited to the even or odd ending of the account number. For example, in the case of 3-way distribution, distribution may be performed according to the remainder when the ending is divided by 3, or distributed processing may be performed according to a distribution condition table (which may be described in a program constituting the distributed processing means 44, or may be stored by an external distribution condition table storage means).

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

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

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

[0134] The distributed processing means 44 automatically generates "001", "002" as the branches of the root process ID indicating the distributed processing route according to the number of distributions (in the example of FIG. 4, the number of distributions = 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, and automatically generates "ZS101D001001" which is the root process ID (RPID1) indicating the first processing route after distribution and "ZS101D001002" which is the root process ID (RPID2) indicating the second processing route after distribution by adding these branches to the end of the base distribution ID = "ZS101D001". Note that when the number of distributions is 3 or more, the branches "003", "004", ... are added to the base distribution ID, and the root process IDs (RPID3, RPID4, ...) indicating the third, fourth, ... processing routes after distribution are automatically generated. The route process IDs (RPID1, RPID2, . . . ) indicating these automatically generated post-distribution processing routes are common to the pre-registration data acquisition container (DPP infrastructure container) 45 portion and the business container (APP container) 49 portion.

[0135] Therefore, the 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 the 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. The distributed processing means 44 returns information indicating either the first or second processing route after distribution ("ZS101D001001" or "ZS101D001002") to the 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 infrastructure 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 both 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, a first processing means 49-1 and a second processing means 49-2 are provided in the business container (APP container) 49Y 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] Since the pre-registration data acquisition container (DPP-based container) 45Y and the business container (APP container) 49Y have lower processing performance than the associated data acquisition container (MQR-based container) 41Y and the associated data transmission container (MQS-based container) 52Y, the processing route is multiplexed (dual in this embodiment) only for these containers 45Y, 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. If it is determined that the transaction data relates 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). 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 a similar flow to that 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] At this time, since only one business database 61 and one post-registration database 66 are provided and 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) are merged here, the order in which transaction data containing the same account number is stored in the business database 61 and the post-registration database 66 maintains the processing order in the processing route (RPID1) before distribution, as shown in Fig. 5. That is, even if a speed difference occurs between the processing speed of the first processing route (RPID1) after distribution and the processing speed of the second processing route (RPID2) due to, for example, uneven distribution, and the order of registration of transaction data in the business database 61 and the post-registration database 66 does not maintain the processing order (acquisition order from the associated data storage means 72X) in the processing route (RPID1) before distribution, as shown in Fig. 5, transaction data including the same account number is processed in the same processing route, so the processing order is always maintained, and therefore no inconvenience is caused by the reversal of the registration order of transaction data including the same account number. For example, inconvenience is not caused by the registration of transaction data for a correction of an order before the registration of transaction data for a new order, or the registration of correction transaction data after the 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 stores the transaction data in the associated data storage means 72Y in a variable-length data format consisting of a combination of a key and a value (in this embodiment, JSON format).

[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-end system 10. The configurations shown in Fig. 1 and Fig. 2 above are detailed descriptions of the contents common to each of the service units 20, 40 shown in Fig. 6. Due to space limitations, Fig. 6 omits the reference characters for the reception means 22, reception database (reception DB) 31, data selection means 50, and business database (business DB) 61, but they are the same as Figs. 1 and 2.

[0145] In this invention (the claimed invention), the reason why the source and destination of the link are described as "service units" without specifying whether they are reception service unit 20 or business service unit 40 is because the data linkage method of the present invention is applicable to both data linkage from reception service unit 20 to business service unit 40, and data linkage from business service unit 40 to the subsequent business service unit 40. The reason why "database" is described without specifying whether it is reception database (reception DB) 31 or 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 system 10 is provided with reception service units (reception SLUs) 20, which include 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 in / out service unit 20A is equipped with a simple in / out API reception means (22A, although the symbol is omitted in the illustration) which is a reception means 22 that receives simple in / out data sent from the external system 100, and a reception database 31 (31A, although the symbol is omitted in the illustration) which stores the received simple in / out data.

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

[0150] The balance update reception / agreement service unit 20C is equipped with reception means 22 which receives domestic stock agreement data, investment trust agreement data, domestic bond agreement data, foreign stock agreement data (not shown), futures / OP (option) settlement data (not shown), foreign bond agreement data (not shown), foreign exchange agreement data (not shown), etc. transmitted from the external system 100, such as domestic stock agreement API reception means, investment trust agreement API reception means, domestic bond agreement API reception means (not shown), foreign stock agreement API reception means (not shown), futures / OP (option) agreement API reception means (not shown), foreign bond agreement API reception means (not shown), foreign exchange agreement API reception means (not shown), etc. (each reception means which can be assigned the symbol 22C), and a reception database 31 (31C, symbols omitted from illustration) which stores these 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 is equipped with a transfer deposit / withdrawal API reception means 22E (symbol omitted), which is a reception means 22 that receives transfer deposit / withdrawal data transmitted 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 links the reception layer and the business layer)

[0154] The securities back-end system 10 is also provided with data linking 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 keys and values. 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), there are business service units (business SLUs) 40, such as 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 linking container 70 upstream of its own unit 40A is transaction data related to the business processing responsible for its own unit 40A, 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 responsible for its own unit 40A 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 linking container 70 upstream of its own unit 40B is transaction data related to the business processing responsible for its own unit 40B, and a deemed securities detail database (61B, symbol omitted) which is a business database 61 that stores the transaction data after the business processing responsible for its own unit 40B 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 linking container 70 upstream of its own unit 40C is transaction data related to the business processing responsible for its own unit 40C, and an individual payment money details database (61C, symbol omitted) which is a business database 61 that stores the transaction data after the business processing responsible for its own unit 40C has been performed.

[0160] The transaction details management service unit 40D is provided with a transaction details database (61D, reference numerals not shown) which is a business database 61 that stores the transaction data after the business process for which the unit 40D is responsible has been performed. Note that, since the transaction details management service unit 40D is not provided with a data selection means 50, all of the linked data (transaction data) acquired from the data linking container 70 upstream of the unit 40D is transaction data related to the business process for which the 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 linking container 70 upstream of its own unit 40E is transaction data related to the business processing responsible for its own unit 40E, and a money details database (61E, symbol omitted) which is a business database 61 that stores the transaction data after the business processing responsible for its own unit 40E 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, looking mainly at the data linkage container 70, it is the business service units 40A, 40B, and 40D that monitor and acquire the linked 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 linkage container 70A.

[0164] Also, it is the business service units 40A and 40D that monitor and acquire the linked data (transaction data) stored in the data linkage 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 linkage 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 linkage container 70D. It is the business service units 40D and 40E that monitor and acquire the linked data (transaction data) stored in the data linkage container 70E.

[0165] On the other hand, looking mainly 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, 70C. Therefore, the linked data acquisition means 42 (see Figs. 1 and 2) of this Financial Instruments and Exchange Act customer securities balance management service unit 40A stores information regarding which data linkage container 70 its own unit 40A should monitor, and this information may be written in the program constituting 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 regarding which data linkage container 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 linking 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 linking 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 linking 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 linking 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, first-level data linkage containers 70A, 70B, 70C, 70D, and 70E that link the reception layer and the business layer) and its subsequent linked business service unit 40 (here, first-level 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 system 900 (see Figure 17) (however, there may be some parts where the relationship is partially one-to-one), but allows for a many-to-many, or one-to-many, or many-to-1 relationship. As described above, it is the relationship between the "linked data storage means" and the "linked service unit" in the present invention that 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 Fig. 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 / The second-level data integration container in the business layer)

[0169] Furthermore, the securities back-end system 10 is provided with data linking 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 (in this embodiment, JSON format) consisting of a combination of keys and values. 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), there are business service units (business SLUs) 40, such as an investment trust customer securities balance management service unit (SLU) 40F, a domestic bond customer securities balance management service unit (SLU) 40G, an advance payment management service unit (SLU) 40H, and a 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 responsible for its own unit 40F, and an investment trust customer securities balance and securities details database (61F, although the symbol is omitted in the illustration) which is a business database 61 that stores the transaction data after the business processing responsible for its own unit 40F 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 responsible for its own unit 40G, and a domestic bond customer securities balance and securities details database (61G, symbol omitted) which is a business database 61 that stores the transaction data after the business processing responsible for its own unit 40G 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 linking 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 the 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 linking container 70 upstream of its own unit 40J is transaction data related to the business processing for which its own unit 40J is responsible, and a margin / margin details database (61J, symbol omitted) which is a business database 61 that stores the transaction data after the business processing for which its own unit 40J is responsible 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, second-level data linkage containers 70F, 70G provided in the business layer) and its subsequent linked business service unit 40 (here, 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 as in the conventional securities core business back-end system 900 (see FIG. 17). Note that here too, many-to-many and many-to-one relationships are permitted, and some one-to-one relationships may be included.

[0178] In other words, 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 a data linking method using transaction attribute information, Fig. 7 shows an example of a specific configuration of the securities core business back-end system 10 shown in Fig. 6. In Fig. 7, due to space limitations, the detailed configuration of each service unit 20, 40 is omitted, but since these detailed configurations are the same as those shown in Fig. 1 and Fig. 2, the same names and symbols as those in Fig. 1 and Fig. 2 are used as appropriate for the explanation.

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

[0183] As shown in Fig. 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, and this domestic stock contract data includes a transaction code, which may be a (regular transaction) or b (margin spot settlement transaction). Note that b (margin spot settlement transaction) is a settlement in which a margin transaction is filled (closed) by spot delivery, and for example, when filling a short position in a margin transaction, the same securities are not purchased to fill the position, but rather the actual stocks held are used for repayment.

[0184] The reception data registration means 23 (see Figure 2) of the balance update reception / agreement service unit 20C stores domestic stock agreement data (trading data) in the reception database 31C, and uses information in the transaction attribute database 32 (see Figures 2 and 8) 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).

[0185] 7, when 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 the money update flag = "1" and the securities update flag = "1" in the transaction data as transaction attribute information and stores it in the post-registration database 33. On the other hand, when the transaction code included in the transaction data received from the external system 100 is b (credit spot settlement transaction), since the settlement is by spot delivery, the accepted data registration means 23 includes the money update flag = "0" and the securities update flag = "1" in the transaction data as transaction attribute information and stores it 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 associated data storage means 72 of the data association container 70C via the post-registration data acquisition means 26 and the associated data transmission means 27 (see Figure 2) in 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 in this way using the public API, it becomes possible to use this transaction code to determine 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 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 (the transaction data stored in the records constituting the table of the reception database 31C) includes 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., as well as record registration trace ID code (trace ID at the time of new registration issued by the balance update reception and contract service unit 20C), record registration transaction number, record update function ID code (own TX linking ID at the time of new registration of the balance update reception / contract service unit 20C), record registration function ID code (own function ID at the time of new registration of the balance update reception / contract service unit 20C), record update trace ID code (trace ID at the time of update issued by the balance update reception / contract service unit 20C), record update transaction ID code (own TX linking ID at the time of update of the balance update reception / contract service unit 20C), and record update function ID code (own function ID at the time of update of the balance update reception / contract service unit 20C).

[0190] Here, the six codes, 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 when domestic stock contract data (transaction data) is stored in the reception database 31C by the reception data registration means 23 (see FIG. 2) of the balance update reception / contract service unit 20C. These six codes are also added when the transaction data is stored in other reception databases 31 and the 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 updating (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 present in the record are maintained as is), and only the three codes related to record updating are changed.

[0193] Furthermore, as shown in FIG. 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, buying / selling category, delivery amount, contract quantity, contract unit price, contract amount, etc., as trace information, a trace ID (ID issued by the balance update reception / contract service unit 20C), a self TX linking ID (ID indicating the balance update reception / contract service unit 20C), a requester TX linking ID (however, since the requester is the external system 100, this ID does not exist. Enter 0.), a self function ID (ID indicating the function of the balance update reception / contract service unit 20C), a requester function ID (however, since the requester is the external system 100, this ID does not exist. Enter 0.), and as transaction attribute information, 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 with reference to FIGS. 10 to 16.

[0195] (Explanation of the latter 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 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 70C (TOPIC), and executes data selection processing with the data selection means 50A. At this time, the data selection means 50A judges that, among the acquired transaction data, the transaction data with the securities update flag set to "1" is the target of the business processing of its own unit 40A.

[0197] Then, the transaction data after the transaction processing is performed 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 stores the transaction data after the business process in the post-registration database 66. At this time, the transaction data still contains the money update flag and the securities update flag that were included in the transaction data acquired from the linked data storage means 72 of the data linkage container 70C. The money update flag and the securities update flag may be temporarily cancelled by the business data registration means 51 and 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 linked data storage means 72 of the data linkage container 70F via the post-registration data acquisition means 53 and the linked data transmission means 54 in the service unit (see FIG. 2).

[0199] (Explanation of the latter half of FIG. 7 / Balance update reception / 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 a 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 contained 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 post-registration database 33.

[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 linking 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 linking 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 FIG. 7 / Balance update reception / 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 contained in the transaction data received from the external system 100 is d (deposit transfer), as shown in FIG. 7, the received 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 linking 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 linking container 70E stores transaction data including a transaction code of d (deposit transfer) and a money update flag of 1.

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

[0210] In the Financial Instruments and Exchange Act customer money 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 linking containers 70C, 70D, and 70E (each TOPIC), and executes data selection processing with the data selection means 50E. At this time, the data selection means 50E judges that, among the acquired transaction data, the transaction data with the money update flag set to "1" is the target of business processing for its own unit 40E.

[0211] Then, the business data registration means 51 (see FIG. 2) stores the transaction data after the business processing in the money 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 money details database 61E is either a (normal transaction), c (simple deposit / withdrawal), or d (security deposit transfer). If the transaction code is b (credit spot settlement transaction), the balance update reception / contract service unit 20C adds a money update flag = "0" to the transaction data as transaction attribute information, and the transaction data including the money update flag = "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 money 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 money details database 61E.

[0212] In addition, the business data registration means 51 stores the transaction data after the business process in the post-registration database 66. At this time, the transaction data still contains the money update flag and the securities update flag contained in the transaction data acquired from each of the linked data storage means 72 of the data linkage containers 70C, 70D, and 70E. The money update flag and the securities update flag may be temporarily cancelled 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 contains a security deposit / margin type classification = "01 (credit)", the security deposit / margin type classification = "01 (credit)" is also included in the transaction data to be stored in the post-registration database 66. 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 70G via the post-registration data acquisition means 53 and the associated 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 any one of the transaction codes a (normal transaction), c (simple deposit / withdrawal), and d (security deposit transfer). As shown in FIG. 9, some transaction data includes transaction data=d (security deposit transfer) and security deposit / margin type classification="01 (credit)". Note that the security deposit / margin type classification is information specified by the external system 100 and corresponds to the "transaction attribute classification" in the present invention, and as shown in FIG. 9, there are, for example, 01 (credit), 02 (issue date settlement), 03 (futures / options), 04 (over-the-counter FX), 05 (market FX), etc. If these 01 (credit), 02 (issue date settlement), etc. are individually divided and flagged, they will correspond to the "transaction attribute flag" in the present invention.

[0214] (Explanation of the latter 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 judges that, among the acquired transaction data, all transaction data with a money update flag set to "1", i.e., all transaction data related to money registration, is to be subject to business processing by its own unit 40H.

[0216] Then, the business data registration means 51 (see FIG. 2) stores the transaction data after the business processing in the advance payment 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 advance payment balance database 61H is either a (ordinary transaction), c (simple deposit / withdrawal), or d (security deposit transfer). Note that, as mentioned above, transaction data with transaction code b (credit 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, and also does not have a subsequent data linkage container 70, output processing to the database 66 after registration by the business data registration means 51 is not performed.

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

[0219] In the security deposit / 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 by the data selection means 50J. At this time, the data selection means 50J judges that, among the acquired transaction data, data that has information on security deposit / 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] Furthermore, since the margin / margin balance management service unit 40J does not have a subsequent business service unit 40, nor is there 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] <Trace of the series of processes executed in data integration: Figures 10 to 16>

[0223] (Explanation of Figure 10)

[0224] Fig. 10 shows a recording format of trace information for tracing the contents 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 described above, but are symbols given 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 between 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 for identifying the transaction processing function of the requester that has made the transition to the transaction processing related to the above-mentioned own function ID.

[0229] The self-TX linking 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 linking ID identifies the transaction process, the self-TX linking ID will be different if the process has the same content but is executed at different times. For example, if the same process is executed multiple times in a day, the self-function ID will not change, but the self-TX linking ID will be different each time.

[0230] The request source TX linking ID is an ID that is assigned when a transaction process related to the above-mentioned 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 the same process content if the time period is different. For example, if the same process content is executed multiple times in a day, the request source function ID will not change, but the request source TX linking ID will be different each time.

[0231] (Description 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 an 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) for storing (2) insert information when the reception data registration means 23 stores the received transaction data in the reception database 31. The log data of the (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) to be stored as linked data in the linked data storage means 72M by the reception data registration means 23. This log data of (3) subsequent linkage information is saved as a subsequent linkage information log file.

[0235] The log data of the input / 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 linking ID (reception service unit 20), requester TX linking 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 a log data storage means 80 (not shown) for storing 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 a log data storage means 80 (not shown) for storing 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. The log data of the (1A) and (1B) input message information in these two places is saved as an input message information log file.

[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 the transaction data after business processing in the business database 61U. The log data of the (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 linkage information when the transaction data after business processing is output to the post-registration database 66 (see FIG. 2) by the business data registration means 51U to be stored as linked data in the linked data storage means 72N. This log data of (3) subsequent linkage information is saved as a subsequent linkage information log file.

[0240] Among the log data of the input / output of each part in 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, own TX linking ID (business service unit 40U), requester TX linking ID (reception service unit 20), own function ID (business service unit 40U), and requester function ID (reception service unit 20).

[0241] On the other hand, the log data of (1B) input message information, and the log data of (2) insert information and (3) subsequent linkage information at the time of receiving a registration API request by the business data registration means 51U include 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, the processing has been transferred 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 captured and 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 a log data storage means 80 (not shown) for storing 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 a log data storage means 80 (not shown) for storing 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 the (1A) and (1B) input message information in these two places 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 the transaction data after business processing in the business database 61V. The log data of the (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 linkage data storage means 72, (3) a log data storage means 80 for storing log data of subsequent linkage information is not provided.

[0246] Among the log data of the input and output of each part in 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 at the time of receiving a data selection API request by the data selection means 50V includes trace ID, own TX linking ID (business service unit 40V), requester TX linking ID (business service unit 40U), own function ID (business service unit 40V), and requester function ID (business service unit 40U) as trace information. 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 (1B) log data of input message information and (2) log data of insert information when the business data registration means 51V receives a registration API request include a trace ID, a self TX linking ID (business service unit 40V), a requester TX linking ID (business service unit 40V), a self function ID (business service unit 40V), and a requester function ID (business service unit 40V). Therefore, since all trace information is information related to the business service unit 40V, the processing has been transferred from the self unit to the self unit within the business service unit 40V. This is because the self function, the requester 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 the trace information shown in Figure 10 above, and shows the recording format of the trace information in the balance update reception / settlement service unit 20C, which is the reception service unit 20, as well as the recording format of the 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 detail 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 input message information including trace information, the insert information, and the subsequent linkage information, as well as the log files storing these log data, are denoted by the same reference numerals (1-1), (1-2), (1-3), etc., without any particular distinction between them. Each log data (input message information, insert information, and 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 a non-volatile memory, and further collected by log data collection means 82, and accumulated and saved in collected log database 84 (see Figs. 1 and 2).

[0252] (Explanation of Fig. 11 and Fig. 12 / Balance update reception and contract service unit 20C)

[0253] As shown in Fig. 11, the balance update reception and contract service unit 20C stores (records in a log file) in a log data storage means 80 (not shown) log data of (1-1) input message information when the domestic stock contract API reception means 22C receives the trading data (domestic stock contract data) transmitted from the external system 100 (consumer), log data of (1-2) insert information when the reception data registration means 23C stores the trading data in the reception database 31C, and log data of (1-3) subsequent linkage information when the reception data registration means 23 outputs the trading data to the post-registration database 33C to store it in the linkage data storage means 72C. These log data are collected by a log data collection means 82 and are 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. Search conditions include, for example, date, 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 FIG. 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 the screen 8611. The (1-1) input message information displayed on this screen 8611 includes a trace ID=UK2015011XXXXXXXXXXXXXXXX. This trace ID is an ID given by the balance update reception and contract service unit 20C (UK201), so it begins with an ID indicating the function of the unit 20C, "UK2015011", followed by an automatically given complex character and symbol string XXXX.... Note that the number of digits in XXXX... in FIG. 12 is written to convey the image of a long and complex character and symbol string, and is not the actual number of digits, and the same is true for the following YYYY..., ZZZZ..., etc.

[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 Fig. 12 (1-2), 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 in Fig. 12 (1-1) described above.

[0258] Also, the (1-2) insert information displayed on screen 8612 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 = YYYYYYYYYYYYYYYYYYYY and requestor 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 described 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 = UK2015011XXXXXXXXXXXXX, 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] In addition, since this is a case of newly registered transaction data, the same data is stored in the record registration transaction ID code and the 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 the record update function ID code, both of which are the same data as the own function ID.

[0263] In (1-3) of Fig. 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 screen 8611 of (1-1) and screen 8612 of (1-2) of Fig. 12 described above.

[0264] Also, the (1-3) subsequent linkage information 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 = YYYYYYYYYYYYYYYYYYYY 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 Fig. 11 and Fig. 13 / Financial Instruments and Exchange Act Customer Securities Balance Management Service Unit 40A)

[0266] As shown in Fig. 11, in the Financial Instruments and Exchange Act customer securities balance management service unit 40A, the following log data are stored (recorded in a log file) in a log data storage means 80 (not shown): (2-1A) log data of input message information 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) log data of input message information when the business data registration means 51A receives a registration API request transmitted from the registration API calling means 48A; (2-2) log data of insert information when the business data registration means 51A stores the transaction data in the securities statement database 61A, which is a business database; and (2-3) log data of subsequent linkage information when the business data registration means 51A outputs the transaction data to the post-registration database 66A to store it in the linkage data storage means 72F. These log data are collected by a log data collection means 82 and are 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 associated balance update reception and settlement service unit 20C is UK201.

[0268] In FIG. 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 (2-1A) input message information displayed on the screen 8621A 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.

[0270] Also, the (2-1A) input message information displayed on screen 8621A includes own function ID = ZS1025071 (FIEA customer securities balance data selection / contract) and requester function ID = UK2015011 (balance update registration acceptance / contract). Furthermore, own TX linking ID = PPPPPPPPPPPPPPPPPPPPPP and requester TX linking ID = QQQQQQQQQQQQQQQQQQQQ. Therefore, for myself, the information is about 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 the screen 8621B also contains the same trace ID = UK2015011XXXXXXXXXXXXXXXX as the (2-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.

[0272] In addition, 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). In addition, the self TX linking ID = RRRRRRRRRRRRRRRRRRRRRR and the requester TX linking ID = PPPPPPPPPPPPPPPPPPPP. Therefore, within the FIEA customer securities balance management service unit 40A (ZS102), the processing has shifted from self unit to self unit, but this is because it is trace information on an API basis. For this reason, the requester function ID on screen 8621B is the same as the self function ID on screen 8621A, and both are ZS1025071 (FIEA customer securities balance data selection and contract). In addition, the request source TX linking ID in screen 8621B is the same as the own TX linking ID in screen 8621A, and both are PPPPPPPPPPPPPPPPPPPP.

[0273] In (2-2) of Fig. 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 a 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 Fig. 13 described above.

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

[0275] In the (2-2) insert information displayed on screen 8622, the contents of the transaction data stored in the securities detail database 61A, which is the business database, are included in the 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] In addition, since this is a case of newly registered transaction data, the same data is stored in the record registration transaction ID code and the 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 the record update function ID code, both of which are the same data as the own function ID.

[0279] In (2-3) of Fig. 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 a screen 8623. The (2-3) subsequent linkage information displayed on this screen 8623 includes a trace ID = UK2015011XXXXXXXXXXXXXXXX. This trace ID is the same as that displayed on screens 8621A and 8621B of (2-1A) and (2-1B) of Fig. 13 described above and screen 8622 of (2-2).

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

[0281] (Description of Figs. 11 and 14 / Transaction statement management service unit 40D)

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

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

[0284] 14, 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 transaction details management service unit 40D is GK108, and the identification information of the balance update reception and contract service unit 20C with which it is linked 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 own function ID = GK1085061 (transaction details registration (internally generated details registration)) and requester function ID = UK2015011 (balance update registration acceptance and contract). Furthermore, own TX linking ID = SSSSSSSSSSSSSSSSSSSS and requester TX linking ID = YYYYYYYYYYYYYYYYYYYYY. Therefore, for itself, the information is about the transaction details management service unit 40D (GK108), and for the requester, the information is about the linked balance update acceptance and contract service unit 20C (UK201).

[0287] In Fig. 14 (3-2), the insert information to the transaction statement management service unit 40D, i.e., the information recorded in the insert information log file (3-2), is displayed on a 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 the screen 8631 of Fig. 14 (3-1) described above.

[0288] Additionally, the (3-2) insert information displayed on screen 8632 includes Own Function ID = GK1085061 (Transaction Detail Registration (Internal Generation Detail Registration)) and Requester Function ID = UK2015011 (Balance Update Registration Acceptance / Contract). Additionally, Own TX Linking ID = SSSSSSSSSSSSSSSSSSSSSS and Requester TX Linking ID = YYYYYYYYYYYYYYYYYYYY. These Own Function ID, Requester Function ID, Own TX Linking ID, and Requester TX Linking ID are the same as the respective IDs displayed on screen 8631 above.

[0289] In the (3-2) insert information displayed on screen 8632, the contents of the transaction data stored in the transaction details database 61D, which is the business database, are included in the parentheses following "VALUES", and the data following "VALUES" includes record registration trace ID code = UK2015011XXXXXXXXXXXXXXXX, record registration transaction ID code = SSSSSSSSSSSSSSSSSSS, record registration function ID code = GK1085061, record update trace ID code = UK2015011XXXXXXXXXXXXXXX, record update transaction ID code = SSSSSSSSSSSSSSSSSSSS, 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] In addition, since this is a case of newly registered transaction data, the same data is stored in the record registration transaction ID code and the 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 the record update function ID code, both of which are the same data as the own function ID.

[0293] (Explanation of Figure 11 and Figure 15 / Reference Function Customer Securities Service Unit 40K)

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

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

[0296] As shown in Fig. 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 the Financial Instruments and Exchange Act customer securities balance management service unit 40A with which it is linked 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 (4-1A) input message information displayed on the screen 8641A includes a trace ID = UK2015011XXXXXXXXXXXXXXX. This trace ID is an ID 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 own function ID = ZS3015011 (reference function customer securities balance data selection / Financial Instruments and Exchange Act customer securities details) and requester function ID = ZS1025051 (Financial Instruments and Exchange Act customer securities balance registration). Furthermore, own TX linking ID = TTTTTTTTTTTTTTTTTTTT and requester TX linking ID = RRRRRRRRRRRRRRRRRRRRRR. Therefore, for itself, 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 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] In addition, the input message information (4-1B) displayed on the screen 8641B includes the self function ID = ZS3015021 (reference function: customer securities statement registration) and the requester function ID = ZS3015011 (reference function: customer securities balance data selection, Financial Instruments and Exchange Act customer securities statement). In addition, the self TX linking ID = UUUUUUUUUUUUUUUUUUUU and the requester TX linking ID = TTTTTTTTTTTTTTTTTTTT. Therefore, in the reference function customer securities service unit 40K (ZS301), the processing has shifted from the self unit to the self unit, but this is because it is trace information on an API basis. Therefore, the requester function ID on the screen 8641B is the same as the self function ID on the 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 TTTTTTTTTTTTTTTTTTTT.

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

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

[0304] In the (4-2) insert information displayed on screen 8642, the contents of the transaction data stored in the investment trust customer securities balance and securities detail database 61K, which is the business database, are included in the parentheses below "VALUES," and the data below "VALUES" includes record registration trace ID code = UK2015011XXXXXXXXXXXXXXXX, record registration transaction ID code = UUUUUUUUUUUUUUUUUUU, record registration function ID code = ZS3015021, record update trace ID code = UK2015011XXXXXXXXXXXXX, record update transaction ID code = UUUUUUUUUUUUUUUUUUUU, 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] In addition, since this is a case of newly registered transaction data, the same data is stored in the record registration transaction ID code and the 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 the 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 a log data storage means 80 (not shown) log data of (5-1) input message information when the data selection means 50G receives a data selection API request transmitted from the data selection API calling means 47 (see Fig. 2), log data of input message information when the business data registration means 51G receives a registration API request transmitted from the registration API calling means 48K (see Fig. 2) (however, not shown in Fig. 16), and log data of (5-2) insert information when the business data registration means 51G stores transaction data in the domestic bond customer securities balance and securities details database 61G, which is a business database. These log data are collected by a log data collection means 82 and are accumulated and stored in a collection log database 84 (see Figs. 1 and 2).

[0310] Incidentally, 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, so 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, so there is no log data of input message information when the business data registration means 51G receives a registration API request, and no registration processing is performed in the domestic bond customer securities balance and securities detail database 61G, so there is no log data of (5-2) insert information.

[0311] As shown in Fig. 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), which is a further cooperating source.

[0313] Also, 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 requester function ID = ZS1025051 (FIEA customer securities balance registration). Furthermore, self TX linking ID = VVVVVVVVVVVVVVVVVVVV and requester TX linking ID = RRRRRRRRRRRRRRRRRRRR. Therefore, for myself, the information is about domestic bond customer securities balance management service unit 40G (ZS110), and for the requester, the information is about FIEA customer securities balance management service unit 40A (ZS102).

[0314] <Effects of this embodiment>

[0315] According to this embodiment, the following effects are obtained. That is, in the securities core business back-end system 10, the service unit of the link 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 link destination (the business service unit 40) acquires the transaction data stored in the linked data storage means 72, and executes a data selection process by the data selection means 50, using the transaction attribute information included in the acquired transaction data, to determine whether the acquired transaction data is transaction data for which the unit (the linked business service unit 40) is responsible for the business process.

[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] As a result, when providing a new service (when a new service unit 40 is added as a partner) or when changing the content of an existing service (when the content of the business process of the existing service unit 40 as a partner changes), there is no need to change the design of the service units 20 and 40 as the partner, so the effort and time required for system change work can be reduced. This makes it possible to realize a new platform infrastructure that takes into account future sales expansion and scalability, and improves the maintainability of the system. Thus, by realizing such loose coupling, it is possible to solve the problems associated with the complication and enlargement of the system that occurred in the case of a monolithic system such as the conventional securities back-end system 900 shown in FIG. 17, that is, when the service units 20 and 40 as the partner were tightly coupled with the service unit 40 as the partner.

[0318] Furthermore, the transaction attribute information included in the transaction data output from the service units 20 and 40 of the linking origin to the linking data storage means 72 is transaction attribute information about the transaction data to be sent to the service unit 40 of the linking destination, but is not intended for a specific service unit 40 of the linking destination, but merely describes the contents of the linked data (attributes of the transaction data) output by the service units 20 and 40 of the linking origin so that it can be used in data selection processing at unspecified service units 40 of the linking destination (including service units 40 that will be additionally installed in the future and service units 40 whose processing contents 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 contents of the business processing performed by the service unit 40 of the linking destination, but merely conveys the contents of the linked data (attributes of the transaction data) output by the service units 20 and 40 of the linking origin to the unspecified service unit 40 of the linking destination that will acquire 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 which obtains transaction data therefrom can be a many-to-many relationship as shown in Figure 6, and all of the one-to-many, many-to-one, and one-to-one relationships can be permitted.

[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 a key and a value, 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 (number of items, contents of each item, order of each item, etc.) of the linked service units 20, 40. That is, the linked service unit 40 can recognize at what position in the transaction data acquired from the linked data storage means 72 the transaction attribute information exists, or at what position what item of data exists. Therefore, the linked service unit 40 can execute the data selection process by the data selection means 50 even if the output format (number of items, contents of each item, order of each item, etc.) defined by the linked service unit 20, 40 is unknown.

[0320] In the securities core business back system 10, the money update flag and / or securities update flag added by the cooperating reception service unit 20 is used to execute data selection processing by the data selection means 50 in the cooperating business service unit 40 (see FIG. 7), so that a securities core business system of a loosely coupled data linkage type can be realized by transaction attribute information suitable for the securities core business, namely, the money update flag and / or securities update flag. Also, since the money update flag and / or securities update flag added by the cooperating 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 a transaction code is included in the transaction data transmitted from the external system 100, the coordinating reception service unit 20 can use this transaction code to determine a money update flag and / or a securities update flag to be added to the transaction data as coordinating data to be output to the coordinating 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, distributed processing can be performed 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 a portion with high processing performance and a portion with low processing performance, the overall processing speed of the business service unit 40 can be improved by applying distributed processing to the portion with low processing performance.

[0323] Furthermore, when performing distributed processing, the distributed processing means 44 does not simply distribute to multiple processing routes, but distributes transaction data having the same data in an item set as a distribution key (in this embodiment, an account number as an example) in a state in which the processing order of the transaction data before distribution is maintained, as shown in Fig. 5. This makes it possible to avoid inconvenience caused by reversing the processing order for transaction data having the same data in an item set as a distribution key.

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

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

[0326] In addition, the securities back-end business system 10 includes a trace information display means 86 (see Figs. 1 and 2), and can display trace information of a series of business processes executed by data linkage on a screen (see Figs. 10 to 16). This allows users such as employees of a securities company to check and track the contents of each business process executed by data linkage between the multiple service units 20 and 40 on a screen, improving traceability and visibility. This allows quick identification of which function of which service unit 20 or 40 issued the trace information, making it possible to compensate for the shortcomings of microservices in general, and thus making it suitable for use in mission-critical securities back-end business systems that do not permit failures or malfunctions, thereby realizing high maintainability. For example, users of this system can quickly investigate the extent of the impact of a system failure when it 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 this is not limited thereto 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 α, β, γ are sent to a first processing route, stocks δ, ε, ζ are sent to a second processing route, and stocks η, θ, σ 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 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, 40 is configured by a container, but this is not limited to this, and each of the service units may be configured by a normal server integrated with hardware. [Industrial Applicability]

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

[0333] 10. Securities Core Business Back-End Systems that Comprise 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 is a processing means after dispersion 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 clients' securities, A plurality of service units that execute business processing related to the transaction data through data linkage; a linkage 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 linkage data for data linkage between the plurality of service units; The service unit as a cooperation source is The transaction data after the transaction processing in charge of the unit is performed is stored in a database provided in the unit, The transaction attribute information for the transaction data to be transmitted to the associated service unit includes a money update flag added by the associated 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 category of the transaction data specified by an external system, and the data for each item constituting the transaction data is stored in the associated 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 to determine whether the acquired transaction data is transaction data for which the transaction processing in charge of the own unit is to be performed, using the transaction attribute information included in the acquired transaction data; When it is determined that the transaction data is to be processed by the unit, the transaction data after the processing is performed is stored in a database provided in the unit. A securities core business system characterized by:

2. Among the plurality of service units, The service unit as the link source includes a 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 the own unit, and The service unit to which the service 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 that should be subjected to the business process handled by the service unit itself, using the money update flag and / or the securities update flag that are included in the acquired transaction data and that are added by the service unit from which the service unit is linked.

2. The securities core 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 service unit is linked include a subsequent business service unit of the reception service unit; The reception service unit includes: storing the transaction data received from the external system 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 the 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, including the added money update flag and / or the securities update flag.

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

4. The service unit of the cooperation destination is a distribution management database that stores a distribution number for distributing the transaction data acquired from the linked data storage means within its own unit, an item that is a distribution key, and a distribution ID that indicates a base of a root process ID after distribution within its own unit, in association with a root process ID before distribution within its own unit; a distribution processing means for distributing the transaction data acquired from the linked data storage means according to the distribution number using information stored in the distribution management database, with respect to 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 root process ID after distribution by adding identification information of a branch part determined for each route after distribution according to the distribution number to the distribution ID; In order to process the transaction data distributed by the distributed processing means in separate routes, post-distribution processing means are provided in the own unit in a number equal to the number of distributions in correspondence with 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 transferred among a series of processes executed in cooperation between the plurality of service units; a function ID for identifying a function of each transaction processing executed by each of the service units; a requester function ID for identifying the function of the transaction processing of the requester that has made the transition to the transaction processing related to the own 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 is included, 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