WO2022270431A1 - 情報処理装置、情報処理方法およびプログラム - Google Patents

情報処理装置、情報処理方法およびプログラム Download PDF

Info

Publication number
WO2022270431A1
WO2022270431A1 PCT/JP2022/024302 JP2022024302W WO2022270431A1 WO 2022270431 A1 WO2022270431 A1 WO 2022270431A1 JP 2022024302 W JP2022024302 W JP 2022024302W WO 2022270431 A1 WO2022270431 A1 WO 2022270431A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
invoice
document data
recipient
issuer
Prior art date
Application number
PCT/JP2022/024302
Other languages
English (en)
French (fr)
Inventor
手島太郎
Original Assignee
Ｂａｎｋ Ｉｎｖｏｉｃｅ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ｂａｎｋ Ｉｎｖｏｉｃｅ株式会社 filed Critical Ｂａｎｋ Ｉｎｖｏｉｃｅ株式会社
Publication of WO2022270431A1 publication Critical patent/WO2022270431A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services

Definitions

  • the present invention relates to an information processing device, an information processing method, and a program.
  • Blockchain for example, is known as a method of protecting business document information from being tampered with. This blockchain performs a so-called mining process at regular intervals to form a consensus. Also known is a technique that enables viewing of business documents (for example, invoices) of an entire company or an entire corporate group and centralized management of the information.
  • the received business document data is associated with the identification information of the recipient and the identification information of the issuer of the business document data. and at least one of the number of changes in the status indicating the progress of processing relating to business document data between the issuer and the recipient, or the number of changes in data accompanying the business document data.
  • a determination unit for determining whether or not the number of times has been reached, a transmission unit for accumulating business document data and data attached to the business document data when a predetermined number of times has been reached, and transmitting the data to a plurality of consensus building devices for consensus building; is known.
  • the present invention aims to generate new profits in the field of accounting.
  • the disclosed information processing device receives document data related to a business document sent from a terminal device to a specific recipient through a network, the received document data is processed by identifying the recipient and the document data issuer.
  • a storage unit that associates and stores identification information; a document that receives document data and generates unique tokens for the issuer and the recipient that can be exchanged for currency in the future; and a processing unit that stores the data in the storage unit in association with the data.
  • new profits can be generated in the accounting field.
  • FIG. 1 illustrates a bill management system according to a first embodiment
  • FIG. It is a figure explaining an example of the screen displayed on a terminal device after login. It is a figure which shows the hardware constitutions of the invoice management apparatus of embodiment.
  • 3 is a block diagram showing functions of the invoice management device of the embodiment;
  • FIG. It is a figure explaining an example of invoice data. It is an example of information stored in a token storage unit. It is an example of information stored in a token storage unit. It is a figure explaining the information displayed on an outline
  • 3 is a block diagram illustrating functions of a database according to an embodiment; FIG.
  • FIG. 4 is a flowchart for explaining processing of a data processing unit associated with transmission/reception of invoice data; It is a flow chart explaining deposit processing.
  • FIG. 10 is a flowchart for explaining processing for managing the amount of tokens generated; FIG.
  • FIG. 1 is a diagram showing an invoice management system according to the first embodiment.
  • an invoice management device 1 is connected to terminal devices 2a, 2b, and 2c via a network such as the Internet or a dedicated line.
  • the terminal device 2a is for company A
  • the terminal device 2b is for company B
  • the terminal device 2c is for company C
  • the terminal devices 2a, 2b, and 2c are devices located in the accounting departments of different companies. Examples of the terminal devices 2a, 2b, and 2c include desktop PCs, notebook PCs, tablet terminals, and smart phones.
  • the invoice management device 1 and the terminal devices 2a, 2b, and 2c are equipped with web programs.
  • the terminal devices 2a, 2b, and 2c exchange invoice data related to invoices with the invoice management apparatus 1 via Web browsers.
  • exchange of invoice data is exemplified, but an invoice is an example of a business document, and the present invention is not limited to exchange of invoices.
  • Other examples of business documents include, for example, quotations and purchase orders.
  • the invoice management device 1 sends information (such as file hashes) to be written to the blockchain to the network.
  • the information to be written is invoice data and data attached to the invoice data.
  • Databases 3 a , 3 b , 3 c are connected to each other via blockchain network 20 .
  • the databases 3a, 3b, and 3c generate an irreversible random hash function uniquely determined based on some data.
  • the bill management system 10 is used by accounting personnel from companies A, B, and C. As shown in FIG.
  • Each of the accounting personnel of Company A, Company B, and Company C performs user registration on the invoice management apparatus 1 using their assigned email address, etc., and thereby creates invoices constructed by the invoice management apparatus 1. Prepare the environment for accessing the processing system.
  • a person in charge of accounting at Company A operates the terminal device 2a, so that the invoice management device 1 displays a login screen on the monitor connected to the terminal device 2a.
  • the person in charge of accounting can log in to the service provided by the invoice management apparatus 1 by entering the e-mail address and password on the login screen.
  • the e-mail address is an example of identification information that identifies the person in charge of accounting.
  • the terminal devices 2a, 2b, and 2c can execute processing related to invoice data, which is the electronic version of the original invoice itself, via the invoice management device 1.
  • Types of processing include, for example, creation, transmission/reception, viewing, and editing of invoice data.
  • the person in charge of accounting of company A issues an invoice to company B
  • the person in charge of accounting of company A operates the terminal device 2a to display the billing address on the management screen displayed after login.
  • the invoice data specifying the e-mail address of the person in charge of accounting (recipient) of Company B is sent to the destination of the created invoice.
  • the bill management apparatus 1 stores the transmitted bill data.
  • the bill management apparatus 1 gives the terminal devices 2a, 2b, and 2c authority to view and edit bill data as necessary. In this manner, the original bill itself can be digitized and processed electronically. Therefore, it is possible to save the trouble of managing and storing bills by paper or PDF.
  • FIG. 2 is a diagram illustrating an example of a screen displayed on the terminal device after login.
  • a management screen 110 shown in FIG. 2 is an example of a screen displayed on the terminal device 2a.
  • the person in charge of accounting can create, issue, view, edit, etc. invoice data as if it were mail software.
  • the person in charge of accounting at company A cannot rewrite the invoice data once it has been sent.
  • the person in charge of accounting at Company B cannot rewrite the invoice data.
  • the bill data of the old version is stored by the bill management apparatus 1 without being discarded, and can be browsed at any time.
  • the invoice management apparatus 1 also manages the version number of invoice data, searching for new version invoice data from old version invoice data, and searching for old version invoice data from new version invoice data. can also be easily done. Details of the management screen 110 will be described later.
  • the invoice management device 1 When a new invoice data exchange (transaction) occurs, the invoice management device 1 notifies the databases 3a, 3b, and 3c of the details of the transaction.
  • the administrators of the databases 3a, 3b, and 3c refer to their own databases to check whether there is any fraudulent exchange of new invoice data.
  • Consensus building methods include, for example, proof of work and proof of stake.
  • FIG. 3 is a diagram showing the hardware configuration of the invoice management device according to the embodiment.
  • the invoice management device 1 is entirely controlled by a CPU (Central Processing Unit) 101 .
  • a RAM (Random Access Memory) 102 and a plurality of peripheral devices are connected to the CPU 101 via a bus 108 .
  • the RAM 102 is used as the main storage device of the invoice management device 1.
  • the RAM 102 temporarily stores at least part of an OS (Operating System) program and application programs to be executed by the CPU 101 .
  • OS Operating System
  • Various data used for processing by the CPU 101 are stored in the RAM 102 .
  • a hard disk drive (HDD) 103 , a graphics processing device 104 , an input interface 105 , a drive device 106 and a communication interface 107 are connected to the bus 108 .
  • the hard disk drive 103 magnetically writes data to and reads data from the built-in disk.
  • the hard disk drive 103 is used as a secondary storage device for the invoice management device 1 .
  • the hard disk drive 103 stores OS programs, application programs, and various data.
  • a semiconductor storage device such as a flash memory can also be used as the secondary storage device.
  • a monitor 104a is connected to the graphics processing unit 104.
  • the graphics processing unit 104 displays an image on the screen of the monitor 104a in accordance with an instruction from the CPU 101.
  • FIG. Examples of the monitor 104a include a display device using a CRT (Cathode Ray Tube), a liquid crystal display device, and the like.
  • a keyboard 105a and a mouse 105b are connected to the input interface 105.
  • the input interface 105 transmits to the CPU 101 signals sent from the keyboard 105a and the mouse 105b.
  • the mouse 105b is an example of a pointing device, and other pointing devices can also be used.
  • Other pointing devices include, for example, touch panels, tablets, touch pads, trackballs, and the like.
  • the drive device 106 reads data recorded in a portable recording medium such as an optical disc on which data is recorded so as to be readable by light reflection, or a USB (Universal Serial Bus) memory, for example.
  • a portable recording medium such as an optical disc on which data is recorded so as to be readable by light reflection, or a USB (Universal Serial Bus) memory, for example.
  • the drive device 106 is an optical drive device, data recorded on the optical disc 200 is read using a laser beam or the like.
  • the optical disc 200 includes Blu-ray (registered trademark), DVD (Digital Versatile Disc), DVD-RAM, CD-ROM (Compact Disc Read Only Memory), CD-R (Recordable)/RW (ReWritable), and the like. .
  • the communication interface 107 is connected to the network 50. Communication interface 107 transmits and receives data to and from other computers or communication devices via network 50 .
  • FIG. 4 is a block diagram showing functions of the invoice management apparatus according to the embodiment.
  • the invoice management device 1 includes a data processing unit 11, an invoice data storage unit 12, an external contact data storage unit 13, an attached file data storage unit 14, a history data storage unit 15, and a memo data storage unit 16. , a block data generation unit 17 and a token storage unit 18 .
  • the data processing unit 11 displays the management screen 110 shown in FIG. 2 on the terminal device 2a or the like in accordance with the operation of the accounting staff.
  • the data processing unit 11 executes processing according to exchange of invoice data performed via the management screen 110 .
  • the data processing unit 11 distributes and stores bill data received by the bill management apparatus 1, external communications (described later), memos, etc. created by an accounting person in each storage unit.
  • the data processing unit 11 for example, when an accounting person in charge of company A creates invoice data addressed to company B and the invoice management apparatus 1 receives the invoice data, A unique token (hereinafter referred to as BI token) is given.
  • BI token A unique token
  • the data processing unit 11 gives a BI token to each of the billing source and the billing destination of the bill data each time each company transmits and receives bill data.
  • This BI token can be generated, for example, by the transaction data generation unit 17 managing bill data (suppressing falsification of bill data) using blockchain technology.
  • the BI token has information that can identify billing data.
  • the transaction data generation unit 17 gives the BI token generated by the blockchain technology
  • the data processing unit 11 gives the BI token to each of the billing source and the billing destination of the bill data at the timing of sending and receiving the bill data.
  • the data processing unit 11 stores the issued amount of BI tokens generated by the transaction data generating unit 17 and the grant amount of already granted BI tokens in the token storage unit 18 .
  • this BI token can be treated as a claim with a value that can be converted into virtual currency or legal currency.
  • the data processing unit 11 monitors the amount of BI tokens issued. Then, when the number of issued BI tokens exceeds a certain number, the administrator of the invoice management apparatus 1 may purchase the BI tokens at a set rate. If the BI token is not listed, the set rate is, for example, a rate predetermined by the administrator of the invoice management device 1 . Also, if the BI token is listed, the set rate is determined based on the listing price of the exchange, for example.
  • the granted BI tokens can be managed individually for each predetermined unit.
  • This unit includes, for example, an individual unit, a corporate unit, an internal department unit (department, section), and the like. In this embodiment, it is assumed to be a corporation unit.
  • the invoice data storage unit 12 stores the invoice data received by the invoice management apparatus 1 for each person in charge of accounting (specifically, for each e-mail address of the person in charge of accounting).
  • the invoice data received by the invoice management apparatus 1 may be invoice data sent by the accounting staff of the billing source to the accounting staff of the billing destination, or bill data created as a draft by the accounting staff of the billing source (issuer). Contains invoice data.
  • FIG. 5 is a diagram illustrating an example of invoice data. In this embodiment, data is tabulated and stored.
  • the invoice data management table T1 has columns for invoice ID, transmission/reception, date/time of transmission/reception, person in charge status, partner status, person in charge address, name of person in charge, address of partner, and name of partner in charge. Information arranged in the horizontal direction is associated with each other.
  • invoice ID column an ID unique to invoice data is stored for managing the invoice data.
  • the invoice ID is assigned to the invoice data by the data processing unit 11 when the invoice management apparatus 1 receives the invoice data.
  • a classification is set to indicate whether the invoice data is received invoice data or transmitted invoice data as viewed from the accountant. Specifically, “receive” is set for received bill data, and “send” is set for transmitted bill data. The most recent date and time among the dates and times when the invoice data was sent and received is stored in the column of date and time of transmission. The status of invoice data (progress regarding processing) as seen from the person in charge of accounting is set in the person in charge status column.
  • the partner status column contains the status of bill data as seen from the accountant of the partner with whom the bill data is exchanged.
  • the statuses set in the person in charge status column and the other party status column include "unopened”, “returning”, “destroyed by the other party”, “confirmed”, “paid”, “storage box”, and “sent”. "Done”, “Returned”, “Destroyed”, and “Deposited”. Details of each status will be described later.
  • the email address of the person in charge of accounting is stored in the person in charge address column.
  • the name of the person in charge of accounting is stored in the name of person in charge column.
  • the counterparty address column stores the e-mail address of the accountant with whom the invoice data is exchanged.
  • the name of the person in charge of the other party stores the name of the other party with whom the invoice data is exchanged.
  • the information stored in the invoice data management table includes the company name and department name of the person in charge of accounting, the company name and name of the person in charge of accounting with whom the invoice data is exchanged, and It contains data related to invoices, such as department name, postal code of each company, address, billing items, billing amount, etc.
  • FIG. 6 is an example of information stored in the token storage unit.
  • the wallet management table T2 shown in FIG. 6 has columns for the address of the person in charge and the wallet number. Information arranged in the horizontal direction is associated with each other.
  • the wallet number column stores the number that identifies the deposit destination of the currency obtained by converting BI tokens. There may be one wallet or multiple wallets.
  • the currency may be virtual currency or legal currency.
  • the type of wallet is not particularly limited, and can be specified by the person in charge of accounting when creating the invoice data, for example. In addition, the timing of redemption is also arbitrary.
  • the wallet may also store information indicating when and at what rate it was redeemed.
  • FIG. 6 shows an example in which the grant amount and wallet are set for each person in charge
  • the grant amount and wallet may be set in arbitrary units (for example, by department or company).
  • the application amount may be set on a daily basis, a weekly basis, a monthly basis, or the like.
  • FIG. 7 is an example of information stored in the token storage unit.
  • the grant token management table T3 shown in FIG. 7 has columns for company name ID, person in charge address, transaction date and time, grant amount at transmission, grant amount at reception, total grant amount, remaining amount, total issued amount, and redemption. ing. Information arranged in the horizontal direction is associated with each other. Information for identifying a company name is set in the company name ID. The email address of the person in charge of rights is stored in the column of person in charge address. The amount of BI tokens given by the data processing unit 11 when the bill data is sent by the person in charge of accounting is stored in the column of the amount given at the time of transmission. The amount of BI tokens given by the data processing unit 11 when the bill data is sent by the person in charge of accounting is stored in the column of amount given at reception.
  • the total grant amount column stores the total amount of BI tokens granted during the exchange of invoice data.
  • the amount obtained by subtracting the total applied amount from the total generated amount is stored in the remaining amount column.
  • the column of total generated amount stores the generated amount of BI tokens generated so far.
  • the repurchase column stores the amount of BI tokens repurchased by the data management device 1 .
  • the data processing unit 11 confirms that the total generated amount matches (1000 in the present embodiment) each time a BI token is given.
  • the data processing unit 11 sets the transmission and reception of invoice data as one set, and gives each of the transmission and reception parties a predetermined amount of BI tokens.
  • the data processing unit 11 Upon receiving a buyback request from an accountant at an arbitrary timing, the data processing unit 11 converts the accepted amount of BI tokens into money at a set rate and deposits the BI tokens into the accountant's wallet. Next, the management screen will be explained. ⁇ Management screen> The data processing unit 11 displays the management screen 110 shown in FIG. 2 on the terminal device 2a or the like according to the operation of the person in charge of accounting.
  • the management screen 110 includes a user information display section 111, a status display section 112, a summary display section 113, an invoice display section 114, an external contact button 115, an attached file button 116, a history button 117, a memo button 118, and an external contact list.
  • a button 119, a memo list button 120, an information display section 121, an information input section 122, and a token exchange button 123 are displayed.
  • the user information display section 111 displays information (user information) about the person in charge of accounting who has logged in to the invoice management system.
  • information user information
  • FIG. 2 as an example, the name of the company to which the person in charge of accounting belongs, the name of the department, the name of the person in charge of accounting, and the e-mail address of the person in charge of accounting are displayed.
  • the status display section 112 the number of invoice data handled by the accounting staff logged in to the invoice management system is displayed for each status. Roughly divided, the status display section 112 is provided with columns for a reception box, a draft, a transmission box, and a transmission and reception box.
  • the data processing unit 11 allocates the invoice data destined for the e-mail address of the person in charge of accounting to the receiving box.
  • the data processing unit 11 When the person in charge of accounting selects the reception box, the data processing unit 11 refers to the invoice data management table T1. Then, out of the invoice data whose person-in-charge address matches “bbb@xxmail.co.jp”, outlines of the invoice data whose transmission/reception column is “received” are displayed on the outline display portion 113 .
  • the breakdown of the status of the invoice data assigned to the Inbox is "Unopened”, “Returning”, “Destroyed”, “Confirmed”, “Paid”, and "Storage Box". There is.
  • the "unopened" status is assigned by the data processing unit 11 to invoice data that has not been confirmed by the person in charge of accounting among the invoice data assigned to the Inbox.
  • the "returning" status is a status assigned by the data processing unit 11 to the invoice data returned by the accounting staff to the accounting staff of the billing source among the invoice data allocated to the receiving box.
  • the status of "discarded by the other side" indicates that the received invoice data among the invoice data allocated to the Inbox was discarded by the accounting staff after the accounting staff sent it back to the accounting staff of the requesting party. This is the status assigned by the data processing unit 11 to the invoice data.
  • the "confirmed" status is a status assigned by the data processing unit 11 to invoice data that has been viewed by an accounting staff and selected a confirmation button (described later) from among the invoice data allocated to the Inbox. .
  • the "paid" status is assigned by the data processing unit 11 to invoice data for which the accountant has made a payment and selected a payment button (not shown) among the invoice data allocated to the reception box. .
  • the person in charge of accounting can comprehend the payment details by summarizing the invoice data in the paid status.
  • the “storage box” status is a status assigned by the data processing unit 11 to bill data moved to a storage box at an arbitrary timing by an accountant among bill data with a status of “paid”.
  • Each number displayed in the status display section 112 indicates the number of assigned statuses. For example, in the unopened column of the status display section 112, the number of invoice data that has not been confirmed by the person in charge of accounting among the received invoice data is displayed. Note that no particular number is displayed in the storage box column of the status display section 112 .
  • the data processing unit 11 refers to the invoice data management table T1. Then, the data processing unit 11 displays, on the summary display unit 113, an outline of the invoice data whose person-in-charge status is unopened among the invoice data whose person-in-charge address matches “bbb@xxmail.co.jp”. do.
  • the data processing unit 11 allocates invoice data created and stored by the person in charge of accounting, but not yet transmitted to the person in charge of accounting as the transmission destination, to a draft.
  • the data processing unit 11 allocates the invoice data sent by the person in charge of accounting to the transmission BOX.
  • the data processing unit 11 When the person in charge of accounting selects the transmission box, the data processing unit 11 refers to the bill data management table T1. Then, out of the invoice data whose person-in-charge address matches “bbb@xxmail.co.jp”, outlines of the invoice data whose transmission/reception column is “send” are displayed on the outline display portion 113 .
  • the breakdown of the invoice data statuses assigned to the Outbox includes "Sent”, “Returned”, “Destroyed”, “Deposited”, and "Storage Box".
  • the "sent" status is assigned by the data processing unit 11 to invoice data for which payment has not been processed by the billing accountant, among the invoice data assigned to the transmission box.
  • the "return return" status is a status assigned by the data processing unit 11 to the invoice data returned from the billing accountant, among the invoice data assigned to the transmission BOX.
  • the person in charge of accounting can process the invoice data returned from the billing party.
  • the "discarded" status is a status assigned by the data processing unit 11 to the invoice data returned from the accounting staff of the billing destination that has been discarded by the accounting staff of the billing source.
  • the status of "paid” is given by the data processing unit 11 for invoice data for which the person in charge of accounting of the billing party has confirmed the payment and selected the payment button (not shown) among the invoice data allocated to the transmission box. This is the status to allocate.
  • the “storage box” status is a status assigned by the data processing unit 11 to bill data moved to a storage box at an arbitrary timing by an accounting staff among bill data with a “paid” status. No particular number is displayed in the storage box column of the status display section 112 .
  • the overview display portion 113 displays an overview of the invoice data corresponding to the status selected by the accounting staff in the status display portion 112, as described above.
  • the billing company name, subject, due date of payment, and status of sender and receiver are displayed.
  • the same statuses are displayed on the management screens of both accountants who have sent and received the invoice data.
  • 8 and 9 are diagrams for explaining information displayed in the overview display section.
  • FIG. 8 shows an overview 113a of invoice data displayed in the overview display section 113 of the management screen 110 viewed by the accounting staff of the billing destination, and an overview display section 113 of the management screen 110 viewed by the accounting staff of the billing source.
  • a summary 113b is shown in FIG.
  • the management screen of the terminal device operated by the accounting staff of the invoice source displays "Send” in the status display section. It is included in "Finished”.
  • the billing accountant selects "sent” in the status display section, the billing destination is ⁇ Corporation, the subject is ⁇ work, and the billing accountant's status is is “sent”, and the status of the billing accountant is "unopened”.
  • Outlines 113c, 113d, and 113e shown in FIG. 9(a) all represent outlines of the invoice data D2.
  • the data processing unit 11 displays the overview display unit 113 of the management screen 110 of the terminal device operated by the billing person in charge of accounting. changes the information displayed in the summary 113c to the summary 113d.
  • the data processing unit 11 displays the management screen 110 of the terminal device operated by the billing person in charge of accounting.
  • the information displayed in the summary display portion 113 is changed from the summary 113d to the summary 113e.
  • summaries 113f and 113g shown in FIG. 9B both show summaries of the invoice data D3.
  • the data processing unit 11 displays the The displayed information is changed from summary 113f to summary 113g. Returning to FIG. 2 again, description will be made.
  • the data processing section 11 displays the details of the bill data on the bill display section 114 .
  • the contents of the invoice displayed on the invoice display section 114 are the same as the existing (paper or PDF based) invoice except for the provision of the address display section 114a and various buttons described later.
  • the data processing unit 11 displays the mail address of the accounting staff (from) of the transmission source on the address display unit 114a.
  • the data processing unit 11 displays the mail address of the accounting staff (to) of the transmission destination.
  • the data processing unit 11 may display the invoice ID of the invoice data on the invoice display unit 114 .
  • the person in charge of accounting can process the invoice displayed in the invoice display section 114 on the management screen 110 .
  • a button for processing the invoice is displayed on the invoice display portion 114 according to the status of the invoice data.
  • FIG. 2 shows buttons displayed when invoice data whose status is unopened is selected.
  • the invoice display section 114 is provided with a confirmation button 114b, a return button 114c, and a copy button 114d.
  • the data processing unit 11 refers to the invoice data management table T1. Then, the status of the person in charge of the invoice data displayed on the invoice display section 114 is changed to "confirmed". In addition, the data processing unit 11 decreases the number of “unopened” in the status display unit 112 by one, and increases the number of “confirmed” by one.
  • the data processing unit 11 When the return button 114c is selected by the person in charge of accounting, the data processing unit 11 refers to the invoice data management table T1. Then, the status of the person in charge of the invoice data displayed on the invoice display section 114 is changed to "returning", and the other party's status is changed to "returned back". The data processing unit 11 also decrements the number of “unopened” in the status display unit 112 by one, and increases the number of “returning” by one. On the management screen of the person in charge of accounting who has received the returned bill data, the return return number in the status display section is incremented by one.
  • the data processing section 11 When the copy button 114d is selected by the person in charge of accounting, the data processing section 11 creates new bill data in which the company names and addresses of the billing source and the billing destination of the bill data are exchanged. Then, the data processing unit 11 stores information about the created invoice data in the invoice data management table T1. At this time, the person-in-charge status of the invoice data is "draft", and the counterparty status is blank. Returning to FIG. 2 again, description will be made.
  • the data processing unit 11 switches the management screen 110 to the external contact input mode.
  • the data processing unit 11 receives a document (text data) that has been input to the information input unit 122 and confirmed by pressing the enter key on the keyboard, etc., as an external contact, and It is stored in the external communication data storage unit 13 in association with the invoice data displayed in the address and invoice display unit 114 .
  • the data processing unit 11 switches the management screen 110 to the attached file mode.
  • the data processing unit 11 clicks and drags the attached data to the information input unit 122, presses the enter key on the keyboard, etc., and sends the attached data to the e-mail address of the person in charge of accounting and the invoice display unit.
  • 114 is stored in the attached file data storage unit 14 in association with the invoice data displayed.
  • the data processing unit 11 stores the operation history (history data) of both accountants in the history data storage unit 15 .
  • the data processing unit 11 switches the management screen 110 to memo input mode.
  • the data processing unit 11 converts characters, etc., which are input to the information input unit 122 and confirmed by pressing the enter key on the keyboard, etc., into a memo, and displays the e-mail address and invoice of the accountant.
  • the data is stored in the memo data storage unit 16 in association with the invoice data displayed in the unit 114 . This memo can be viewed only by the person who created the memo.
  • the data processing unit 11 refers to the external contact data storage unit 13 in which data related to external contact is stored,
  • the external communication list screen (external communication list screen) is displayed on the management screen 110 in chronological order.
  • the data processing unit 11 refers to the memo data storage unit 16 in which data related to external contact is stored, and selects the memo related to the bills handled by the person in charge of accounting.
  • list screen (memo list screen) is displayed on the management screen 110 in chronological order.
  • the data processing unit 11 converts the amount of the invoice currently displayed on the invoice display unit 114 into cash using the BI token (payment processing). to run. This process will be detailed later. Returning to FIG. 4 again, description will be made.
  • the transaction data generation unit 17 accumulates the transaction data stored in the storage units 12 to 16 up to that point at the timing when the transaction data is updated a predetermined number of times, signs the transaction data, and forms a consensus database 3a, 3b, 3c.
  • the transaction data includes at least one of invoice data, invoice data status, external contact data, attached file data, history data, and memo data.
  • FIG. 10 is a block diagram for explaining functions of the database according to the embodiment.
  • the database 3 a has a storage unit 31 , a transmission/reception unit 32 , a block header generation unit 33 and a consensus formation unit 34 .
  • a block 311 and a database list 312 are stored in the storage unit 31 .
  • the information stored in the storage unit 31 is not limited to these.
  • a block 311 is a block of information (transaction) to be registered in a block chain, such as an individual transaction history or a block of processing in a computer, added with information necessary for configuring the block chain.
  • 11 is a diagram illustrating an example of information included in the blockchain according to the embodiment; FIG. Block 311 includes block number 311a, time stamp 311b, and transaction list 311c.
  • the block number 311a is information for identifying the block 311 concerned.
  • the timestamp 311b is the timestamp of the newly created block.
  • the transaction list 311c is a collection of transaction histories and computer processing. Here, it refers to a list of information to be registered in the blockchain. Specifically, it includes invoice data, external contact data, attached file data, history data and memo data, billing source wallet number of bill data, and billing destination wallet number.
  • the database list 312 is a list storing identification information (for example, IP addresses) identifying other databases connected to the blockchain network 20 .
  • the transmitting/receiving unit 32 receives data to be recorded in the block 311 (data to be recorded) from the invoice management apparatus 1 .
  • the block header generator 33 generates a hash value using a hash function for data to be recorded. Also, the block header generation unit 33 generates a block header using the generated hash value, the hash value of the previous block, and the time stamp 311b.
  • the consensus building unit 34 calculates a hash value of the block header by putting an appropriate value in the nonce “Nonce” generated by the block header generation unit 33 .
  • FIG. 12 is a flowchart for explaining the processing of the data processing unit associated with the transmission and reception of invoice data.
  • the data processing unit 11 updates the invoice data management table T1. Further, the data processing unit 11 refers to the grant token management table T3, and increases the grant amount at the time of transmission of the accountant who transmitted the invoice data by a predetermined amount. Then, the data processing unit 11 sets an amount obtained by subtracting the amount given at transmission from the remaining amount of the record one level above in the remaining amount column. Add the grant amount at the time of transmission to the total grant amount. In addition, the data processing unit 11 increases the amount given to the person in charge of accounting who has received the invoice data by a predetermined amount. Then, the data processing unit 11 sets an amount obtained by subtracting the amount given at transmission from the remaining amount of the record one level above in the remaining amount column.
  • FIG. 13 is a flowchart for explaining deposit processing.
  • Step S12 The data processing unit 11 issues a payment ID for the invoice data for which selection has been accepted.
  • This payment ID is a number obtained by hashing information from who to whom, when and how much in a block transaction. After that, the process transitions to step S13.
  • the data processing unit 11 stores the issued payment ID in the payment ID column of the corresponding invoice data in the invoice data management table T1. For example, in the example shown in FIG. 5, separate payment IDs are stored for bill IDs "001" and "002". Therefore, these are invoice data recorded in separate blocks. Also, the same payment ID is stored for each of the invoice IDs "003" and "004". Therefore, these are invoice data recorded in the same block.
  • the data processing unit 11 determines whether or not the aforementioned approval process has been executed. After the approval process is executed, the process proceeds to step S14.
  • Step S14 Using the payment ID, the data processing unit 11 confirms whether the data stored in the block 311 has been approved. Notifications from each database 3a to 3c may be received.
  • Step S15 If the data stored in the block 311 is approved to be added to an existing block, the data processing unit 11 changes the person-in-charge status and counterparty status of the corresponding invoice in the invoice data management table T1. to a status indicating that the payment has been completed. Specifically, the person in charge status is changed from "sent" to "paid”. Change the partner status from "unopened” or "confirmed” to "paid”. By the processing shown in FIG. 13, it is possible to automate the payment processing of the billed amount described in the invoice data. Next, processing for managing the amount of generated tokens will be described using a flowchart.
  • FIG. 14 is a flowchart illustrating processing for managing the amount of generated tokens.
  • the data processing unit 11 refers to the total generated amount column of the token grant management table T3. After that, the process transitions to step S22.
  • Step S22 The data processing unit 11 determines whether or not the total generated amount is equal to or greater than a predetermined amount.
  • This predetermined amount is, for example, an amount preset by an administrator of the data management device 1 . If the total generated amount is equal to or greater than the predetermined amount (Yes in step S22), the process proceeds to step S23. If the total generated amount is less than the predetermined amount (No in step S22), the process of FIG. 14 ends.
  • Step S23 The data processing unit 11 determines whether or not the BI token is listed. If the BI token is listed (Yes in step S23), the process proceeds to step S24. If the BI token is not listed (No in step S23), the process proceeds to step S25. [Step S24] The data processing unit 11 deposits the currency obtained by converting the BI token into the listed value to the wallet. After that, the process transitions to step S25.
  • Step S25 The data processing unit 11 deposits the currency converted from the BI token at the pre-assigned rate into the wallet. After that, the process transitions to step S26.
  • the data processing unit 11 refers to the grant token management table T3 and updates the remaining amount and total grant amount columns. Specifically, the data processing unit 11 increases the remaining amount by the repurchased amount. It also reduces the total production by the amount bought back. After that, the process of FIG. 14 ends.
  • the repurchased BI tokens may be made permanently unusable (introduction of the Burn system).
  • the repurchased BI token may be temporarily disabled (introduction of a lockup system). This makes it possible to control the scarcity of BI tokens by reducing the amount of BI tokens on the market.
  • bill management device 1 when the bill management device 1 receives the bill data transmitted from the terminal devices 2a, 2b, and 2c to a specific recipient via the network, bill data storage unit 12 for storing the bill data in association with the identification information of the recipient and the identification information of the issuer of the bill data; and a data processing unit 11 that generates unique BI tokens for the issuer and the recipient that can be exchanged with each other, associates the generated BI tokens with the received invoice data, and stores them in the grant token management table T3. Therefore, new profits can be generated in the accounting field.
  • the remittance fee that occurs when going through a bank is reduced to zero, and (when billing data collected in hundreds of parts is broken down into pieces when paying with virtual currency), for billing data 1 1 can be paid.
  • remittance and payment can be executed immediately on the day when the bill data is transmitted to the bill management apparatus 1 .
  • Third party (bank) credit is not required for settlement.
  • the BI token used for payment has information that can identify the billing data, and when the receiving side selects the payment amount (token), the billing data corresponding to the BI token is displayed on the screen. , the breakdown of the bill can also be understood. This makes it possible to automate the deposit processing on the side that received the deposit.
  • BI tokens become redeemable, for example, the accounting department will transform from a cost center to a profit center. This can facilitate the digitization (DX) of invoices on a global scale.
  • BI token generation is not limited to when bill data is sent or received.
  • the BI token may be generated when the bill data recipient selects the "confirm” button or when the bill data issuer selects the "paid” button.
  • the invoice management apparatus 1 may have the functions of the databases 3a, 3b, and 3c.
  • the information display section 121 displays external communications entered by the accounting personnel of both the sender and receiver of the invoice data. Therefore, by using this external communication input mode, the two accounting staff can communicate like a chat.
  • the processing performed by the invoice management apparatus 1 may be distributed by a plurality of apparatuses.
  • the invoice management apparatus 1 is configured to include storage units such as the invoice data storage unit 12 , but the present invention is not limited to this. It may be provided in the place of
  • the information processing apparatus, information processing method, and program of the present invention have been described above based on the illustrated embodiments, but the present invention is not limited to this, and the configuration of each part has the same function. Any configuration can be substituted. Also, other optional components and steps may be added to the present invention. Moreover, the present invention may be a combination of any two or more configurations (features) of the above-described embodiments.
  • the above processing functions can be realized by a computer.
  • a program describing the processing contents of the functions of the invoice management apparatus 1 is provided.
  • the above processing functions are realized on the computer.
  • a program describing the processing content can be recorded in a computer-readable recording medium.
  • Examples of computer-readable recording media include magnetic storage devices, optical disks, magneto-optical recording media, and semiconductor memories.
  • Magnetic storage devices include hard disk drives, flexible disks (FD), magnetic tapes, and the like.
  • Optical discs include DVD, DVD-RAM, CD-ROM/RW, and the like.
  • Magneto-optical recording media include MO (Magneto-Optical disk) and the like.
  • a computer that executes a program stores, for example, a program recorded on a portable recording medium or a program transferred from a server computer in its own storage device. The computer then reads the program from its own storage device and executes processing according to the program. The computer can also read the program directly from the portable recording medium and execute processing according to the program. In addition, the computer can also execute processing according to the received program every time the program is transferred from a server computer connected via a network.
  • DSPs Digital Signal Processors
  • ASICs Application Specific Integrated Circuits
  • PLDs Protein Deformation Deformation Devices

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Human Resources & Organizations (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Quality & Reliability (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

請求書管理装置１は、端末装置２ａ、２ｂ、２ｃから特定の受取人に向けて送信された請求書データをネットワークを通じて受信すると、受信した請求書データを、受取人の識別情報と、請求書データの発行者の識別情報と、を関連づけて記憶する請求書データ記憶部１２と、請求書データの受信に対応して、将来、通貨と交換可能な発行者および受取人に対するそれぞれ固有のＢＩトークンを生成し、生成したＢＩトークンを受信した請求書データと関連づけて付与トークン管理テーブルに記憶するデータ処理部１１と、を有する。

Description

情報処理装置、情報処理方法およびプログラム
　本発明は情報処理装置、情報処理方法およびプログラムに関する。
　ビジネス文書情報を改ざんから守る方法として、例えばブロックチェーンが知られている。このブロックチェーンは、一定時間毎に所謂マイニング処理を行い、合意形成を行う。
　また、会社全体または企業グループ全体のビジネス文書（例えば、請求書等）の閲覧とその情報の一元管理を可能とする技術が知られている。
　例えば、端末装置から特定の受取人に向けて送信されるビジネス文書データをネットワークを通じて受信すると、受信したビジネス文書データを、受取人の識別情報と、ビジネス文書データの発行者の識別情報とを関連づけて記憶する記憶部と、発行者と受取人との間でのビジネス文書データに関する処理の進捗状況を示すステータスの変更回数または当該ビジネス文書データに付随するデータの変更回数のうち、少なくとも一方が所定回数に達するか否かを判断する判断部と、所定回数に達するとビジネス文書データおよび当該ビジネス文書データに付随するデータを集積し、合意形成を行う複数の合意形成装置に送信する送信部と、を備える情報処理装置が知られている。
国際公開第２０２０／００９１１８号
　ブロックチェーン技術を使用すると、何らかの価値付けがなされたトークンが発行されることが知られている。このトークンをビジネス文書データの分野に適用することが考えられる。
　特に、今まで利益を生み出さないとされてきた経理分野にトークンを適用すれば、新たな利益を生み出すことが期待できる。
　１つの側面では、本発明は、経理分野における新たな利益を生み出すことを目的とする。
　上記目的を達成するために、開示の情報処理装置が提供される。この情報処理装置は、端末装置から特定の受取人に向けて送信されたビジネス文書に関する文書データをネットワークを通じて受信すると、受信した前記文書データを、受取人の識別情報と、文書データの発行者の識別情報と、を関連づけて記憶する記憶部と、文書データの受信に対応して、将来、通貨と交換可能な発行者および受取人に対するそれぞれ固有のトークンを生成し、生成したトークンを受信した文書データと関連づけて前記記憶部に記憶する処理部と、を有する。
　１態様では、経理分野における新たな利益を生み出すことができる。
第１の実施の形態の請求書管理システムを示す図である。 ログイン後の端末装置に表示される画面の一例を説明する図である。 実施の形態の請求書管理装置のハードウェア構成を示す図である。 実施の形態の請求書管理装置の機能を示すブロック図である。 請求書データの一例を説明する図である。 トークン記憶部に記憶される情報の一例である。 トークン記憶部に記憶される情報の一例である。 概要表示部に表示される情報を説明する図である。 概要表示部に表示される情報を説明する図である。 実施の形態のデータベースが有する機能を説明するブロック図である。 実施の形態のブロックチェーンに含まれる情報の一例を示す図である。 請求書データの送受信に伴うデータ処理部の処理を説明するフローチャートである。 入金処理を説明するフローチャートである。 トークンの生成量を管理する処理を説明するフローチャートである。
　以下、実施の形態の請求書管理システムを、図面を参照して詳細に説明する。
　＜第１の実施の形態＞
　図１は、第１の実施の形態の請求書管理システムを示す図である。
　第１の実施の形態の請求書管理システム１０は、請求書管理装置１が、インターネットや専用回線等のネットワークを介して端末装置２ａ、２ｂ、２ｃに接続されている。
　端末装置２ａは、Ａ社、端末装置２ｂはＢ社、端末装置２ｃはＣ社等、端末装置２ａ、２ｂ、２ｃは、それぞれ異なる会社の経理部門に配置されている装置である。端末装置２ａ、２ｂ、２ｃとしては、例えばデスクトップＰＣ、ノートＰＣ、タブレット端末、スマートフォン等が挙げられる。
　請求書管理装置１と、端末装置２ａ、２ｂ、２ｃはＷｅｂプログラムを実装している。端末装置２ａ、２ｂ、２ｃは、Ｗｅｂブラウザを介して請求書に関する請求書データを請求書管理装置１とやりとりする。なお、本実施の形態では請求書データのやりとりを例示するが、請求書はビジネス文書の一例であり、本発明は請求書のやりとりに限定されない。ビジネス文書の他の例としては、例えば見積書や注文書等が挙げられる。
　請求書管理装置１は、ブロックチェーンに書き込みたい情報（ファイルのハッシュ等）をネットワークに流す。書き込みたい情報としては、本実施の形態では請求書データおよび請求書データに付随するデータである。
　データベース３ａ、３ｂ、３ｃはブロックチェーンネットワーク２０を介して互いに接続されている。
　データベース３ａ、３ｂ、３ｃは、何らかのデータを基に一義に決まり、且つ、不可逆でランダムなハッシュ関数を生成する。
　以下、請求書管理システム１０をＡ社、Ｂ社、Ｃ社の各経理担当者が利用するものとして説明する。
　Ａ社、Ｂ社、Ｃ社の各経理担当者は、それぞれ自己に割り当てられたＥｍａｉｌアドレス等を用いて請求書管理装置１にユーザ登録を行うことにより、請求書管理装置１が構築する請求書処理システムにアクセスする環境を整える。
　その後、例えばＡ社の経理担当者が端末装置２ａを操作することにより、請求書管理装置１が端末装置２ａに接続されたモニタにログイン画面を表示させる。経理担当者はログイン画面にメールアドレスおよびパスワードを入力することにより、請求書管理装置１が提供するサービスにログインすることができる。なお、メールアドレスは、経理担当者を識別する識別情報の一例である。
　端末装置２ａ、２ｂ、２ｃは、ログイン後に、請求書の原本そのものを電子化した請求書データに関する処理を、請求書管理装置１を介して実行することができる。処理の種別としては、例えば、請求書データの作成、送受信、閲覧、編集等が挙げられる。
　例えば、Ａ社の経理担当者がＢ社宛に請求書を発行する際には、Ａ社の経理担当者は、端末装置２ａを操作することにより、ログイン後に表示される管理画面にて請求先をＢ社とする請求書を作成する。そして、作成した請求書の送付先にＢ社の経理担当者（受取人）のメールアドレスを指定した請求書データを送信する。送信された請求書データは、請求書管理装置１が保管する。
　すなわち、端末装置２ａ、２ｂ、２ｃ間で請求書データを直接やりとりするのではなく、端末装置２ａ、２ｂ、２ｃで作成され、請求先に送信された全ての請求書データは請求書管理装置１が保管し共有データのような取扱いとなる。そして、請求書管理装置１は、必要に応じて請求書データの閲覧、編集権限を端末装置２ａ、２ｂ、２ｃに与える。
　このように、電子上で請求書原本そのもの電子化し、処理することができる。従って、紙やＰＤＦによる請求書の管理や保管の手間を省くことができる。
　なお、前述したように、端末装置２ａ、２ｂ、２ｃ間で請求書データを直接やりとりするのではなく、請求書管理装置１が保管しておくものである。しかし、以下の説明では、説明を分かり易くするために、例えばＡ社の経理担当者からＢ社の経理担当者のメールアドレスを宛先とする請求書データが送信された場合、
一般的な請求書データのやりとりと同じく、「経理担当者が請求書データを受信する」という表現を用いる場合がある。
　なお、請求書管理装置１と各端末装置２ａ、２ｂ、２ｃとの請求書データのやりとりは暗号化されるのが好ましい。
　図２は、ログイン後の端末装置に表示される画面の一例を説明する図である。
　図２に示す管理画面１１０は、端末装置２ａに表示される画面の一例である。
　図２に示すように、経理担当者は、メールソフトウェアのような感覚で請求書データの作成、発行、閲覧、編集等をすることができる。
　ところで、前述した例では、Ａ社の経理担当者は、一度送信した請求書データは書き替えることができない。また、Ｂ社の経理担当者も請求書データを書き替えることができない。請求書データに不備がある場合は、版数の異なる請求書データを再発行することになる。また、旧版の請求書データは、破棄されずに請求書管理装置１が保管し、いつでも閲覧できる状態になる。さらに、請求書管理装置１は、請求書データの版数管理も行い、旧版の請求書データから新版の請求書データを検索したり、新版の請求書データから旧版の請求書データを検索したりすることも容易に行うことができる。
　なお、管理画面１１０の詳細については、後に詳述する。
　新たな請求書データのやりとり（取引）が発生すると、請求書管理装置１は、データベース３ａ、３ｂ、３ｃに取引内容を通知する。データベース３ａ、３ｂ、３ｃの管理者は、自己の保有するデータベースを参照し、新たな請求書データのやりとりに不正がないか確認する。
　そして、データベースの更新権限者を決める合意形成を実施する。合意形成の方法としては、例えば、プルーフ・オブ・ワーク（Proof Of Work）やプルーフ・オブ・ステーク（Proof Of Stake）等が挙げられる。
　例えば、データベース３ａの管理者が最初に答えを発見したとすると、データベース３ａの管理者は、他のデータベース３ｂ、３ｃの参加者へ答えを発見した旨、通知する。
　このときデータベース３ａの管理者に何らかの報酬が払われてもよい。
　データベース３ａ、３ｂ、３ｃの管理者は、請求書管理装置１が通知した取引データを自己のデータベースに追加する。
　以下、開示の請求書管理システムをより具体的に説明する。
　図３は、実施の形態の請求書管理装置のハードウェア構成を示す図である。
　請求書管理装置１は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０８を介してＲＡＭ（Random Access Memory）１０２と複数の周辺機器が接続されている。
　ＲＡＭ１０２は、請求書管理装置１の主記憶装置として使用される。ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に使用する各種データが格納される。
　バス１０８には、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、ドライブ装置１０６、および通信インタフェース１０７が接続されている。
　ハードディスクドライブ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ハードディスクドライブ１０３は、請求書管理装置１の二次記憶装置として使用される。ハードディスクドライブ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、二次記憶装置としては、フラッシュメモリ等の半導体記憶装置を使用することもできる。
　グラフィック処理装置１０４には、モニタ１０４ａが接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１０４ａの画面に表示させる。モニタ１０４ａとしては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や、液晶表示装置等が挙げられる。
　入力インタフェース１０５には、キーボード１０５ａとマウス１０５ｂとが接続されている。入力インタフェース１０５は、キーボード１０５ａやマウス１０５ｂから送られてくる信号をＣＰＵ１０１に送信する。なお、マウス１０５ｂは、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、例えばタッチパネル、タブレット、タッチパッド、トラックボール等が挙げられる。
　ドライブ装置１０６は、例えば、光の反射によって読み取り可能なようにデータが記録された光ディスクや、ＵＳＢ（Universal Serial Bus）メモリ等の持ち運び可能な記録媒体に記録されたデータの読み取りを行う。例えば、ドライブ装置１０６が光学ドライブ装置である場合、レーザ光等を利用して、光ディスク２００に記録されたデータの読み取りを行う。光ディスク２００には、Ｂｌｕ－ｒａｙ（登録商標）、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ－ＲＡＭ、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ－Ｒ（Recordable）／ＲＷ（ReWritable）等が挙げられる。
　通信インタフェース１０７は、ネットワーク５０に接続されている。通信インタフェース１０７は、ネットワーク５０を介して、他のコンピュータまたは通信機器との間でデータを送受信する。
　以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３には請求書管理装置１のハードウェア構成を示したが、端末装置２ａ等、他のコンピュータも同様のハードウェア構成で実現することができる。
　図３に示すようなハードウェア構成の請求書管理装置１内には、以下のような機能が設けられる。
　図４は、実施の形態の請求書管理装置の機能を示すブロック図である。
　請求書管理装置１は、データ処理部１１と、請求書データ記憶部１２と、社外連絡データ記憶部１３と、添付ファイルデータ記憶部１４と、履歴データ記憶部１５と、メモデータ記憶部１６と、ブロックデータ生成部１７と、トークン記憶部１８とを有している。
　データ処理部１１は、経理担当者の操作に応じて図２に示す管理画面１１０を端末装置２ａ等に表示する。データ処理部１１は、管理画面１１０を介して行われる請求書データのやり取りに応じた処理を実行する。例えば、データ処理部１１は、請求書管理装置１が受信した請求書データや、経理担当者が作成した社外連絡（後述）やメモ等を各記憶部に振り分けて記憶させる。
　また、データ処理部１１は、例えばＡ社の経理担当者がＢ社宛ての請求書データを作成し、請求書管理装置１が請求書データを受信したときに、Ａ社およびＢ社それぞれに対し固有のトークン（以下、ＢＩトークンと言う）を付与する。本実施の形態では、各社が請求書データを送受信する度にデータ処理部１１が、請求書データの請求元および請求先それぞれにＢＩトークンを付与する。
　このＢＩトークンは、例えば、取引データ生成部１７が請求書データをブロックチェーン技術によって管理（請求書データの改ざんの抑制）することにより生成することができる。ＢＩトークンは、請求書データを特定できる情報を備えている。つまり、取引データ生成部１７がブロックチェーン技術によって生成したＢＩトークンを、データ処理部１１が請求書データの送受信のタイミングで請求書データの請求元および請求先それぞれにＢＩトークンを付与する。
　データ処理部１１は、取引データ生成部１７が生成したＢＩトークンの発行量と既に付与したＢＩトークンの付与量をトークン記憶部１８に記憶しておく。
　このＢＩトークンは例えば請求書管理装置１の管理元がＢＩトークンの価値を保証することにより、仮想通貨や法定通貨と換金できる価値を持つ債権として取り扱うことができる。
　また、ＢＩトークンは、審査を経て仮想通貨取引所（暗号資産交換業者）に、取り扱いを委託することも可能である。その場合、ＢＩトークンが上場され、ＢＩトークンが公開されて、ＢＩトークン自体のレートも変動する。換金するときもそのレートが適用される。
　また、データ処理部１１は、ＢＩトークンの発行量を監視する。そして、ＢＩトークンの発行量が一定数以上になった場合は、請求書管理装置１の管理元が設定レートでＢＩトークンを買い取るようにしてもよい。設定レートは、ＢＩトークンが上場していなければ、例えば、請求書管理装置１の管理元が予め定めたレートである。また、ＢＩトークンが上場している場合は、例えば取引所の上場価格に基づき設定レートが定まる。
　このように独自トークンの活用により、サービスを利用する経理担当者にインセンティブが生まれるため、従来のＥＤＩ（Electronic Data Interchange）等のシステムの利用に比べて請求書管理装置１の利用者の積極的利用を促進することができる。
　付与されたＢＩトークンは、所定の単位毎に個別に管理することができる。この単位は、例えば個人単位、法人単位、社内部署単位（部、課）等が挙げられる。本実施の形態では法人単位とする。
　請求書データ記憶部１２には、請求書管理装置１が受信した請求書データが、経理担当者毎（具体的には、経理担当者のメールアドレス毎）に記憶される。請求書管理装置１が受信する請求書データは、請求元の経理担当者が請求先の経理担当者宛に送信した請求書データや、請求元の経理担当者（発行者）が下書きとして作成した請求書データが含まれる。
　図５は、請求書データの一例を説明する図である。
　本実施の形態ではデータがテーブル化されて記憶されている。
　請求書データ管理テーブルＴ１には、請求書ＩＤ、送受信、送受信日時、担当者ステータス、相手ステータス、担当者アドレス、担当者名、相手アドレス、および相手担当者名の欄が設けられている。横方向に並べられた情報同士が互いに関連づけられている。
　請求書ＩＤの欄には、請求書データを管理するための請求書データ固有のＩＤが記憶されている。この請求書ＩＤは、請求書管理装置１が請求書データを受信した時点でデータ処理部１１が請求書データに割り振る。
　送受信の欄には、当該経理担当者から見て当該請求書データが、受信した請求書データなのか送信した請求書データなのかを示す区分が設定される。具体的には、受信した請求書データであれば「受信」、送信した請求書データであれば「送信」が設定される。
　送受信日時の欄には、当該請求書データを送受信した日時のうち、最新の日時が格納される。
　担当者ステータスの欄には、当該経理担当者から見た請求書データのステータス（処理に関する進捗）が設定される。
　相手ステータスの欄には、当該請求書データをやり取りをする相手の経理担当者から見た請求書データのステータスが設定される。
　担当者ステータスの欄および相手ステータスの欄に設定されるステータスには、「未開封」、「返送中」、「先方破棄」、「確認済」、「支払済」、「保管箱」、「送信済」、「返送戻り」、「破棄済」、「入金済」がある。各ステータスの内容については、後に詳述する。
　担当者アドレスの欄には、当該経理担当者のメールアドレスが格納される。
　担当者名の欄には、当該経理担当者の氏名が格納される。
　相手アドレスの欄には、当該請求書データをやり取りをする相手の経理担当者のメールアドレスが格納される。
　相手担当者名の欄には、当該請求書データをやり取りをする相手の名前が格納される。
　なお、請求書データ管理テーブルに記憶される情報としては、図示した情報以外にも、当該経理担当者の会社名および部署名、当該請求書データをやり取りをする相手の経理担当者の会社名および部署名、各会社の郵便番号、住所、請求項目、請求額等、請求書に関するデータが含まれる。
　次に、トークン記憶部１８に記憶される情報を説明する。トークン記憶部１８には、生成されたＢＩトークンの量に関する情報や、付与されたＢＩトークンの量に関する情報が記憶されている。
　図６は、トークン記憶部に記憶される情報の一例である。
　図６に示すウォレット管理テーブルＴ２には、担当者アドレスおよびウォレット番号の欄が設けられている。横方向に並べられた情報同士が互いに関連づけられている。
　ウォレット番号の欄には、ＢＩトークンを換金することにより得られる通貨の入金先を識別する番号が格納される。ウォレットは１つでもよいし、複数でもよい。通貨は仮想通貨でもよいし、法定通貨でもよい。ウォレットの種別は特に限定されず、例えば当該請求書データを作成する際に経理担当者が指定することができる。また、換金のタイミングも任意である。また、ウォレットには、いつ、どのレートで買い戻されたのかを示す情報を記憶するようにしてもよい。
　なお、図６では担当者毎に付与量およびウォレットを設定する例を示したが、これに限らず、任意の単位（例えば部署毎や会社毎）で付与量およびウォレットを設定してもよい。また、付与量は、日単位、週単位、月単位などで設定してもよい。
　図７は、トークン記憶部に記憶される情報の一例である。
　図７に示す付与トークン管理テーブルＴ３には、社名ＩＤ、担当者アドレス、取引日時、送信時付与量、受信時付与量、総付与量、残量、総発行量、および買い戻しの欄が設けられている。横方向に並べられた情報同士が互いに関連づけられている。
　社名ＩＤには、社名を識別する情報が設定される。
　担当者アドレスの欄には、権利担当者のメールアドレスが格納される。
　送信時付与量の欄には、当該経理担当者が請求書データを送信したときにデータ処理部１１が付与したＢＩトークンの量が格納される。
　受信時付与量の欄には、当該経理担当者が請求書データを送信したときにデータ処理部１１が付与したＢＩトークンの量が格納される。
　総付与量の欄には、請求書データのやりとりの際に付与されたＢＩトークンの総量が格納される。
　残量の欄には、総生成量から総付与量を減算した量が格納される。
　総生成量の欄には、今まで生成されたＢＩトークンの生成量が格納される。
　買い戻しの欄には、データ管理装置１がＢＩトークンを買い戻した量が格納される。
　データ処理部１１は、ＢＩトークンを付与する度に、総生成量が一致する（本実施の形態では１０００になる）ことを確認している。
　図７に示すように、本実施の形態では、データ処理部１１は、請求書データの送受信を１セットにして、送受信者それぞれに予め定めた量のＢＩトークンを付与する。
　そして、任意のタイミングで経理担当者からの買い戻し要求を受け付けると、データ処理部１１は、受け付けた量のＢＩトークンを設定レートで換金して当該経理担当者のウォレットに入金する。
　次に、管理画面を説明する。
　＜管理画面＞
　データ処理部１１は、経理担当者の操作に応じて図２に示す管理画面１１０を端末装置２ａ等に表示する。
　管理画面１１０には、利用者情報表示部１１１、ステータス表示部１１２、概要表示部１１３、請求書表示部１１４、社外連絡ボタン１１５、添付ファイルボタン１１６、履歴ボタン１１７、メモボタン１１８、社外連絡一覧ボタン１１９、メモ一覧ボタン１２０、情報表示部１２１、情報入力部１２２、およびトークン換金ボタン１２３が表示されている。
　利用者情報表示部１１１には、請求書管理システムにログインしている経理担当者に関する情報（利用者情報）が表示される。図２では一例として経理担当者が所属する会社名、部署名、名字、および経理担当者のメールアドレスが表示されている。
　ステータス表示部１１２には、請求書管理システムにログインしている経理担当者が取り扱う請求書データの数がステータス毎に表示される。
　大きく分けて、ステータス表示部１１２には受信ＢＯＸ、下書き、送信ＢＯＸおよび送受信ＢＯＸの欄が設けられている。
　データ処理部１１は、経理担当者のメールアドレスを宛先とする請求書データを受信ＢＯＸに割り振る。
　経理担当者が受信ＢＯＸを選択すると、データ処理部１１は、請求書データ管理テーブルＴ１を参照する。そして、担当者アドレスが「bbb@xxmail.co.jp」に一致する請求書データのうち、送受信の欄が「受信」の請求書データの概要を概要表示部１１３に表示する。
　図２に示すように、受信ＢＯＸに割り振られた請求書データのステータスの内訳は、「未開封」、「返送中」、「先方破棄」、「確認済」、「支払済」、「保管箱」がある。
　「未開封」のステータスは、受信ＢＯＸに割り振られた請求書データのうち、経理担当者が未確認の請求書データに対してデータ処理部１１が、割り振るステータスである。
　「返送中」のステータスは、受信ＢＯＸに割り振られた請求書データのうち、経理担当者が請求元の経理担当者に返送した請求書データに対してデータ処理部１１が割り振るステータスである。
　「先方破棄」のステータスは、受信ＢＯＸに割り振られた請求書データのうち、受信した請求書データを経理担当者が請求元の経理担当者に返送した後に、請求元の経理担当者が破棄した請求書データに対してデータ処理部１１が割り振るステータスである。
　「確認済」のステータスは、受信ＢＯＸに割り振られた請求書データのうち、経理担当者が閲覧し、確認ボタン（後述）を選択した請求書データに対してデータ処理部１１が割り振るステータスである。
　「支払済」のステータスは、受信ＢＯＸに割り振られた請求書データのうち、経理担当者が入金を行い、図示しない支払ボタンを選択した請求書データに対してデータ処理部１１が割り振るステータスである。
　経理担当者は、支払済のステータスの請求書データを集計することで、入金明細を把握することができる。
　「保管箱」のステータスは、ステータスが「支払済」の請求書データのうち、経理担当者が任意のタイミングで保管箱に移した請求書データに対してデータ処理部１１が割り振るステータスである。
　ステータス表示部１１２に表示される数字は、それぞれ、割り振られたステータスの数が表示されている。
　例えば、ステータス表示部１１２の未開封の欄には、受信した請求書データのうち、経理担当者が未確認の請求書データの数が表示される。
　なお、ステータス表示部１１２の保管箱の欄には、特に数字は表示されない。
　「未開封」、「返送中」、「先方破棄」、「確認済」、「支払済」、「保管箱」の各ＢＯＸに割り振られている請求書データの内容を経理担当者が閲覧する場合には、ステータス表示部１１２の該当箇所を選択すればよい。
　例えば、経理担当者が受信ＢＯＸを選択すると、データ処理部１１は、請求書データ管理テーブルＴ１を参照する。そして、データ処理部１１は、担当者アドレスが「bbb@xxmail.co.jp」に一致する請求書データのうち、担当者ステータスが未開封の請求書データの概要を、概要表示部１１３に表示する。
　データ処理部１１は、経理担当者が作成し、保存したが、送信先の経理担当者に未送信の請求書データを下書きに割り振る。
　データ処理部１１は、経理担当者が発送した請求書データを送信ＢＯＸに割り振る。
　経理担当者が送信ＢＯＸを選択すると、データ処理部１１は、請求書データ管理テーブルＴ１を参照する。そして、担当者アドレスが「bbb@xxmail.co.jp」に一致する請求書データのうち、送受信の欄が「送信」の請求書データの概要を概要表示部１１３に表示する。
　図２に示すように、送信ＢＯＸに割り振られた請求書データのステータスの内訳には、「送信済」、「返送戻り」、「破棄済」、「入金済」、「保管箱」がある。
　「送信済」のステータスは、送信ＢＯＸに割り振られた請求書データのうち、請求先の経理担当者が支払処理を行っていない請求書データに対してデータ処理部１１が割り振るステータスである。
　「返送戻り」のステータスは、送信ＢＯＸに割り振られた請求書データのうち、請求先の経理担当者から戻ってきた請求書データに対してデータ処理部１１が割り振るステータスである。経理担当者は、請求先から戻ってきた請求書データについての処理が可能となる。
　「破棄済」のステータスは、請求先の経理担当者から戻ってきた請求書データのうち、請求元の経理担当者が破棄した請求書データに対してデータ処理部１１が割り振るステータスである。
　「入金済」のステータスは、送信ＢＯＸに割り振られた請求書データのうち、請求元の経理担当者が入金を確認し、図示しない入金ボタンを選択した請求書データに対してデータ処理部１１が割り振るステータスである。
　「保管箱」のステータスは、ステータスが「入金済」の請求書データのうち、経理担当者が任意のタイミングで保管箱に移した請求書データに対してデータ処理部１１が割り振るステータスである。
　ステータス表示部１１２の保管箱の欄には、特に数字は表示されない。
　「送信済」、「返送戻り」、「破棄済」、「入金済」、「保管箱」の各ＢＯＸに入っている請求書データの内容を閲覧する場合には、その箇所を選択すればよい。
　概要表示部１１３には、前述したように、経理担当者がステータス表示部１１２にて選択したステータスに対応する請求書データの概要が表示される。概要としては、受信した請求書データであれば、請求元の会社名、件名、支払期限日、および送信側、受信側のステータスが表示される。
　これらのステータスは、請求書データを送受信した双方の経理担当者の管理画面上にそれぞれ同じものが表示される。
　図８および図９は、概要表示部に表示される情報を説明する図である。
　図８では、請求先の経理担当者が閲覧する管理画面１１０の概要表示部１１３に表示される請求書データの概要１１３ａと、請求元の経理担当者が閲覧する管理画面１１０の概要表示部１１３に表示される概要１１３ｂとを示している。
　すなわち、図８に示す請求元が株式会社ＡＢＣであり、件名が○○ｗｏｒｋの請求書データＤ１については、請求元の経理担当者が操作する端末装置の管理画面上ではステータス表示部の「送信済」に入っている。請求元の経理担当者がステータス表示部の「送信済」を選択した際には、請求書データＤ１について、請求先が□□株式会社、件名が○○ｗｏｒｋ、請求元の経理担当者のステータスが「送信済」、請求先の経理担当者のステータスが「未開封」である旨が概要表示部１１３に表示される。
　また、ステータスの遷移を確認することにより、請求元の経理担当者は容易に請求先の経理担当者の処理の進捗を確認することができる。このため、双方の経理担当者が、各請求書データについて今どのような状態にあるのかを、リアルタイムに確認することができる。
　図９（ａ）に示す概要１１３ｃ、１１３ｄ、１１３ｅは、いずれも請求書データＤ２についての概要を示している。
　請求先の経理担当者が請求書データＤ２を閲覧し、確認ボタン（後述）を選択すると、データ処理部１１は、請求元の経理担当者が操作する端末装置の管理画面１１０の概要表示部１１３に表示される情報を概要１１３ｃから概要１１３ｄに変更する。
　その後、請求先の経理担当者が請求書データＤ２の支払処理を行い、図示しない支払済ボタンを選択すると、データ処理部１１は、請求元の経理担当者が操作する端末装置の管理画面１１０の概要表示部１１３に表示される情報を概要１１３ｄから概要１１３ｅに変更する。
　また、他の例として、図９（ｂ）に示す概要１１３ｆ、１１３ｇは、いずれも請求書データＤ３についての概要を示している。
　請求先の経理担当者が請求書データＤ３を閲覧し、返送ボタン（後述）を選択すると、データ処理部１１は、請求先の経理担当者が操作する端末装置の管理画面の概要表示部１１３に表示される情報を概要１１３ｆから概要１１３ｇに変更する。
　再び図２に戻って説明する。
　概要表示部１１３に表示された請求書データの概要が経理担当者により選択されると、データ処理部１１は、請求書データの詳細を請求書表示部１１４に表示する。請求書表示部１１４に表示される請求書の内容は、アドレス表示部１１４ａおよび後述する各種ボタンを供えること以外は、既存の（紙やＰＤＦベースの）請求書と同じである。
　経理担当者が受信ＢＯＸに割り振られた請求書データを閲覧する場合には、データ処理部１１は、送信元の経理担当者（ｆｒｏｍ）のメールアドレスをアドレス表示部１１４ａに表示する。
　また、経理担当者が下書きまたは送信ＢＯＸに割り振られた請求書データを閲覧する場合には、データ処理部１１は、送信先の経理担当者（ｔｏ）のメールアドレスを表示する。
なお、データ処理部１１は、請求書データの請求書ＩＤを請求書表示部１１４に表示するようにしてもよい。
　経理担当者は、管理画面１１０上にて請求書表示部１１４に表示されている請求書の処理が可能である。
　具体的には、請求書データのステータスに応じて、請求書を処理するためのボタンが請求書表示部１１４に表示される。
　図２では、ステータスが未開封の請求書データを選択したときに表示されるボタンを示している。
　請求書表示部１１４には、確認ボタン１１４ｂ、返送ボタン１１４ｃおよびコピーボタン１１４ｄが設けられている。
　経理担当者により確認ボタン１１４ｂが選択されると、データ処理部１１は、請求書データ管理テーブルＴ１を参照する。そして、請求書表示部１１４に表示されている請求書データの担当者ステータスを「確認済」に変更する。また、データ処理部１１は、ステータス表示部１１２の「未開封」の数字を１つ減らし、「確認済」の数字を１つ増やす。
　経理担当者により返送ボタン１１４ｃが選択されると、データ処理部１１は、請求書データ管理テーブルＴ１を参照する。そして、請求書表示部１１４に表示されている請求書データの担当者ステータスを「返送中」に変更し、相手ステータスを「返送戻り」に変更する。また、データ処理部１１は、ステータス表示部１１２の「未開封」の数字を１つ減らし、「返送中」の数字を１つ増やす。
　返送された請求書データを受信した経理担当者の管理画面上では、ステータス表示部の返送戻りの数字を１つ増やす。
　経理担当者によりコピーボタン１１４ｄが選択されると、データ処理部１１は、当該請求書データの請求元と請求先の社名および住所が入れ替えられた新たな請求書データを作成する。そして、データ処理部１１は、請求書データ管理テーブルＴ１に作成した請求書データに関する情報を格納する。このとき、当該請求書データの担当者ステータスは、「下書き」、相手ステータスは空欄となる。
　再び図２に戻って説明する。
　送受信ＢＯＸには、受信ＢＯＸおよび送信ＢＯＸに入っている全ての請求書データのうち、破棄された請求書データと保管箱に割り振られた請求書データと下書きに割り振られた請求書データを除くデータが割り振られている。
　＜社外連絡ボタン＞
　経理担当者により社外連絡ボタン１１５が選択されると、データ処理部１１は、管理画面１１０を社外連絡入力モードに切り替える。この社外連絡入力モードでは、データ処理部１１は、情報入力部１２２に入力され、キーボードのエンターキーを押す等して確定された文書（テキストデータ）を、社外連絡として、当該経理担当者のメールアドレスおよび請求書表示部１１４に表示されている請求書データに関連づけて社外連絡データ記憶部１３に記憶する。
　＜添付ファイルボタン＞
　経理担当者により添付ファイルボタン１１６が選択されると、データ処理部１１は、管理画面１１０を添付ファイルモードに切り替える。この添付ファイルモードでは、データ処理部１１は、情報入力部１２２にクリック＆ドラッグされ、キーボードのエンターキーを押す等して確定された添付データを、当該経理担当者のメールアドレスおよび請求書表示部１１４に表示されている請求書データに関連づけて添付ファイルデータ記憶部１４に記憶する。
　＜履歴ボタン＞
　データ処理部１１は、今までの双方の経理担当者の操作履歴（履歴データ）を履歴データ記憶部１５に記憶しておく。
　＜メモボタン＞
　経理担当者によりメモボタン１１８が選択されると、データ処理部１１は、管理画面１１０をメモ入力モードに切り替える。このメモ入力モードでは、データ処理部１１は、情報入力部１２２に入力され、キーボードのエンターキーを押す等して確定された文字等を、メモとして、当該経理担当者のメールアドレスおよび請求書表示部１１４に表示されている請求書データに関連づけてメモデータ記憶部１６に記憶する。このメモは、メモを作成した者しか閲覧することができない。
　＜社外連絡一覧ボタン＞
　経理担当者により社外連絡一覧ボタン１１９が選択されると、データ処理部１１は、社外連絡に関するデータが記憶されている社外連絡データ記憶部１３を参照し、当該経理担当者が担当する請求書に関する社外連絡の一覧画面（社外連絡一覧画面）を時系列で管理画面１１０上に表示する。
　＜メモ一覧ボタン＞
　経理担当者により、メモ一覧ボタン１２０が選択されると、データ処理部１１は、社外連絡に関するデータが記憶されているメモデータ記憶部１６を参照し、当該経理担当者が担当する請求書に関するメモの一覧画面（メモ一覧画面）を時系列で管理画面１１０上に表示する。
　＜トークン換金ボタン＞
　経理担当者により、トークン換金ボタン１２３が選択されると、データ処理部１１は、現在請求書表示部１１４に表示されている請求書の金額を、ＢＩトークンを用いて換金する処理（入金処理）を実行する。この処理については、後に詳述する。
　再び図４に戻って説明する。
　取引データ生成部１７は、取引データが所定回数更新されたタイミングで各記憶部１２～１６に記憶されているそれまでの取引データを集積して暗号署名し、合意形成を行うデータベース３ａ、３ｂ、３ｃに送信する。補足すると、取引データは、請求書データ、請求書データのステータス、社外連絡データ、添付ファイルデータ、履歴データ、メモデータのうち、少なくとも１つを含む。
　ブロック生成のタイミングでＢＩトークンが生成される。取引データ生成部１７は、生成したＢＩトークンを、トークン記憶部１８に記憶する。その後、取引データ生成部１７は、所定回数に達したカウンタの数値をリセットする。
　次に、データベース３ａ、３ｂ、３ｃが有する機能を説明する。
　図１０は、実施の形態のデータベースが有する機能を説明するブロック図である。
　データベース３ａは、記憶部３１と、送受信部３２と、ブロックヘッダ生成部３３と、合意形成部３４とを有している。
　記憶部３１には、ブロック３１１と、データベースリスト３１２とが記憶されている。なお、記憶部３１に記憶される情報はこれらに限定されないのは言うまでも無い。
　ブロック３１１は、例えば、個々の取引履歴やコンピュータにおける処理のまとまり等、ブロックチェーンに登録する情報のまとまり（トランザクション）に、ブロックチェーンを構成するために必要な情報を付加したものである。
　図１１は、実施の形態のブロックチェーンに含まれる情報の一例を示す図である。
　ブロック３１１には、ブロックナンバー３１１ａ、タイムスタンプ３１１ｂ、トランザクションリスト３１１ｃが含まれている。
　ブロックナンバー３１１ａは、当該ブロック３１１を識別する情報である。
　タイムスタンプ３１１ｂは、新たに作成するブロックのタイムスタンプである。
　トランザクションリスト３１１ｃは、取引履歴やコンピュータにおける処理のまとまりをいう。ここではブロックチェーンに登録する情報のまとまりをリスト化したものをいう。具体的には、請求書データ、社外連絡データ、添付ファイルデータ、履歴データおよびメモデータ、請求書データの請求元のウォレット番号、請求先のウォレット番号が含まれる。
　データベースリスト３１２は、ブロックチェーンネットワーク２０に接続されている他のデータベースを識別する識別情報（例えばＩＰアドレス）が記憶されたリストである。
　送受信部３２は、ブロック３１１に記録するデータ（記録対象データ）を請求書管理装置１から受信する。
　ブロックヘッダ生成部３３は、記録対象データにハッシュ関数を用いてハッシュ値を生成する。
　また、ブロックヘッダ生成部３３は、生成したハッシュ値と、直前のブロックのハッシュ値と、タイムスタンプ３１１ｂとを用いてブロックヘッダを生成する。
　合意形成部３４は、ブロックヘッダ生成部３３が生成したノンス「Nonce」に適当な値を入れることによりブロックヘッダのハッシュ値を計算する。
　データベース３ａ、３ｂ、３ｃのうち、最初に答えを見つけたデータベース（ここではデータベース３ａとする）は、データベース３ｂ、３ｃにその旨を通知する（承認処理）。承認されると、各データベース３ｂ、３ｃは、自己のデータベースに通知されたブロックをそれぞれが有する既存のブロックに追加する。これにより、データベース３ａ、３ｂ、３ｃが有する取引データの整合性が保たれる。
　次に、請求書データの送受信に伴うデータ処理部１１の処理を、フローチャートを用いて説明する。
　図１２は、請求書データの送受信に伴うデータ処理部の処理を説明するフローチャートである。
　［ステップＳ１］　データ処理部１１は、請求書データを受信する。その後、ステップＳ２に遷移する。
　［ステップＳ２］　データ処理部１１は、請求書データ管理テーブルＴ１を更新する。また、データ処理部１１は、付与トークン管理テーブルＴ３を参照し、請求書データを送信した経理担当者の送信時付与量を所定量増やす。そして、データ処理部１１は、１つ上のレコードの残量から送信時付与量を減算した量を残量の欄に設定する。送信時付与量を総付与量に加算する。また、データ処理部１１は、請求書データを受信した経理担当者の受信時付与量を所定量増やす。そして、データ処理部１１は、１つ上のレコードの残量から送信時付与量を減算した量を残量の欄に設定する。受信時付与量を総付与量に加算する。
　以上で図１２の処理を終了する。
　次に、本実施の形態の入金処理を説明する。
　図１３は、入金処理を説明するフローチャートである。
　［ステップＳ１１］　データ処理部１１は、トークン換金ボタン１２３の選択を受け付けると、ステップＳ１２に遷移する。
　［ステップＳ１２］　データ処理部１１は、選択を受け付けた請求書データの支払ＩＤを発行する。この支払ＩＤは、ブロックのトランザクションで、誰から誰へ何時にいくらという情報をハッシュ化した番号である。その後、ステップＳ１３に遷移する。データ処理部１１は、発行した支払ＩＤを、請求書データ管理テーブルＴ１の該当する請求書データの支払ＩＤの欄に格納する。例えば、図５に示す例では、請求書ＩＤ「００１」、「００２」はそれぞれ別個の支払ＩＤが格納されている。このため、これらは別個のブロックに記録されている請求書データである。また、請求書ＩＤ「００３」、「００４」はそれぞれ同じ支払ＩＤが格納されている。このため、これらは同じブロック内に記録されている請求書データである。
　［ステップＳ１３］　データ処理部１１は、前述した承認処理が実行されたか否かを判断する。承認処理が実行されるとステップＳ１４に遷移する。
　［ステップＳ１４］　データ処理部１１は、ブロック３１１に保存したデータが承認されたか否かを、支払ＩＤを利用して確認する。各データベース３ａ～３ｃからの通知を受けるようにしてもよい。
　［ステップＳ１５］　データ処理部１１は、ブロック３１１に保存したデータが既存のブロックに追加されることが承認されている場合、請求書データ管理テーブルＴ１の該当する請求書の担当者ステータスおよび相手ステータスを入金が完了したことを示すステータスに変更する。具体的には、担当者ステータスを「送信済」から「入金済」に変更する。相手ステータスを「未開封」、または「確認済」から「支払済」に変更する。
　図１３に示す処理によって、請求書データに記載された請求額の入金処理の自動化を図ることができる。
　次に、トークンの生成量を管理する処理を、フローチャートを用いて説明する。
　図１４は、トークンの生成量を管理する処理を説明するフローチャートである。
　［ステップＳ２１］　データ処理部１１は、トークン付与管理テーブルＴ３の総生成量の欄を参照する。その後、ステップＳ２２に遷移する。
　［ステップＳ２２］　データ処理部１１は、総生成量が所定量以上か否かを判断する。この所定量は、例えばデータ管理装置１の管理者が予め設定しておく量である。総生成量が所定量以上である場合（ステップＳ２２のＹｅｓ）、ステップＳ２３に遷移する。総生成量が所定量未満である場合（ステップＳ２２のＮｏ）、図１４の処理を終了する。
　［ステップＳ２３］　データ処理部１１は、ＢＩトークンが上場されているか否かを判断する。ＢＩトークンが上場されている場合（ステップＳ２３のＹｅｓ）、ステップＳ２４に遷移する。ＢＩトークンが上場されていない場合（ステップＳ２３のＮｏ）、ステップＳ２５に遷移する。
　［ステップＳ２４］　データ処理部１１は、ＢＩトークンを上場価値に換算した通貨をウォレットに入金する。その後、ステップＳ２５に遷移する。
　［ステップＳ２５］　データ処理部１１は、ＢＩトークンを予め割り当てたレートで換算した通貨をウォレットに入金する。その後、ステップＳ２６に遷移する。
　［ステップＳ２６］　データ処理部１１は、付与トークン管理テーブルＴ３を参照し、残量および総付与量の欄を更新する。具体的には、データ処理部１１は、買い戻した分だけ残量を増やす。また、買い戻した分だけ総生成量を減らす。その後、図１４の処理を終了する。
　なお、買い戻したＢＩトークンは永久に使えないようにしてもよい（Ｂｕｒｎ制度の導入）。買い戻したＢＩトークンを一時的に使えないようにしてもよい（ロックアップ制度の導入）。これにより、市場に出回っているＢＩトークンの量を減らすことで希少性を高めるようにコントロール可能にする。
　以上述べたように、請求書管理システム１０によれば、請求書管理装置１は、端末装置２ａ、２ｂ、２ｃから特定の受取人に向けて送信された請求書データをネットワークを通じて受信すると、受信した請求書データを、受取人の識別情報と、請求書データの発行者の識別情報と、を関連づけて記憶する請求書データ記憶部１２と、請求書データの受信に対応して、将来、通貨と交換可能な発行者および受取人に対するそれぞれ固有のＢＩトークンを生成し、生成したＢＩトークンを受信した請求書データと関連づけて付与トークン管理テーブルＴ３に記憶するデータ処理部１１と、を有する。
　従って、経理分野における新たな利益を生み出すことができる。
　前述したように、独自トークンの活用により、サービスを利用する経理担当者にインセンティブが生まれるため、従来は目立たず、評価の対象とならなかった業務が収益化することで目立つようになり、労働に対する正当な評価が期待できる。
　また、請求書の支払い額をＢＩトークンにより支払うこともできる。これにより銀行を経由した場合に発生する送金手数料を限りなくゼロにして、（何百部分もまとめられた請求データを仮想通貨で支払う時に１つ１つに分解して）請求データ１に対して１の支払を行うことができる。また、送金や入金は請求書データを請求書管理装置１に送信した日に即座に実行させることが可能となる。第三者（銀行）による信用は決済の際に不要となる。
　また、支払に使用するＢＩトークンに請求データを特定できる情報を持たせて、入金を受けた側はその入金額（トークン）を選択すると、そのＢＩトークンに対応する請求データを画面上に表示させ、その請求の内訳もわかる状態にすることができる。これにより、入金を受けた側の入金処理の自動化を実現することができる。
　さらに、ＢＩトークンを保有しているほどＢＩトークンの価値を高めようとするインセンティブがうまれるため、取引先に請求書管理システム１０が提供するサービスを紹介する等してサービスの成長に貢献してくれるようになる。主にＢｔｏＢの世界でＢＩトークンを中心に経済圏が生まれ拡大していく。
　ＢＩトークンが換金可能になれば、例えば、経理部門がコストセンターからプロフィットセンターに転換する。これにより、請求書のデジタル化（ＤＸ）を地球規模で促進することができる。
　なお、ＢＩトークンの生成は請求書データの送信時・受信時に限定されない。例えば請求書データの受取人が「確認」ボタンを選択したときや、請求書データの発行者が「入金済」ボタンを選択したときにＢＩトークンを生成するようにしてもよい。
　また、請求書管理装置１がデータベース３ａ、３ｂ、３ｃが有する機能を備えていてもよい。
　また、端末装置２ａ、２ｂ、２ｃ間で請求書データを直接やりとりするのではなく、端末装置２ａ、２ｂ、２ｃで作成され、請求先に送信された全ての請求書データは請求書管理装置１が保管し共有データのような取扱いとなる。このため、請求先の経理担当者は、請求書データをプリントアウトすることで請求書の原本を入手することができる。
　また、電子署名処理やタイムスタンプ処理等を施さなくてもよいので、税務調査のために紙の請求書をＰＤＦ化する等の手間を削減することができる。
　情報表示部１２１には、請求書データの送信元、送信先双方の経理担当者自身が入力した社外連絡が表示される。このため、この社外連絡入力モードを用いることにより、双方の経理担当者は、チャットのようなやりとりが可能である。
　請求書データを送信した時点で請求書データ管理テーブルＴ１に情報が記憶され、その後のやり取りのステータスは、この請求書データ管理テーブルＴ１上で管理される。このため、経理担当者は、手入力により請求書をデータシートにまとめ直す作業から開放される。
　なお、請求書管理装置１が行った処理が、複数の装置によって分散処理されるようにしてもよい。
　また、本実施の形態では、請求書管理装置１が請求書データ記憶部１２等各記憶部を備える構成としたが、これに限らず、各記憶部はクラウド化され、データ処理部１１と別個の場所に設けられていても良い。
　以上、本発明の情報処理装置、情報処理方法およびプログラムを、図示の実施の形態に基づいて説明したが、本発明はこれに限定されるものではなく、各部の構成は、同様の機能を有する任意の構成のものに置換することができる。また、本発明に、他の任意の構成物や工程が付加されていてもよい。
　また、本発明は、前述した各実施の形態のうちの、任意の２以上の構成（特徴）を組み合わせたものであってもよい。
　なお、上記の処理機能は、コンピュータによって実現することができる。その場合、請求書管理装置１が有する機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリ等が挙げられる。磁気記憶装置には、ハードディスクドライブ、フレキシブルディスク（ＦＤ）、磁気テープ等が挙げられる。光ディスクには、ＤＶＤ、ＤＶＤ－ＲＡＭ、ＣＤ－ＲＯＭ／ＲＷ等が挙げられる。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）等が挙げられる。
　プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ－ＲＯＭ等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
　プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。
　また、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）等の電子回路で実現することもできる。
　１　請求書管理装置
　２ａ、２ｂ、２ｃ　端末装置
　３ａ、３ｂ、３ｃ　データベース
　１０　請求書管理システム
　１１　データ処理部
　１２　請求書データ記憶部
　１３　社外連絡データ記憶部
　１４　添付ファイルデータ記憶部
　１５　履歴データ記憶部
　１６　メモデータ記憶部
　１７　取引データ生成部
　２０　ブロックチェーンネットワーク
　３１　記憶部
　３１１　ブロック
　３１２　データベースリスト
　３２　送受信部
　３３　ブロックヘッダ生成部
　３４　合意形成部
　Ｔ１　請求書データ管理テーブル

Claims (9)

  1. 　端末装置から特定の受取人に向けて送信されたビジネス文書に関する文書データをネットワークを通じて受信すると、受信した前記文書データを、前記受取人の識別情報と、前記文書データの発行者の識別情報と、を関連づけて記憶する記憶部と、
    　前記文書データの受信に対応して、将来、通貨と交換可能な前記発行者および受取人に対するそれぞれ固有のトークンを生成し、生成したトークンを受信した前記文書データと関連づけて記憶部に記憶する処理部と、
    　を有することを特徴とする情報処理装置。
  2. 　前記処理部は、前記発行者の要求に応じて前記文書データの受信に対応して発行されたトークンを通貨に換金して換金した通貨を前記発行者に支払う請求項１に記載の情報処理装置。
  3. 　前記処理部は、前記受取人の要求に応じて前記文書データの受信に対応して発行されたトークンを通貨に換金して換金した通貨を前記受取人に支払う請求項１に記載の情報処理装置。
  4. 　前記処理部は、前記文書データの閲覧または編集に応じて変化する前記文書データの発行者、受取人それぞれの処理に関する進捗ステータスを記憶部に記憶し、
    　前記文書データはブロックに保存され、
    　前記処理部は、前記発行者または前記受取人の要求に応じて前記文書データに対応する、ブロックに保存した前記文書データを参照できるＩＤを発行し、
    　前記ＩＤを参照して前記ブロックが既存のブロックに追加されることが承認されたか否かを判断し、承認された場合に前記進捗ステータスを前記文書データの処理が完了したことを示すステータスに変更する請求項１ないし３のいずれかに記載の情報処理装置。
  5. 　前記トークンは市場に公開されて価値付けされており、
    　前記処理部は、前記トークンの現在の価値を参照して換金した通貨を前記発行者または受取人に支払う請求項２または３に記載の情報処理装置。
  6. 　前記記憶部には前記受取人または前記発行者の識別情報に基づくウォレットが記憶されており、特定したウォレットに換金した通貨を支払う請求項２または３に記載の情報処理装置。
  7. 　前記処理部は前記トークン毎に現在市場に供給されている量を前記記憶部に記憶し、供給量が一定以上となったトークンを通貨に換金して支払う請求項２または３に記載の情報処理装置。
  8. 　コンピュータが、
    　端末装置から特定の受取人に向けて送信されたビジネス文書に関する文書データをネットワークを通じて受信すると、受信した前記文書データを、前記受取人の識別情報と、前記文書データの発行者の識別情報と、を関連づけて記憶しておき、
    　前記文書データの受信に対応して、将来、通貨と交換可能な前記発行者および受取人に対するそれぞれ固有のトークンを生成し、生成したトークンを受信した前記文書データと関連づけて記憶する、
    　ことを特徴とする情報処理方法。
  9. 　コンピュータに、
    　端末装置から特定の受取人に向けて送信されたビジネス文書に関する文書データをネットワークを通じて受信すると、受信した前記文書データを、前記受取人の識別情報と、前記文書データの発行者の識別情報と、を関連づけて記憶しておき、
    　前記文書データの受信に対応して、将来、通貨と交換可能な前記発行者および受取人に対するそれぞれ固有のトークンを生成し、生成したトークンを受信した前記文書データと関連づけて記憶する、
    　処理を実行させることを特徴とするプログラム。
PCT/JP2022/024302 2021-06-23 2022-06-17 情報処理装置、情報処理方法およびプログラム WO2022270431A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-103853 2021-06-23
JP2021103853A JP2023002972A (ja) 2021-06-23 2021-06-23 情報処理装置、情報処理方法およびプログラム

Publications (1)

Publication Number Publication Date
WO2022270431A1 true WO2022270431A1 (ja) 2022-12-29

Family

ID=84545697

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/024302 WO2022270431A1 (ja) 2021-06-23 2022-06-17 情報処理装置、情報処理方法およびプログラム

Country Status (2)

Country Link
JP (1) JP2023002972A (ja)
WO (1) WO2022270431A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004145865A (ja) * 2002-08-27 2004-05-20 Canal Group Corp 電子事務処理方法及び電子事務処理システム
WO2017164240A1 (ja) * 2016-03-25 2017-09-28 Ｂａｎｋ Ｉｎｖｏｉｃｅ株式会社 端末装置、表示方法およびプログラム
WO2020123464A1 (en) * 2018-12-10 2020-06-18 Shelterzoom Corp. Decentralized marketplace and ecosystem powered by blockchain-based document delivery, collaboration, and dissemination

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004145865A (ja) * 2002-08-27 2004-05-20 Canal Group Corp 電子事務処理方法及び電子事務処理システム
WO2017164240A1 (ja) * 2016-03-25 2017-09-28 Ｂａｎｋ Ｉｎｖｏｉｃｅ株式会社 端末装置、表示方法およびプログラム
WO2020123464A1 (en) * 2018-12-10 2020-06-18 Shelterzoom Corp. Decentralized marketplace and ecosystem powered by blockchain-based document delivery, collaboration, and dissemination

Also Published As

Publication number Publication date
JP2023002972A (ja) 2023-01-11

Similar Documents

Publication Publication Date Title
JP6611064B2 (ja) 端末装置、表示方法およびプログラム
US20210150493A1 (en) Information processing apparatus and information processing method
US20180239813A1 (en) Information processing apparatus and information processing method
WO2015049948A1 (ja) 情報処理装置およびアクセス権限付与方法
WO2021235453A1 (ja) 情報処理方法、情報処理装置およびプログラム
US20190188762A1 (en) Information processing apparatus and information processing method
JP6550572B2 (ja) 情報処理装置、表示方法およびプログラム
US20130173472A1 (en) Transaction Management System
JP7199079B2 (ja) 情報処理装置、情報処理方法およびプログラム
WO2022270431A1 (ja) 情報処理装置、情報処理方法およびプログラム
US20190139108A1 (en) Information processing apparatus and display method
JP7075142B2 (ja) 情報処理装置、情報処理方法およびプログラム
US20210012063A1 (en) Information processing device, display method and program
JP7311897B2 (ja) 情報処理装置、表示方法およびプログラム
JP7202493B1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
JP6425156B2 (ja) 情報処理装置、情報処理方法およびプログラム
JP2018014061A (ja) 債務管理装置、債務管理方法、債務管理プログラム
JP2020155156A (ja) 債務管理装置、債務管理方法、債務管理プログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22828348

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE