JP2019121220A - Information processing device, audit support method, and computer program - Google Patents

Abstract

To improve the traceability of property to be a transaction object.SOLUTION: A transaction data storage device 106 stores transaction data including double entry bookkeeping data showing property transfer and compensation acquisition by using exchange algebra as transaction description of a first entity side, and double entry bookkeeping data showing property acquisition and compensation transfer by using exchange algebra as transaction description of a second entity side in association with a property ID in the case that the first entity sells the property to the second entity. A transaction management device 108 receives an audit request designating ID of certain property, and acquires a plurality of transaction data associated with the ID from the transaction data storage device 106. The transaction management device 108 generates property transaction chain data being data obtained by projecting elements about the property transaction from the sum of the plurality of transaction data, and generates data for supporting an audit about the transaction of the property identified by the ID designated with the audit request on the basis of the property transaction chain data.SELECTED DRAWING: Figure 9

Description

  The present invention relates to data processing technology, and more particularly to an information processing apparatus, an audit support method, and a computer program.

  The inventor has proposed a method of recording real transactions by applying exchange algebra (see, for example, Patent Document 1).

International Publication No. 2017/077920

  In many fields including food, interest in product safety and consumer choice has increased, and product traceability has been attracting attention. The present inventor thought that the traceability of the goods to be traded can be improved by recording real transactions using exchange algebra.

  The present invention has been made based on the above-described idea of the inventor, and one object is to improve the traceability of goods to be traded.

  In order to solve the above problems, an information processing apparatus according to an aspect of the present invention transfers goods as a transaction description on the side of the first entity and pays the goods when the goods are sold from the first entity to the second entity. Transaction data including double-entry bookkeeping data that indicates the acquisition of L using exchange algebra, and double-entry book data that indicates the acquisition of goods and transfer of consideration using exchange algebra as the transaction description of the second entity, An audit request receiving unit that can access a storage unit that stores in association with an ID and that receives an audit request specifying an ID of a certain item, and a plurality of transaction data items associated with the ID specified in the audit request Data that generates goods transaction chain data, which is data obtained by projecting elements related to goods transactions, from the sum, and based on the goods transaction chain data, data that supports audit on goods transactions identified by the ID specified in the audit request Audit to generate And, equipped with a.

  Another aspect of the present invention is an audit support method. In this method, when goods are sold from the first entity to the second entity, double-entry bookkeeping data indicating the transfer of goods and the acquisition of compensation using exchange algebra as a transaction description on the first entity side, and A computer capable of accessing a storage device which stores transaction data including transaction data including acquisition of goods and transfer of consideration using exchange algebra as transaction descriptions of two entities in association with the ID of the goods A step of accepting an audit request specifying an ID of a good, and a commodity transaction chain which is data obtained by projecting an element related to a transaction of a good from the sum of a plurality of transaction data associated with the ID designated in the audit request Generating data, and based on the goods transaction chain data, generating data to support an audit related to the trade of the good identified by the ID specified in the audit request.

  Note that any combination of the above-described components, and one obtained by converting the expression of the present invention between a system, a program, a recording medium storing the program, and the like are also effective as an aspect of the present invention.

  According to the present invention, the traceability of goods to be traded can be improved.

It is a figure showing an example of a sales slip. FIG. 18 is a block diagram showing a functional configuration of a data editing device of Prerequisite Technique 2. It is a figure which shows an example of the user code for operating accounting type data. It is a figure which shows the execution code corresponding to the user code of FIG. It is a figure which shows the execution code corresponding to the user code of FIG. It is a figure which shows an example of the user code for operating record type | mold data. It is a figure which shows the execution code corresponding to the user code of FIG. It is a figure which shows the execution code corresponding to the user code of FIG. It is a flowchart which shows operation | movement of a data editing apparatus. 8 (a) and 8 (b) are diagrams showing transaction descriptions by price display. 9 (a) and 9 (b) are diagrams showing transaction descriptions using actual bookkeeping. It is a figure which shows the structure of the transaction management system of an Example. It is a block diagram which shows the function structure of the trader apparatus of FIG. FIG. 6 is a diagram showing an example of a transaction data container. FIG. 6 is a diagram showing an example of a transaction hash container. It is a block diagram which shows the function structure of the transaction management apparatus of FIG. FIG. 6 is a diagram showing an example of a transaction data container. FIG. 6 is a diagram showing an example of a transaction hash container. It is a figure showing an example of a transaction route map. It is a figure which shows the example of the transaction by which goods are divided | segmented in a distribution process. It is a figure which shows the example of the transaction in which a new good is produced in a distribution process.

(Prerequisite technology 1)
Before describing the configuration of the embodiment of the present invention, the exchange algebra on which the present embodiment is based will be described.

The inventor considered that eight to ninety percent of data in an organization such as a company can be represented by the two data structures shown below.
1. Multi-class type (hereinafter also referred to as "accounting type data")
A combination of data values and data attributes (hereinafter also referred to as “base”), numerical values are used as data values, and names, units, times, subjects are used as data attributes. For example, it is expressed as 40 <cash, yen> +30 <tanger, individual>.
2. Multi-class mixed type (hereinafter also referred to as "record type data")
It is a combination of data values and bases, and numbers and non-numeric literals are used for data values and bases. For example, it is expressed as 55 <age> + Taro Yamada <name> + Tsugaru <favorite fruit>.
The following mainly describes the accounting data in detail.

The accounting type data collectively represents numerical data given for each classified item, and belongs to an algebraic system (hereinafter also referred to as "exchange algebra") for performing an operation thereon. It can be said that it is exchange algebra data. The basis (that is, classification item) in accounting type data consists of <name, unit, time, subject> and four items. Data is expressed as a combination of values for one or more bases, in other words, a sum of values for one or more bases.
Example 1: x = 200 <apple, circle, #, #> + 400 <sample, circle, #, #>
Example 2: y = 200 <apple, yen, first quarter of 2006, #> + 400 <apple, yen, second quarter of 2006, #> + 720 <apple, yen, third quarter of 2006, #>
In Example 1 above, time and subject are omitted, and in Example 2 the subject is omitted. In Example 2, it can be said that time-series data is represented. Further, identification information of an organization such as a company name may be set as a base subject.

  The merits of representation by exchange algebra are that data can be represented using various bases (classifications), and that bases can be represented by characters that can be easily interpreted by humans rather than program code. Furthermore, as will be described later, unified data editing by transfer operation becomes possible.

In the exchange algebra of the base technology, the symbol ^ (hat) is used instead of a negative number. For example, x = 20 ^ <apple, #, #, #> indicates that the number of apples is reduced by 20. In other words, ^ indicates a base that means the opposite item to be offset for a certain item. Also, "-(bar)" is introduced as an operator (operator) representing the cancellation operation. An example is shown below.
x1 = 30 <cash> +20 <apple> +50 <debt>
y1 = ^ x1 = 30 ^ <cash> + 20 ^ <apple> + 50 ^ <debt>
~ (Y1 + x 1) = (30 ^ <cash> + 20 ^ <apple> + 50 ^ <debt>) + (30 <cash> + 20 <apple> + 50 <debt>) = 0

  Next, transfer operation by exchange algebra will be described. In bookkeeping, there is an operation called transfer. This can be said to be a sort of reclassification (basis transformation) operation. Here, an example is shown in which the sales slip of the grocery store shown in (a) of FIG. 1 is transferred to the sales slip shown in (b) of FIG.

The transactions shown in (a) and (b) of FIG. 1 can be expressed as follows in a circle.
x1 = 200 <Cash, Yen> + 100 ^ <Apple, Yen> +100 <Profit, Yen>
x2 = 50 <utility fee, yen> + 50 ^ <cash, yen>
x3 = 100 ^ <Profit, Yen> +100 <Operating revenue, Yen>
x4 = 50 ^ <operating revenue, yen> + 50 ^ <heat expenses, yen>
y = x 1 + x 2 + x 3 + x 4 = (200 <cash, yen> + 100 ^ <apple, yen> + 100 <profit, yen>) + (50 <utility cost, yen> + 50 ^ <cash, yen>) + (100 ^ <profit, yen > + 100 <Operating revenue, Yen> + (50 ^ <Operating revenue, Yen> + 50 ^ <Utility expenses, Yen>)
~ Y = 150 <cash, yen> + 100 ^ <apple, yen> + 50 <operating revenue, yen>

Next, aggregation (merger) regarded as a transfer operation and distribution will be described.
1. Aggregation Suppose that there were 300 yen Tsugaru, 200 yen Fuji and 100 yen red ball (all are one variety of apple). This is expressed as x = 300 <Tsugaru, circle> +200 <Fuji, circle> +100 <red ball, circle>. The operation of grouping and classifying this Tsugaru-Fuji-Kohidama as "apple" is also a kind of transfer, and is called aggregation. In addition, it is necessary to be given the map of correspondence of {Tsugaru, Fuji, red ball}-> {apple} as a premise.

  In this example, F (x) = 300 ^ <Tsugaru, circle> + 200 ^ <Fuji, circle> + 100 ^ <red ball, circle> +300 <apple, circle> +200 <apple, circle> according to the map of the above correspondence. Generate an element of +100 <apple, circle>. The value of the base <apple> is a value for each of the base <Tsugaru>, <Fuji>, and <red ball> to be consolidated. In other words, the total value of the values for each of the base <Tsugaru>, <Fuji>, and <red ball> to be consolidated is calculated as the value of the base <apple>.

  The transfer G (x) representing the aggregation is given by ̃ {x + F (x)} using F (x). That is, G (x) = 〜 {x + F (x)} = (300 <Tsugaru, yen> +200 <Fuji, circle> +100 <red ball, circle>) + (300 ^ <Tsugaru, circle> + 200 ^ <Fuji, circle > + 100 ^ <red ball, circle> +300 <apple, circle> +200 <apple, circle> +100 <apple, circle>) = 600 <apple, circle>.

2. Proportional division is the division of one classification item into more detailed classification items. For example, in the example shown in the aggregation, it means that the value corresponding to the base <apple> is divided into Tsugaru-Fuji-red ball. As a premise, it is necessary to give a division ratio of {apple}-> {Tsugaru, Fuji, red ball}, and in this case, it is 1: 1: 1.

In this example, F (x) = 600 ^ <apple, circle> +200 <Tsugaru, circle> +200 <Fuji, circle> +200 <red ball, according to the distribution ratio described above, for x = 600 <apple, circle> Generate an element of circle>.
The transfer G (x), which represents the division, is given by ~ {x + F (x)} using F (x). That is, G (x) = 〜 {x + F (x)} = 600 <apple, circle> + (600 ^ <apple, circle> +200 <Tsugaru, circle> +200 <Fuji, circle> +200 <red ball, circle>) = 200 <Tsugaru, circle> + 200 <Fuji, circle> + 200 <red ball, circle>.

(Required technology 2)
Hereinafter, an information processing apparatus (hereinafter, referred to as “data editing apparatus”) that executes data editing processing using the concept of the exchange algebra of the base technology 1 will be described. In Prerequisite Technique 2, the user describes the content of editing data using an inclusive notation, which is a method of describing a set by giving necessary and sufficient conditions for an object to belong to the set. The data editing apparatus of the base technology 2 outputs the program code described in the extensional notation, which is a method of describing the set by enumerating all the elements of the set based on the edited content described by the intensional notation. . Then, the data to be edited is read into the memory as a data object in a format corresponding to the exchange algebra, and the above program code is executed to execute data editing processing.

  FIG. 2 is a block diagram showing a functional configuration of the data editing device 10 of the prerequisite technology 2. As shown in FIG. The data editing apparatus 10 includes a data holding unit 12, a code correspondence relationship table 14, an aggregation rule table 16, a distribution rule table 18, a code acquisition unit 20, a code generation unit 22, and an editing processing unit 24.

  Each block shown in the block diagram of the present specification can be realized by hardware as an element such as a CPU of a computer or a mechanical device, and as software as a computer program or the like. It depicts the functional blocks realized by the coordination of them. Therefore, it is understood by those skilled in the art that these functional blocks can be realized in various forms by a combination of hardware and software. For example, each functional block in FIG. 2 may be stored as software in a recording medium, installed in the hard disk of the data editing device 10, read appropriately into the main memory of the data editing device 10, and executed by the CPU.

  The data holding unit 12 is a storage area for holding pre-edit data to be edited and post-edit data. The data holding unit 12 holds a CSV (Comma Separated Values) file in which data values and bases are associated with each other before editing data and after editing data. For example, one line of the CSV file may be "value, presence / absence of hat, name, unit, time, subject", and a blank line may indicate the original division. Of course, the data holding unit 12 may be provided in an information processing apparatus different from the data editing apparatus 10, for example, a database server. In this case, an information processing system in which the database server and the data editing apparatus 10 are connected via a communication network such as LAN, WAN, or the Internet may be constructed.

  The code correspondence relationship table 14 includes a program language (hereinafter, also referred to as “inclusive notation language”) for describing editing content (editing operation) of data by an inclusive notation, and the editing content of data by an extension notation. It is a storage area that holds the correspondence with a program language (hereinafter, "extensible notation language") to be described. The extension notation language in the base technology 2 is assumed to be Java (registered trademark) language, but may be another programming language such as C language.

  For example, the correspondence relation between the inclusive notation language and the extension notation language is a code (function) that implements a keyword indicating an editing operation in the inclusion notation language and a logic for realizing the editing operation in the extension notation language And are associated with each other. More specifically, the description of the condition for extracting specific data from the plurality of data in the intensional notation language is associated with the description of the repetitive instruction for sequentially listing the plurality of data in the extension notation language. Also, for example, a code that specifies input data in a comprehension notation language and a code that implements a logic for reading the input data into a memory in the extension notation language are associated with each other. A specific example of the correspondence will be described later with reference to FIGS.

  The aggregation rule table 16 is a storage area that holds an aggregation rule that defines an aggregation relationship of a plurality of types of bases to be referred to at the time of aggregation operation. The aggregation rule defines, for example, the above-mentioned aggregation relationship of {Tsugaru, Fuji, red ball}-> {apple}. Hereinafter, a base (a apple in the above example) that aggregates plural types of bases will be referred to as an “aggregate base”. The distribution rule table 18 is a storage area that holds distribution rules that define distribution ratios of a plurality of types of bases that are referred to at the time of distribution operation. The distribution rule defines, for example, the aforementioned distribution relationship of {apple}-> {Tsugaru, Fuji, red ball} and a distribution ratio of 1: 1: 1.

  The code acquisition unit 20 acquires a program code (hereinafter, also referred to as “user code”) input by the user via a predetermined input device such as a keyboard. This user code is described in a comprehension notation language. Specific user code examples will be described later.

  The code generation unit 22 is a program code in which the data editing content described in the user code is described in the extended notation language from the user code according to the correspondence relationship held in the code correspondence relationship table 14 (hereinafter referred to as “execution code Also called "). The execution code in Prerequisite Technique 2 is Java byte code. Specifically, the Java source code corresponding to the user code is generated, and the Java code is generated by compiling the source code. A concrete execution code example will be described later.

  The editing processing unit 24 edits the data to be edited held in the data holding unit 12 in accordance with the execution code generated by the code generation unit 22. The editing processing unit 24 includes a data reading unit 26, a data editing unit 28, and an editing result output unit 30. Of course, the functions of the editing processing unit 24 (the data reading unit 26 to the editing result output unit 30) may be realized by executing the execution code in a predetermined execution engine. For example, when the execution code is Java byte code, the execution engine is a JVM (Java Virtual Machine).

  The data reading unit 26 reads the data to be edited from the data holding unit 12 and generates a data object in which the value of the data is associated with the base on the memory from the data. The data editing unit 28 performs an operation on the data object generated by the data reading unit 26 to set data of an editing result. The editing result output unit 30 records the data of the editing result set in the data reading unit 26 as a CSV file, and stores the data in the data holding unit 12.

  FIG. 3 shows an example of a user code for operating the accounting type data. In the following code example, a line number is shown at the left end, and the position of the code is appropriately indicated by the line number. In FIG. 3, a set C including an element of 200 <cash> +100 <wheat> and an element of 200 <cash> +200 <soy> is specified as edit target data. Although the data to be edited is directly input here for simplification of the explanation, typically the input data is specified by specifying the name of the CSV file as an input file and the description position of the input data in the CSV file. A data object indicating is generated.

  In the fourth line of FIG. 3, projection processing of exchange algebra, that is, a projection operation for extracting a subelement that matches the specified base is specified. Specifically, a process is specified for extracting from the set C a base that corresponds to the base <cash> or <wheat> and that satisfies the condition that the value has already been set and substitutes it into the set aset. The fifth line specifies the original addition process in aset. Since aset includes 200 <cash>, 100 <wheat>, and 200 <cash>, the addition result alpha is 400 <cash> +100 <wheat>. Here, to simplify the explanation, the editing result is output to the standard output, but typically a CSV file as an output file is specified, and the editing result (here, the contents of the addition result alpha is added to the CSV file) ) Is recorded.

  FIG. 4A shows an execution code corresponding to the user code of FIG. Specifically, the execution code is generated by the code generation unit 22 according to the second line of FIG. 3 and corresponds to the function of the data reading unit 26. In the description of the base technology 2, a Java source program is shown as an execution code for convenience. In the figure, the ExAlgeSet object corresponding to the set C corresponds to the ExAlge object (lines 15 to 23) corresponding to the source of 200 <cash> +100 <wheat> and the source of 200 <cash> +200 <soy> The ExAlge object (the 24th to 32nd lines) is stored.

  FIG. 4 (b) shows the execution code corresponding to the user code of FIG. Specifically, the execution code is generated by the code generation unit 22 in accordance with the fourth line in FIG. 3, and corresponds to the function of the data editing unit 28. In the same figure, it is in a double loop of a for loop which enumerates ExAlge objects corresponding to a plurality of elements contained in set C, and a for loop which enumerates ExBase objects corresponding to a plurality of bases contained in set D , Projection method is called, and the result of projection processing is added to the list. And the set aset is set from the list.

  FIG. 5 shows an example of user code for operating record type data. In the figure, there are 5 of Yamada <name> + 5 <score>, Tanaka <name> + 3 <score>, Suzuki <name> + 4 <score>, Sato <name> +2 <score>, Honda <name> + 5 <score>. A set dataset containing two elements is specified.

  In line 9 of FIG. 5, a process of substituting the element “1 <4 or more, people, #, #>” into the set aset whenever an element having a value of 4 or more associated with the base <score> exists. Is specified. Then, in line 11, the original addition process in aset is specified. As a result, the aset includes three elements “1 <4 or more, people, #, #>”, and ret = 3 <4 or more, people, #, #>. That is, this example counts the number of people having a score of 4 or more.

  FIG. 6A shows an execution code corresponding to the user code of FIG. Specifically, the execution code is generated by the code generation unit 22 in accordance with the 2nd to 7th lines in FIG. 5, and corresponds to the function of the data reading unit 26. In the figure, Dtalge objects corresponding to the originals of the five record type data are stored in DtAlgeSet objects corresponding to the set data set. Since record type data allows various data types in both value and base, information indicating the data type of each of value and base is also set in the Dtalge object.

  FIG. 6 (b) shows an execution code corresponding to the user code of FIG. Specifically, it is an execution code generated by the code generation unit 22 according to the ninth line in FIG. 5, and corresponds to the function of the data editing unit 28. In the figure, in a for loop that enumerates DtAlgeSet objects corresponding to a plurality of elements included in the set dataset, if the value corresponding to the base <score> is 4 or more, the element “1 <4 or more, a person, #, #> Is added to the list. And the set aset is set from the list.

  When an aggregation instruction (function) is set in the user code, the code generation unit 22 refers to the aggregation rule held in the aggregation rule table 16 and firstly, an object corresponding to the description of bookkeeping (hereinafter referred to as “intermediate object Generate an executable code to set "." Specifically, data indicating aggregation of plural aggregation target data is calculated, data indicating that the aggregation value is associated with the aggregation base, and each value of the aggregation target plurality of data is subtracted (ie, aggregation An execution code is generated in which an object indicating an object to be added with data obtained by adding a hat attribute to a plurality of target original data is set as an intermediate object. This intermediate object corresponds to F (x) shown in the aggregation of the base technology 1.

  Then, the code generation unit 22 adds the object indicating the source to which the plurality of original data to be aggregated is added and the intermediate object, in other words, the hat attribute is added to the plurality of original data to be aggregated and their data. By offsetting the data, an execution code is generated that stores data in which the aggregation value of the plurality of data to be aggregated and the aggregation base are associated with each other in the object of the aggregation result. This execution code is a code corresponding to ̃ (x + F (x)) shown in the aggregation of the base technology 1. The code generation unit 22 may further generate an execution code for outputting the content of the intermediate object to a predetermined file. According to this aspect, by presenting the contents of the intermediate object to the user, it is possible to support efficient debugging and to provide the user with information that can be used for bookkeeping transfer calculation.

  Also, when an apportionment instruction (function) is set in the user code, the code generation unit 22 refers to the aggregation rule held in the apportionment rule table 18 and first sets an execution code to set an intermediate object as in aggregation. Generate Specifically, the value of the distribution target data is distributed according to the distribution ratio, and data in which the distribution value is associated with each base of the distribution destination and data obtained by adding the hat attribute to the distribution target original data are used. An execution code is generated that sets an object indicating an addition source as an intermediate object. This intermediate object corresponds to F (x) shown in the distribution of the base technology 1.

  Then, the code generation unit 22 adds the object indicating the source of the original data of the distribution target and the intermediate object, in other words, by offsetting the original data of the distribution target and the data obtained by adding the hat attribute to the data. An execution code is generated for storing data in which the apportioned values are associated with the respective bases of the apportioned distribution in the apportionment result object. This execution code is a code corresponding to ̃ (x + F (x)) shown in proportion to the base technology 1. The code generation unit 22 may further generate an execution code for outputting the content of the intermediate object to a predetermined file, as in the aggregation.

The operation according to the above configuration will be described below.
FIG. 7 is a flowchart showing the operation of the data editing apparatus 10. First, the user describes the editing content of data by the comprehension-like notation using the comprehension-like notation language, and inputs an editing instruction of data designating the program code to the data editing apparatus 10. When the data editing apparatus 10 receives a data editing instruction via a predetermined input device (Y in S10), the code acquisition unit 20 of the data editing apparatus 10 acquires the program code input by the user as a user code. (S12). The code generation unit 22 starts an execution code generation process from the user code in accordance with the correspondence between the user code and the execution code held in the code correspondence relationship table 14 (S14).

  When there is a transfer instruction such as an aggregation instruction or an apportionment instruction in the user code (Y in S16), the code generation unit 22 sets an output instruction of an intermediate object for offset processing according to the transfer instruction in the execution code ( S18). If there is no transfer instruction in the user code (N in S16), S18 is skipped. The editing processing unit 24 executes editing processing on the data to be edited according to the generated execution code (S20). For example, the data reading unit 26 reads the user code and the data to be edited specified in the execution code generated from the user code from the CSV file for storing the input data of the data holding unit 12 and generates a data object. Then, the data editing unit 28 executes an editing operation (a projection operation based on a base, an aggregation operation, an apportionment operation, etc.) specified by the execution code on the generated data object, and generates a data object indicating an editing result. Do. The editing result output unit 30 edits the editing result by the editing processing unit 24, for example, the contents (attribute values, etc.) of the data object indicating the editing result generated by the data editing unit 28 into a CSV for storing the editing result of the data holding unit 12. Output to a file (S22). If the data editing apparatus 10 does not receive the data editing instruction (N at S10), the process from S12 is skipped.

  According to the data editing apparatus 10 of the base technology 2, data which has conventionally been handled by the RDB can be expressed as a data object corresponding to accounting type data or a data object corresponding to record type data. This can support standardization of data object representation on a computer. In addition, accumulation of data to be edited does not require a complicated mechanism like RDB, and can be accumulated in a highly visible CSV file.

  Further, according to the data editing apparatus 10, since the user can describe the editing content of data in a comprehension-like notation language, if a user who correctly understands the editing content of data, the extension operation for actually operating the computer Even if you do not understand the notation language, you can realize correct data editing. Further, since the data to be edited is held as a combination of the value and the base in the data editing apparatus 10, the user can easily describe the editing content based on the definition by using the inclusive notation. In addition, since the intensional notation does not depend on a computer and reflects the specification of data editing, the user can realize correct data editing if the specification of the correct specification is made. For example, the user may describe the edited content of the data as specified, without being aware of the for loop and the like. Therefore, it is possible to reduce the incorporation of bugs into user code, in other words, it becomes easy to limit the occurrence of a bug to a bug of the data itself. For example, in the operation of accounting data, various transfer processes such as aggregation and apportionment can be described robustly.

  Further, according to the data editing apparatus 10, by performing value editing processing based on the basis of data, even if there is a change in the data format (schema), the influence range can be limited. For example, even if column replacement occurs in a table storing data to be edited, the influence on editing logic in user code can be eliminated.

  Further, according to the data editing apparatus 10, since the rules for transfer processing such as aggregation and apportionment are held in the table outside the program code, it is sufficient to change the data of the table even if the rule is changed. You can eliminate the impact.

  As a modification, the data editing device 10 may further include a transfer rule table. The transfer rule table is a storage area for holding transfer rules to be referred to in a transfer operation (here, it is assumed to be a base conversion operation without aggregation or apportionment). The transfer rule is data in which a transfer source base and a transfer destination base are associated. When the transfer instruction is set in the user code, the code generation unit 22 generates an execution code for setting the intermediate object F (x) with reference to the transfer rule held in the transfer rule table. For example, in the case of x = numerical value A <transfer source base>, F (x) = numerical value A ^ <transfer source base> + numeric value A <transfer destination base>. Then, the code generation unit 22 generates an execution code corresponding to (x + F (x)). As the execution result of the code, in the above example, the numerical value A <transfer source base> is converted to the numerical value A <transfer destination base>.

(Description of the outline of the embodiment)
The embodiment proposes a technology for improving the traceability of a trade or a good when a good with a unique ID is traded between entities and the trade is chained. Specifically, a system and apparatus (a transaction management system 100 and a transaction management apparatus 108 described later) that support the above-described audit related to traceability are proposed. A “good” is something that has some utility, materially or mentally, and includes tangible goods, intangible goods (services, etc.) and intellectual property that are the subject of transactions. The "goods" in the embodiment is a product such as an apple. Also, “audit” in the embodiment includes authentication / verification regarding the content of the transaction or the subject of the transaction. Transaction entities include various companies, organizations, and individuals.

  When describing transactions between two entities in double-entry bookkeeping, prices are generally used. For example, assuming that the entity A sells one or more apples to the entity B for 800 yen, this transaction is described as shown in FIGS. 8 (a) and 8 (b). FIG. 8A shows the transaction description on the side of the subject A, and FIG. 8B shows the transaction description on the side of the subject B. In the case of price display, the transaction description on the subject A side and the transaction description on the subject B side are not symmetrical. The subject A does not want the subject B to know the information including the cost of the apple shown in FIG. This is the same as using the sales account. Therefore, the information shown in FIGS. 8A and 8B can not be shared between the subject A and the subject B.

  In the embodiment, real transactions are recorded using multiple bookkeeping, which is an extension of double-entry bookkeeping using algebraic expressions, using exchange algebra, which is a bookkeeping abstraction. Specifically, in the transaction description, a double-entry bookkeeping statement (hereinafter, also referred to as "actual bookkeeping") is used which allows a unit system of measurement unique to each item (for example, in the case of an apple, its amount is evaluated by Kg).

  FIGS. 9 (a) and 9 (b) show the transaction description using the real bookkeeping when the subject A sells 2 Kg of apple to the subject B for 800 yen. FIG. 9A shows the transaction description on the side of the subject A, and FIG. 9B shows the transaction description on the side of the subject B. In the real thing bookkeeping, the transaction description on the subject A side and the transaction description on the subject B side are symmetrical. In addition, the transaction statement by physical bookkeeping does not include selling side cost information. Therefore, it is possible to share the contents of the transaction description using the real bookkeeping among the entities that have made the transaction.

  In the system of the embodiment, a transaction of goods between two entities is a basic unit, and the transaction is recorded as transaction description data (also referred to as journal data) using real bookkeeping. Then, each time the goods are being circulated several times, data of transaction descriptions are accumulated. The system of the embodiment combines data of a plurality of transaction descriptions related to the goods to generate data (also referred to as a “trade chain”) indicating a chain of trades of the goods, and based on the trade chains, the goods Ensure traceability of In addition, the system of the embodiment executes various audit calculations (in other words, authentication calculation) on the transaction chain, and as a result, provides various audit information (in other words, authentication information).

  The national statistics bureau can be considered as a special case for providing audit information. The Commodity Flow Law, which forms the basis of national accounts for the national economy, seeks to grasp the flow of goods between companies using questionnaires. The commodity flow method has major problems such as the accuracy of survey and time delay. If the traceability chain of inter-company transactions is recognized and expanded as essential to a credible transaction, the information of this transaction chain is not used as information of individual companies but of goods flow per item. You can capture the situation daily, weekly, monthly. This makes it possible to observe the state of the dynamic process of the network of economic transactions, and greatly contributes not only to national policy planning but also to the business plan of the company itself, as a means of revitalizing conventional social statistics. can do. Furthermore, in financial statistics, for example, if it is possible to trace the creation and spread transactions of CDS (credit default swap) as a similar traceability chain, it is possible to observe and evaluate the financial risk itself as a dynamic process, which is policyistic It is considered that the significance is great.

In the system of the embodiment, the transaction is recorded using the real bookkeeping based on the exchange algebra described in the base technology. The following equation 1 represents the contents of the journal entry shown in FIG. 9 (a), and the equation 2 represents the contents of the journal entry shown in FIG. 9 (b).
x1 = 2 ^ <Apple, Kg, apple_243, id_A> + 800 <Cash, Yen, *, id_A> (Equation 1)
y1 = 2 <Apple, Kg, apple_243, id_B> + 800 ^ <Cash, Yen, *, id_B> (Equation 2)
"Apple_243" of Formula 1 and Formula 2 is a unique ID of a tradeable item (apple). Also, “id_A” and “id_B” are the IDs of the entities A and B who are the transaction parties.

  As described in part in the base technology, the compounding book data and exchange algebra data in the embodiment may actually be stored in storage and memory as object data in an object-oriented language, and persistent as data in a CSV file. May be stored. The CPU of each device that processes double-entry bookkeeping data and exchange algebra data may treat the above object data logically as double-entry bookkeeping data and exchange algebra data, and may execute various arithmetic processing based on the base.

(First embodiment)
FIG. 10 shows the configuration of the transaction management system 100 of the embodiment. The transaction management system 100 includes a plurality of trader devices 102 (for example, a trader device 102a, a trader device 102b, a trader device 102c), an auditor device 104, a transaction data storage device 106, and a transaction management device 108. . These devices are connected via a communication network 110 including a LAN, a WAN, the Internet, and the like.

  The plurality of trader devices 102 are information processing devices operated by the parties of transaction of goods (subject A, subject B, etc., in fact, employees of a company, etc.). The auditor device 104 is an information processing device operated by an auditor who audits a transaction of a product. The auditor may be a company or an individual (such as an end consumer). Also, the auditor may be a party of the transaction, in which case the auditor device 104 and the trader device 102 may be identical. The trader device 102 and the auditor device 104 may be, for example, a PC, a tablet terminal, or a smartphone.

  The transaction data storage device 106 is a storage device that stores transaction data indicating the contents of the transaction in association with the ID of the transaction target when the item is sold from the first entity to the second entity. The transaction data includes double-entry bookkeeping data indicating the transfer of goods and the acquisition of compensation using the exchange algebra as the transaction description of the first entity, and the acquisition of goods and the transfer of compensation as the transaction description of the second entity. And double entry bookkeeping data showing the exchange algebra. The transaction data storage apparatus 106 according to the embodiment stores a plurality of transaction data containers (described later) registered from a plurality of trader devices 102. The transaction data storage device 106 may be a storage device or a database server.

  The transaction management device 108 is an information processing device that stores a hash value of transaction data (in the embodiment, a transaction hash container to be described later) indicating a transaction of a product, and supports an audit (or authentication) regarding the transaction of the product. The transaction management device 108 according to the embodiment is installed in an organization (also referred to as a “certificate authority”) that supports audit and certification regarding transactions.

  FIG. 11 is a block diagram showing a functional configuration of the trader device 102 of FIG. The trader device 102 includes a transaction record acquisition unit 120, a transaction data container generation unit 122, a transaction data container registration unit 124, a transaction hash container generation unit 126, and a transaction hash container registration unit 128. A computer program including a plurality of modules corresponding to the plurality of functional blocks may be stored in a recording medium such as a DVD or downloaded via a network and installed in the storage of the trader device 102. The CPU of the trader device 102 may exert the function of each functional block by reading the computer program to the main memory and executing it.

  The transaction result acquisition unit 120 acquires transaction result data input from the keyboard. Alternatively, the transaction result acquisition unit 120 acquires transaction result data transmitted from another device (not shown). The transaction result data of the embodiment includes the ID of the trader (for example, the ID of the seller and the ID of the purchaser), the ID of the goods to be traded and the type of the goods, the date and time of trading, the volume of trading Amount of consideration)). The contents of sales record data are generically referred to as transaction contents.

  The transaction data container generation unit 122 generates a transaction data container including a transaction description based on physical bookkeeping based on the transaction result data. FIG. 12 shows an example of a transaction data container. The transaction data container of the embodiment is key-value type. Also, the transaction data container may be in JSON (JavaScript (registered trademark) Object Notation) format. The same applies to the transaction hash container described later.

  The transaction data container generation unit 122 generates a transaction description between the two entities (for example, Equation 1 and Equation 2 above) from the transaction result data according to a predetermined conversion rule. For example, the transaction data container generation unit 122 sets the value of each item of the transaction result data and the generated transaction description to the corresponding item in the transaction data container.

  The conversion rules may include data on bases to be assigned to each of a plurality of types of goods that can be traded. For example, it may include data in which the type of goods and data of the base (for example, apple and "<Apple, Kg, ID of goods, ID of trade subject ID>") are associated. The conversion rule may include data defining whether the item corresponds to a credit item in bookkeeping or a debit item, and the conversion rules include “^” (hat) for seller-source data and seller-destination data. It may also include data that determines whether or not to grant.

  The transaction data container generation unit 122 is a public key of the certificate authority provided in advance by the certificate authority with the transaction description between the two entities (the above-mentioned Equation 1 and Equation 2 in FIG. 12) as the value of the transaction data in the transaction data container. The data "Encode [P_key1] ({x1, y1})" encrypted by (P_key1) is set. Further, the transaction data container generation unit 122 sets the transaction date and time indicated by the transaction result data to the value of the transaction date and time in the transaction data container. In addition, the transaction data container generation unit 122 sets, as the value of the trader ID in the transaction data container, the IDs of the two parties who are the transaction parties. In the embodiment, they are set in the order of “{seller of goods, purchaser of goods}}. In addition, the transaction data container generation unit 122 sets the ID of the transaction target product to the value of the item ID in the transaction data container.

  Referring back to FIG. 11, the transaction data container registration unit 124 registers the transaction data container generated by the transaction data container generation unit 122 in the transaction data storage device 106. For example, the transaction data container registration unit 124 transmits a registration request including the transaction data container to the transaction data storage device 106, and causes the transaction data storage device 106 to store the transaction data container.

  The transaction hash container generation unit 126 generates a transaction hash container that includes a hash value of a transaction description based on physical bookkeeping, based on the transaction result data. The transaction hash container generation unit 126 encrypts the transaction description between the two entities (the above Equation 1 and Equation 2 in FIG. 12) with the certificate authority public key (P_key 1) provided in advance from the certificate authority and encrypts it. Data is input to a predetermined hash function to obtain a hash value "Hash (encode [P_key1] ({x1, y1}))". In other words, the transaction hash container generation unit 126 acquires the hash value of the transaction data set in the transaction data container. The hash function to be used may be a known one such as MD5 or SHA-2.

  FIG. 13 shows an example of a transaction hash container. The transaction hash container generation unit 126 sets the hash value of the transaction data to the value of the transaction hash data in the transaction hash container. Other items are similar to the transaction data container.

  Referring back to FIG. 11, the transaction hash container registration unit 128 registers the transaction hash container generated by the transaction hash container generation unit 126 in the transaction management device 108. For example, the transaction hash container registration unit 128 transmits a registration request including the transaction hash container to the transaction management device 108, and causes the transaction management device 108 to store the transaction hash container.

  Note that, as described above, transaction data related to a certain transaction to which actual bookkeeping is applied can be shared between two parties who are parties to the transaction. Therefore, the registration entity of the transaction data container and the transaction hash container may be any of two entities (for example, the above-mentioned entity A and entity B).

  FIG. 14 is a block diagram showing a functional configuration of the transaction management device 108 of FIG. The transaction management device 108 includes a transaction hash container storage unit 130, a transaction hash container reception unit 132, an audit request reception unit 134, a transaction data container extraction unit 136, a transaction hash container extraction unit 138, an audit unit 140, and an audit data transmission unit 142. Prepare. A computer program including a plurality of modules corresponding to the plurality of functional blocks may be stored in a recording medium such as a DVD or downloaded via a network and installed in the storage of the transaction management device 108. The CPU of the transaction management device 108 may exert the function of each functional block by reading the computer program to the main memory and executing it.

  The transaction management device 108 may be configured to include the function of the transaction data storage device 106. That is, the transaction management device 108 comprises: a storage unit for storing the transaction data container; and a transaction data container reception unit for receiving the registration request data transmitted from the trader device 102 and storing the transaction data container in the storage unit. You may provide further.

  When a good is sold from the first entity to the second entity, the transaction hash container storage unit 130 stores the hash value of the transaction data indicating the content of the transaction in association with the ID of the good to be transacted. As described above, the transaction data includes, as the transaction description of the first entity, double-entry bookkeeping data indicating the transfer of goods and the acquisition of compensation using exchange algebra, and the goods as the transaction description of the second entity. Including double-entry bookkeeping data showing exchange acquisition and transfer of consideration using exchange algebra. In the embodiment, the transaction hash container storage unit 130 stores a plurality of transaction hash containers registered from the plurality of trader devices 102.

  The transaction hash container reception unit 132 receives the registration request data transmitted from each of the plurality of trader devices 102, and stores the transaction hash container included in the registration request data in the transaction hash container storage unit 130.

  The audit request reception unit 134 receives an audit request specifying an ID of an item to be audited (also referred to as a product ID, for example, “apple_243” described above) transmitted from the auditor apparatus 104. The audit request can be said to be data that instructs the transaction management device 108 to execute audit processing, and can also be said to be data that requests provision of audit support information.

  The transaction data container extraction unit 136 acquires, from the transaction data storage device 106, a transaction data container including the item ID with the item ID designated by the inspection request received by the inspection request receiver 134 as a key. The transaction data container extraction unit 136 passes the acquired one or more transaction data containers to the audit unit 140.

  The transaction hash container extraction unit 138 acquires a transaction hash container including the item ID from the transaction hash container storage unit 130, using the item ID designated by the audit request received by the inspection request accepting unit 134 as a key. The transaction hash container extraction unit 138 acquires the transaction hash container corresponding to the transaction data container acquired by the transaction data container extraction unit 136, in other words, the same as the transaction data container acquired by the transaction data container extraction unit 136. Get a transaction hash container for the transaction. The transaction hash container extraction unit 138 passes the acquired one or more transaction hash containers to the audit unit 140.

  The audit unit 140 confirms that each of the plurality of transaction data containers input from the transaction data container extraction unit 136 is not falsified. Specifically, the auditing unit 140 obtains the hash value of the transaction data included in the transaction data container for the transaction data container and the transaction hash container corresponding to each other, and the obtained hash value is included in the transaction hash container. Determine if it matches the value of the data. The corresponding transaction data container and the transaction hash container are data recorded based on the same transaction. The audit unit 140 identifies the transaction data container and the transaction hash container that correspond to the transaction date and time, the trader ID, and the goods ID as corresponding to each other.

  The audit unit 140 determines that the transaction data of the transaction data container is not falsified if the two hash values match, and determines that the transaction data of the transaction data container is falsified if the two hash values do not match. . If the audit unit 140 determines that the transaction data of the transaction data container is tampered with, the audit unit 140 skips the audit support process based on the audit request. In this case, the audit unit 140 may record alert information indicating that the transaction data is falsified in a predetermined log or notify the predetermined external device of the alert information.

  If it is determined that the transaction data of the transaction data container is not tampered with, the audit unit 140 continues the audit support processing based on the audit request. The auditing unit 140 generates goods transaction chain data, which is data obtained by projecting an element related to goods transactions, from the sum of a plurality of pieces of transaction data associated with the goods ID specified in the audit request. The audit unit 140 generates data (hereinafter, also referred to as “audit support data”) that supports an audit related to the transaction of the goods identified by the goods ID specified in the audit request, based on the goods transaction chain data.

  The audit data transmission unit 142 transmits the audit support data generated by the audit unit 140 to the auditor device 104. Alternatively, the audit data transmission unit 142 may store audit support data as an audit log in a predetermined storage device.

  The audit unit 140 includes a uniqueness audit unit 144, a producer audit unit 146, and a transaction path audit unit 148. The uniqueness audit unit 144 generates data as audit support data on the uniqueness of the transaction of the good identified by the good ID specified in the audit request by offsetting the good transaction chain data. The data on the uniqueness of the trade of goods may be data indicating the presence or absence of double trade of goods (duplicate trade).

  The producer audit part 146, by offsetting the goods transaction chain data, an entity (also referred to as "production entity") which produced the goods identified by the goods ID specified in the audit request, or a series of the goods Data on an entity (also referred to as a “transaction initiating entity”) that has initiated the transaction of the above is generated as audit support data.

  The transaction path auditing unit 148, by offsetting the commodity transaction chain data, starts the transaction initiating entity of the series of transactions of the commodity identified by the commodity ID specified in the audit request, or the entity of the terminal of the series of transactions (“ Identify the end-of-transaction entity). The transaction path auditing unit 148 generates data on the transaction path of the product as audit support data by tracing the other transaction data indicating the transaction of the product starting from the transaction data including the transaction initiating entity or the transaction terminating entity. .

The operation of the transaction management system 100 having the above configuration will be described.
Here, the auditor D audits the goods sold from the subject A to the subject B and from the subject B to the subject C. The auditor D may be, for example, a person who is examining the purchase of the above-mentioned good from the subject C.

Specifically, subject A sold apple 2 kg (the lot ID is “apple — 243”) to subject B for 800 yen. This transaction is represented by the transaction description of the above-mentioned Formula 1 (x1) and Formula 2 (x2). In addition, the subject B sold 2 Kg of an apple to the subject C (ID of lot is “apple — 243”) for 1000 yen. This transaction is expressed by Equation 3 and Equation 4 below. Formula 3 is a transaction description on the subject B side, and formula 4 is a transaction description on the subject C side.
x2 = 2 ^ <Apple, Kg, apple_243, id_B> + 1000 <Cash, Yen, *, id_B> (Equation 3)
y2 = 2 <Apple, Kg, apple_243, id_C> + 1000 ^ <Cash, Yen, *, id_C> (Equation 4)

  The transaction data of Formula 1 and Formula 2 are real bookkeeping and can be shared between A and B of the transaction parties because they do not include the selling side cost information. Similarly, the transaction data of Equation 3 and Equation 4 are also real bookkeeping, and can be shared between B and C of the transaction parties because they do not include the selling side cost information.

  The subject A or the subject B inputs transaction result data to its own trader device 102. The transaction data container generation unit 122 of the trader device 102 generates the transaction data container shown in FIG. 12 based on the transaction result data. The transaction data container registration unit 124 of the trader device 102 registers the transaction data container in the transaction data storage device 106. Further, the transaction hash container generation unit 126 of the trader device 102 generates the transaction hash container shown in FIG. 13 based on the transaction result data. The transaction hash container registration unit 128 of the transaction apparatus 102 registers the transaction hash container in the transaction management apparatus 108.

  The subject B or the subject C inputs transaction result data to the trader apparatus 102 of the company. The transaction data container generation unit 122 of the trader device 102 generates a transaction data container, and the transaction data container registration unit 124 registers the transaction data container in the transaction data storage device 106. Also, the transaction hash container generation unit 126 of the trader device 102 generates a transaction hash container, and the transaction hash container registration unit 128 registers the transaction hash container in the transaction management device 108. An example of the transaction data container here is shown in FIG. 15, and an example of the transaction hash container is shown in FIG.

  The auditor D transmits an audit request specifying the item ID “apple — 243” from the auditor device 104 to the transaction management device 108. The audit request accepting unit 134 of the transaction management device 108 accepts the audit request transmitted from the auditor device 104. The audit request in the embodiment may include (1) audit request for uniqueness of transaction, (2) audit request for goods producer, and (3) audit request for transaction path.

  The transaction data container extraction unit 136 of the transaction management device 108 searches the plurality of transaction data containers stored in the transaction data storage device 106 for the transaction data container associated with the item ID specified in the audit request. In this example, two transaction data containers (FIG. 12, FIG. 15) are acquired. Further, the transaction hash container extraction unit 138 searches the transaction hash container associated with the item ID specified in the audit request from among the plurality of transaction hash containers stored in the transaction hash container storage unit 130, and In the example, two transaction hash containers (FIG. 13, FIG. 16) are acquired.

  The audit unit 140 determines whether the transaction data of each transaction data container acquired by the transaction data container extraction unit 136 is tampered with based on the transaction hash data of the corresponding transaction hash container. If none of the plurality of transaction data containers has been tampered with, the audit unit 140 decrypts the transaction data of the plurality of transaction data containers using the secret key of the transaction management device 108 stored in advance. For example, the audit unit 140 acquires the transaction descriptions x1 and y1 from the transaction data of the transaction data container of FIG. 12, and acquires the transaction descriptions x2 and y2 from the transaction data of the transaction data container of FIG. Hereinafter, x1, y1, x2 and y2 are also simply referred to as transaction data.

  The audit unit 140 generates transaction chain data (also referred to as exchange algebra chain, hereinafter also referred to as “ExalgeChain”) for the item ID “apple — 243” specified in the audit request. The transaction chain data is the sum of transaction data extracted from the transaction data container having the item ID specified in the audit request. Generally, transaction chain data of a certain good is expressed as "ExalgeChain [goods ID]". In the example here, the audit unit 140 generates the following equation (5) as the transaction chain data.

ExalgeChain [apple_243] = {{x | x ∈ {x1, y1} ∪ {x2, y2}}
= 2 ^ <Apple, Kg, apple_243, id_A> + 800 <Cash, Yen, *, id_A>
+ 2 <Apple, Kg, apple_243, id_B> + 800 ^ <Cash, Yen, *, id_B>
+ 2 ^ <Apple, Kg, apple_243, id_B> + 1000 <Cash, Yen, *, id_B>
+ 2 <Apple, Kg, apple_243, id_C> + 1000 ^ <Cash, Yen, *, id_C> (Equation 5)

  The audit unit 140 generates exchange algebra data obtained by projecting only elements related to the trade of goods from the trade chain data as goods trade chain data (also referred to as exchange algebra product chain and hereinafter also referred to as “ExalgeProductChain”). The goods transaction chain data is data representing a chain of buying and selling goods from the first seller (for example, producer of goods) of the goods to be traded to the last buyer (for example, final consumer). In the example here, the audit unit 140 generates the following equation 6 as goods transaction chain data.

w1 = Projection [<Apple, *, apple_243, *>] (ExalgeChain [apple_243])
= 2 <Apple, Kg, apple_243, id_B> + 2 <Apple, Kg, apple_243, id_C>
w2 = Projection [^ <Apple, *, apple_243, *>] (ExalgeChain [apple_243])
= 2 ^ <Apple, Kg, apple_243, id_A> + 2 ^ <Apple, Kg, apple_243, id_B>
ExalgeProductChain [apple_243] = w1 + w2
= 2 <Apple, Kg, apple_243, id_B> + 2 <Apple, Kg, apple_243, id_C> + 2 ^ <Apple, Kg, apple_243, id_A> + 2 ^ <Apple, Kg, apple_243, id_B> 6)
The audit unit 140 of the embodiment generates various audit support data based on the goods transaction chain data.

(1) When an audit request for uniqueness of transaction is received:
The uniqueness audit unit 144 performs the offset operation on the good transaction chain data. In the example here, the uniqueness audit unit 144 generates Equation 7 below as the offset result.
~ (ExalgeProductChain [apple_243]) = 2 <Apple, Kg, apple_243, id_C> + 2 ^ <Apple, Kg, apple_243, id_A>
By performing an offset operation on the goods transaction chain data, the trade by Entity B as an intermediate trade is offset, and the first seller (here, Entity A) and the last buyer (here, Entity C) are extracted. . Also, regardless of the number of stages of trading between the first seller and the last buyer, the middle trading is offset regardless of the change in price because it is a real bookkeeping.

  In the offset result of the goods transaction chain data, the first sales volume by the seller is the transaction volume of the item with "^", and if there are multiple terms with "^", the total of the transaction volumes of those multiple terms It becomes. In addition, the amount purchased by the final purchaser is the transaction amount of the term without "^", and if there are a plurality of terms without "^", the total of the transaction amounts of the plurality of terms is obtained. If the uniqueness of the transaction is maintained, the offset result of the goods transaction chain data is the sales volume by the first seller (in this example, 2 kg of apples with "^") and the purchase volume by the last buyer (this In the example, 2 Kg of apples without "^" are equal. On the other hand, when the transaction is not unique, for example, when the entity B falsely sells an apple as "apple_243" to the subject E different from the subject C, the sales volume by the first seller and the last buyer The amount purchased by will not match.

  The uniqueness inspection unit 144 is unique in the transaction of the good ID "apple_243" when the sales volume by the first seller and the purchase amount by the last purchaser match in the offset result of the goods transaction chain data Generate audit support data. On the other hand, when the sales volume by the first seller and the purchase amount by the last buyer do not match, the uniqueness audit unit 144 generates audit support data indicating that the transaction of the good ID “apple_243” is not unique. Do. This audit support data can also be said to be certification result data of transaction uniqueness. According to this aspect, it is possible to efficiently detect the presence or absence of the uniqueness of the trade of the goods designated by the auditor and present it to the auditor.

(2) When receiving an audit request for a goods producer:
Similar to the uniqueness audit unit 144, the producer audit unit 146 performs the offset operation on the good transaction chain data. In the example here, the producer audit part 146 generates Equation 7 above as the offset result.

  The producer auditing section 146 audits the trader in the item with “^” (ie, the fourth data in the base) as the first seller of the goods or the producer of the goods in the offset result of the goods transaction chain data. Generate support data. The audit support data here can be said to be the certification result data of the producer. According to this aspect, it is possible to efficiently detect the producer or the trade initiator of the goods designated by the auditor and present it to the auditor.

(3) When a transaction route audit request is received:
Similar to the uniqueness audit unit 144, the transaction path audit unit 148 performs the offset operation on the good transaction chain data. In the example here, the transaction path auditing unit 148 generates Equation 7 above as the offset result. The trade path auditing unit 148 identifies the trader in the term with “^” (ie, the fourth data in the base) as the first seller of the goods in the offset result of the goods transaction chain data. The first seller of a good is the top-of-the-line trader in a series of goods trades and will be referred to hereinafter as the "trade initiator."

  The transaction path auditing unit 148 is a transaction data container associated with the item ID designated in the audit request to the transaction data container extracting unit 136, and the value of the seller side of the trader ID is the transaction initiator A transaction data container matching the ID is acquired from the transaction data storage device 106. The trade path auditing unit 148 identifies the purchaser's value of the trader ID in the acquired trade data container as the second trader. Further, the transaction path auditing unit 148 is a transaction data container associated with the item ID specified in the audit request in the transaction data container extracting unit 136, and the value of the seller side of the trader ID is second. A transaction data container that matches the ID of the trader of the transaction is acquired from the transaction data storage device 106.

  The trade path auditing unit 148 identifies the purchaser's value of the trader ID in the acquired trade data container as the third trader. Repeat this to identify the N-th trader. The transaction path auditing unit 148 is a transaction data container associated with the item ID specified in the audit request, and transaction data in which the value of the seller side of the trader ID matches the ID of the N-th trader If the container does not exist in the transaction data storage device 106, the Nth trader is identified as the last purchaser.

  In this manner, the transaction path auditing unit 148 identifies the last purchaser by tracing the other transaction data containers indicating the same good transaction starting from the transaction data container of the transaction initiator. For example, if the item ID “apple — 243” is specified in the audit request, the transaction path auditing unit 148 sequentially acquires the transaction data containers shown in FIGS. 12 and 15, and the first seller “subject A”, middle trader Identify "subject B", the last buyer "subject C".

  The transaction path auditing unit 148 generates, as audit support data, a transaction path diagram showing, from the first seller, the middle trader and arranging up to the last purchaser. FIG. 17 shows an example of a transaction path diagram. The transaction path auditing unit 148 refers to the transaction data container of the transaction initiator and the transaction data of each of the other transaction data containers sequentially traced starting from the container, and identifies the volume of goods trade among the respective traders And set the trading volume in the trading route diagram. According to this aspect, it is possible to support an audit as to what route the goods have been sold to the present.

  Here, the distribution of goods is traced from the first seller to the downstream, but as a modification, the distribution of goods is traced from the last buyer to the upstream, and the middle trader, the first sales Persons may be identified sequentially. For example, the trade path auditing unit 148 may identify the trader in the item without “^” as the last purchaser of the good in the offset result of the good transaction chain data. The transaction path auditing unit 148 may sequentially acquire other transaction data containers related to the same good transaction starting from the transaction data container corresponding to the purchaser.

  As another modification, the transaction path auditing unit 148 causes the transaction data container extracting unit 136 to obtain one or more transaction data containers associated with the item ID specified in the audit request from the transaction data storage device 106. May be The transaction path auditing unit 148 arranges the acquired one or more transaction data containers in order of transaction date and time (in other words, time series of transactions), and from the transaction data container with the earliest transaction date and time, transaction data whose transaction date is later The sequential sellers may identify the first seller, the middle trader, and the last buyer.

Second Embodiment
The trade route in the first embodiment is not divided midway, and there is no synthesis midway. However, in an actual business, there may be a division in which 2 Kg of purchased apples are sold to different subjects by 1 Kg, and in this case, a division of the transaction path occurs. Also, when producing jams using apples and sugar as raw materials and putting the jams in separately purchased glass bottles and selling them, synthesis of the trading route occurs. In the second embodiment, a technique is proposed to improve traceability in the case where transaction routes are divided or combined.

  The configuration of the transaction management system 100 of the second embodiment and the function of each device of the transaction management system 100 are the same as in the first embodiment. Hereinafter, the contents described in the first embodiment will be omitted as appropriate, and mainly the points different from the first embodiment will be described.

1. When the transaction path includes a split (in other words, a transaction in which goods are split in the distribution process):
When the distribution channel of the goods is divided into a plurality of parts in the distribution process of the goods, the transaction data storage device 106 pre-division ID, which is the ID of the goods before the division, and the goods in each of the distribution paths after division. The transaction data indicating the correspondence with a plurality of post-division IDs, which are IDs, is stored. When the pre-division ID or the post-division ID (for example, any of a plurality of post-division IDs) is designated in the audit request, the audit unit 140 of the transaction management device 108 divides the transaction data associated with the pre-division ID with Goods transaction chain data is generated based on both of the transaction data associated with the post ID (e.g., each of the plurality of post-division IDs).

  As an example, in the distribution of food, goods shipped from a starting producer may be subdivided and sold from wholesale to retail. FIG. 18 shows an example of a transaction in which a good is divided in the distribution process. In this example, the subject B changes the ID of the apple. In this case, it is possible to connect the pre-division transaction and the post-division transaction by describing the production as the internal transaction of the subject B as an apple with a new ID is produced even at the subject B.

In this example, it is assumed that 2 kg of apples are sold for 800 yen from subject A to subject B. This transaction is expressed by Equation 8 and Equation 9 below.
x1 = 2 ^ <Apple, Kg, apple_243, id_A> + 800 <Cash, Yen, *, id_A> (Equation 8)
y1 = 2 <Apple, Kg, apple_243, id_B> + 800 ^ <Cash, Yen, *, id_B> (Equation 9)
The trader device 102 of the entity A or B registers the transaction data container storing the transaction descriptions of the equations 8 and 9 in the transaction data storage device 106.

Also, Subject B produces two lots of 1 kg of apples from a lot of 2 kg of apples, and assigns a new lot number (goods ID) to each lot. This is expressed by the following equation 10. The new item IDs are "apple_243_1" and "apple_243_2".
x2 = 2 ^ <Apple, Kg, apple_243, id_B> + 1 <Apple, Kg, apple_243_1, id_B> + 1 <Apple, Kg, apple_243_2, id_B>

  The trader device 102 of the subject B registers the transaction data container storing the transaction description of Expression 10 in the transaction data storage device 106. In the item ID of the transaction data container, both the original item ID “apple — 243” and the new item ID “apple — 243 — 1” “apple — 243 — 2 after division are set. Further, to the transaction data container, a flag (hereinafter also referred to as "division definition flag") indicating that the transaction data (exchange algebra data) indicating division of goods is included is added.

Subsequently, it is assumed that 1 kg of apples is sold for 500 yen from subject B to subject C, and 1 kg of apples is sold for 500 yen from subject B to subject D. The former transaction is represented by Equation 11 and Equation 12 below, and the latter transaction is represented by Equation 13 and Equation 14 below.
x3 = 1 ^ <Apple, Kg, apple_243_1, id_B> + 500 <Cash, Yen, *, id_B> (Equation 10)
y2 = 1 <Apple, Kg, apple_243_1, id_C> + 500 ^ <Cash, Yen, *, id_C> (Equation 11)
x4 = 1 ^ <Apple, Kg, apple_243_2, id_B> + 500 <Cash, Yen, *, id_B> (Equation 12)
y3 = 1 <Apple, Kg, apple_243_2, id_D> + 500 ^ <Cash, Yen, id, id_D> (Equation 13)

  The trader device 102 of the subject B or the subject C registers the transaction data container storing the transaction descriptions of Equation 10 and Equation 11 in the transaction data storage device 106. Also, the trader device 102 of the subject B or the subject D registers the transaction data container storing the transaction descriptions of Equation 12 and Equation 13 in the transaction data storage device 106.

  It is assumed that the item ID "apple_243" is specified in the audit request. The transaction data container extraction unit 136 of the transaction management device 108 acquires, from the transaction data storage device 106, the transaction data container associated with the item ID “apple — 243”. Further, the transaction data container extraction unit 136 determines that the item with the ID “apple_243” has the item with the ID “apple_243_1”, based on the transaction data of the transaction data container to which the division definition flag is added among the acquired transaction data containers. It detects that it has been divided into “apple_243_2” goods. The transaction data container extraction unit 136 further acquires, from the transaction data storage device 106, the transaction data container associated with the item ID “apple — 243 — 1” or “apple — 243 — 2”.

  As in the first embodiment, the transaction hash container extraction unit 138 acquires a transaction hash container corresponding to the transaction data container from the transaction hash container storage unit 130. The inspection unit 140 detects the presence or absence of tampering of the transaction data container by comparing the hash value generated from the transaction data container with the hash value stored in advance in the transaction hash container.

The auditing unit 140 sums the transaction data included in the transaction data container associated with the item ID “apple_243” and the transaction data included in the transaction data container associated with the item ID “apple_243_1” or “apple_243_2”. Are generated as transaction chain data (equation 14 below).
ExalgeChain [apple_243] = {{x | x ∈ {x1, y1} ∪ {x2} ∪ {x3, y2} ∪ {x4, y3}}
= 2 ^ <Apple, Kg, apple_243, id_A> + 800 <Cash, Yen, *, id_A>
+ 2 <Apple, Kg, apple_243, id_B> + 800 ^ <Cash, Yen, *, id_B>
+ 2 ^ <Apple, Kg, apple_243, id_B> + 1 <Apple, Kg, apple_243_1, id_B> + 1 <Apple, Kg, apple_243_2, id_B>
+ 1 ^ <Apple, Kg, apple_243_1, id_B> + 500 <Cash, Yen, *, id_B>
+ 1 <Apple, Kg, apple_243_1, id_C> + 500 ^ <Cash, Yen, *, id_C>
+ 1 ^ <Apple, Kg, apple_243_2, id_B> + 500 <Cash, Yen, *, id_B>
+ 1 <Apple, Kg, apple_243_2, id_D> + 500 ^ <Cash, Yen, *, id_D> (Equation 14)

The auditing unit 140 performs a projection operation on the above-described transaction chain data, including “apple_243”, “apple_243_1”, and “apple_243_2”, to obtain good transaction chain data (Equation 15 below).
ExalgeProductChain [apple_243]
= Projection [<Apple, *, apple_243, *>] (ExalgeChain [apple_243])
+ Projection [^ <Apple, *, apple_243, *>] (ExalgeChain [apple_243])
+ Projection [<Apple, *, apple_243_1, *>] (ExalgeChain [apple_243])
+ Projection [^ <Apple, *, apple_243_1, *>] (ExalgeChain [apple_243])
+ Projection [<Apple, *, apple_243_2, *>] (ExalgeChain [apple_243])
+ Projection [^ <Apple, *, apple_243_2, *>] (ExalgeChain [apple_243])
= 2 ^ <Apple, Kg, apple_243, id_A> + 2 <Apple, Kg, apple_243, id_B> + 2 ^ <Apple, Kg, apple_243, id_B> + 1 <Apple, Kg, apple_243_1, id_B> + 1 <Apple , Kg, apple_243_2, id_B> + 1 ^ <Apple, Kg, apple_243_1, id_B> + 1 <Apple, Kg, apple_243_1, id_C> + 1 ^ <Apple, Kg, apple_243_2, id_B> + 1 <Apple, Kg, apple_243_2 , id_D> · · · (Equation 15)

As in the first embodiment, the audit unit 140 can generate various audit support data based on the goods transaction chain data. For example, the following equation 16 is obtained by performing the offset operation on the goods transaction chain data of equation 15.
~ (ExalgeProductChain [apple_243]) = 2 ^ <Apple, Kg, apple_243, id_A> + 1 <Apple, Kg, apple_243_1, id_C> + 1 <Apple, Kg, apple_243_2, id_D>
The uniqueness audit unit 144, the producer audit unit 146, and the transaction path audit unit 148 generate audit support data according to the same procedure as the first embodiment based on the offset result of the goods transaction chain data shown in Expression 16. Can.

  Although the item ID (“apple_243”) before the distribution route division is specified in the above-mentioned audit request, the item ID (“apple_243_1” or “apple_243_2”) after the distribution route division may be specified. When the item ID after the route division (here, “apple_243_1”) is specified in the audit request, the transaction data container extraction unit 136 stores the transaction data container associated with the item ID “apple_243_1” as transaction data Acquired from the device 106.

  Among the acquired transaction data containers, the transaction data container extraction unit 136 determines, based on the transaction data of the transaction data container to which the division definition flag is added, the item of ID “apple_243” is the item of ID “apple_243_1” and “apple_243_2” Detect that it has been divided into The transaction data container extraction unit 136 further acquires, from the transaction data storage device 106, the transaction data container associated with the item ID “apple — 243” or “apple — 243 — 2”. Thereafter, as in the above example, various audit support data can be generated based on the transaction data container associated with the item ID “apple — 243”, “apple — 243 — 1”, or “apple — 243 — 2”.

2. If the transaction path involves composition (in other words, a transaction in which new goods are produced in the distribution process):
When a plurality of distribution channels are combined into one distribution channel in the distribution process of goods, the transaction data storage device 106 combines a plurality of pre-combination IDs, which are IDs of goods in each distribution channel before distribution channel composition, The transaction data indicating the correspondence with the post-combination ID, which is the ID of the good in the later distribution channel, is stored. When the pre-combination ID (for example, any one of a plurality of pre-combination IDs) or the post-combination ID is designated in the audit request, the audit unit 140 of the transaction management device 108 pre-combination ID (for example, each of a plurality of pre-combination IDs) The product transaction chain data is generated on the basis of both the transaction data associated with and the transaction data associated with the post-combination ID.

  FIG. 19 shows an example of a transaction in which a new good is produced in the distribution process. In this example, subject C produces 10 jams (bottled) based on 2 kg of apples purchased from subject A, 600 g of sugar purchased from subject B, and 10 glass bottles purchased from subject C. Sell 10 pieces to subject E.

The sale of 2 kg of apple from subject A to subject D is the following transaction description.
x1 = 2 ^ <Apple, Kg, apple_243, id_A> + 800 <Cash, Yen, *, id_A> (17)
y1 = 2 <Apple, Kg, apple_243, id_D> + 800 ^ <Cash, Yen, *, id_D> (Equation 18)
The sale of 600 g of sugar from subject B to subject D results in the following transaction description:
x2 = 600 ^ <Sugar, g, sugar_111, id_B> + 300 <Cash, Yen, *, id_B> (Equation 19)
y2 = 600 <Sugar, g, sugar_111, id_D> + 300 ^ <Cash, Yen, *, id_D> (Equation 20)
The sale of 10 glass bottles from subject C to subject D results in the following transaction description:
x3 = 10 ^ <Jar, q, jar_222, id_C> + 100 <Cash, Yen, *, id_C> (Equation 21)
y3 = 10 <Jar, q, jar_222, id_D> + 100 ^ <Cash, Yen, *, id_D> (Equation 22)

The production of jam by subject D is described as the following transaction description as a transaction within subject D.
x4 = 2 ^ <Apple, Kg, apple_243, id_D> + 600 ^ <Sugar, g, sugar_111, id_D> + 10 ^ <Jar, piece, jar_222, id_D> + 10 <Jam, piece, jam_333, id_D> (Equation 23)
In the goods ID of the transaction data container including the transaction description of Expression 23, both “apple_243”, “sugar_111”, and “jar_222”, which are goods IDs before combining, and “jam_333”, which is goods IDs after combining, are set. . Also, a flag indicating that the transaction data container includes transaction data indicating composition of goods (in other words, production of a new good) (hereinafter also referred to as "composition definition flag", can also be referred to as production definition flag) is added. Be done.

The sale of ten (bottled) jams from subject D to subject E results in the following transaction description:
x1 = 10 ^ <Jam, pieces, jam_333, id_D> + 2000 <Cash, Yen, *, id_D>
y1 = 10 <Jam, piece, jam_333, id_E> + 2000 ^ <Cash, Yen, *, id_E> (Equation 25)

  As described above, when composition of distribution channels occurs in the distribution process of goods, in other words, even when a new good is produced in the distribution process of goods, the ID “apple — 243” It becomes possible to detect that the goods of "sugar_111" and "jar_222" are combined with the goods of ID "jam_333". As a result, it is possible to generate transaction chain data (in addition, goods transaction chain data) combining Eqs. 17 to 25 regardless of which of "apple_243", "sugar_111", "jar_222" and "jam_333" is specified in the audit request. Can provide various audit information on jam transactions including raw materials. For example, support for the certification and audit of (1) uniqueness of transactions including raw materials, (2) producers of raw materials, and (3) trade routes including raw materials by the buyer (entrant E) of jam. Can.

  The present invention has been described above based on the first embodiment and the second embodiment. It is understood by those skilled in the art that these embodiments are exemplifications, and that various modifications can be made to the combination of each component and each processing process, and such modifications are also within the scope of the present invention.

  A first modification will be described. In the first embodiment and the second embodiment, when transactions between two entities are chained and goods are distributed, two entities are registered at the time of registration of the transaction data container and the transaction hash container, and at the time of generation of the audit support data. There is a need for a kind of “confidence calculation” in which transaction information between the parties does not leak to a third party other than the party and only information related to authentication or audit is extracted.

  Generally, in a calculation called secure calculation, calculation processing such as addition / subtraction is directly performed on an encrypted object while data is encrypted. However, secret computation often requires a large amount of computation, and while it is a large-scale process, possible computations are limited. As such, secret calculations are not well-suited to authentication and audits of many transaction data across the entire trading chain.

  In this modification, a mechanism of “non-disclosure computation” is introduced. In non-disclosure calculation, each time a calculation is performed that a calculation module has not been tampered with for a calculation module that has been certified (confirmed) in advance that an algorithm that does not leak calculation target data is implemented is implemented (confirmed) Verify.

  Specifically, for a function (in other words, a filter) defined in a function calculation type language capable of calculating exchange algebra, the security on the definition is first verified. If it is a function implemented in a functional computing language, for example, verifying its definitional security by checking its source code, specifically, processing concerning information leakage other than the target calculation is It is easy to verify if it is not included in the function definition.

  The hash value of the object code (or execution form) in which the function (source code) thus verified is compiled is registered in the list. This list is called a white list, and the functions verified to be safe are called white functions. A composite function formed by linking white functions is also a white function. A plurality of combinations of identification names of functions (functional blocks) and valid hash values may be recorded in the white list.

  At the time of execution of the function, the hash value of the object code (or execution form) of the function to be executed is dynamically acquired, and the hash value is compared with the hash value in the white list stored in advance. Then, the function to be executed is executed only when the two hash values match. On the other hand, when the two hash values do not match, the execution of the function to be executed is suppressed. Thereby, it is possible to suppress the leakage of information to the outside in the calculation process regarding the exchange algebra.

  This non-disclosure calculation scheme may be introduced to the trader device 102 and the transaction management device 108, which are information processing devices that perform exchange algebra calculations. Specifically, the present invention may be applied to the transaction data container generation unit 122, the transaction hash container generation unit 126, and the audit unit 140 of the transaction management device 108 of the trader device 102, and when the execution of these functional blocks starts The hash value of the calculation module (object code) that exerts the function of the block may be obtained and compared with the hash value of the white list. In addition, the non-disclosure calculation scheme is useful for various information processing apparatuses that process secret information, and is useful, for example, for an information processing apparatus that handles medical information.

  The whitelist may be stored in each of the trader device 102 and the transaction management device 108. Also, the whitelist may be stored in the transaction manager 108 (ie, the certificate authority's device), and the trader device 102 may query the transaction manager 108 for whitelist data. Further, the whitelist may be stored in a device not shown in FIG. 10, and the trader device 102 and the transaction management device 108 may inquire data of the whitelist from the device not shown. In order to secure the same execution environment, it is desirable that the function is executed on a virtual server (in other words, a container) by container type virtualization (Docker or the like).

  A configuration example of the first modification will be described. Here, an example of introducing a non-disclosure calculation mechanism into the transaction management device 108 is shown. The function of the audit unit 140 of the transaction management apparatus 108 may be exhibited by the CPU of the transaction management apparatus 108 executing a computer program (also referred to herein as an “audit unit instruction set”) in which the function is implemented. . The transaction management device 108 can access a storage unit that stores a first hash value that is a hash value of a regular audit unit instruction set. For example, the storage unit that stores the first hash value may be provided in the transaction management device 108, or may be provided in another device connected to the transaction management device 108 via a communication network.

  The transaction management device 108 may further include a collation unit. The collation unit is an execution target when the CPU of the transaction management device 108 executes the audit unit instruction set (in other words, when execution of the audit unit instruction set starts, that is, when the function of the audit unit 140 is to be exhibited). Dynamically obtain a second hash value which is a hash value of the instruction set of The collation unit acquires the first hash value from the storage unit and collates the first hash value with the second hash value. The CPU of the transaction management device 108 executes an audit unit instruction set when the collation unit determines that the first hash value and the second hash value match, and the first hash value and the second hash value do not match. If it is determined, the execution of the audit unit instruction set is suppressed (canceled).

  A second modification will be described. In the above embodiment, when the transaction management device 108 receives an audit request, transaction chain data (for example, “ExalgeChain [apple_243]) obtained by adding together a plurality of transaction data corresponding to the item ID specified in the audit request. ") Was generated. As a modification, the transaction management device 108 may update the transaction chain data each time the transaction data container is registered for each item ID for which the transaction data container is registered in the transaction data storage device 106. The transaction management device 108 updates the plurality of transaction chain data corresponding to the plurality of goods IDs regardless of whether or not the audit request is received, encrypts the latest plurality of transaction chain data, and stores it in a predetermined storage unit. You may According to this aspect, it is possible to skip acquisition processing of transaction data at the time of receiving an audit request and generation processing of transaction chain data, and it is possible to streamline calculation for authentication or audit.

  A third modification will be described. The transaction data container may contain additional or supplementary information about the production, sale, environmental impact, producers, traders of the good. It may also include a resource location (URL) from which these additional information can be obtained. The same applies to the transaction hash container.

  A fourth modification will be described. The transaction management system 100 may include a plurality of certificate authorities, and may include a plurality of transaction data storage devices 106 and a plurality of transaction management devices 108 as devices of the plurality of certificate authorities. In this case, the plurality of transaction data storage devices 106 and the plurality of transaction management devices 108 mutually refer to each other (data of transaction data container etc.) and calculation results (such as offset result of goods transaction chain data) of each other. Configured as possible. Also, calculation processing for authentication or audit can be delegated to each other. As a result, no problem occurs even if the trader uses any certificate authority, and competition between certificate authorities can be promoted.

  Any combination of the above-described embodiment and modification is also useful as an embodiment of the present invention. The new embodiments resulting from the combination combine the effects of the combined embodiment and the variations. It is also understood by those skilled in the art that the functions to be performed by the respective constituent features described in the claims are realized by a single member of each constituent shown in the embodiment and the modification or a combination thereof.

  100 transaction management system, 106 transaction data storage device, 108 transaction management device, 134 audit request reception unit, 140 audit unit, 142 audit data transmission unit, 144 uniqueness audit unit, 146 producer audit unit, 148 transaction path audit unit.

Claims (9)

When the goods are sold from the first entity to the second entity, double-entry bookkeeping data representing the transfer of the goods and the acquisition of the consideration using the exchange algebra as the transaction description of the first entity side, and the second It is possible to access a storage unit that stores transaction data including double-entry bookkeeping data indicating acquisition of the goods and transfer of the consideration using exchange algebra as transaction descriptions on the subject side in association with the IDs of the goods. ,
An audit request reception unit that receives an audit request specifying an ID of a certain item;
Goods transaction chain data, which is data obtained by projecting an element related to goods transactions, is generated from the sum of a plurality of pieces of transaction data associated with the ID specified in the audit request, and based on the goods transaction chain data An audit department that generates data to support an audit on transactions of goods identified by the ID specified in the audit request;
An information processing apparatus comprising:   The information processing apparatus according to claim 1, wherein the transaction data indicates transfer of the good using a unit system unique to the good.   The audit department generates data on uniqueness of transactions of goods identified by the ID specified in the audit request as data supporting the audit by offsetting the goods transaction chain data. The information processing apparatus according to claim 1 or 2, wherein The transaction data includes data indicating an entity of the transaction,
The audit department offsets the goods transaction chain data to generate an asset identified by the ID specified in the audit request as data for supporting the audit, or a series of transactions of the asset The information processing apparatus according to any one of claims 1 to 3, wherein data relating to a subject who has started is generated. The transaction data includes data indicating an entity of the transaction,
The audit department offsets the goods transaction chain data to identify an entity that has initiated a series of transactions of the article identified by the ID specified in the audit request, or an entity at the end of the series of transactions. Generating data on a trade path of the good as data supporting the audit by tracing the other trade data indicating the trade of the good starting from the trade data including the started entity or the termination end entity. The information processing apparatus according to any one of claims 1 to 4, characterized by When the distribution channel of the goods is divided into a plurality of parts in the distribution process of the goods, the storage unit stores the pre-division ID which is the ID of the goods before the division of the distribution channels and the goods in the respective distribution channels after division. Store transaction data indicating correspondence with multiple post-division IDs that are IDs,
When the pre-division ID or the post-division ID is specified in the audit request, the audit unit is capable of both transaction data associated with the pre-division ID and transaction data associated with the post-division ID. The information processing apparatus according to any one of claims 1 to 5, wherein the goods transaction chain data is generated based on. The function of the audit unit is exhibited by the CPU of the information processing apparatus executing a computer program in which the function is implemented.
The information processing apparatus can access a storage unit that stores a first hash value, which is a hash value of the legitimate computer program,
When the CPU executes the computer program, a collating unit for acquiring a second hash value that is a hash value of the computer program to be executed and collating the first hash value with the second hash value is further provided. The information processing apparatus according to any one of claims 1 to 6, comprising: When the goods are sold from the first entity to the second entity, double-entry bookkeeping data representing the transfer of the goods and the acquisition of the consideration using the exchange algebra as the transaction description of the first entity side, and the second A computer capable of accessing a storage device which stores transaction data including double-entry bookkeeping data indicating acquisition of the goods and transfer of compensation using an exchange algebra as transaction descriptions on the subject side in association with IDs of the goods But,
Accepting an audit request specifying an ID of a good;
Goods transaction chain data, which is data obtained by projecting an element related to goods transactions, is generated from the sum of a plurality of pieces of transaction data associated with the ID specified in the audit request, and based on the goods transaction chain data Generating data to support an audit on trades of goods identified by the ID specified in the audit request;
An audit support method characterized by performing. When the goods are sold from the first entity to the second entity, double-entry bookkeeping data representing the transfer of the goods and the acquisition of the consideration using the exchange algebra as the transaction description of the first entity side, and the second A computer capable of accessing a storage device which stores transaction data including double-entry bookkeeping data indicating acquisition of the goods and transfer of compensation using an exchange algebra as transaction descriptions on the subject side in association with IDs of the goods To
A function for receiving an audit request specifying a certain goods ID;
Goods transaction chain data, which is data obtained by projecting an element related to goods transactions, is generated from the sum of a plurality of pieces of transaction data associated with the ID specified in the audit request, and based on the goods transaction chain data A function of generating data to support an audit on transactions of goods identified by an ID specified in the audit request;
Computer program to make it happen.

Images