WO2009116415A1 - 電子的価値情報管理サーバ - Google Patents

電子的価値情報管理サーバ Download PDF

Info

Publication number
WO2009116415A1
WO2009116415A1 PCT/JP2009/054438 JP2009054438W WO2009116415A1 WO 2009116415 A1 WO2009116415 A1 WO 2009116415A1 JP 2009054438 W JP2009054438 W JP 2009054438W WO 2009116415 A1 WO2009116415 A1 WO 2009116415A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
management
management data
server
information
Prior art date
Application number
PCT/JP2009/054438
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 有限会社アプリコシステム
Priority to JP2010503834A priority Critical patent/JPWO2009116415A1/ja
Publication of WO2009116415A1 publication Critical patent/WO2009116415A1/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
    • G06Q30/00—Commerce

Definitions

  • the present invention relates to a processing device for processing electronic money settlement, transfer of electronic money and other electronic value information, a method for processing electronic value information, and the like.
  • values such as money are associated with information such as bit strings. Transfer of value such as settlement is realized by exchanging information such as the bit string.
  • Electronic money is rapidly spreading and is used as a means of paying fares at ticket gates of transportation facilities and paying for goods at stores.
  • a server device that manages electronic value information that can be transferred without using a special device such as a dedicated IC card, and can be recovered even if it is lost, preventing double use. Etc.
  • a database unit associating value information with owner identification information of a person who owns the value represented by the value information, and first management data including first matching data If the management data receiving unit that receives the first verification data is associated with the first value information by the database unit, new data for verification is prepared and the first value information is stored in the first value information.
  • a replacement unit that associates the new verification data and generates second management data in which the first verification data included in the first management data is replaced with the new verification data; and If the first owner identification information is included in the management data, a change operation for associating the new collation data with the first owner identification information is performed on the database unit.
  • a data transmission / reception method by a management server device in which the management server includes value information and owner identification information of a person who owns the value represented by the value information in the verification data. If the first management data including the first verification data is received and the first verification data is associated with the first value information, new verification data is prepared. Second management data obtained by associating the new verification data with the first value information and replacing the first verification data included in the first management data with the new verification data. Generate and transmit the second management data by associating the new verification data with the first owner identification information if the first owner identification information is included in the first management data Special to do That discloses a method of transmitting and receiving data associated with the value information.
  • a storage server operating method for mediating transfer of management data including verification data associated with value information associated with owner identification information in the management server establishes a communication session between a first terminal that transmits management data including verification data associated with value information and a second terminal that receives the management data, and is established
  • the first terminal and the second terminal perform mutual authentication through the communication session, receive management data transmitted from the first terminal and identification information of the established communication session, and
  • the management data included in the received management data is replaced with newly prepared verification data to generate replaced management data, and the received communication session identification information is generated.
  • the replacement management data is stored in a linked manner, the communication session identification information is received from the second terminal, and the replacement management data stored in association with the communication session is returned.
  • a database unit associating value data representing a separable value with the verification data, and first value information representing a value equal to or less than the upper limit amount transmitted from the first terminal
  • the first management data including the first verification data associated with the second verification information associated with the second value information transmitted from the second terminal and representing the value less than the upper limit amount
  • the management data receiving unit that receives the second management data including the business data, and the value that does not exceed the difference in value represented by the second value information from the upper limit is subtracted from the value of the first value information
  • a management server having a database changing unit for adding to the value represented by the second value information, and a management data transmitting unit for transmitting the second management information to the second terminal is disclosed.
  • the first management data including the first verification data associated with the first value information representing the value below the upper limit value is received from the first terminal
  • the second management data including the second verification data associated with the second value information representing the value less than the upper limit value is received from the second terminal
  • the second value information is received from the upper limit.
  • a value that does not exceed the difference in value to be expressed is subtracted from the value of the first value information and added to the value represented by the second value information, and management data including the second management data is sent to the second terminal.
  • a transmission unit that transmits identification information to the management server, and screen information for displaying the name of the holder when performing the payment settlement process are received as a response to the transmission of the identification information.
  • a verification unit associated with the management server with value information corresponding to the amount of money transferred in the settlement process after the confirmation that the settlement process has been performed is made to the management server.
  • a terminal device having a management data receiving unit for receiving management data including business data is disclosed.
  • the identification information of the user terminal is transmitted from the user terminal to the management server, and the name of the holder at the time of performing the payment settlement process is generated in the management server, and the generated The name of the holder is transmitted to the user terminal, a browser is started on the user terminal, and a payment process is performed on the payment server using the name of the name of the holder, and the payment server performs the payment to the management server.
  • Payment information including the name of the holder and the amount of money and the payment server generates management data including information for matching associated with value information corresponding to the amount of money included in the payment information,
  • the payment information is transmitted to the storage server in association with ID information for identifying the payment information, the user terminal transmits a notification of the payment processing to the management server, and the management server
  • the user terminal sends back to the user terminal a notification that the payment information including the message is received, the user terminal transmits ID information for identifying the payment process to the storage server, and the storage server transmits from the user terminal.
  • a data transmission / reception method associated with value information including transmitting management information transmitted by the management server in association with the ID information.
  • management data including data associated with value information in the first server is stored in a user terminal, a browser is activated in the user terminal, and sales of products or services are performed.
  • a session ID for communication between the first server and the browser and price information to be paid are received from the second server for providing via the browser, and the stored management data is received.
  • reception and transmission of data and information means performing notification via a network by controlling a network adapter as hardware.
  • the association of two or more data is realized by storing two or more data as one line of data in a table stored in a storage device as hardware, or by an equivalent method.
  • use of electronic value information that prevents double use can be recovered even if lost, and can be distributed without using a special device such as a dedicated IC card, etc. Can provide. Further, since it is not necessary to use a special device, settlement processing via the Internet or the like can be performed more easily than conventional techniques.
  • FIG. 1 is a system configuration diagram including a management server, a settlement server, a storage server, and a user terminal according to an embodiment of the present invention.
  • FIG. 1 shows the screen display of the user terminal which concerns on one Embodiment of this invention.
  • FIG. 1 shows the screen display of the user terminal which concerns on one Embodiment of this invention.
  • FIG. 1 shows the screen display of the user terminal which concerns on one Embodiment of this invention.
  • FIG. 1 shows the screen display of the user terminal which concerns on one Embodiment of this invention.
  • FIG. 1 shows the screen display of the user terminal which concerns on one Embodiment of this invention.
  • FIG. 1 shows the screen display of the user terminal which concerns on one Embodiment of this invention.
  • FIG. 1 shows the screen display of the user terminal which concerns on one Embodiment of this invention.
  • FIG. 1 shows the screen display of the user terminal which concerns on one Embodiment of this invention.
  • FIG. 1 shows the screen display of the user terminal which concerns on one Embodiment of this invention.
  • FIG. 1 shows the screen display of the user terminal which concerns on one Embodiment of this invention.
  • FIG. 1 shows
  • Management Server 101 Database Unit 102 Issuance Request Receiving Unit 103 Generation Unit 105 Management Data Receiving Unit 106 Replacement Unit 107 Replacement Management Data Transmission Unit 108 Management Data Issuance Request 109, 110, 111 Management Data
  • the management server is a server device that mainly performs electronic value information transfer processing.
  • Other processes performed by the management server are not essential processes for the management server, but there may be a process of issuing electronic value information, a process of refunding the value associated with the issued electronic money, etc. as money, etc. is there.
  • FIG. 1 illustrates a functional block diagram of a management server according to an embodiment of the present invention.
  • the management server 100 includes a database unit 101, an issue request reception unit 102, a generation unit 103, a generation management data transmission unit 104, a management data reception unit 105, a replacement unit 106, and a replacement management data transmission unit 107.
  • the management server 100 by causing the computer to read the software and calculating or processing information according to the purpose of use by a specific means in which the software and hardware resources cooperate. Some information processing apparatuses are specific to the purpose of use. Also, a hardware-only configuration with a dedicated circuit is possible. Such an implementation will be appreciated by those skilled in the art in connection with the following description of the invention.
  • the database unit 101 manages the association between electronic value information and value.
  • the term “management data” is used instead of the term “electronic value information”.
  • the management data includes verification data, and the verification data is associated with the value itself or information representing the value. Further, the verification data can be associated with other information.
  • Other information that can be associated with the verification data includes, for example, the number of times the management data including the verification data has been transferred (number of transfers), the management data including the verification data, Identification information such as a user and a terminal device indicating which user's terminal device has been issued, and the like, may be stored in the database unit 101 as necessary.
  • FIG. 2 (a) there is a column storing collation data and a column storing value information.
  • This table is managed by the database unit 101 as table data such as a relational database system.
  • the value information may be simply referred to as “value information”.
  • the verification data is data generated as a random number with a sufficiently long bit length. “Sufficiently long” means that there is no or substantially no management data to be issued having the same verification data. For example, an arbitrary length can be determined according to design requirements such as 128 bits, 512 bits, 1024 bits, and 2048 bits.
  • Value information indicates the content of the value that the management data including verification data represents.
  • the value represented by money is shown.
  • the unit of value is yen, dollar, euro, yuan, or the like.
  • the value information may be a security number of securities having a value equivalent to money, an amount of noble metal, a storage number, or the like.
  • the issue request receiving unit 102 receives the management data issue request 108.
  • the management data issue request 108 is information indicating that some value has been transferred to or transferred to the management server or its operator. Therefore, the management data issuance request 108 is generated within the area controlled by the operator of the management server 100, or transmitted from a person who has a special relationship with the operator (for example, a parent company subsidiary relationship or a special contract relationship). It is preferable that
  • FIG. 2 (b) shows a specific example of the management data issue request.
  • XML eXtensible Markup Language
  • FIG. 2B 1000 yen surrounded by ⁇ value> and ⁇ / value> is the value that the management data to be issued should represent.
  • the memory address of a part surrounded by ⁇ value> and ⁇ / value> is specified as an argument as value information in an argument of a function such as a software module that implements the generation unit 103. This is done by calling a function.
  • management data issue request may include other information that can be associated with the verification data as necessary.
  • the generation unit 103 prepares collation data, and stores the prepared collation data and the value information transmitted from the issue request reception unit 102 in the table of FIG. 2A managed by the database unit 101. Insert as data. “Preparing data for verification” means generating a random number and using the random number as data for verification, or selecting a random number from a list of previously generated random numbers and using it as data for verification Say. When the insertion is completed, the generation unit 103 transmits the verification data to the generation management data transmission unit 104. Value information may also be transmitted.
  • FIG. 2C shows a state immediately after “135711” is prepared as collation data and “135711” and 1000 yen are inserted into the table shown in FIG. When the insertion is performed, collation data “135711” is transmitted to the generation management data transmission unit 104.
  • the generation management data transmission unit 104 generates management data 109 from the verification data transmitted from the generation unit 103 and transmits it.
  • the transmission destination of the management data 109 is mainly assumed to be a device that has transmitted the management data issue request 108. If the transmission destination of the management data 109 is specified by the e-mail address or the IP address in the management data issue request 108, the management data 109 is transmitted to the transmission destination. Transmission may be performed encrypted.
  • FIG. 2D shows an example of management data generated and transmitted by the generation management data transmission unit 104.
  • management data “ ⁇ management data> ⁇ matching data> 135711 ⁇ / matching data> ⁇ / management data>” is generated, such as the Internet. Sent to other networks.
  • the management data may include data other than the verification data. For example, information indicating how much value, for example, how much monetary value the matching data is associated with may be included.
  • the management data includes monetary values such as “ ⁇ management data> ⁇ collation data> 135711 ⁇ / collation data> ⁇ value> 1000 yen ⁇ / value> ⁇ / management data>”. Also good.
  • related with the data for collation may be contained. Further, when the number of times of transfer is included in the management data, it is reset to an initial value such as 0 and transmitted. Furthermore, in order to be able to verify that the management data is generated by the management server 100, signature data by the management server 100 for the verification data or the like may be included.
  • an upper limit may be set for the value represented by the management data.
  • one piece of management data represents a monetary value up to 5000 yen.
  • Management data representing a value of 5000 yen or more is expressed by combining a plurality of management data. In this way, by setting an upper limit on the value represented by the management data, it is possible to prevent loss caused when the management data is lost.
  • FIG. 3 exemplifies a flowchart for explaining the flow of processing by the database unit 101, the issue request receiving unit 102, the generating unit 103, and the generation management data transmitting unit 104.
  • the processing illustrated in this flowchart can be executed as information processing by software capable of controlling hardware.
  • the processing exemplified in this flowchart can also be executed by a hardware-only configuration using a dedicated circuit as described above.
  • the feasibility as information processing by software and the feasibility by the configuration of only hardware by a dedicated circuit are the same for the processes exemplified by the flowcharts and sequence diagrams of other drawings.
  • step S301 the issue request receiving unit 102 receives a management data issue request. For example, when a network adapter as hardware receives data and an interrupt occurs, an interrupt handler is called to read the data and place it in the read data queue. Then, the process returns from a READ system call issued by a module that implements the issue request receiving unit 102, and the data stored in the read data queue is expanded in the memory as a management data issue request.
  • a management data issue request For example, when a network adapter as hardware receives data and an interrupt occurs, an interrupt handler is called to read the data and place it in the read data queue. Then, the process returns from a READ system call issued by a module that implements the issue request receiving unit 102, and the data stored in the read data queue is expanded in the memory as a management data issue request.
  • the issue request receiving unit 102 acquires value information by specifying the address of the value information from the management data issue request developed in the memory.
  • the acquired value information is transmitted to the generation unit 103.
  • step S303 the generation unit 103 prepares collation data.
  • step S304 the generation unit 103 associates the prepared verification data with the transmitted value information and inserts them into the table as row data.
  • the table can be stored in a storage device such as a hard disk device.
  • the database unit 101 is realized using such a storage device.
  • the prepared collation data is transmitted to the generation management data transmission unit 104.
  • step S305 the generation management data transmission unit 104 generates management data from the transmitted verification data.
  • step S306 the management data generated is transmitted by issuing a WRITE system call or the like.
  • the management data is stored in the transmission data queue by issuing a WRITE system call or the like and the network adapter is ready to transmit data, an interrupt is generated, and the data in the transmission data queue is read by the interrupt handler, Sent to a network etc.
  • the management data transmitted in this way is not limited to a dedicated IC card or the like, but can be stored in a memory such as a normal personal computer, a PDA (Personal Digital Assistant), or a mobile phone. Further, it can be recorded on a general removable storage medium such as a flexible disk, an optical disk, and a nonvolatile semiconductor memory. Then, by transferring the storage medium, the value represented by the management data stored in the storage medium can be transferred. However, in order to prevent double assignment, it is desirable to assign as described below.
  • the management data receiving unit 105 receives management data 110 to be transferred.
  • the received management data 110 is expanded in the memory of the management server 100. If the management data 110 includes signature data or the like, it may be determined whether the signature data is correct.
  • the replacement unit 106 acquires collation data from the management data received by the management data reception unit 105, and first determines whether the collation data is stored in a table managed by the database unit 101. For example, it is determined whether the data is stored in the collation data column of the table shown in FIG. If the verification data is not stored, a reply is sent to the sender of the management data 110 that management data including invalid verification data has been transmitted. On the contrary, if the matching data is stored in the table managed by the database unit 101, it is determined that the management data includes valid matching data. If valid collation data is included, new collation data is prepared, and the collation data stored in the collation data included in the management data 110 and the table managed by the database unit 101 are prepared based on the collation data. Replace data. As a result, new verification data is associated with the value information.
  • the information may be used for further checking. For example, if the identification information is associated with the verification data, the identification information of the user or terminal device that has received the management data by the management data receiving unit 105 is acquired and compared. If the comparison result is not OK, a reply indicating that the comparison is invalid is performed. If the comparison result is OK, the identification information associated with the verification data and the identification information included in the management data are used as the transmission destination of management data by the replacement management data transmission unit 107 described below. To the identification information of the user or terminal device.
  • the transfer count is included in the management data, update the transfer count. If the number of transfers before the update indicates an initial value, it is associated with the verification data in addition to whether the verification data before replacement is stored in the table managed by the database unit 101. You may perform a check using other information. For example, the management server log is used to check whether there is a management data issuance request received when the management data is issued, or whether or not money is actually transferred from the bank. The server device may be inquired. Of course, such check and inquiry processing may be performed each time management data is received by the management server 100. In general, however, such checking and inquiry processing takes time.
  • the replacement management data transmission unit 107 transmits the management data 111 in which the verification data is replaced by the newly prepared verification data by the replacement unit 106.
  • the management data 111 may be transmitted to the transmission source of the management data 110.
  • the management data 110 is received and information indicating the transmission destination is received, or if the management data 110 includes information indicating the transmission destination, the management data 111 is transmitted to the transmission destination. It may be.
  • the table shown in FIG. 4A becomes a table having data as shown in FIG. 4C
  • the management data 110 shown in FIG. 4B becomes as shown in FIG. 4D.
  • the management data shown in FIG. 4A becomes a table having data as shown in FIG. 4C
  • the management data 110 shown in FIG. 4B becomes as shown in FIG. 4D.
  • the rewriting of the collation data in the table shown in FIG. 4A may be performed as an update operation on the data stored in the collation data column.
  • the value information associated with the verification data to be rewritten (“1317192” in the above example) is read and temporarily stored, and the row including the verification data to be rewritten is stored. Operation for inserting data into the table so that the newly prepared collation data ("14991625" in the above example) and temporarily stored value information etc.
  • the table is provided with a column (deletion flag) indicating that the verification data has been deleted, and the value of the deletion flag of the row storing the verification data to be rewritten May be updated to a value indicating that the row has been deleted, and a row including the prepared collation data may be newly inserted into the table.
  • the data for rewriting before rewriting may be stored in the row inserted into the table.
  • the rewriting of the verification data of the management data may be performed by rewriting the verification data portion of the management data portion expanded in the memory as the wording indicates. Or you may produce
  • the replacement management data transmission unit 107 After the management data shown in FIG. 4 (d) is transmitted by the replacement management data transmission unit 107, even if the management data shown in FIG. The data 1317192 is not stored in the table shown in FIG. 4C (or when the deletion flag column is provided in the table, the value of the deletion flag is a value indicating that it has been deleted). ). Therefore, it is determined that the management data includes invalid verification data. This prevents double use of management data.
  • FIG. 5 exemplifies a flowchart for explaining the flow of processing in the database unit 101, the management data receiving unit 105, the replacement unit 106, and the replacement management data transmission unit 107.
  • the processing exemplified in this flowchart can be realized as information processing by software (the same applies to the processing exemplified in the flowcharts and sequence diagrams in other drawings).
  • the processing exemplified in this flowchart can also be executed by a configuration of only hardware by a dedicated circuit (the same applies to the processing exemplified in the flowcharts and sequence diagrams of other drawings). ).
  • step S501 the management data 110 is received by the management data receiving unit 105. Thereafter, the management data 110 is expanded in the memory.
  • step S502 the replacement unit 106 acquires verification data from the management data 110 developed in the memory. It is confirmed that the acquired collation data is stored in the database unit 101 in association with the value information in the process of step S503. If it is not stored, an error is returned to the effect that invalid verification data is included in the management data 110.
  • step S504 new verification data is prepared. For example, a random number obtained by a random number generator is used as new verification data.
  • step S505 the verification data in the management data 110 is replaced with new verification data.
  • “Management data 110 verification data” means not only verification data included in the management data 110 expanded in the memory, but also verification data stored in association with value data in step S503. .
  • step S506 the replacement management data transmission unit 107 transmits management data 111 obtained by rewriting the verification data.
  • Storage server By using the management server described above, management data including verification data generated as a random number is issued, management data including valid verification data is transmitted, and verification data is received by receiving return management data. Will be rewritten. Thereby, double use of management data can be prevented.
  • a storage server used for extending the function of the management server in order to further transfer management data while maintaining anonymity will be described.
  • FIG. 6 shows a configuration of a system 600 including a management server 601, a settlement server 602, a storage server 603, and a user terminal 604.
  • the management server 601, the settlement server 602, the storage server 603, and the user terminal 604 can communicate with each other by using hardware such as a communication adapter of each server and the terminal.
  • the user of the user terminal 604 performs payment processing between the user terminal 604 and the payment server 602 in order to obtain management data issued by the management server 601.
  • the settlement server 602 is a server that processes bank transfers, and a settlement process is performed when a user makes a transfer to a bank account such as an operator of the management server 601.
  • the management data is returned to the management server 601. Thereafter, the management data is transferred from the settlement server 603 to the user terminal 604 via the storage server 603.
  • the storage server 603 receives the management data from the settlement server 602
  • the storage server 603 transmits the management data to the management server 601 to replace the management data with new verification data in order to prevent double use of the management data. Receive and store the management data replaced by. Thereafter, if there is a management data request from the user terminal 604, the storage server 603 transmits the stored management data.
  • the storage server 603 can be trusted by authenticating the payment server 602 or the like, the storage server 603 need not transmit the management data received from the payment server 602 to the management server 601. However, if the management data transmitted to the storage server 603 remains without being deleted in the payment server 602 and the payment server 602 is illegally intruded, the person who has illegally accessed the payment server 602 manages it. Since the data may be obtained, it can be said that the storage server 603 preferably transmits the management data received from the settlement server 602 to the management server 601.
  • FIG. 7 is a sequence diagram illustrating an example of processing from settlement processing in system 600 to transfer of management data to a user.
  • a payment process for issuing management data is performed between the user terminal 604 and the payment server 602.
  • the credit card number and the settlement amount are presented from the user terminal 604, and the settlement server 602 confirms the correctness of the credit card number and the like.
  • the user terminal 604 applies for a transfer to a bank account, and the settlement server 602 returns a transfer destination bank account number, an identification character string added to the transfer person, and the like. Thereafter, confirmation that the transfer has been made is performed on the settlement server 602 side.
  • the identification information of the user and the user terminal 604 may be transmitted from the user terminal 604 to the payment server 602 to the payment server by the payment process. In this case, the identification information is included in a management data issue request transmitted from the settlement server 602 to the management server 601 later.
  • a number specifying the payment process in the process of step S701 is determined, and this number is shared between the payment server and the user terminal.
  • the number for specifying the payment process is, for example, a number for uniquely identifying the management data generated by the payment server, or a session ID (session for specifying a session for communication between the user terminal 604 and the payment server 602). Or session identification information that uniquely identifies the client).
  • the management server generates a number for specifying the settlement process as a random number.
  • a part of the number may be a random number. In this case, a part other than the random number may include a number for identifying the user or the user terminal 604.
  • the session ID is used as the number for specifying the settlement process.
  • the number specifying the payment process is not limited to the session ID.
  • a number for specifying the settlement process may be referred to as ID information.
  • a management data issue request is transmitted from the settlement server 602 to the management server 601 as processing in step S702.
  • This management data issue request includes information such as the amount settled.
  • the “paid amount” may be an amount obtained by subtracting a predetermined fee from the amount of payment between the user terminal 604 and the payment server 602.
  • management data (referred to as “management data 1”) is transmitted from the management server 601 to the settlement server 602 as processing in step S703.
  • the settlement server 602 transmits the received management data 1 and the session ID described above to the storage server 603.
  • the storage server 603 When the storage server 603 receives the management data 1 and the session ID from the settlement server, the received management data is transmitted to the management server 601 as processing in step S705, and the management data 1 includes valid verification data. Confirmation and replacement of the verification data is requested to the management server 601.
  • the management server 601 is configured not to increase the number of transfers when the storage server 603 requests rewriting of the verification data, and is included in the identification information and management data associated with the verification data.
  • the identification information may not be rewritten. For example, when the IP address of the storage server 603 is registered in the management server 601 and management data is received from the registered IP address, the number of transfers is not increased and the identification information is not rewritten. May be.
  • step S706 the management server 601 confirms that the management data 1 contains valid verification data, generates management data 2 in which the verification data is rewritten, and returns the management data 2 to the storage server 603. The Then, the storage server 603 stores the management data 2 in association with the session ID.
  • a storage notification is transmitted from the storage server 603 to the settlement server 602 as processing in step S707.
  • the deposit notification is transmitted to the user terminal 604 as processing in step S708 to inform the user that the management data is stored in the storage server 603.
  • the user operates the user terminal 604 to request management data stored in the storage server 603, as a process of step S 709, as a management data transmission request to the storage server 603.
  • the storage server 603 confirms that the management data 2 is stored in association with the session ID
  • the management server 2 returns the management data 2 and discards the association with the session ID in step S710.
  • management data can be issued to the user without using the configuration and processing shown in FIGS.
  • the settlement server may receive management data from the management server and directly transmit the management data to the user terminal.
  • the payment server holds the management data received from the management server until it can communicate with the user terminal next time. There is a need.
  • the settlement server knows information on which management data is issued to whom, and anonymity is impaired.
  • the settlement server transmits the management data transmission destination to the management server together with the management data issuance request, and the management server transmits the management data issued to the transmission destination.
  • the management server knows information on who the management data was issued to, and the anonymity is still lost.
  • the management server 601 does not need to know to which user terminal the management data is issued and transmitted. Moreover, although the payment server 602 can associate the management data transmitted from the user terminal 604 and the management server 601, it is only temporary. This is because when the management data is transmitted to the storage server 603, the verification data is rewritten on the storage server 603 side. Further, the storage server 603 associates the management data with information determined by the communication session between the settlement server 602 and the user terminal 604, so that it is not necessary to identify the user.
  • FIG. 8 shows a functional block diagram of the storage server 603.
  • the storage server 800 includes a deposit management data reception unit 801, a management data transmission unit 802, a management data reception unit 803, a storage unit 804, an ID reception unit 805, and a deposit management data transmission. Part 806.
  • the deposit management data receiving unit 801 receives the management data 807 and the ID 808.
  • Management data 807 and ID 808 correspond to management data 1 and session ID transmitted from the settlement server to the storage server in the description in step S704 of FIG. However, as will be described later, the deposit management data receiving unit 801 does not always receive the management data 807 and the ID 808 from only the payment server.
  • the ID 808 is desirably information that uniquely identifies the management data 807. For this reason, the deposit management data receiving unit 801 may manage the history of received IDs, and may return a request for retransmission of IDs when receiving data that matches an ID received in the past.
  • the received ID history can also be managed by a table or the like managed by the storage unit 804 described later. That is, if the same ID is stored in the table managed by the storage unit 804, an ID retransmission request may be returned.
  • the deposit management data receiving unit 801 expands the received management data 807 and ID 808 in the memory. Then, the management data 807 is transmitted by passing the memory address of the management data 807 to the management data transmission unit 802, and the ID 808 is transmitted by passing the memory address of the ID 808 to the storage unit 804.
  • the management data transmission unit 802 transmits the management data 807 transmitted from the deposit management data reception unit 801.
  • the transmission destination is a management server.
  • the verification data is rewritten, and the updated management data 809 is returned.
  • Management data receiving unit 803 receives management data 809 returned from the management server in response to transmission of management data 807 from management data transmitting unit 802. As described above, the management data 809 is obtained by replacing at least the verification data in the management data 807. The management data receiving unit 803 transfers the management data 809 by expanding the received management data 809 in a memory and passing the memory address and the like to the storage unit 804.
  • the storage unit 804 holds the ID 808 transmitted from the deposit management data receiving unit 801 and the management data 809 transmitted from the management data receiving unit 803 in association with each other.
  • the ID 808 and the management data 809 are transmitted to the storage unit 804 at different times.
  • the storage server 800 may give unique identification information to the management data 807 and the ID 808 received by the deposit management data receiving unit 801, for example.
  • the deposit management data receiving unit transmits the unique identification information together with the ID 808 to the storage unit 804. Further, when the management data transmission unit 802 starts a communication session with the management server in order to transmit the management data 807, the communication session is associated with the unique identification information.
  • the management data 809 When the management data 809 is received, unique identification information is acquired from the communication session, and the management data receiving unit 803 transmits the unique identification information to the storage unit 804 together with the management data 809. As a result, the storage unit 804 can associate the ID 808 with the management data 809. Further, the unique identification information given by the storage server 800 may be included in the management data 807 and transmitted. The management server rewrites the verification data without changing the unique identification information.
  • the storage unit 804 may use a table to store IDs and management data in association with each other.
  • FIG. 9 shows such a table.
  • ID “e987abc” and management data including “1491625” as collation data are held in association with each other.
  • the ID “e987abc” is, for example, the ID of the communication session between the user terminal and the payment server for the payment processing performed as the processing in step S701 in FIG.
  • step S707 information serving as a storage notification in step S707 may be transmitted.
  • This storage notification may be returned as an ACK when the deposit management data receiving unit 801 receives the management data 807 and the ID 808, for example.
  • the ID receiving unit 805 receives the ID 810 and searches for management data stored in association with the ID 810 and the storage unit 804. If there is management data stored in association with the ID 810 as a result of the search, the ID reception unit 805 reads the management data and transmits it to the deposit management data transmission unit 806. Also, the association between the ID 810 and its management data is canceled or discarded. Specifically, the cancellation or destruction is realized by deleting the row data in which the ID 810 is stored from the table shown in FIG. Alternatively, the table shown in FIG. 9 may be provided with a column for storing a deletion flag, and a value indicating that it has been deleted may be stored to express that it has been canceled or discarded.
  • the deposit management data transmission unit 806 transmits the management data transmitted from the ID reception unit 805. It is assumed that the transmission destination of the management data is the transmission source of ID810. However, when the transmission destination of the management data is received by the ID receiving unit 805 together with the ID 810, the management data may be transmitted to the transmission destination.
  • FIG. 10 is an example of a flowchart for explaining the flow of processing until the management data and ID are received and stored in the storage server 800.
  • the deposit management data receiving unit 801 receives management data and ID.
  • the management data is transmitted to the management server by the management data transmitting unit 802.
  • the management data receiving unit 803 receives management data.
  • the storage unit 804 stores the ID received in step S1001 in association with the management data received in step S1003.
  • FIG. 11 is an example of a flowchart for explaining the flow of processing from receiving an ID in the storage server 800 to transmitting management data stored in association with the ID.
  • the ID reception unit 805 receives an ID.
  • it is confirmed that management data associated with the ID is stored in the storage unit 804. If it cannot be confirmed, an error is returned to the sender of the ID. If it can be confirmed, the management data stored in association with the ID is read as the processing of step S1103.
  • step S1104 the state where the ID and the management data are stored in association with each other is canceled. For example, the row data is deleted from the table shown in FIG. 9 as described above. Thereafter, as processing in step S1105, the deposit management data transmission unit 806 transmits management data.
  • management data can be issued while maintaining anonymity.
  • management data can be transferred between users via such a storage server.
  • a storage server Although described as “between users,” in this case, one user is a person who purchases goods or services, and the other is a person who provides the goods or services. Is assumed to be transferred from one person to the other.
  • the other may be a virtual store accessed from the Internet using a WEB server or the like.
  • the storage server operates as a server that performs a settlement process. Further, by using the storage server, management data can be transferred between general users such as individuals.
  • FIG. 12 shows a configuration of a system 1200 for transferring management data between users.
  • the server has a management server 1201, a storage server 1203, an assigner terminal 1204, and an assignee terminal 1205.
  • a flow of processing when the user (transferee) of the transferee terminal 1204 transfers management data to the user (transferee) of the transferee terminal 1205 will be described below.
  • the transferor receives management data from the management server in advance, obtains management data via the settlement server, or obtains management data from the settlement server and the storage server in advance. Alternatively, management data is transferred from another transferor.
  • the transfer in this case may be performed via a storage server, as will be described, or a storage medium such as an optical disk or portable nonvolatile semiconductor memory on which management data is recorded from another transferor. It may be assigned or assigned as e-mail attachment data.
  • FIG. 13 is a sequence diagram illustrating the flow of transfer of management data via the storage server.
  • the transfer of management data is agreed between the transferor terminal 1204 and the transferee terminal 1205.
  • This agreement is an agreement in which the transferor transfers management data to the transferee for free, or an agreement in which the transferor transfers management data in exchange for the transferee providing goods or services as described above.
  • the transferor terminal (first terminal) used by the transferor and the transferee terminal (second terminal) used by the transferee may mutually authenticate.
  • an encryption key for encryption and decryption is shared between the first terminal and the second terminal.
  • information that uniquely identifies the mutual authentication is determined. For example, when shopping at a WEB shop, the ID of an encrypted communication session between a WEB server and a terminal is used.
  • the transferee's terminal receives management data issuance, or selects from the management data that has already been issued or has been transferred by a third party for management.
  • Data 3 and session ID are transmitted to the storage server 1203.
  • the storage server that has received the management data 3 and the session ID transmits the management data 3 to the management server as the process of step S1303.
  • the management server confirms that the verification data included in the management data 3 is valid
  • the management server 4 replaces the data with the newly prepared verification data, and returns the management data 4 to the storage server as the process of step S1304.
  • the management data 3 becomes management data including invalid verification data and cannot be used twice.
  • the storage server When the storage server receives the management data 4, the storage server stores the data in association with the session ID received in step S1302, and transmits a storage notification to the transferee terminal as the process of step S1305. The transferee terminal that has received the storage notification transmits a deposit notification to the transferor terminal as the process of step S1306.
  • the transferee terminal that has received the deposit notification transmits a management data transmission request together with the session ID at the time of the transfer agreement to the storage server as processing in step 1307, and in response to this, the storage server sends the management data 4 in step S1308 Reply as a process.
  • the same processing can be performed by the storage server when issuing the management data and when transferring the management data.
  • anonymity of management data can be secured.
  • an upper limit may be provided for the value represented by the management data.
  • the value of 13000 yen is represented by, for example, two management data representing 5000 yen and one management data representing 3000 yen.
  • management data representing value less than the upper limit value, such as management data representing 3000 yen is referred to as “fractional management data”.
  • the amount of money is not necessarily the upper limit mentioned above. For this reason, the price is paid by the management data including the fraction management data, or the management data including the fraction management data is transferred instead of the change in the management data flow in the direction opposite to the payment. For this reason, the number of fraction management data increases. As a result, there arises a problem that the data managed by the database unit of the management server increases. Therefore, hereinafter, a configuration for preventing an increase in the fraction management data will be described.
  • the management data receiving unit 105 includes a fraction management data receiving unit and a payment amount receiving unit
  • the replacement unit 106 includes a fraction changing unit, Fishing management data generation means
  • the replacement management data transmission unit 107 has fraction management data transmission means and fishing management data transmission means.
  • the fraction management data receiving means is means for receiving fraction management data. It is assumed that the received fraction management data is transmitted from the storage server and received by the management server together with one or more other management data, and the validity of the verification data is confirmed. When the fraction management data receiving means receives the fraction management data, the fraction management data is expanded in the memory, acquires the address of collation data included in the fraction management data, and transmits it to the fraction change means.
  • the payment amount receiving means represents the value to be transferred out of the values represented by the management data excluding those received by the fraction management data receiving means among the management data received by the management data receiving unit 105. That is, it is mainly assumed to represent the value to be transferred from the transferor terminal to the transferee terminal via the storage server. If there is a value that is not transferred, the value is transmitted to the transferor terminal as fishing management data as will be described later.
  • the fraction changing means converts the value received by the payment receiving means to the value represented by the fraction management data received by the fraction management data receiving means when the remainder when dividing the value by the above upper limit value is not zero. A process of adding the remainder is performed. For example, if the upper limit is 5000 yen and the value received by the payment receiving means is 13000 yen, dividing 13000 yen by 5000 yen results in a remainder of 3000 yen. Therefore, if the fraction management data received by the fraction management data receiving means represents 1000 yen by the database unit 101, the database managed by the database unit 101 is changed to represent 4000 yen obtained by adding 3000 yen to 1000 yen. Perform operations.
  • the fraction changing means searches the table shown in FIG. 2 (a) by the matching data designated by the address transmitted from the fraction management data receiving means, and the matching data is stored in the table.
  • the above-mentioned remainder is added to the value of the value associated with the verification data. If the result of addition exceeds the above upper limit, the value of the upper limit is registered in the table instead of the result of addition, and data for comparison is newly prepared and inserted into the table. Associate the amount minus. For example, it is assumed that 1000 yen is associated with the verification data designated by the address transmitted from the fraction management data receiving means, and the remainder is 4500 yen. The result of the addition is 5500 yen, exceeding the upper limit of 5000 yen.
  • an upper limit of 5000 yen is associated with the verification data designated by the address transmitted from the fraction management data receiving means, and 500 yen is associated with the newly prepared verification data.
  • associating with 5000 yen and 500 yen is an example, and can be arbitrarily divided into a plurality of values so as not to exceed the upper limit of 5500 yen. For example, it may be 2500 yen and 3000 yen.
  • the fishing management data generating means subtracts the value received by the payment receiving means from the value represented by the management data excluding the management data received by the fraction management data receiving means from the management data received by the management data receiving unit 105. If the value (referred to as “fishing value”) is not 0, management data representing the fishing value is generated. Management data may be newly generated, or management data other than the management data received by the management data receiving unit 105 other than that received by the fraction management data receiving means may be reused. You may add a fishing value to the value you represent. If the added result exceeds the upper limit, new management data is generated so that the value exceeding the upper limit is not associated with the management data.
  • Each of the fraction change means and the fishing management data generation means includes the verification data included in the fraction management data received by the fraction management data reception means, and the verification data included in the management data representing the fishing value generated by the fishing management data generation means. May be rewritten by preparing new verification data.
  • the fraction management data transmission means transmits the management data to which the value has been added by the fraction changing means, and newly generated management data as necessary.
  • the fishing management data transmission means transmits the management data generated by the fishing management data generation means.
  • the deposit management data receiving unit 801 of the storage server can receive the payment amount information together with the management data and the ID.
  • the payment amount information is information indicating the value to be transferred by transferring the management data. Then, when the payment amount information is received, the deposit management data receiving unit 801 searches the management data stored in the storage unit 804 in association with the received ID, and receives the obtained management data.
  • the payment amount information is transmitted to the management data transmission unit 802 together with the management data.
  • the management data associated with the received ID and stored in the storage unit 804 is fraction management data transmitted from the transferee terminal.
  • the management data transmission unit 802 transmits the payment amount information transmitted together with the management data.
  • the management data receiving unit 803 can also receive fishing management data.
  • the storage server sends the fishing management data together with the storage notification to the transmission source of the management data received by the deposit management data receiving unit 801. Send back.
  • FIG. 14 is a sequence diagram for explaining an example of the flow of transfer of management data via the storage server in the present embodiment.
  • a transfer agreement is performed between the transferor terminal and the transferee terminal as in step S1301.
  • the value transferred by the transfer of the management data is agreed. For example, the price of goods, the shipping cost, etc.
  • the management data that the transferor terminal transmits to the storage server is referred to as payment management data.
  • step S1402 the fraction management data 1 and the session ID are transmitted to the storage server from the transferee terminal to the storage server. At this time, information indicating that the terminal is an assignee terminal may also be transmitted.
  • step S1403 the storage server transmits the received fraction management data 1 to the management server to confirm its validity.
  • step S1404 the storage server receives the fraction management data 2 from the management server. . Then, the fraction management data 2 is stored in association with the session ID.
  • the transferee terminal transmits the payment amount, the payment management data 1 for payment, and the session ID to the storage server as processing in step S1405.
  • the storage server transmits the payment management data 1 and the payment amount to the management server. Further, the storage server detects the presence / absence of the fraction management data associated with the session ID, and if such fraction management data exists, transmits the fraction management data to the management server.
  • the transfer amount may be transmitted from the transferee terminal. In this case, it may be confirmed that the payment amount transmitted from the transferor terminal is the same as the transfer amount. If they are not the same, an error is notified to the transferee terminal and transferor terminal.
  • step S1402 the transfer amount is transmitted from the transferee terminal, and in step S1405, the payment amount is not transmitted from the transferor terminal.
  • the value associated with the payment management data 1 is greater than or equal to the amount transferred. If a fee or the like is collected along with the transfer, it is confirmed that the value obtained by subtracting the value of the fee or the like from the value associated with the payment management data 1 is equal to or greater than the amount received. Further, an amount such as a fee may be collected from the value associated with the fraction management data 1.
  • the management server generates fraction management data 3, payment management data 2, and fishing management data from the received payment management data 2, payment amount, and fraction management data 1 by the replacement unit 106 and replacement management data transmission unit 107.
  • the data is transmitted to the storage server.
  • the fraction management data 3 is management data changed and generated by the fraction changing means
  • the fishing management data is management data generated by the fishing management data generating means.
  • the storage server that has received the fraction management data 3, the payment management data 2, and the fishing management data stores the payment management data 3 and the fraction management data in association with the session ID received in step S1402 or S1405.
  • fishing management data and a storage notification are transmitted to the transferee terminal.
  • the transferor terminal transmits a deposit notice to the transferee terminal
  • the transferor terminal transmits a transmission request and a session ID to the storage server, and the storage server responds with the session ID and the session ID.
  • the fraction management data 3 and the payment management data 2 stored in association with each other are transmitted to the assignee terminal as the process of step S1411. Then, the association between the session ID, the fraction management data 3 and the payment management data 2 is discarded.
  • the value agreed upon in the transfer agreement is transferred electronically from the transferor terminal to the transferee terminal.
  • an upper limit is set for the value represented by the management data
  • by providing the fraction management data from the transferee terminal it is possible to add a value corresponding to change to the fraction management data.
  • the increase in the number of fraction management data can be prevented.
  • the assignee terminal may have a function equivalent to that of the terminal device, and includes a case where the server device is used as the terminal device. The same applies to the transferee terminal.
  • FIG. 15A shows an example of a table to be managed by the database unit 101 of the management server in the present embodiment.
  • the database unit 101 in addition to the table for associating the verification data with the value data as in the first or second embodiment, the database unit 101 has a table for associating the verification data with the owner ID (owner identification information).
  • the owner ID is an ID for identifying a person who owns the management data. Having management data means a person who has the title to which the value represented by the management data belongs.
  • the owner ID for example, information that can identify a person such as an ID issued by a management server, an e-mail address, a resident card code, a public key certificate, or the like can be used.
  • the management server preferably authenticates a person who has accessed by presenting the owner ID to the management server or the like by holding the owner ID associated with a password or the like. Note that it is not necessary to store the owner ID as it is in the table shown in FIG. 15A, and the hash value of the owner ID may be calculated and stored.
  • FIG. 15B illustrates a management data issue request according to this embodiment.
  • ⁇ owner ID> MEKAJIKA ⁇ / owner ID> using a tag indicating the owner ID is added. This indicates that the owner of the management data to be issued should be identified by an ID (identification information) “MEKAJIKA”.
  • ID identification information
  • MEKAJIKA is, for example, an ID for identifying a settlement server, a user terminal that has settled with the settlement server, or an ID for identifying the user.
  • the management server that has received the management data issuance request as shown in FIG. 15B issues the management data as in the first or second embodiment, and the verification data and the management data issuance request included in the issued management data. Are inserted into a table that associates the verification data with the owner ID. If the received management data issuance request does not include the owner ID, it is not necessary to perform an operation such as insertion into a table that associates the verification data with the owner ID.
  • FIG. 15C shows a table in the case where management data including “351113” as the verification data is generated in response to the management data issue request shown in FIG.
  • management data including “351113” as the verification data is generated in response to the management data issue request shown in FIG.
  • the table associating the verification data with the owner ID “351113” and “MEKAJIKA” are stored in association with each other.
  • FIG. 15D shows an example of management data in the present embodiment.
  • the management data includes verification data.
  • the owner ID is also included. However, it is not essential that the owner ID is included in the management data, but when transferring the management data, the transferor sends the owner ID of the transferee together with the management data to the management server or the storage server. Thus, the owner ID included in the management data is changed in the management server or the storage server. Alternatively, the transferor sends the owner ID of the transferee to the management server or storage server by including it in the management data in a state surrounded by ⁇ owner ID> and ⁇ / owner ID>.
  • the table for associating the verification data managed by the database unit 101 of the management server with the owner ID can be updated.
  • the replacement unit owns the owner ID associated with the verification data included in the management data.
  • the owner ID included in the management data is associated with the verification data included in the management data, for example, by replacing with the owner ID. If the management data received by the management data receiving unit 105 does not include an owner ID, the association between the verification data included in the management data and the owner ID may be canceled. This operation is referred to as “an operation for changing the association between the verification data and the owner ID”.
  • a unit that performs the “operation for changing the association between the verification data and the owner ID” is referred to as an owner changing unit.
  • the owner change unit may be realized as an internal module of the replacement unit, for example.
  • the change operation by the owner change unit prepares new collation data and replaces the collation data contained in the received management data and stored in the database unit with the prepared collation data
  • the verification data included in the received management data may be replaced with the prepared verification data before execution.
  • FIG. 16 illustrates a functional block diagram of the management server according to the present embodiment.
  • the management server 1600 includes a database unit 101, an issue request reception unit 102, a generation unit 103, a generation management data transmission unit 104, a management data reception unit 105, and a replacement unit 106. And a replacement management data transmission unit 107, and further includes an owner ID acquisition unit 1601, a collation data search unit 1602, and a search data transmission unit 1603.
  • the management server in the first or second embodiment may further include an authentication management data acquisition unit 1604, an owner ID search unit 1605, and an owner ID transmission unit 1606.
  • the management server 1600 includes an owner ID acquisition unit 1601, a verification data search unit 1602, a search data transmission unit 1603, an authentication management data acquisition unit 1604, and an owner ID search unit. 1605 and an owner ID transmission unit 1606 may be included.
  • the owner ID acquisition unit 1601 acquires the owner ID 1607.
  • the owner ID 1607 transmitted from the user terminal is acquired by receiving it through a network adapter connected to a network or the like. And it is preferable to authenticate the person who acquired the owner ID 1607. As this authentication, whether or not the password associated with the owner ID matches, generates a random number, etc., encrypts and returns with the public key associated with the owner ID, and receives the decryption result Judgment is made based on whether it matches the generated random number. If authentication is not possible, an error is returned and processing is stopped.
  • the matching data search unit 1602 searches the table for associating the matching data with the owner ID based on the owner ID acquired by the owner ID acquisition unit 1601 and searches for the matching data associated with the owner ID. get.
  • the search management data transmission unit 1603 generates and transmits management data from the verification data acquired by the verification data search unit 1602.
  • the search management data transmission unit 1603 may be configured not to transmit management data due to the suspension of processing due to failure of authentication by the owner ID acquisition unit 1601.
  • FIG. 17 is a flowchart for explaining the processing flow of the management server 1600 by the owner ID acquisition unit 1601, the collation data search unit 1602, and the search data transmission unit 1603.
  • the owner ID acquisition unit 1601 acquires the owner ID by reception or the like.
  • the collation data retrieval unit 1602 retrieves collation data associated with the owner ID.
  • the search data transmission unit 1603 generates management data based on the searched collation data as the process of step S1703, and transmits the management data as the process of step S1704.
  • the management server 1600 includes the owner ID acquisition unit 1601, the collation data search unit 1602, and the search data transmission unit 1603, thereby presenting the owner ID to the management server 1600.
  • the management data owned by the user ID can be restored. That is, even if the management data is lost, the management data can be restored by the owner ID.
  • the authentication management data acquisition unit 1604 acquires management data 1609. Acquisition is performed by receiving via a network adapter connected to the network.
  • the owner ID search unit 1605 acquires the verification data included in the management data 1609 acquired by the authentication data acquisition unit 1604, and searches the table for associating the verification data with the owner ID based on the verification data. , Get the owner ID.
  • the owner ID transmission unit 1606 transmits the ID acquired by the owner ID search unit 1605.
  • a case where a plurality of different owner IDs are acquired by the owner ID search unit 1605 is conceivable. For example, when a plurality of management data is acquired by the authentication management data acquisition unit 1604, a plurality of different owner IDs may be acquired. In this case, only the owner ID that appears most frequently acquired by the owner ID search unit 1605 may be transmitted. Further, the owner ID transmission unit 1606 authenticates the user who uses the destination terminal device or the destination terminal device with a password or the like for each owner ID, and transmits the owner ID that has been successfully authenticated. It may be.
  • FIG. 18 is a flowchart illustrating the processing flow of the management server 1600 by the authentication management data acquisition unit 1604, the owner ID search unit 1605, and the owner ID transmission unit 1606.
  • management data is received by the authentication management data acquisition unit 1604.
  • the owner ID search unit 1605 acquires verification data from the received management data and searches for the owner ID associated with the verification data as the process of step S1802.
  • the owner ID obtained by the search is transmitted.
  • the management server 1600 includes the authentication management data acquisition unit 1604, the owner ID search unit 1605, and the owner ID transmission unit 1606, the owner ID is forgotten.
  • the owner ID can be obtained. That is, it can be considered that authentication is performed using management data as a kind of authentication data. Also, other management data can be obtained by presenting the owner ID to the management server.
  • the management data that should originally be held in the transferee terminal is held in the storage server, so that the execution of the processing in steps S1402, S1403, S1404, S1410, and S1411 in the sequence diagram of FIG. 14 may be omitted.
  • the fraction management data 2 uses the fraction management data stored in the storage server for the assignee.
  • the storage server may store the transferee identification information, and the identification information included in the fraction management data 3 and the payment management data 2 received in step S1407 may be the transferee identification information. Thereby, it is possible to prevent the stored data from being accessed illegally and the fraction management data and payment management data from being used illegally.
  • the management data stored in the storage server may be downloaded to the terminal device after the transferee receives the authentication of the storage server using FTP (File Transfer Protocol) or the like to log in.
  • FTP File Transfer Protocol
  • the assignee can use the downloaded management data for payment or the like.
  • FIG. 19 shows a configuration of a system 1900 according to the fifth embodiment of the present invention.
  • the system 1900 includes a management server 1901, a settlement server 1902, a storage server 1903, and a user terminal 1904.
  • the management server 1901, the settlement server 1902, the storage server 1903, and the user terminal 1904 each include hardware such as a communication adapter and perform communication.
  • the user of the user terminal 604 does not need to directly communicate with the management server 601, but in the present embodiment, the user terminal 1940 is configured so as to be compatible with various payment server configurations.
  • the user is also configured to communicate with the management server 1901.
  • the management server 1901, the settlement server 1902, the storage server 1903, and the user terminal 1904 are basically the management server 601, the settlement server 602, the storage server 603, and the usage in the first embodiment.
  • the same configuration as the person terminal 604 may be used.
  • the management server 1901 and the user terminal 1904 since the management server 1901 and the user terminal 1904 communicate with each other, the configuration for realizing this point is different. That is, the management server 1901 has a configuration for providing a service to the user terminal 1904.
  • the management server 601 includes a unit that operates as a web server, and provides services to the terminal device 1904. Therefore, in this case, the user terminal 1904 communicates with the management server 1901 using browsing software such as a web browser.
  • an application program for managing management data (referred to as “management data management application”) may be installed in the user terminal 1904, and the management server 1901 is used using the management data management application. You may come to communicate with.
  • FIG. 20 is a sequence diagram for explaining processing from when the payment processing is performed in the system 1900 according to the present embodiment until management data is generated and received by the user terminal.
  • step S2001 information including identification information of the user terminal 1904 is transmitted from the user terminal 1904 to the management server 1901.
  • the identification information is information for identifying the user terminal 1904. Examples of the identification information include a manufacturing number, a MAC address, and an IP address of the user terminal 1904. Alternatively, a user ID or owner ID that is information for identifying a user may be used. Further, the identification information does not need to be the information itself such as the manufacturing number, MAC address, and IP address of the user terminal 1904, and is a value calculated by applying a predetermined hash function to the information. May be. This identification information may be embedded in management data issued later by the management server 1901.
  • the identification information includes a random number, and there may be a portion that changes each time the information is transmitted to the management server 1901.
  • an identification information receiving part a part that receives identification information is called an identification information receiving part.
  • the identification information is transmitted from the user terminal 1904 to the management server 1901 as, for example, a POST message of HTTP (Hyper Text Transfer Protocol).
  • the identification information does not need to be transmitted by the browser, and may be transmitted by the management data management application described above.
  • the management data management application it is possible to easily access the hardware of the terminal device 1904 and acquire the MAC address and the like.
  • step S2002 the management server 1901 returns the screen information to the user terminal 1904.
  • the screen information is described using, for example, HTML (Hyper Text Markup Language), and can be used to perform a deposit process for issuing management data and a process for receiving issued management data.
  • HTML Hyper Text Markup Language
  • the screen is displayed according to the description of the screen information.
  • the management data management application operating on the user terminal 1904 acquires the received screen information using a READ system call or the like, the web browser is activated and the screen information is displayed by the web browser.
  • FIG. 21 shows an example of displayed screen information.
  • buttons having displays of “deposit” and “receive management data” are displayed.
  • a button having a “deposit” display is pressed, a screen shown in FIG. 21B is displayed by processing such as a script included in the screen information.
  • FIG. 21B is a screen for making a bank transfer, in which a message “Please set the transfer holder's name to 12345” is displayed, and a button having a display of “transfer” is displayed.
  • 12345 is information generated on the management server 1901 side when the management server 1901 receives the identification information in step S2001. Alternatively, it may be a number generated on the user terminal 1904 side, transmitted to the management server 1901 in step S2001, and approved by the management server 1901. The approval is to confirm that the information generated on the user terminal 1904 side is appropriate. For example, it is confirmed that the same information is not generated by another user terminal and transmitted to the management server 1901. Alternatively, if the identification information is a user ID, the user ID itself or a value associated with the user ID.
  • this information is included in the name of the transfer holder so that when the management server 1901 receives a transfer notification from the bank, the transfer responds to which identification information is received. You can know if it was done by screen information.
  • the screen of FIG. 21B may include information on the bank account of the transfer destination.
  • a part that generates, approves, or acquires a transfer holder name and transmits it to the user terminal 1904 is called a transfer holder name transmitter.
  • a button corresponding to each of the plurality of banks may be displayed so that the user of the user terminal 1904 can select a bank contracted from among the plurality of banks.
  • the user terminal 1904 accesses a settlement server 1902 such as a bank, and Internet banking as shown in FIG.
  • a settlement server 1902 such as a bank, and Internet banking as shown in FIG.
  • the login screen for etc. is displayed.
  • a transfer request is transmitted from the user terminal 1904 to the settlement server 1902 as processing in step S2204.
  • This transfer request includes information on the bank account of the operator such as the management server 1901, the transfer holder's name, and the transfer amount.
  • the button including the display of “to transfer” in FIG. 21B is associated with a URL including information on the account of the transfer destination and the name of the transfer holder, and when the URL is accessed, the settlement server 1902 is accessed.
  • the transfer account information and transfer holder name are communicated and the transfer screen is opened, the transfer account information and transfer holder name may already be entered as default values. .
  • a payment notification indicating that the transfer request process is completed is transmitted from the user terminal 1904 to the management server 1901 as the process of step S2204.
  • the identification information and the transfer holder's name transmitted in step S2201 are also transmitted. That is, when the transfer request process is completed at the user terminal 1904, a screen as shown in FIG. 22B is displayed on the user terminal 1904. In the screen shown in FIG. 22B, a button having a display of “payment notification” is displayed. When this button is pressed, a payment notice is transmitted from the user terminal 1904 to the management server 1901 as processing in step S2004.
  • the payment notice is information that informs the management server 1901 from the user terminal 1904 that the transfer request process has been completed at the user terminal 1904.
  • step S2205 the management server 1901 that has received the payment notification obtains the transfer holder name from the information transmitted together with the payment notification, and whether the transfer server 1902 actually requested the transfer with the transfer holder name. Inquire about it. If there is a transfer by the transfer holder name, the settlement server 1902 returns a transfer notification as the process of step S2206.
  • This transfer notification may also include a transfer amount, whereby the management server 1901 can obtain the transfer amount.
  • the management server 1901 may make an inquiry about the presence / absence of the transfer to the management server 1901 once every 5 minutes, for example, and confirm the presence / absence of the transfer.
  • the management server 1901 notifies the payment notification in step S2004 that the transfer has not been confirmed.
  • a message indicating that the transfer has not been confirmed is displayed by the management data management application or the like, and the user makes a payment notification again after a while.
  • the management server 1901 retrieves and obtains the identification information received from the transfer holder name included in the transfer notification by searching the table or the like, generates management data, In addition, as described in the first embodiment, a number for specifying a transfer settlement process is generated. In the present embodiment, the number specifying the payment process is referred to as “feed information”.
  • the sending information may be, for example, the ID of a session in which the user terminal 1904 and the management server 1901 communicated in steps S2001 and S2002. Moreover, you may use the transfer holder's name transmitted by the transfer holder's name transmission part.
  • the generated sending information and management data are transmitted to the storage server 1903.
  • the storage server 1903 associates the sending information and the management data and holds them in the storage unit.
  • a unit that receives a transfer notification is referred to as a transfer notification receiving unit.
  • a unit for preparing new verification data and generating value data corresponding to the amount of money included in the transfer notification received by the transfer notification receiving unit in association with the database unit 101 in order to generate management data Is referred to as a collation data generation unit.
  • a unit that transmits management data generated from the newly prepared collation data is referred to as a management data transmission unit.
  • the management server 1901 stores the prepared collation data and the identification information received by the identification information receiving unit in the database unit 101 or the like in association with each other.
  • the management server 1901 returns a message indicating that the payment has been confirmed and the sending information to the user terminal 1904.
  • steps S2001 and S2002 in the communication between the user terminal 1904 and the management server 1901, if the sending information is notified to the user terminal 1904 as a session ID or a transfer holder name, in step S2008, There is no need to return the sending information to the user terminal 1904.
  • the management server 1901 acquires the sending information generated by the transfer, and returns the payment confirmation and the sending information to the user terminal 1904 as processing in step S2008.
  • the screen shown in FIG. 22 (c) is displayed.
  • a button having a display of “Receive management data” are displayed.
  • the screen of FIG. 22C does not need to be displayed by a browser, and may be displayed by a management data management application.
  • the payment confirmation and the sending information returned in step S2008 are transmitted using the format of MIME (Multipurpose Internet Mail Extension), and the management data management application uses it as the application program by Content-Type in the format. May be specified.
  • MIME Multipurpose Internet Mail Extension
  • step S2009 When the “Receive Management Data” button is pressed, sending information is transmitted from the user terminal 1904 to the storage server 1903 as processing in step S2009.
  • the sending information is received by the storage server 1903, the management data stored in the storage unit in association with the sending information is read in step S2006.
  • step S2010 the management data is received from the storage server 1903 by the user terminal 1904 and stored in the user terminal 1904.
  • FIG. 23 shows the configuration of a table that is referred to in order for the management server 1901 to perform the processing from receiving the identification information from the user terminal 1904 in step S2001 to transmitting the payment confirmation and the sending information in step S2008.
  • the management server 1901 maintains and manages a table composed of columns having names of “identification information”, “transfer number”, “money amount”, and “feed information”.
  • step S2001 row data is inserted into the table. If the identification information is 98765, for example, as shown in FIG. 23B, a row whose identification information column value is 98765 is inserted into the table. In the row, the value of the column other than the column of identification information is, for example, NULL (not shown). By setting it to NULL, it is expressed that the value is not yet determined.
  • the value of the transfer number column in the inserted row is updated to the transfer holder name. For example, if the transfer holder's name is 12345 as shown in FIG. 21 (b), the transfer number column value of the row whose identification information column value is 98765 is shown in FIG. 23 (c). It is updated to 12345.
  • the management server 1901 When the management server 1901 receives the transfer notification in step S2006, a row having the transfer holder name included in the transfer notification in the transfer number column is searched, and the value in the amount column is updated with the transfer amount included in the transfer notification.
  • the management server 1901 can confirm that there has been a transfer.
  • the management server 1901 When the management server 1901 generates the sending information and sends the sending information to the storage server 1903 in step S2007, the value in the “feed information” column is updated. For example, when 5000 yen is transferred with the transfer holder name of 12345 and the feed information of 246810 is generated, as shown in FIG. 23E, the column of the feed information of the row whose identification information column value is 98765, as shown in FIG. Is updated to 246810. As a result, the management server 1901 can confirm that the management data is generated for the identification number of 98765 and transmitted to the storage server 1903.
  • FIG. 24 shows a functional block diagram of the user terminal 1904.
  • This functional block diagram shows the configuration of an application program installed in the user terminal 1904.
  • a browser and a management data management application are installed on the user terminal 1904.
  • the browser and the management data management application operate in cooperation to perform processing for receiving management data from settlement processing.
  • FIG. 25 the browser installed in the user terminal 1904 and the management data management application cooperate to perform the payment process shown in FIG. 20, and the management data is generated and received by the user terminal.
  • FIG. 25 the browser installed in the user terminal 1904 and the management data management application cooperate to perform the payment process shown in FIG. 20, and the management data is generated and received by the user terminal.
  • Step S2501 corresponds to step S2001.
  • the identification information is transmitted from the management data management application. If the management data management application is used, hardware-specific information such as a MAC address can be acquired by accessing the hardware of the user terminal 1904 more easily than using a browser.
  • the management data management application is activated on the user terminal 1904.
  • a screen display including buttons having displays of “payment (point purchase)”, “receipt of points”, and “payment by points” is displayed on the user terminal. 1904 is displayed.
  • the management data management application calculates identification information and transmits it to the management server 1901.
  • Step S2502 corresponds to step S2002.
  • screen information returned from the management server 1901 in response to the identification information transmitted in step S2501 is received by the management data management application.
  • the management data management application When the management data management application receives the screen information, as a process of step S2503, the management data management application starts a browser and performs a process of displaying a screen according to the description of the screen information. For example, the management data management application writes the received screen information to a temporary file, and gives the name of the temporary file to the browser as a command argument or the like to start the browser. For example, a browser associated with the extension of the temporary file is started.
  • Step S2504, Step S2505, Step S2506, Step S2507, and Step S2508 correspond to Step S2003, Step S2004, Step S2005, Step S2006, Step S2007, and Step S2008, respectively.
  • the browser communicates with the management server 1901 and the settlement server 1902 at the user terminal 1904.
  • step S2509 when the browser receives the payment confirmation and the sending information from the management server 1901, the browser activates the management data management application and causes the management data management application to process the sending information.
  • the payment confirmation and the sending information are received by the browser as information using the MIME format, it is specified by the management data management application by Content-Type or the like in that format.
  • the browser activates the management data management application, and the activated management data management application acquires the sending information.
  • the management data management application sends information to the storage server 1903.
  • a process of receiving management data returned from the storage server 1903 is performed as the process of step S2511.
  • the management data management application receives the management data, the received management data is written in a storage device (such as a hard disk) of the user terminal 1904.
  • the screen of FIG. 26 may be displayed.
  • the processing in steps S2511 and S2512 may be started.
  • FIG. 27 shows a module configuration diagram of the management data management application.
  • the management data management application 2700 includes an identification information acquisition unit 2701, a sending information management unit 2702, a management data management unit 2703, a transmission / reception unit 2704, and a control unit 2705.
  • the identification information acquisition unit 2701 acquires the identification information transmitted in step S2501. For example, the hardware of the user terminal 1904 is accessed using a system call or the like, and a MAC address, a manufacturing number, and the like are acquired. Further, authentication information such as a user ID and password of the user terminal 1904 may be acquired as identification information. The authentication information may be stored in a file or read by a keyboard or a card reader. In addition, when a part of the authentication information includes a random number, the identification information acquisition unit 2701 may generate the random number.
  • the identification information acquired by the identification information acquisition unit 2701 may be stored in a secondary storage such as a hard disk of the user terminal until management data is received by the process of step S2511.
  • the management data management application When the management data management application is activated, it is checked whether or not the identification information is stored in the secondary storage. If it is stored, an indication that the management data not received has been stored in the storage server 1903 is displayed. To alert the user. In this case, if the user is processing the transfer request, the management data management application may send the payment notification in step S2505 to the management server 1901 and receive the payment confirmation and sending information. Display buttons etc. so that you can. When the button is pressed, the management data management application transmits a payment notice to the management server 1901.
  • step S2310 the feed information management unit 2702 manages the feed information passed from the browser.
  • Management means writing, reading, deleting, and updating of data to a file.
  • the sending information passed from the browser is written in a predetermined file.
  • management data is received by the processing in step S2511, a predetermined file is deleted or sending information is deleted from the predetermined file. As a result, it is possible to check whether or not there is management data that has been received but has not been received.
  • Management data management unit 2703 manages management data.
  • the management data received in step S2511 is written to the storage device (hard disk or the like) of the user terminal 1904 by the management data management unit 2703, and is read out, deleted, and deleted during the payment process using the management data. Changes are made.
  • the transmission / reception unit 2704 is a unit for communicating with the management server 1901 and the storage server 1903.
  • the control unit 2705 controls the identification information acquisition unit 2701, the sending information management unit 2702, the management data management unit 2703, and the transmission / reception unit 2704, and performs management data reception processing and payment processing using management data. Do.
  • FIG. 28 shows a sequence diagram of payment processing using management data.
  • FIG. 28 corresponds to FIG. 14, which is a sequence diagram regarding the transfer of management data via the storage server.
  • the transferee terminal in FIG. 14 corresponds to the sales server in FIG. 28, and the transferor terminal corresponds to the user terminal.
  • the management data management application and the browser operate in cooperation within the user terminal.
  • the sales server has a function as a WEB server, and if there is a request for browsing the WEB page, it returns the requested WEB page.
  • step S2801 a process of inputting a URL to a browser of a user terminal or operating a browser to follow a link is performed, and a web page browsing request is transmitted to the sales server.
  • the sales server receives the browsing request, the requested web page is returned in step S2802.
  • the web page returned to the browser in step S2802 describes a screen for applying for purchase of a product or the like.
  • the name of a product to be purchased is displayed as “XX”, and the price is displayed as 100 yen, for example.
  • a button having a display of “purchase” is displayed. This button is associated with an identification number such as a product to be purchased.
  • the web page includes a text area for inputting a delivery destination of the product. When a button having a display of “purchase” is pressed, information input in the text area is displayed. It may be transmitted.
  • purchase information is transmitted to the storage server as processing in step S2803.
  • the purchase information is information including the identification information of the sales server, the identification number of the product to be purchased, the quantity of the product, and the price. Further, it may include a shipping destination such as the above-mentioned product.
  • This purchase information is generated using information associated with the button shown in FIG. 29 and transmitted to the sales server.
  • step S2801 to step S2803 by performing the processing from step S2801 to step S2803, a transfer agreement is made between the sales server as the transfer terminal and the user terminal as the transferor terminal. Accordingly, the processing from step S2801 to step S2803 corresponds to step S1401.
  • a payment instruction and a session ID are transmitted from the sales server to the browser.
  • the payment instruction includes the amount of value to be transferred (payment amount).
  • corresponds to the above-mentioned sending information.
  • the payment instruction and the session ID may be described in, for example, MIME format and specified to be displayed using the management data management application by Content-Type or the like.
  • the sales server transmits the fraction management data 1 and the session ID to the storage server. This is to receive payment by management data transmitted from the user terminal.
  • the storage server that has received the fraction management data 1 and the session ID from the sales server transmits the fraction management data 1 to the management server as a process of step S2806, and determines whether the fraction management data 1 is valid. If there is, the verification data is rewritten, and the fraction management data 2 which is the management data obtained as a result is received in the processing of step 2807. Then, it is stored in association with the feed information.
  • steps S2805, S2806, and S2807 correspond to the processes in steps S1402, S1403, and S1404.
  • step S2804 the browser that has received the payment instruction and the session ID from the sales server activates the management data management application, and processes the payment instruction and the session ID received from the sales server. That is, the started management data management application manages the management data so that the session ID received in step S2804 and the payment amount included in the payment instruction are equal to or more than the payment amount as the processing of step S2809.
  • the data is selected and read out from the unit 2703 and transmitted as payment management data 1 to the storage server.
  • Payment amount or more means that the total amount of value represented by the selected management data is equal to or more than the payment amount. There may be a plurality of management data read from the management data management unit 2703.
  • the payment amount may be displayed on the screen, and the user may confirm the amount of payment management data by pressing a button. Further, when the management data managed by the management data management unit 2703 is encrypted and stored, an input such as a password for decryption may be requested.
  • step S2809 the storage server that has received the session ID, payment amount, and payment management data 1 from the management data management application stores the payment amount and payment management data 1 in association with the session ID.
  • a search is performed to determine whether there is other management data stored in association with the session ID. If there is such management data, the processing from step S2810 is performed.
  • the processes in steps S2810 and S2811 correspond to the processes in steps S1406 and S1407.
  • the storage server transmits the fraction management data 2, the payment amount, and the payment management data 1 to the management data, and receives the fraction management data 3, the payment management data 2, and the fishing management data.
  • step S2812 the storage server transmits fishing management data to the management data management application.
  • the transmission of the fishing management data may be performed as a reply of the payment amount received in step S2809 and the payment management data 1.
  • step S2813 the management data management application starts a browser and displays a settlement end screen.
  • the description of the settlement end screen may be transmitted to the management data management application by the storage server together with the fishing management data in step S2812. Further, the description of the settlement end screen may be transmitted to the storage server by the sales server together with the fraction management data 1 and the session ID in step S2805.
  • the description of the payment end screen is transmitted from the sales server, transmitted to the user terminal via the storage server, and used for electronic data itself, electronic data download, etc.
  • this embodiment can be used for selling electronic data.
  • the fraction management data 3 and the payment management data 2 received from the management server in step S2814 are transmitted from the storage server to the sales server together with the session ID received in step S2805 (step S2814).
  • the transmission of the fraction management data 3 and the payment management data 2 may be performed as a reply to the fraction management data 1 and the session ID transmitted from the sales server in step S2805.
  • the management data management application is activated and the payment using the management data can be performed. Therefore, in the present embodiment, the user performs the payment processing after transmitting the purchase information to the sales server using the browser in step S2803. There is no need to enter complicated data such as bank account numbers. Further, since the payment is performed using the management data stored in the user terminal 1904, there is no need to worry about subsequent repayment like a credit card. Therefore, the user can pay using the management data with a simple operation. Thereby, payment on the internet etc. can be performed safely and simply.
  • a technique that allows a user to easily open a virtual store using a web server will be described.
  • the sales server communicates with the storage server.
  • a general user of the Internet may not be able to use a web server that is used for opening its own home page as it is as a sales server. Therefore, in this embodiment, a general user of the Internet is configured to communicate with a web server used for opening its own home page and a storage server, and receive management data on behalf of the user. The combination with the sales server will be described.
  • FIG. 30 shows an overview of a system in which a sales server 3002 and a web server 3003 are available from a user terminal 3004 via a communication network 3001 such as the Internet.
  • the sales server 3002 is the sales server described in the fifth embodiment.
  • the sales server 3002 stores the order screen file 3005 in its file system.
  • a browsing request is received from the browser 3007 installed in the user terminal 3004 in step S2801
  • the order is received in step S2802.
  • a screen file 3005 can be returned.
  • the sales server 3002 is not a server that is used only by a specific user for selling products, but can be used by a plurality of users for selling products. There may be no special human relationship among a plurality of users.
  • a virtual store where a plurality of users sell products using the sales server 3002 is assigned a store identification number or the like as information for identifying the store. It is assumed that a virtual store can be accessed from the outside of the sales server 3002 using the store identification number. For example, if a store identification number 4567 is assigned to a store opened by a certain user, the store can be accessed from outside the sales server 3002 using 4567.
  • the web server 3003 is a web server used for general users of the Internet to open their home pages.
  • a general user of the Internet places a web page 3006 in his / her space allocated to the web server 3003.
  • a link to the order screen file 3005 stored in the sales server 3002 is provided on the web page 3006.
  • the URL of the link includes the store identification information described above.
  • a general Internet user places an advertisement such as a product on a web page, guides the user who saw the advertisement to the order screen file 3005, and sells the product or the like. It becomes possible to obtain management data obtained as consideration.
  • a user who opened a store in the sales server 3002 establishes communication with the sales server 3002 using, for example, FTP (File Transfer Protocol) and the like, an order screen file 3005, and an order confirmation file indicating that the order has been accepted. Upload an order failure file indicating that the order could not be accepted.
  • FTP File Transfer Protocol
  • FIG. 31 shows an example of a table configuration for the sales server 3002 to manage the uploaded order screen file.
  • this table is referenced to obtain an order screen file uploaded by the user who opened the store specified by the identification information.
  • the sales server 3002 searches the table of FIG. 31 using the store identification number of the store as a key, The order screen file ID is obtained, the web page specified by the order screen file ID is read, and a reply is made in step S2802.
  • the sales server 3002 acquires the store ID included in the purchase information, searches the table of FIG. The ID and the order failure file ID are obtained, the web page designated by them is read, and in step S2805, it is transmitted to the storage server together with the fraction management data 1 and the session ID.
  • FIG. 32 shows an example of the configuration of the file system of the sales server 3002.
  • a folder is referred to as a store folder.
  • An order screen file, an order confirmation file, and an order failure file are stored in the store folder.
  • the management file indicates a file storing management data paid to the store.
  • the management file 3201 stores management data transferred to a store having 4567 as the store identification number.
  • the fraction management data transmitted in step S2805 is the fractional amount of management data read from the store folder management file.
  • the fraction management data and payment management data received by the sales server in step S2815 are stored in the management file of the store folder.
  • the management data stored in the management file in the store folder can be downloaded by the store owner using FTP or the like.
  • the store folder contains the store's
  • the file 3202 including the identification information of the terminal device used by is uploaded.
  • the fraction management data and payment management data transmitted from the storage server to the sales server in step S2815 are only for the store owner. Can be enabled. Thereby, safety can be enhanced.
  • the management data including the verification data associated with the monetary value or the like is stored in the user terminal, and the stored management data is transferred to thereby provide the monetary value. Can be transferred electronically. This makes it possible to make payment using management data on the Internet.
  • the present invention is an eclectic type in that the verification data is managed by the server and at the same time the management data including the verification data is stored in the terminal device of the user, and has both safety and ease of payment. Provide technology.
  • the management data issued by the management server is stored in the user terminal, and the value is transferred by transferring the management data as necessary. .
  • Whether or not the management data is valid is determined by whether or not the management data verification data is recorded in the database section of the management server. Each time transfer is performed through the management server, the verification data is rewritten. Done. For this reason, it can be presumed that the person possessing the management data is a legitimate right holder, and the need to prove that it is a legitimate owner by ID, password, access code, etc. can be reduced, while maintaining security. It becomes possible to maintain convenience.
  • the management data management application can be automatically started, and payment can be made by the management data management application.
  • the session ID corresponds to, for example, a bank account in the prior art, but since the session ID is transmitted from an Internet site, the user does not need to input the session ID.
  • an upper limit can be given to the value represented by the management data, so that damage caused when the management data is lost can be prevented. From the above, the present invention is industrially useful.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

　第１の照合用データを含む第１の管理データを受信する管理データ受信部と、第１の照合用データが第１の価値の情報に関連付けられていれば、新たな照合用データを準備して、第１の価値情報に前記新たな照合用データを関連付けるとともに第１の管理データに含まれる第１の照合用データを前記新たな照合用データに置換した第２の管理データを生成する置換部と、第１の管理データに第１の所有者識別情報が含まれていれば、第１の所有者識別情報に前記新たな照合用データを関連付ける所有者変更部と、第２の管理データを送信する置換管理データ送信部とを有することを特徴とする管理サーバなどを提供する。

Description

電子的価値情報管理サーバ
　本発明は、電子マネーの決済、電子マネーやその他の電子的な価値情報の譲渡などの処理を行う処理装置、電子的な価値情報の処理方法などに関する。
　電子マネーやその他の電子的な価値情報は、ビット列などの情報に貨幣などの価値が関連付けられている。そのビット列などの情報の交換により決済などの価値の譲渡が実現される。そして、電子マネーは急速に普及しつつあり、交通機関の改札での運賃の支払いや店舗での商品の代金の決済の手段として用いられている。
　ところで、電子マネーやその他の電子的な価値情報に関する技術については、ビット列などの情報は容易に複製されてしまうので、複製後に二重に使用されたことを検出する方法を備える必要がある（例えば、特許文献１参照。）。また、一般的に電子マネーは無記名であり、また、実際の貨幣とは異なり無体物であるため、紛失してしまった場合に被害が甚大となる可能性がある。そこで紛失などに備える必要がある（例えば、特許文献２参照。）。
米国特許４，９７７，５９５号明細書 特開２００７－３１０５６２号公報
　特許文献１及び特許文献２に開示された技術に限らず、従来は、電子マネー等には暗号理論の利用が不可欠であると考えられている。暗号理論を用いることにより二重使用や紛失などの対策を取ろうとしている。このため、電子マネー等を利用するためには、利用者は特殊なＩＣカード等を使用する必要があり、店舗などでは、そのＩＣカード等の読取り装置を備える必要がある。このため、電子マネー等の普及には莫大なコストが必要となる。また、個人間などの一般の利用者間での電子マネー等の譲渡も困難である。
　そこで、本発明では、二重使用を防止し、紛失したとしても復旧が可能であり、専用のＩＣカードなど特別な装置を用いなくても譲渡が可能な電子的な価値情報を管理するサーバ装置などを提供する。
　本発明の一実施形態として、照合用データに価値情報とその価値情報が表す価値を所有する者の所有者識別情報とを関連付けるデータベース部と、第１の照合用データを含む第１の管理データを受信する管理データ受信部と、前記第１の照合用データが前記データベース部により第１の価値情報に関連付けられていれば、新たな照合用データを準備して、前記第１の価値情報に前記新たな照合用データを関連付けるとともに前記第１の管理データに含まれる前記第１の照合用データを前記新たな照合用データに置換した第２の管理データを生成する置換部と、前記第１の管理データに第１の所有者識別情報が含まれていれば、前記第１の所有者識別情報に前記新たな照合用データを関連付ける変更操作を前記データベース部に対して実行する所有者変更部と、前記第２の管理データを送信する置換管理データ送信部と、を有することを特徴とする管理サーバを開示する。
　本発明の別の実施形態として、管理サーバ装置によるデータの送受信方法であって、その管理サーバが、照合用データに価値情報とその価値情報が表す価値を所有する者の所有者識別情報とを関連付けて保持し、第１の照合用データを含む第１の管理データを受信し、前記第１の照合用データが第１の価値情報に関連付けられていれば、新たな照合用データを準備して、前記第１の価値情報に前記新たな照合用データを関連付けるとともに前記第１の管理データに含まれる前記第１の照合用データを前記新たな照合用データに置換した第２の管理データを生成し、前記第１の管理データに第１の所有者識別情報が含まれていれば、前記第１の所有者識別情報に前記新たな照合用データを関連付け、前記第２の管理データを送信することを特徴とする、価値情報に関連付けられたデータの送受信方法を開示する。
　本発明の別の実施形態として、管理サーバにて、所有者識別情報と関連付けられた価値情報に関連付けられた照合用データを含む管理データの譲渡を仲介するための保管サーバの動作方法であって、前記保管サーバは、価値情報に関連付けられた照合用データを含む管理データを送信する第１の端末とその管理データを受信する第２の端末との間で通信セッションを確立し、前記確立された通信セッションにより前記第１の端末と前記第２の端末とで相互認証を行い、前記第１の端末より送信される管理データと前記確立された通信セッションの識別情報とを受信し、前記受信された管理データに含まれる照合用データを、新たに準備された照合用データに置換して置換済管理データを生成し、前記受信された通信セッションの識別情報に関連づけて前記置換済み管理データを保管し、前記第２の端末より、通信セッションの識別情報を受信してその通信セッションに関連づけられて保管されている置換済み管理データを返信することを特徴とする、価値情報に関連付けられた、保管サーバの動作方法を開示する。
　本発明の別の実施形態として、照合用データに可分な価値を表す価値情報とを関連付けるデータベース部と、第１の端末より送信された、上限の量以下の価値を表す第１の価値情報に関連付けられた第１の照合用データを含む第１の管理データと、第２の端末より送信された、前記上限の量未満の価値を表す第２の価値情報に関連付けられた第２の照合用データを含む第２の管理データとを受信する管理データ受信部と、前記上限から前記第２の価値情報が表す価値の差を越えない価値を、前記第１の価値情報の価値から差し引き前記第２の価値情報が表す価値に加算するデータベース変更部と、前記第２の管理情報を前記第２の端末へ向けて送信する管理データ送信部と、有する管理サーバを開示する。
　本発明の別の実施形態として、第１の端末より、上限の値以下の価値を表す第１の価値情報に関連付けられた第１の照合用データを含む第１の管理データを受信し、第２の端末より、前記上限の値未満の価値を表す第２の価値情報に関連付けられた第２の照合用データを含む第２の管理データを受信し、前記上限から前記第２の価値情報が表す価値の差を越えない価値を、前記第１の価値情報の価値から差し引き前記第２の価値情報が表す価値に加算し、前記第２の端末へ前記第２の管理データを含む管理データを送信し、前記第１の端末と前記第２の端末との間で決済処理を行うサーバの動作方法を開示する。
　本発明の別の実施形態として、識別情報を管理サーバに送信する送信部と、前記識別情報の送信の返信として、振り込みの決済処理を行う際の名義人名を表示するための画面情報を受信する受信部と、前記受信された画面情報を表示し決済処理を行うブラウザを起動する起動部と、前記起動されたブラウザによる決済処理の後、前記決済処理が行われたことの確認を前記管理サーバに要求する要求部と、前記決済処理が行われたことの確認が前記管理サーバにされて前記決済処理にて振り込まれた金額の額に相当する価値情報に前記管理サーバにて関連付けられた照合用データを含む管理データを受信する管理データ受信部とを有する端末装置を開示する。
　本発明の別の実施形態として、利用者端末より管理サーバへ前記利用者端末の識別情報を送信し、振り込みの決済処理を行う際の名義人名を前記管理サーバにて生成し、前記生成された名義人名を前記利用者端末へ送信し、前記利用者端末にてブラウザを起動して前記名義人名を用いて決済サーバにて決済処理を行い、前記決済サーバは前記管理サーバに、決済が行われた名義人名と金額とを含む決済情報を送信し、前記決済サーバは、前記決済情報に含まれる金額の額に相当する価値情報に関連付けられた照合用情報を含んで生成された管理データを、前記決済情報を識別するＩＤ情報と関連付けて保管サーバへとともに送信し、前記利用者端末は、前記決済処理を行った通知を前記管理サーバへ送信し、前記管理サーバは、前記名義人名を含む決済情報を受信した通知を前記利用者端末へ返信し、前記利用者端末は、前記決済処理を識別するＩＤ情報を前記保管サーバへ送信し、前記保管サーバは、前記利用者端末より送信されたＩＤ情報に関連付けて前記管理サーバが送信した管理情報を送信することを含む、価値情報に関連付けられたデータの送受信方法を開示する。
　本発明の別の実施形態として、第１のサーバにおいて価値情報が関連付けられているデータを含む管理データを利用者端末に記憶し、前記利用者端末においてブラウザを起動し、商品の販売または役務の提供を行うための第２のサーバより、前記第１のサーバと前記ブラウザとの通信のセッションＩＤと支払うべき価格情報とを、前記ブラウザを経由して受信し、前記記憶されている管理データを１以上選択して前記選択された管理データに関連付けられている価値情報の額を前記価格情報の額以上とし、前記選択された管理データを前記セッションＩＤとともに第３のサーバへ送信するデータ送信方法を開示する。
　なお、本発明において、データや情報の受信及び送信は、ハードウェアとしてのネットワークアダプタなどを制御してネットワークを介した通知を行うことを意味する。２つ以上のデータの関連付けは、ハードウェアとしての記憶装置に記憶されているテーブルに１行のデータとして２つ以上のデータを格納すること、また、それと均等な方法により実現される。
　本発明の一実施形態により、二重使用を防止し、紛失したとしても復旧が可能であり、専用のＩＣカードなど特別な装置を用いなくても流通が可能な電子的な価値情報の利用などを提供できる。また、特別な装置を用いる必要がないので、インターネットなどを介した決済処理を従来の技術よりも簡単に行うことができる。
本発明の一実施形態に係る管理サーバの機能ブロック図である。 本発明の一実施形態における管理データ発行の具体例を説明する図である。 本発明の一実施形態に係る管理サーバの処理のフローチャートである。 本発明の一実施形態における照合用データの書き換えの具体例を説明する図である。 本発明の一実施形態に係る管理サーバの処理のフローチャートである。 本発明の一実施形態に係る管理サーバ、決済サーバ、保管サーバ及び利用者端末からなるシステム構成図である。 本発明の一実施形態に係る管理サーバ、決済サーバ、保管サーバ及び利用者端末からなるシステムによる処理のシーケンス図である。 本発明の一実施形態に係る保管サーバの機能ブロック図である。 本発明の一実施形態における管理データを保管するためのテーブルの一例図である。 本発明の一実施形態における管理データとＩＤとを受信し保管するまでの処理のフローチャートである。 本発明の一実施形態におけるＩＤと関連付けられて補間されている管理データを送信するまでの処理のフローチャートである。 本発明の一実施形態に係る利用者間で管理データを譲渡するシステムの構成図である。 本発明の一実施形態に係る利用者間で管理データを譲渡するシステムによる処理のシーケンス図である。 本発明の一実施形態に係る利用者間で管理データを譲渡するシステムによる処理のシーケンス図である。 本発明の一実施形態における管理データ発行の具体例を説明する図である。 本発明の一実施形態に係る管理サーバの機能ブロック図である。 本発明の一実施形態に係る管理サーバの処理のフローチャートである。 本発明の一実施形態に係る管理サーバの処理のフローチャートである。 本発明の一実施形態に係る管理サーバ、決済サーバ、保管サーバ及び利用者端末からなるシステム構成図である。 本発明の一実施形態において決済処理が行われ管理データが生成されて利用者端末に受信されるまでの処理のシーケンス図である。 本発明の一実施形態に係る利用者端末の画面表示を示す図である。 本発明の一実施形態に係る利用者端末の画面表示を示す図である。 本発明の一実施形態に係る管理サーバが保持するテーブルの構成と内容の遷移を示す図である。 本発明の一実施形態に係る利用者端末の機能ブロック図である。 本発明の一実施形態において決済処理が行われ管理データが生成されて利用者端末に受信されるまでの処理のシーケンス図である。 本発明の一実施形態に係る利用者端末の画面表示を示す図である。 本発明の一実施形態に係る管理データ管理アプリケーションの機能ブロック図である。 本発明の一実施形態に係る利用者端末から販売サーバへ管理データを譲渡する処理のシーケンス図である。 本発明の一実施形態における商品などの購入の申込を行うための画面の一例図である。 本発明の一実施形態に係る販売サーバと、ウェブサーバと、利用者端末とからなるシステムの構成図である。 本発明の一実施形態に係る販売サーバが管理するテーブルの一例図である。 本発明の一実施形態に係る販売サーバのファイルシステムの構成の一例図である。
符号の説明
　　１００　管理サーバ
　　１０１　データベース部
　　１０２　発行要求受信部
　　１０３　生成部
　　１０５　管理データ受信部
　　１０６　置換部
　　１０７　置換管理データ送信部
　　１０８　管理データ発行要求
　　１０９、１１０、１１１　管理データ
　以下、本発明を実施するための最良の形態について実施形態として図を参照しつつ説明を行う。なお、本発明は以下の実施形態に限定されるものではなく、その要旨を逸脱しない範囲において種々なる態様で実施することができる。
　（実施形態１）
　（管理サーバ）
　本発明の一実施形態において、管理サーバとは、電子的な価値情報の譲渡処理を主に行うサーバ装置である。管理サーバが行うその他の処理としては、管理サーバとして必須の処理ではないが、電子的な価値情報の発行処理、発行した電子マネー等に関連付けられた価値を貨幣などとして払い戻す処理などがある場合がある。
　図１は、本発明の一実施形態に係る管理サーバの機能ブロック図を例示する。管理サーバ１００は、データベース部１０１と、発行要求受信部１０２と、生成部１０３と、生成管理データ送信部１０４と、管理データ受信部１０５と、置換部１０６と、置換管理データ送信部１０７とを有する。なお、管理サーバ１００の実現の一態様としては、コンピュータにソフトウェアを読み込ませ、ソフトウェアとハードウェア資源とが協働した具体的手段によって、使用目的に応じた情報の演算又は加工を実現することにより、使用目的に応じた特有の情報処理装置とするものがある。また、専用の回路によるハードウェアのみの構成も可能である。このような実現は、本発明の以下の説明に接した当業者により理解される。
　データベース部１０１は、電子的な価値情報と価値との関連付けを管理する。本発明の一実施形態においては、電子的な価値情報は管理サーバ１００により管理などされるデータであるので、「電子的な価値情報」という用語のかわりに「管理データ」という用語を用いる。そして、本発明の一実施形態においては、管理データは照合用データを含み、この照合用データが価値そのものあるいは価値を表す情報と関連付けられる。また、照合用データは他の情報とも関連付けることができる。
　照合用データと関連付けることができる他の情報としては、例えば、その照合用データを含む管理データの譲渡が行われた回数（譲渡回数）、その照合用データを含む管理データが、どの利用者やどの利用者の端末装置などに対して発行されたかを示す利用者や端末装置などの識別情報などが挙げられ、これらは必要に応じてデータベース部１０１に格納されてもよい。
　本発明の一実施形態においては、図２（ａ）に示すように、照合用データが格納される列と価値の情報が格納される列とを有し、照合用データと価値の情報とを関連付けるテーブルを用意する。このテーブルは、関係データベースシステムなどの表データとしてデータベース部１０１によって管理される。なお、価値の情報を単に「価値情報」という場合がある。
　照合用データは、充分に長いビット長の乱数として生成されるデータである。「充分に長い」とは、発行される管理データの中で同じ照合用データを有するものが存在しない、あるいは、実質的に存在しないことを意味する。例えば、１２８ビット、５１２ビット、１０２４ビット、２０４８ビットなど設計上などの必要に応じて任意の長さを決めることができる。
　価値情報は、照合用データを含む管理データが表すことになる価値の内容などを示す。具体的な例としては、貨幣により表される価値を示す。この場合、価値の単位は、円、ドル、ユーロ、元などである。また、価値の情報は、貨幣と同等の価値を有する有価証券の証券番号、貴金属の量や保管の番号などであってもよい。
　発行要求受信部１０２は、管理データ発行要求１０８を受信する。管理データ発行要求１０８は、なんらかの価値が管理サーバやその運営者などに移転されたことあるいは移転されることを示す情報である。このため、管理データ発行要求１０８は、管理サーバ１００の運営者の支配する領域の内部で生成されたり、運営者と特別な関係（例えば親会社子会社の関係や特別な契約関係）にある者から送信されたりするのが好ましい。
　図２（ｂ）は、管理データ発行要求の具体的な例を示す。この例では、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）による表現がされている。管理データ発行要求はＸＭＬ以外にも種々の表現形式があるが、以下では、ＸＭＬを例にして説明を行う。図２（ｂ）では、＜価値＞と＜／価値＞とで囲まれている１０００円が、発行される管理データが表すべき価値となっている。発行要求受信部１０２が、このような管理データ発行要求を受信する際には、管理データ発行要求の送信者の認証を行い、受信した管理データ発行要求をメモリに展開して正しい構文であるかどうかの確認を行い、＜価値＞と＜／価値＞とで囲まれている部分を特定して、次に説明する生成部１０３に伝達する。伝達は、例えば、生成部１０３を実現するソフトウェアモジュールなどの関数の引数に＜価値＞と＜／価値＞とで囲まれている部分のメモリアドレスを価値の情報として引数に指定するなどしてその関数を呼び出すことで行われる。
　なお、管理データ発行要求には、照合用データと関連付けることができる他の情報が必要に応じて含まれていてもよい。
　生成部１０３は、照合用データを準備し、準備された照合用データと発行要求受信部１０２から伝達された価値の情報とを、データベース部１０１で管理される図２（ａ）のテーブルに行データとして挿入する。「照合用データを準備する」とは、乱数を生成してその乱数を照合用データとすること、又は、予め生成しておいた乱数のリストなどから乱数を選択して照合用データとすることをいう。挿入が完了すると、生成部１０３は、生成管理データ送信部１０４へ、照合用データを伝達する。なお価値の情報も伝達されてもよい。
　図２（ｃ）は、照合用データとして"１３５７１１"が準備されて、"１３５７１１"と１０００円とを図２（ａ）に示されるテーブルに挿入した直後の状態を示している。挿入が行われると、"１３５７１１"という照合用データが生成管理データ送信部１０４へ伝達される。
　生成管理データ送信部１０４は、生成部１０３から伝達された照合用データから管理データ１０９を生成して送信する。管理データ１０９の送信先は、管理データ発行要求１０８を送信した装置であることが主に想定される。もし、管理データ発行要求１０８に、管理データ１０９の送信先が、電子メールアドレスやＩＰアドレスなどによって指定されていれば、その送信先へ管理データ１０９が送信される。送信は暗号化されて行われてもよい。
　図２（ｄ）は、生成管理データ送信部１０４で生成され送信される管理データの一例を示す。生成部１０３から照合用データとして"１３５７１１"が伝達されたとすれば、"＜管理データ＞＜照合用データ＞１３５７１１＜／照合用データ＞＜／管理データ＞"という管理データが生成され、インターネットなどのネットワークなどに送信される。なお管理データには、照合用データ以外のデータが含まれていてもよい。例えば、照合用データがどれだけの価値、例えばいくらの貨幣価値、に関連付けられているかを示す情報が含まれていてもよい。例えば、管理データが"＜管理データ＞＜照合用データ＞１３５７１１＜／照合用データ＞＜価値＞１０００円＜／価値＞＜／管理データ＞"のように貨幣価値などを含むようになっていてもよい。また、照合用データと関連付けることができる他の情報が含まれていてもよい。また、譲渡回数が管理データに含まれる場合には、０などの初期値にリセットが行われて送信がされる。さらに、管理データが管理サーバ１００により生成されたことを検証できるようにするために、照合用データなどに対する管理サーバ１００による署名データが含まれていてもよい。
　なお、価値として、貨幣価値のように可分な価値が用いられる場合には、管理データが表す価値に上限を設けてもよい。例えば、一つの管理データは、５０００円までの貨幣価値を表すことにする。そして、５０００円以上の価値を表す管理データは、複数の管理データを組み合わせることによって表す。このように管理データが表す価値に上限を設けることにより、管理データを紛失したときに生じる損失が大きくならないようにすることができる。
　管理データが表す価値に上限を設ける場合には、管理データ発行要求がその上限を越える価値の管理データを発行することを表している場合には、上限以下の価値を表す管理データを複数発行する。このため、図２（ａ）などに示すテーブルに複数の行データが挿入される。
　図３は、データベース部１０１、発行要求受信部１０２、生成部１０３、生成管理データ送信部１０４による処理の流れを説明するフローチャートを例示する。このフローチャートが例示する処理は、ハードウェアを制御可能なソフトウェアによる情報処理として実行可能である。あるいは、上述したように専用の回路によるハードウェアのみの構成によってもこのフローチャートが例示する処理を実行することも可能である。また、ソフトウェアによる情報処理として実行可能性、専用の回路によるハードウェアのみの構成による実行可能性は、他の図面のフローチャート、シーケンス図により例示される処理について同様である。
　ステップＳ３０１の処理として、発行要求受信部１０２により管理データ発行要求を受信する。例えば、ハードウェアとしてのネットワークアダプタがデータを受信し割り込みが発生すると、割り込みハンドラが呼ばれて、データを読取り、読取りデータキューに入れる。そして、発行要求受信部１０２を実現するモジュールなどが発行していたＲＥＡＤシステムコールなどから処理が戻り、読取りデータキューに入れられたデータを管理データ発行要求としてメモリに展開する。
　ステップＳ３０２の処理として、発行要求受信部１０２は、メモリに展開された管理データ発行要求から価値の情報のアドレスを特定などすることにより、価値の情報を取得する。取得された価値の情報は生成部１０３へ伝達される。
　ステップＳ３０３の処理として、生成部１０３が照合用データを準備する。そしてステップＳ３０４の処理として、生成部１０３は、準備した照合用データと伝達された価値の情報を関連付けて行データとしてテーブルに挿入して格納する。なお、テーブルはハードディスク装置などの記憶装置により記憶することができる。データベース部１０１は、そのような記憶装置を用いて実現される。そして、準備された照合用データは生成管理データ送信部１０４へ伝達される。
　ステップＳ３０５の処理として、生成管理データ送信部１０４は、伝達された照合用データから管理データを生成する。そして、ステップＳ３０６の処理として、ＷＲＩＴＥシステムコールなどを発行することにより、生成された管理データを送信する。ＷＲＩＴＥシステムコールなどの発行により、管理データが送信データキューに格納され、ネットワークアダプタがデータを送信可能な状態になると、割り込みが発生し、割り込みハンドラにより、送信データキューのデータが読み出されて、ネットワークなどに送信される。
　このようにして送信された管理データは、専用のＩＣカードなどに限らず、通常のパーソナルコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ　Ｄｉｇｉｔａｌ　Ａｓｓｉｓｔａｎｔ）や携帯電話などのメモリに格納することができる。また、フレキシブルディスク、光ディスク、不揮発性の半導体メモリなどの着脱可能な一般的な記憶媒体に記録することができる。そして、その記憶媒体を譲渡することにより、その記憶媒体に格納されている管理データが表す価値の譲渡を行うことができる。ただし、二重の譲渡を防止するために以下に説明するようにして譲渡するのが望ましい。
　管理データ受信部１０５は、譲渡の対象などとなる管理データ１１０を受信する。受信された管理データ１１０は、管理サーバ１００のメモリに展開される。そして、管理データ１１０に署名データなどが含まれていれば、その署名データが正しいかどうかを判断してもよい。
　置換部１０６は、管理データ受信部１０５で受信された管理データから照合用データを取得し、まず、その照合用データがデータベース部１０１で管理されているテーブルに格納されているかどうかを判断する。例えば、図２（ｃ）に示されるテーブルの照合用データの列に格納されているかどうかを判断する。もし、その照合用データが格納されていなければ、管理データ１１０の送信者などに、無効な照合用データを含む管理データが送信された旨を返信などする。反対に、その照合用データがデータベース部１０１で管理されているテーブルに格納されていれば、有効な照合用データを含む管理データであると判断する。有効な照合用データを含めば、新たな照合用データを準備し、この照合用データにより、管理データ１１０に含まれる照合用データとデータベース部１０１で管理されているテーブルに格納されている照合用データを置き換える。これにより、価値の情報に新たな照合用データが関連付けされる。
　また、照合用データと関連付けられている他の情報があれば、その情報を用いてさらにチェックを行ってもよい。例えば、識別情報が照合用データと関連付けられていれば、管理データを管理データ受信部１０５に受信させた利用者や端末装置の識別情報を取得し、比較を行う。比較の結果がＯＫでなければ、無効である旨の返信などを行う。比較の結果がＯＫであれば、照合用データと関連付けられている識別情報と管理データに含まれている識別情報を、次に説明する置換管理データ送信部１０７による管理データの送信先となる利用者や端末装置の識別情報に書き換える。
　管理データに譲渡回数が含まれている場合には、譲渡回数を更新する。また、更新前の譲渡回数が初期値を示していれば、置き換え前の照合用データがデータベース部１０１で管理されているテーブルに格納されているかどうかに加えて、照合用データと関連付けられている他の情報を用いたチェックを行ってもよい。例えば、その管理データを発行した際に受信された管理データ発行要求が存在するかどうかを管理サーバのログによりチェックを行ったり、実際に銀行などから金銭の振り込みが実際に行われたかどうかを銀行などのサーバ装置に問い合せたりしてもよい。もちろん、このようなチェックや問い合わせの処理は、管理データが管理サーバ１００に受信されるたびに行ってもよい。しかし、一般には、このようなチェックや問い合せの処理には時間を要する。そこで、このようなチェックや問い合せの処理の実行は、更新前の譲渡回数が初期値を示していたり、所定の値以下であったり、所定の値以上である場合に行うことに限ることで、処理の時間を短縮することが可能となる。また、異なるサーバに格納されたデータと照合を行うことにより、管理データの不正な作出などを検出することができる。
　置換管理データ送信部１０７は、置換部１０６により、新たに準備された照合用データによりその照合用データが置換された管理データ１１１を送信する。管理データ１１１の送信は、管理データ１１０の送信元に対して行ってもよい。あるいは管理データ１１０の受信とともに送信先を示す情報が受信されたり、あるいは、管理データ１１０の中に送信先を示す情報が含まれていたりすれば、その送信先へ管理データ１１１を送信するようになっていてもよい。
　例えば、データベース部１０１で管理されているテーブルに、図４（ａ）に示すように、照合用データとして"１３１７１９２"が９９５円という価値の情報と関連付けられて格納されているとする。この状態で、管理データ１１０として、図４（ｂ）に示すような照合用データとして"１３１７１９２"を含む管理データ１１０が管理データ受信部１０５により受信されたとする。すると、管理データ１１０に含まれる照合用データ"１３１７１９２"は、図４（ａ）のテーブルに格納されているので、管理データ１１０は有効な照合用データを含む管理データであると判断される。そこで、置換部は、新たな照合用データとして、例えば"１４９１６２５"を準備する。そして、この照合用データにより、図４（ａ）に示すテーブルの照合用データ"１３１７１９２"と図４（ｂ）に示す管理データに含まれる照合用データ"１３１７１９２"とを置き換える。この結果、図４（ａ）に示すテーブルは図４（ｃ）に示すような、データを有するテーブルになり、図４（ｂ）に示す管理データ１１０は図４（ｄ）に示すようになる。この結果、図４（ｄ）に示す管理データが管理データ１１１として送信される。
　なお、照合用データを置き換える際に、照合用データに関連付けられている価値情報の表す金額などのうち一定の額や一定の割合を控除するようにしてもよい。このように控除を行うことにより、管理サーバの運営者が管理サーバの運営などのための費用を得ることが可能となる。
　なお、図４（ａ）に示すテーブルの照合用データの書き換えは、照合用データの列に格納されているデータに対する更新操作として実行してもよい。あるいは、書き換えの対象となる照合用データ（上の例での"１３１７１９２"）に関連付けられている価値の情報などを読出して一時的に記憶し、書き換えの対象となる照合用データを含む行を削除し、新たに準備された照合用データ（上の例での"１４９１６２５"）と一時的に記憶した価値の情報などを新たな行のデータとして格納されるようにテーブルに対するデータの挿入の操作として実行してもよい。また、更新操作として実行するのではなく、照合用データが削除されたことを示す列（削除フラグ）をテーブルに備えておき、書き換えの対象となる照合用データを格納する行の削除フラグの値を、その行が削除されたことを示す値に更新するとともに、準備された照合用データを含む行を新たにテーブルに挿入してもよい。また、テーブルに挿入される行には、書き換え前の照合用データが格納されていてもよい。これにより、不正などが発覚した場合に、書き換えの履歴をさかのぼることができる。
　また、管理データの照合用データの書き換えは、その文言通り、メモリに展開されている管理データの部分のうち照合用データの部分を書き換えて実行してもよい。あるいは、新たに準備された照合用データを含む管理データを新たに生成してもよい。
　図４（ｄ）に示す管理データが置換管理データ送信部１０７により送信された後、再度、図４（ｂ）に示す管理データが管理データ受信部１０５で受信されても、それに含まれる照合用データ１３１７１９２は、図４（ｃ）に示すテーブルに格納されていない（あるいは、削除フラグの列がテーブルに備わっている場合には、削除フラグの値が削除されたことを示す値になっている）。したがって、無効な照合用データを含む管理データと判断される。これにより管理データの二重使用を防止できる。
　図５は、データベース部１０１、管理データ受信部１０５、置換部１０６、置換管理データ送信部１０７における処理の流れを説明するフローチャートを例示する。このフローチャートが例示する処理は、ソフトウェアによる情報処理として実現可能である（他の図面のフローチャート、シーケンス図により例示される処理も同様である。）。あるいは、上述したように専用の回路によるハードウェアのみの構成によってもこのフローチャートが例示する処理を実行することも可能である（他の図面のフローチャート、シーケンス図により例示される処理も同様である。）。
　ステップＳ５０１の処理として、管理データ受信部１０５により、管理データ１１０が受信される。その後、管理データ１１０がメモリに展開などされる。そして、ステップＳ５０２の処理として、置換部１０６により、メモリに展開された管理データ１１０より照合用データが取得される。取得された照合用データが、ステップＳ５０３の処理において、価値の情報と関連付けてデータベース部１０１に格納されていることを確認する。もし、格納されていなければ、管理データ１１０に無効な照合用データが含まれている旨のエラーの返信などをする。
　ステップＳ５０４の処理として、新しい照合用データを準備する。例えば、乱数発生器により得られる乱数を新しい照合用データとする。そしてステップＳ５０５の処理として、管理データ１１０の照合用データを新しい照合用データに置き換える。「管理データ１１０の照合用データ」とは、メモリに展開された管理データ１１０に含まれる照合用データのみならず、ステップＳ５０３において価値のデータと関連付けて格納されている照合用データをも意味する。最後にステップＳ５０６の処理として、照合用データを書き換えられて得られる管理データ１１１を置換管理データ送信部１０７により送信する。
　このように、乱数として発生された照合用データに価値を関連付け、管理データが通過するたびにその照合用データを置き換えることにより、管理サーバから送信される管理データの照合用データの予測がつかないようにすることができる。この結果、異なる照合用データに同じ価値が関連付けられることを防止でき、また、管理データの二重使用等を防止することができる。
　（保管サーバ）
　上述した管理サーバを用いることにより、乱数として発生された照合用データを含む管理データが発行され、有効な照合用データを含む管理データを送信し返信される管理データを受信することにより照合用データが書き換えられる。これにより、管理データの二重使用を防止することができる。以下では、さらに管理データの譲渡等を、匿名性を保ちながら行うために管理サーバの機能を拡張するためなどに用いられる保管サーバについて説明を行う。
　図６は、管理サーバ６０１と、決済サーバ６０２と、保管サーバ６０３と、利用者端末６０４とからなるシステム６００の構成を示す。管理サーバ６０１と、決済サーバ６０２と、保管サーバ６０３と、利用者端末６０４とは、それぞれのサーバと端末の通信アダプタなどのハードウェアを用いて通信が可能となっている。システム６００においては、利用者端末６０４の利用者が、管理サーバ６０１で発行される管理データを得るために、利用者端末６０４と決済サーバ６０２との間で決済の処理を行う。例えば、決済サーバ６０２が銀行の振り込みを処理するサーバとなっており、利用者が管理サーバ６０１の運営者などの銀行口座に振り込みを行うことにより決済の処理が行われる。そして決済の処理が行われたことを示す結果が管理データ発行要求として決済サーバ６０２から管理サーバ６０１に送信されると、管理データが管理サーバ６０１に返信される。その後、管理データは決済サーバ６０３から保管サーバ６０３を経由して利用者端末６０４へ譲渡される。保管サーバ６０３は、管理データを決済サーバ６０２から受信すると、管理データの二重使用を防止するために、新たな照合用データに置き換えるために、管理サーバ６０１に管理データを送信し、照合用データが置き換えられた管理データを受信し保管する。その後、保管サーバ６０３は、利用者端末６０４から管理データの要求があれば、保管されている管理データを送信する。
　もちろん、保管サーバ６０３が決済サーバ６０２を認証などして信頼できるのであれば、保管サーバ６０３は決済サーバ６０２から受信した管理データを管理サーバ６０１に送信する必要はない。しかし、もし保管サーバ６０３に送信された管理データが決済サーバ６０２内に消去されずに残り、決済サーバ６０２が不正な侵入などされてしまうと、不正に決済サーバ６０２にアクセスを行った者が管理データを入手してしまう可能性があるので、保管サーバ６０３は決済サーバ６０２から受信した管理データを管理サーバ６０１に送信するのが好ましいと言える。
　図７は、システム６００における決済処理から管理データの利用者への譲渡までの処理の一例を説明するシーケンス図である。
　ステップＳ７０１の処理として、利用者端末６０４と決済サーバ６０２との間で、管理データの発行のための決済の処理が行われる。例えば、利用者端末６０４よりクレジットカード番号等と決済金額を提示して、決済サーバ６０２がクレジットカード番号等の正しさを確認等する。あるいは、利用者端末６０４より銀行口座への振り込みの申込を行い、決済サーバ６０２が振込先の銀行口座番号や振込人に付加する識別文字列などを返信する。その後、振込が行われたことについての確認を決済サーバ６０２側にて行う。なお、決済処理により、利用者端末６０４から決済サーバ６０２へ利用者や利用者端末６０４の識別情報が決済サーバに伝達されてもよい。この場合、識別情報は、後に決済サーバ６０２から管理サーバ６０１へ送信される管理データ発行要求の中に含まれる。
　本発明の一実施形態において、ステップＳ７０１の処理における決済処理を特定する番号などが決定され、この番号が決済サーバと利用者端末とで共有される。決済処理を特定する番号は、例えば、決済サーバが、生成する管理データを一意に識別する番号であったり、利用者端末６０４と決済サーバ６０２との間の通信のセッションを特定するセッションＩＤ（セッションを一意に特定するセッション識別情報）であったりしてもよい。この決済処理を特定する番号は、乱数として管理サーバが生成するのが好ましい。また番号の一部が乱数であってもよい。この場合、乱数以外の部分には利用者や利用者端末６０４を特定する番号などが含まれていてもよい。以下、決済処理を特定する番号として、セッションＩＤが用いられるとして説明を行う。ただし、本発明では、決済処理を特定する番号はセッションＩＤに限定されない。また、決済処理を特定する番号をＩＤ情報と称する場合がある。
　クレジットカード番号等の正しさや振込等の確認がされると、ステップＳ７０２の処理として、決済サーバ６０２から管理サーバ６０１へ管理データ発行要求が送信される。この管理データ発行要求の中に、決済された金額などの情報が含まれる。なお、「決済された金額」は、利用者端末６０４と決済サーバ６０２との間での決済金額から所定の手数料を差し引いた額であってもよい。
　管理データの発行要求に応じて、ステップＳ７０３の処理として、管理サーバ６０１から管理データ（「管理データ１」と呼ぶ）が決済サーバ６０２へ送信される。
　ステップＳ７０４の処理として、決済サーバ６０２は、受信した管理データ１と上述のセッションＩＤとを保管サーバ６０３に送信する。
　保管サーバ６０３が決済サーバより管理データ１とセッションＩＤを受信すると、ステップＳ７０５の処理として、受信した管理データを管理サーバ６０１へ送信し、管理データ１に有効な照合用データが含まれていることの確認と、その照合用データの置き換えを管理サーバ６０１に依頼する。
　なお、管理サーバ６０１は、保管サーバ６０３より照合用データの書き換えが依頼された場合、譲渡回数は増加させない構成になっており、また、照合用データと関連付けられている識別情報と管理データに含まれている識別情報を書き換えない構成となっているとよい。例えば、保管サーバ６０３のＩＰアドレスが管理サーバ６０１に登録されており、登録されているＩＰアドレスから管理データを受信した場合には、譲渡回数を増加させず、識別情報も書き換えない構成となっていてもよい。
　ステップＳ７０６の処理として、管理サーバ６０１にて、管理データ１に有効な照合用データが含まれていることを確認して照合用データを書き換えた管理データ２を生成し、保管サーバ６０３に返信される。そして、保管サーバ６０３にて、その管理データ２がセッションＩＤに関連付けて記憶される。
　管理データ２がセッションＩＤに関連付けて記憶されたことを通知するために、ステップＳ７０７の処理として、保管通知が保管サーバ６０３から決済サーバ６０２へ送信される。
　決済サーバ６０２が保管通知を受信すると、ステップＳ７０８の処理として、利用者端末６０４へ寄託通知が送信され、管理データが保管サーバ６０３に保管されたことが利用者に伝えられる。
　その後、利用者は、利用者端末６０４を操作して、保管サーバ６０３に保管された管理データを要求するために、ステップＳ７０９の処理として、保管サーバ６０３に対して、管理データの送信要求として、セッションＩＤを送信する。保管サーバ６０３では、セッションＩＤに管理データ２が関連付けて記憶されていることを確認すると、ステップＳ７１０の処理として、管理データ２を返信し、セッションＩＤとの関連付けを破棄する。
　もちろん、図６と図７とに示される構成、処理などを用いなくても、管理データを利用者に発行することができる。例えば、決済サーバが管理サーバから管理データを受信し、直接その管理データを利用者端末へ送信するようにしてもよい。しかし、決済手段として銀行振込を採用した場合などには、決済の確認までタイムラグが生じるので、決済サーバは管理サーバから受信した管理データを次に利用者端末と通信可能になるまで保持しておく必要がある。しかしこれでは、どの管理データが誰に発行されたかの情報を決済サーバが知ることとなり、匿名性が損なわれる。
　また、決済サーバが管理データの発行要求とともに管理データの送信先を管理サーバに送信し、管理サーバがその送信先に発行した管理データを送信する構成を採用することもできる。しかし、これでも、管理データが誰に発行されたかの情報を管理サーバが知ることとなり、やはり匿名性が損なわれる。
　図６と図７とに示される構成、処理では、管理サーバ６０１は、どの利用者の利用者端末に対して管理データを発行して送信するか知る必要がなくなる。また、決済サーバ６０２は利用者端末６０４と管理サーバ６０１から送信される管理データを関連付けることはできるが、それは一時的なものに過ぎない。管理データを保管サーバ６０３に送信すると、保管サーバ６０３側で照合用データが書き換えられてしまうからである。また、保管サーバ６０３は、管理データを決済サーバ６０２と利用者端末６０４との通信セッションにより決まる情報と関連付けるので、利用者を識別する必要がない。
　図８は、保管サーバ６０３の機能ブロック図を示す。図８の機能ブロック図において、保管サーバ８００は、預管理データ受信部８０１と、管理データ送信部８０２と、管理データ受信部８０３と、保管部８０４と、ＩＤ受信部８０５と、預管理データ送信部８０６とを有する。
　預管理データ受信部８０１は、管理データ８０７とＩＤ８０８とを受信する。管理データ８０７とＩＤ８０８とは、図７のステップＳ７０４においての説明での決済サーバから保管サーバへ送信される管理データ１とセッションＩＤとに相当する。ただし、後に説明されるように、預管理データ受信部８０１は、管理データ８０７とＩＤ８０８を決済サーバのみより受信するとは限らない。
　ＩＤ８０８は、管理データ８０７を一意に特定する情報であることが望ましい。このため、預管理データ受信部８０１は、受信したＩＤの履歴を管理し、過去に受信したＩＤと一致するものを受信した場合には、ＩＤの再送要求を返信してもよい。また、受信したＩＤの履歴は、後に説明される保管部８０４が管理するテーブルなどで管理することもできる。すなわち、保管部８０４が管理するテーブルに同じＩＤが格納されていればＩＤの再送要求を返信してもよい。
　預管理データ受信部８０１は、受信した管理データ８０７とＩＤ８０８とをメモリに展開する。そして、管理データ８０７のメモリアドレスなどを管理データ送信部８０２へ渡すことにより管理データ８０７を伝達し、ＩＤ８０８のメモリアドレスを保管部８０４へ渡すことによりＩＤ８０８を伝達する。
　管理データ送信部８０２は、預管理データ受信部８０１より伝達された管理データ８０７を送信する。送信先は、管理サーバである。送信の結果、管理サーバにて管理データ８０７に含まれる照合用データの有効性が確認されると、照合用データの書き換えが行われ、書き換え後の管理データ８０９が返信される。
　管理データ受信部８０３は、管理データ送信部８０２からの管理データ８０７の送信に応じて管理サーバより返信される管理データ８０９を受信する。上述したように管理データ８０７の少なくとも照合用データが置き換えられたものが管理データ８０９となっている。管理データ受信部８０３は、受信した管理データ８０９をメモリに展開し、そのメモリアドレスなどを保管部８０４に渡すことにより、管理データ８０９を伝達する。
　保管部８０４は、預管理データ受信部８０１より伝達されたＩＤ８０８と管理データ受信部８０３より伝達された管理データ８０９とを関連付けて保持する。ＩＤ８０８と管理データ８０９とは、異なる時に保管部８０４に伝達される。このために、保管サーバ８００は、例えば預管理データ受信部８０１が受信した管理データ８０７とＩＤ８０８とに一意の識別情報を付与するようにしてもよい。そして、預管理データ受信部はＩＤ８０８とともにその一意の識別情報を保管部８０４に伝達する。また、管理データ送信部８０２が管理データ８０７を送信するために管理サーバと通信セッションを開始するとその通信セッションをその一意の識別情報と関連付ける。そして、管理データ８０９が受信されると、通信セッションから一意の識別情報を取得し、管理データ受信部８０３は、管理データ８０９とともにその一意の識別情報を保管部８０４に伝達する。これにより、保管部８０４では、ＩＤ８０８と管理データ８０９とを関連付けることができる。また、保管サーバ８００が付与した一意の識別情報が管理データ８０７に含まれて送信されるようになっていてもよい。管理サーバは、その一意の識別情報を変更することなく、照合用データを書き換える。
　保管部８０４は、ＩＤと管理データとを関連付けて保管するためにテーブルを用いてもよい。図９はそのようなテーブルを示している。図９では、"ｅ９８７ａｂｃ"というＩＤと照合用データとして"１４９１６２５"を含む管理データとが関連付けて保持されている。"ｅ９８７ａｂｃ"というＩＤは、例えば図７におけるステップＳ７０１の処理として行われる決済処理のための利用者端末と決済サーバと間の通信セッションのＩＤなどである。
　なお、保管部８０４にＩＤ８０８と管理データ８０９とが関連付けて格納された場合、ステップＳ７０７の保管通知となる情報が送信されるようになっていてもよい。この保管通知は、例えば、預管理データ受信部８０１が管理データ８０７とＩＤ８０８とを受信したＡＣＫとして返信されるようになっていてもよい。
　ＩＤ受信部８０５は、ＩＤ８１０を受信し、ＩＤ８１０と保管部８０４にて関連づけて保管されている管理データの検索を行う。検索の結果、ＩＤ８１０と関連付けて保管されている管理データが存在すれば、ＩＤ受信部８０５はその管理データを読出し、預管理データ送信部８０６へ伝達する。また、ＩＤ８１０とその管理データとの関連付けを解消あるいは破棄する。解消あるいは破棄は、具体的には、図９に示すテーブルからＩＤ８１０が格納されている行データを削除することにより実現される。あるいは、図９に示すテーブルに削除フラグを格納する列を設けて、削除されたことを示す値を格納することで、解消あるいは破棄されたことを表現するようになっていてもよい。
　預管理データ送信部８０６は、ＩＤ受信部８０５から伝達された管理データを送信する。管理データの送信先は、ＩＤ８１０の送信元であることが想定される。ただし、管理データの送信先がＩＤ８１０とともにＩＤ受信部８０５により受信されたなどの場合には、その送信先へ管理データを送信するようになっていてもよい。
　図１０は、保管サーバ８００における管理データとＩＤとを受信し保管するまでの処理の流れを説明するフローチャートの一例である。ステップＳ１００１の処理として、預管理データ受信部８０１により、管理データとＩＤとを受信する。ステップＳ１００２の処理として、その管理データを、管理データ送信部８０２により、管理サーバへ送信する。そしてステップＳ１００３の処理として、管理データ受信部８０３により、管理データを受信する。その後、ステップＳ１００４の処理として、保管部８０４により、ステップＳ１００１で受信されたＩＤとステップＳ１００３で受信された管理データを関連付けて保管する。
　図１１は、保管サーバ８００におけるＩＤを受信しそのＩＤと関連付けられて保管されている管理データを送信するまでの処理の流れを説明するフローチャートの一例である。ステップＳ１１０１の処理として、ＩＤ受信部８０５により、ＩＤを受信する。ステップＳ１１０２の処理として、そのＩＤと関連付けられて管理データが保管部８０４に保管されていることを確認する。もし確認できなければ、エラーをＩＤの送信元などに返信する。確認ができれば、ステップＳ１１０３の処理として、ＩＤと関連づけて保管されている管理データを読み出す。そして、ステップＳ１１０４の処理として、ＩＤと管理データとが関連付けられて格納されている状態を解消する。例えば、図９に示されるテーブルから上述にように行データを削除する。その後ステップＳ１１０５の処理として、預管理データ送信部８０６により、管理データを送信する。
　このような構成の保管サーバを、図６、図７に示すように決済サーバと管理サーバとを組み合わせることにより、匿名性を保ちつつ管理データの発行が行える。
　また、このような保管サーバを経由することにより、利用者間でも管理データを譲渡することができる。「利用者間」と記載したが、この場合、一方の利用者は物やサービスを購入する者であり、他方はその物やサービスを提供する者であり、その物やサービスの対価として管理データが一方の者から他方の者へ譲渡される場合が想定される。特に、他方はＷＥＢサーバなどを用いてインターネットからアクセスされる仮想的な店舗であってもよい。すなわち、管理データを電子マネーとして使用することにより、財物や役務の提供に対する代金の決済処理を行うことができる。すなわち、保管サーバが決済処理を行うサーバとして動作することになる。また、保管サーバを用いることにより、個人間などの一般の利用者間でも管理データの譲渡をすることが可能となる。
　図１２は、利用者間で管理データを譲渡するシステム１２００の構成を示す。システム１２００を参照しながら、管理サーバ１２０１と、保管サーバ１２０３と、譲渡者端末１２０４と、譲受者端末１２０５とを有する。譲渡者端末１２０４の利用者（譲渡人）が譲受者端末１２０５の利用者（譲受人）へ管理データを譲渡する場合の処理の流れについて以下に説明する。
　譲渡人は、あらかじめ、管理サーバから管理データの発行を受けたり、決済サーバを介して管理データを取得したり、決済サーバと保管サーバを介して管理データから取得したりしておく。あるいは別の譲渡人より、管理データの譲渡を受ける。この場合の譲渡としては、これから説明されるように保管サーバを介して行われてもよいし、別の譲渡人から管理データが記録された光ディスクや可搬型の不揮発性半導体メモリなどの記憶媒体の譲渡を受けたり、電子メールの添付データなどとして譲渡を受けたりしていてもよい。
　図１３は、保管サーバを介しての管理データの譲渡の流れを説明するシーケンス図である。ステップ１３０１の処理として、譲渡者端末１２０４と譲受者端末１２０５との間で管理データの譲渡の合意をする。この合意は、無償にて譲渡人が譲受人に管理データを譲渡する合意であったり、上述のように譲受人が物やサービスを提供することの引き替えに譲渡人が管理データを譲渡する合意であったりする。なお、この合意のために、譲渡人の使用する譲渡者端末（第１の端末）と譲受人の使用する譲受者端末（第２の端末）とが相互に認証し合ってもよい。例えば、暗号化された通信セッションを確立するために第１の端末と第２の端末との間で暗号化と復号化のための暗号鍵を共有する。
　また、相互認証の際には、その相互認証を一意に特定する情報を決める。例えば、ＷＥＢショップで買い物などを行う場合には、ＷＥＢサーバと端末との間の暗号化された通信セッションのＩＤなどを用いる。
　譲渡の合意あるいは相互認証が終了すると、譲渡人側の端末は新たに管理データの発行を受けたり、既に発行がされたり第三者から譲渡がされたりした管理データの中から選択を行い、管理データ３とセッションＩＤとを保管サーバ１２０３へ送信する。管理データ３とセッションＩＤとを受信した保管サーバは、ステップＳ１３０３の処理として管理データ３を管理サーバへ送信する。管理サーバが管理データ３に含まれる照合用データが有効であると確認を行うと、新たに準備した照合用データによる置換を行い、ステップＳ１３０４の処理として管理データ４を保管サーバへ返信する。これにより、管理データ３は無効な照合用データを含む管理データとなり二重に使用ができなくなる。
　保管サーバが管理データ４を受信すると、ステップＳ１３０２で受信したセッションＩＤと関連付けて保管を行い、ステップＳ１３０５の処理として保管通知を譲渡者端末へ送信する。保管通知を受信した譲渡者端末は、ステップＳ１３０６の処理として、寄託通知を譲渡者端末へ送信する。
　寄託通知を受信した譲受者端末は、ステップ１３０７の処理として、管理データの送信要求を譲渡合意の際のセッションＩＤとともに保管サーバへ送信し、これに応じて保管サーバは管理データ４をステップＳ１３０８の処理として返信する。
　以上のように保管サーバを構成することにより、管理データの発行の際、そして、管理データの譲渡の際に同じ処理を保管サーバで行うようにすることができる。また、管理データの匿名性なども確保できる。
　（実施形態２）
　上述の実施形態１において、価値として貨幣価値のように可分な価値が用いられる場合には、管理データが表す価値に上限を設けてもよいことについて説明した。例えば、５０００円を上限とすると、１３０００円の価値は、例えば、５０００円を表す管理データ２つと、３０００円を表す管理データ１つとにより表される。この場合の３０００円を表す管理データのように、上限の価値に満たない価値を表す管理データを「端数管理データ」と呼ぶことにする。
　管理データを用いて商品や役務の代金の決済が行われる場合を考えると、代金の額が上記でいう上限になるとは限らない。このため、端数管理データを含む管理データにより代金が支払われたり、釣り銭の代わりに端数管理データを含む管理データが支払いとは逆の方向の管理データの流れで譲渡されたりする。このため、端数管理データの数は増加することになる。この結果、管理サーバのデータベース部の管理するデータが増加してしまうなどの問題が生ずる。そこで、以下では、端数管理データの増加を防ぐ構成について説明を行う。
　（管理サーバ）
　本実施形態に係る管理サーバは、実施形態１に係る管理サーバ１００において、管理データ受信部１０５が端数管理データ受信手段と、支払額受信手段とを有し、置換部１０６が端数変更手段と、釣管理データ生成手段とを有し、置換管理データ送信部１０７が端数管理データ送信手段と、釣管理データ送信手段とを有する。
　端数管理データ受信手段は、端数管理データを受信する手段である。受信された端数管理データは、他の一または複数の管理データとともに、保管サーバより送信され管理サーバに受信され照合用データの有効性の確認がされることが主に想定される。端数管理データ受信手段は、端数管理データを受信するとメモリに展開し、端数管理データに含まれる照合用データのアドレスなどを取得して、端数変更手段に伝達する。
　支払額受信手段は、管理データ受信部１０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データの表す価値のうち、譲渡が行われる価値を表す。すなわち、保管サーバを経由して譲渡者端末から譲受者端末へ譲渡されるべき価値を表すことが主に想定される。そして、譲渡が行われない価値が存在すれば、その価値は後述のように釣管理データとして譲渡者端末へ送信されることになる。
　端数変更手段は、支払額受信手段が受信した価値を上述の上限の価値で除算を行った時の余りが０で無い場合に、端数管理データ受信手段により受信された端数管理データの表す価値にその余りを加算する処理を行う。例えば、上限額が５０００円で支払額受信手段が受信した価値が１３０００円であれば、１３０００円を５０００円で割り算を行うと、３０００円が余りとなる。そこで、端数管理データ受信手段が受信した端数管理データがデータベース部１０１により、１０００円を表していれば、１０００円に３０００円を加算した４０００円を表すようにデータベース部１０１が管理するデータベースの変更操作などを行う。
　具体的には、端数変更手段は、端数管理データ受信手段からで伝達されたアドレス等により指定される照合用データで図２（ａ）などに示されるテーブルの検索を行いその照合用データがテーブルに格納されているのを確認すると、その照合用データに関連付けられている価値の値に上述の余りを加算する。加算した結果がもし上述の上限を超えていれば、加算した結果のかわりに上限の価値をテーブルに登録し、新たに照合用データを準備してテーブルに挿入し、加算した結果から上述の上限を引いた額を関連付ける。例えば、端数管理データ受信手段からで伝達されたアドレス等により指定される照合用データに１０００円が関連付けられており、上述の余りが４５００円であったとする。すると加算した結果は５５００円となり、上限の５０００円を超えている。そこで、端数管理データ受信手段からで伝達されたアドレス等により指定される照合用データには上限の５０００円を関連づけ、新たに準備される照合用データには５００円を関連付ける。もちろん、５０００円と５００円とに関連付けるのは一例であり、５５００円の上限を超えないように複数の価値に任意に分けることができる。例えば、２５００円と３０００円とであってもよい。
　釣管理データ生成手段は、管理データ受信部１０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データの表す価値のうち、支払額受信手段が受信した価値を引いた価値（「釣価値」という。）が０でなければ、釣価値を表す管理データを生成する。新たに管理データを生成してもよいし、管理データ受信部１０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データを再利用するように、その管理データが表す価値に釣価値を加えてもよい。そして、もし加えた結果が上限を超えていれば、新たな管理データを生成して、管理データに上限を超える価値が関連付けられないようにする。
　端数変更手段、釣管理データ生成手段それぞれは、端数管理データ受信手段が受信した端数管理データが含む照合用データ、釣管理データ生成手段が生成した釣価値を表す管理データが含む照合用データのそれぞれを、新たな照合用データを準備して書き換えてもよい。
　端数管理データ送信手段は、端数変更手段により価値が加算された管理データ、また必要に応じて新たに生成された管理データを送信する。
　釣管理データ送信手段は、釣管理データ生成手段で生成された管理データを送信する。
　また、本実施形態において、保管サーバの預管理データ受信部８０１は、管理データ及びＩＤとともに、支払額情報を受信可能となっている。支払額情報とは、管理データの譲渡により譲渡されるべき価値を示す情報である。そして、預管理データ受信部８０１は、支払額情報が受信された場合には、受信したＩＤに関連付けられて保管部８０４に保管されている管理データを検索し、得られた管理データと受信した管理データとともに支払額情報を管理データ送信部８０２に伝達する。この場合、受信したＩＤに関連付けられて保管部８０４に保管されている管理データは、譲受者端末より送信された端数管理データとなっている。管理データ送信部８０２は、管理データとともに伝達された支払額情報を送信する。
　また、管理データ受信部８０３は、釣管理データも受信可能となっている。釣管理データが受信された場合には、保管サーバは、保管部８０４に管理データが保管されると、保管通知とともに釣管理データを、預管理データ受信部８０１が受信した管理データの送信元へ返信する。
　図１４は、本実施形態において、保管サーバを介しての管理データの譲渡の流れの一例を説明するシーケンス図である。ステップＳ１４０１の処理として、ステップＳ１３０１と同様に譲渡の合意を譲渡者端末と譲受者端末との間で行う。このとき、その合意では、単に管理データの譲渡のみならず、管理データの譲渡により譲渡される価値も合意する。例えば、商品の値段、送料などである。そして、このような場合に譲渡者端末が保管サーバへ送信する管理データを支払管理データという。
　ステップＳ１４０２の処理として、譲受者端末から保管サーバへ、端数管理データ１とセッションＩＤとを保管サーバへ送信する。このとき、譲受者端末である旨の情報も送信してもよい。ステップＳ１４０３の処理として、保管サーバは、受信した端数管理データ１を管理サーバへ送信し、その有効性を確認させ、ステップＳ１４０４の処理として、保管サーバは、端数管理データ２を管理サーバより受信する。そして、セッションＩＤと関連づけて端数管理データ２を保管する。
　なお、譲受者端末に端数管理データが無ければ、保管サーバには端数管理データを送信する必要はなく、したがって、保管サーバが端数管理データを管理サーバに送信する必要もない。
　譲渡者端末は、ステップＳ１４０５の処理として、支払額と支払いのための支払管理データ１とセッションＩＤを保管サーバに送信する。保管サーバは、支払管理データ１と支払額とを管理サーバに送信する。また、保管サーバは、セッションＩＤからそれに関連付けられている端数管理データの有無を検出し、もしそのような端数管理データが存在すれば、その端数管理データもともに管理サーバへ送信する。なお、ステップＳ１４０２において、譲受者端末から譲受額が送信されてもよく、この場合は、譲渡者端末から送信される支払額と譲受額とが同じであることを確認してもよい。もし、同じでなければ譲受者端末、譲渡者端末へエラーを通知する。また、ステップＳ１４０２において、譲受者端末から譲受額が送信され、ステップＳ１４０５において、譲渡者端末から支払額が送信されない構成もある。この場合には、支払管理データ１に関連付けられている価値の値が譲受額以上であることを確認する。もし、譲渡に伴って手数料などを徴収する際には、支払管理データ１に関連付けられている価値の値から手数料などの額の値を引いたものが譲受額以上であることを確認する。また、端数管理データ１に関連付けられている価値から手数料などの額を徴収することにしてもよい。
　管理サーバは、受信した支払管理データ２、支払額、端数管理データ１から、置換部１０６、置換管理データ送信部１０７により、端数管理データ３と支払管理データ２と釣管理データとを生成して、ステップＳ１４０７の処理として、保管サーバへ送信する。ここで、端数管理データ３は、端数変更手段で変更、生成された管理データであり、釣管理データは釣管理データ生成手段で生成された管理データである。
　端数管理データ３と支払管理データ２と釣管理データとを受信した保管サーバは、支払管理データ３と端数管理データをステップＳ１４０２又はＳ１４０５で受信したセッションＩＤと関連づけて保管する。そして、ステップＳ１４０８の処理として、譲渡者端末へ釣管理データと保管通知を送信する。譲渡者端末は、ステップＳ１４０９において寄託通知を譲受者端末へ送信し、譲受者端末はステップＳ１４１０において、送信要求とセッションＩＤとを保管サーバへ送信し、これに応じて保管サーバは、セッションＩＤと関連付けて保管されている端数管理データ３と支払管理データ２をステップＳ１４１１の処理として、譲受者端末へ送信する。そして、セッションＩＤと端数管理データ３及び支払管理データ２との関連付けを破棄する。
　このようにして、譲渡者端末から譲受者端末へ、譲渡合意で合意された価値が電子的に譲渡される。また、本実施形態では、管理データが表す価値に上限を設けられている場合に、譲受者端末から端数管理データを提供することにより、その端数管理データに釣り銭に相当する価値を加えることができ、端数管理データの数の増大を防止することができる。これにより、管理サーバのデータベース部１０１で管理するべき照合用データの数の増加を防止することができる。なお、「譲受者端末」と記載したが、譲受者端末は端末装置と同等の機能を有していればよく、サーバ装置を端末装置として用いられる場合も含まれる。譲渡者端末についても同様である。
　（実施形態３）
　本発明の実施形態３として、管理データを紛失しても回復が可能な構成について説明する。
　図１５（ａ）は、本実施形態において管理サーバのデータベース部１０１にて管理するべきテーブルの一例を示す。本実施形態では、実施形態１または２のように照合用データと価値データとを関連付けるテーブルの他に、照合用データと所有者ＩＤ（所有者識別情報）とを関連づけるテーブルがデータベース部１０１にて管理される。所有者ＩＤとは、管理データを所有している者を識別するＩＤである。管理データを所有しているとは、管理データが表す価値が帰属する権原を有している者をいう。
　所有者ＩＤとしては、例えば、管理サーバなどで発行されたＩＤ、電子メールアドレス、住民票コード、公開鍵証明書など人を識別できる情報を用いることができる。そして、管理サーバは、所有者ＩＤにパスワードなどを関連付けて保持するなどして、管理サーバなどに所有者ＩＤを提示してアクセスしてきた者を認証できるようにしておくのが好ましい。なお、所有者ＩＤをそのまま図１５（ａ）に示すテーブルに格納する必要はなく、所有者ＩＤのハッシュ値を算出し、そのハッシュ値を格納してもよい。
　図１５（ｂ）は、本実施形態での管理データ発行要求を例示している。実施形態１又は２における管理データ発行要求と比較すると、本実施形態では、所有者ＩＤを示すタグを用いた＜所有者ＩＤ＞ＭＥＫＡＪＩＫＡ＜／所有者ＩＤ＞が追加されている。これは、発行される管理データの所有者が"ＭＥＫＡＪＩＫＡ"というＩＤ（識別情報）で識別されるべきことを表している。この"ＭＥＫＡＪＩＫＡ"は、例えば、決済サーバを識別するＩＤであったり、決済サーバと決済を行った利用者端末を識別したり、その利用者を識別するＩＤであったりする。
　図１５（ｂ）のような管理データ発行要求を受信した管理サーバは、実施形態１又は２のように管理データを発行するとともに、発行された管理データに含まれる照合用データと管理データ発行要求で示される所有者ＩＤと、を照合用データと所有者ＩＤとを関連づけるテーブルに挿入する。なお、もし受信した管理データ発行要求に所有者ＩＤが含まれていなければ、照合用データと所有者ＩＤとを関連づけるテーブルに挿入などの操作を行う必要はない。
　図１５（ｃ）は、照合用データとして"３５１１１３"を含む管理データが、図１５（ｂ）に示す管理データ発行要求に応じて生成された場合のテーブルを示す。照合用データと所有者ＩＤとを関連づけるテーブルには、"３５１１１３"と"ＭＥＫＡＪＩＫＡ"とが関連付けて格納されている。
　図１５（ｄ）は、本実施形態における管理データの一例を示す。管理データは、照合用データを含む。また、所有者ＩＤを含んでいる。ただし、管理データに所有者ＩＤが含まれていることは必須ではないが、管理データを譲渡する場合に、譲渡人が管理データとともに譲受人の所有者ＩＤを管理サーバや保管サーバへ送信することにより、管理サーバや保管サーバにて管理データに含まれる所有者ＩＤを変更する。あるいは、譲渡人が譲受人の所有者ＩＤを、＜所有者ＩＤ＞と＜／所有者ＩＤ＞とにより囲まれた状態でその管理データに含ませて管理サーバや保管サーバへ送信することにより、管理サーバのデータベース部１０１が管理する照合用データと所有者ＩＤとを関連づけるテーブルの更新を行うことができる。
　すなわち、管理データ受信部１０５が所有者ＩＤを含む管理データを受信した場合、置換部は、その管理データに含まれる照合用データに関連付けられている所有者ＩＤを、その管理データに含まれる所有者ＩＤに置き換えるなどして、その管理データに含まれる照合用データにその管理データに含まれる所有者ＩＤを関連づける。また、管理データ受信部１０５が受信した管理データに所有者ＩＤが含まれていなければ、その管理データに含まれる照合用データと所有者ＩＤとの関連付けを解消するようになっていてもよい。この操作を「照合用データと所有者ＩＤとの関連付けの変更操作」ということにする。また、この「照合用データと所有者ＩＤとの関連付けの変更操作」を行う部を所有者変更部という。所有者変更部は、例えば、置換部の内部モジュールとして実現されてもよい。
　所有者変更部による変更操作は、新たな照合用データを準備し、受信した管理データに含まれる照合用データでありデータベース部に格納されている照合用データを、準備された照合用データに置換するとともに、受信した管理データに含まれる照合用データを準備された照合用データに置換してから、実行されるようになっていてもよい。
　図１６は、本実施形態に係る管理サーバの機能ブロック図を例示する。管理サーバ１６００は、実施形態１又は２におけるように、データベース部１０１と、発行要求受信部１０２と、生成部１０３と、生成管理データ送信部１０４と、管理データ受信部１０５と、置換部１０６と、置換管理データ送信部１０７とを有し、さらに、所有者ＩＤ取得部１６０１と、照合用データ検索部１６０２と、検索データ送信部１６０３とを有している。また、実施形態１又は２における管理サーバがさらに認証用管理データ取得部１６０４と、所有者ＩＤ検索部１６０５と、所有者ＩＤ送信部１６０６とを有していてもよい。また、管理サーバ１６００は図１６に示すように、所有者ＩＤ取得部１６０１と、照合用データ検索部１６０２と、検索データ送信部１６０３と、認証用管理データ取得部１６０４と、所有者ＩＤ検索部１６０５と、所有者ＩＤ送信部１６０６とを有していてもよい。
　所有者ＩＤ取得部１６０１は、所有者ＩＤ１６０７を取得する。例えば、利用者端末から送信された所有者ＩＤ１６０７をネットワークなどに接続されたネットワークアダプタを介して受信することにより取得する。そして、所有者ＩＤ１６０７を取得させた者の認証を行うのが好ましい。この認証としては、所有者ＩＤに関連付けられているパスワードが一致するかどうか、乱数などを生成し所有者ＩＤに関連づけられている公開鍵で暗号化して返信し、復号化の結果を受信して生成した乱数などに一致するかどうかなどで判断する。もし、認証できなければ、エラーを返信して処理を中止する。
　照合用データ検索部１６０２は、所有者ＩＤ取得部１６０１が取得した所有者ＩＤにより、照合用データと所有者ＩＤとを関連付けるテーブルを検索し、その所有者ＩＤに関連付けられている照合用データを取得する。
　検索管理データ送信部１６０３は、照合用データ検索部１６０２により取得された照合用データから管理データを生成して送信する。所有者ＩＤ取得部１６０１での認証ができなかったことによる処理の中止により、検索管理データ送信部１６０３が管理データを送信しなくなるようになっていてもよい。
　図１７は、所有者ＩＤ取得部１６０１と、照合用データ検索部１６０２と、検索データ送信部１６０３による管理サーバ１６００の処理の流れを説明するフローチャートである。ステップＳ１７０１の処理として、所有者ＩＤ取得部１６０１により、所有者ＩＤを受信などにより取得する。ステップＳ１７０２の処理として、照合用データ検索部１６０２により、所有者ＩＤに関連付けられている照合用データを検索する。そして、検索データ送信部１６０３により、ステップＳ１７０３の処理として、検索された照合用データにより管理データを生成し、ステップＳ１７０４の処理として、管理データを送信する。
　このように、管理サーバ１６００が所有者ＩＤ取得部１６０１と、照合用データ検索部１６０２と、検索データ送信部１６０３とを有することにより、所有者ＩＤを管理サーバ１６００に提示することで、その所有者ＩＤが所有している管理データを復元することができる。すなわち、管理データを紛失したとしても、所有者ＩＤにより管理データを復元することができる。
　また、認証用管理データ取得部１６０４は、管理データ１６０９を取得する。ネットワークなどに接続されたネットワークアダプタなどを介した受信などにより取得を行う。
　所有者ＩＤ検索部１６０５は、認証用データ取得部１６０４が取得した管理データ１６０９に含まれる照合用データを取得し、この照合用データにより、照合用データと所有者ＩＤとを関連付けるテーブルを検索し、所有者ＩＤを取得する。
　所有者ＩＤ送信部１６０６は、所有者ＩＤ検索部１６０５により取得されたＩＤを送信する。なお、異なる複数の所有者ＩＤが所有者ＩＤ検索部１６０５により取得される場合が考えられる。例えば、また、複数の管理データが認証用管理データ取得部１６０４で取得された場合に異なる複数の所有者ＩＤが取得される可能性がある。この場合には、所有者ＩＤ検索部１６０５により取得された中で最も多く出現する所有者ＩＤのみを送信するようになっていてもよい。また、所有者ＩＤ送信部１６０６は、所有者ＩＤごとにパスワードなどにより送信先の端末装置や送信先の端末装置を利用する利用者の認証を行い、認証が成功した所有者ＩＤを送信するようにしてもよい。
　図１８は、認証用管理データ取得部１６０４と、所有者ＩＤ検索部１６０５と、所有者ＩＤ送信部１６０６による管理サーバ１６００の処理の流れを説明するフローチャートである。ステップＳ１８０１の処理として、認証用管理データ取得部１６０４により、管理データを受信する。そして、所有者ＩＤ検索部１６０５により、ステップＳ１８０２の処理として、受信された管理データより照合用データを取得し、照合用データと関連付けられている所有者ＩＤを検索する。ステップＳ１８０４の処理として、検索により得られた所有者ＩＤを送信する。
　このように管理サーバ１６００が認証用管理データ取得部１６０４と、所有者ＩＤ検索部１６０５と、所有者ＩＤ送信部１６０６とを有することにより、所有者ＩＤを失念してしまった場合であっても、手許に存在する管理データを管理サーバ１６００に提示することにより、所有者ＩＤを得ることができる。すなわち、管理データが一種の認証のデータとして用いられて、認証が行われると考えることができる。また、所有者ＩＤを管理サーバに提示することにより、他の管理データを得ることもできる。
　（実施形態４）
　上記の実施形態２のように管理データの表す価値に上限が定められている場合の実施形態３の変形例として、次のものがある。すなわち、譲受者端末が業として商品又は役務を提供しその提供の対価として管理データの譲受けを受ける場合などにおいて、そのような譲受者端末が管理データを保持するかわりに、保管サーバに保持させるようになっていてもよい。この場合、保管サーバが譲受者端末のかわりに保持する管理データの所有者ＩＤを、保管サーバに登録しておく。そして、保管サーバは、その所有者ＩＤの管理データを、価値の上限を表す管理データと端数管理データとに分けて保持しておく。例えば、異なるテーブルに保持しておく。
　このように、本来は譲受者端末で保持するべき管理データを保管サーバで保持することにより、図１４のシーケンス図のステップＳ１４０２、ステップＳ１４０３、Ｓ１４０４、Ｓ１４１０、Ｓ１４１１の処理の実行を省略することが可能となり、ステップＳ１４０６において端数管理データ２は、保管サーバが譲受人のために保管している端数管理データを用いることになる。
　以上のような構成により、例えば、価値の上限を表す管理データを譲受人の公開鍵により暗号化して保持する場合に新たな効果が発生する。すなわち、保管サーバが管理データを保管している際に外部からの不正侵入がされても、不正侵入者による管理データの不正な取得は、端数管理データに限定され、被害を小さくすることが可能となる。
　また、保管サーバは、譲受人の識別情報を格納し、ステップＳ１４０７において受信される端数管理データ３と支払管理データ２に含まれる識別情報が、譲受人の識別情報となるようにしてもよい。これにより、保管データが不正にアクセスされ、端数管理データや支払管理データが不正に使用されることを防止できる。
　保管サーバに保管された管理データは、ＦＴＰ（Ｆｉｌｅ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）などを用いて譲受人が保管サーバの認証を受けてログインなどを行い、その端末装置にダウンロードするようになっていてもよい。これにより、譲受人は、ダウンロードした管理データを用いて支払などに充てることができる。
　（実施形態５）
　実施形態１において、図６、図７などを参照して、管理サーバ、決済サーバ、保管サーバ及び利用者端末からなるシステムの構成などについて説明した。本発明の実施形態５として、別のシステムの構成などについて説明する。
　図１９は、本発明の実施形態５に係るシステム１９００の構成を示す。システム１９００は、管理サーバ１９０１と、決済サーバ１９０２と、保管サーバ１９０３と、利用者端末１９０４とを有する。実施形態１と同様に、管理サーバ１９０１と、決済サーバ１９０２と、保管サーバ１９０３と、利用者端末１９０４とは、それぞれ通信アダプタなどのハードウェアを備え、通信を行う。実施形態１では、利用者端末６０４の利用者は、管理サーバ６０１と直接通信を行う必要は無かったが、本実施形態では、様々な決済サーバの構成に対応できるように、利用者端末１９４０の利用者は、管理サーバ１９０１とも通信を行う構成となっている。
　本実施形態では、管理サーバ１９０１と、決済サーバ１９０２と、保管サーバ１９０３と、利用者端末１９０４とは、基本的に実施形態１における管理サーバ６０１と、決済サーバ６０２と、保管サーバ６０３と、利用者端末６０４と同じ構成でよい。ただし、本実施形態では、管理サーバ１９０１と利用者端末１９０４とが通信を行うので、この点を実現する構成が異なる。すなわち、管理サーバ１９０１は、利用者端末１９０４に対してサービスを提供するための部が備わった構成となっている。例えば、管理サーバ６０１に、ウェブサーバとして動作する部が備わっており、端末装置１９０４に対してサービスを提供するようになっている。したがって、この場合には、利用者端末１９０４は、ウェブブラウザなどの閲覧ソフトウェアを用いて管理サーバ１９０１と通信を行う。また、利用者端末１９０４には、ウェブブラウザなどの他に、管理データを管理するアプリケーションプログラム（「管理データ管理アプリケーション」という）がインストールされていてもよく、管理データ管理アプリケーションを用いて管理サーバ１９０１と通信を行うようになっていてもよい。
　図２０は、本実施形態におけるシステム１９００での決済処理が行われて管理データが生成されて利用者端末に受信されるまでの処理を説明するシーケンス図である。
　ステップＳ２００１において、利用者端末１９０４から管理サーバ１９０１へ、利用者端末１９０４の識別情報を含む情報を送信する。識別情報とは、利用者端末１９０４を識別するための情報である。識別情報の例としては、利用者端末１９０４の製造番号や、ＭＡＣアドレス、ＩＰアドレスなどである。あるいは、利用者を識別する情報であるユーザＩＤや所有者ＩＤなどであってもよい。また、識別情報は、利用者端末１９０４の製造番号や、ＭＡＣアドレス、ＩＰアドレスなどの情報そのものである必要はなく、それらの情報に対して所定のハッシュ関数を適用して計算される値であってもよい。この識別情報は、管理サーバ１９０１により後に発行される管理データに埋め込まれてもよい。識別情報を管理データに埋め込むことにより、管理データを譲渡などする場合に、管理データが不正に他の利用者端末から取得されたものであるかどうかを検出することができる。これにより、管理データの使用の際の安全性を高めることができる。また、識別情報には、乱数が含まれるようになっており、管理サーバ１９０１への送信の都度、変化する部分があってもよい。
　管理サーバ１９０１において、識別情報を受信する部を識別情報受信部という。
　なお、ステップＳ２００１において、識別情報は、例えば、ＨＴＴＰ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）のＰＯＳＴメッセージとして、利用者端末１９０４から管理サーバ１９０１に送信される。ただし、識別情報は、ブラウザで送信される必要はなく、上述した管理データ管理アプリケーションによって送信されてもよい。管理データ管理アプリケーションを用いれば、端末装置１９０４のハードウェアなどにアクセスを行い、ＭＡＣアドレスなどを取得することが容易に行える。
　ステップＳ２００２においては、管理サーバ１９０１は、画面情報を利用者端末１９０４へ返信する。画面情報は、例えば、ＨＴＭＬ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）を用いて記述され、管理データを発行するための入金処理や、発行された管理データを受け取るための処理を行うために使用することができる。
　利用者端末１９０４が画面情報を受信すると、その画面情報の記述に従って画面表示を行う。例えば、受信された画面情報を、利用者端末１９０４で動作する管理データ管理アプリケーションがＲＥＡＤシステムコールなどを用いて取得すると、ウェブブラウザを起動して、そのウェブブラウザによって画面情報を表示させる。
　図２１は、表示される画面情報の例を示す。例えば管理データ管理アプリケーションによりブラウザが起動されて画面情報が表示されると、図２１（ａ）に示されるように、「入金」、「管理データ受取」という表示を有するボタンが表示される。「入金」の表示を有するボタンが押下されると、画面情報に含まれるスクリプトなどの処理により、図２１（ｂ）に示される画面が表示される。
　図２１（ｂ）は、銀行振込を行うための画面であって、「振込名義人名を１２３４５としてください」というメッセージが表示され、「振込」という表示を有するボタンが表示されている。１２３４５というのは、管理サーバ１９０１がステップＳ２００１において識別情報を受信した際に、管理サーバ１９０１側などで生成される情報である。あるいは、利用者端末１９０４側で生成され、ステップＳ２００１において管理サーバ１９０１に送信され、管理サーバ１９０１で承認などされた番号であってもよい。承認とは、利用者端末１９０４側で生成された情報が適切でることを確認することである。例えば、同じ情報を他の利用者端末で生成されて管理サーバ１９０１に送信されていないことを確認する。あるいは、識別情報がユーザＩＤであれば、そのユーザＩＤそのものやユーザＩＤに関連付けられた値である。利用者が銀行振込を行う際に、この情報を振込名義人名に含ませることにより、管理サーバ１９０１が銀行から振込通知を受信などした際に、その振込がどの識別情報の受信に対して返信した画面情報によって行われたかを知ることができる。また、図２１（ｂ）の画面には、振込先の銀行口座の情報が含まれていてもよい。
　管理サーバ１９０１において、振込名義人名を生成あるいは承認、取得し、利用者端末１９０４に送信する部を、振込名義人名送信部という。
　なお、図２１（ｂ）において、複数の銀行の中から利用者端末１９０４の利用者が契約している銀行を選択できるように、複数の銀行それぞれに対応したボタンが表示されていてもよい。
　図２１（ｂ）の「振込へ」の表示を有するボタンが押下されると、利用者端末１９０４から銀行などの決済サーバ１９０２に対してアクセスが行われ、図２２（ａ）のようなインターネットバンキングなどのためのログイン画面が表示される。このログイン画面を介して利用者がログインを行い、振込の依頼を行うと、ステップＳ２２０４の処理として、利用者端末１９０４から決済サーバ１９０２に対して振込依頼が送信される。この振込依頼には、管理サーバ１９０１などの運営者の銀行口座の情報、振込名義人名、振込額が含まれる。なお、図２１（ｂ）の「振込へ」の表示を有するボタンには、振込先の口座の情報や、振込名義人名を含むＵＲＬが関連付けられており、そのＵＲＬにアクセスすると、決済サーバ１９０２に振込先の口座の情報や振込名義人名が伝えられ、振込の画面が開かれた場合に、振込先の口座の情報や振込名義人名が既にデフォルト値などとして入力された状態となっていてもよい。
　振込の依頼が終わると、ステップＳ２２０４の処理として、利用者端末１９０４から管理サーバ１９０１へ、振込の依頼の処理が終わったこと旨を表す入金通知が送信される。この際には、ステップＳ２２０１で送信された識別情報や振込名義人名も送信される。すなわち、利用者端末１９０４にて、振込の依頼の処理が終了すると、利用者端末１９０４では、図２２（ｂ）に示されるような画面が表示される。図２２（ｂ）に示される画面は、「入金通知」という表示を有するボタンが表示されている。このボタンが押下されると、ステップＳ２００４の処理として、入金通知が利用者端末１９０４から管理サーバ１９０１へ送信される。入金通知は、利用者端末１９０４にて振込の依頼の処理が終了したことを、利用者端末１９０４から管理サーバ１９０１に知らせる情報である。
　入金通知を受信した管理サーバ１９０１は、ステップＳ２２０５の処理として、入金通知とともに送信された情報から振込名義人名を取得し、決済サーバ１９０２に対して、その振込名義人名による振込が実際に依頼されたかどうかを問い合せる。決済サーバ１９０２は、その振込名義人名による振込があれば、ステップＳ２２０６の処理として振込通知を返信する。この振込通知には振込額も含まれていてよく、これにより、管理サーバ１９０１は振込額を得ることができる。
　また、ステップＳ２００５とＳ２００６の処理の代わりに、管理サーバ１９０１は、例えば、５分に一回、振込の有無の問い合せを管理サーバ１９０１に行い、振込の有無を確認してもよい。
　もし、振込がされていなければ、管理サーバ１９０１は、ステップＳ２００４の入金通知に対して、振込が確認できなかったことを通知する。この場合、管理データ管理アプリケーションなどによって振込の確認ができていないことの表示がされ、利用者は、しばらく時間が経過してから再度入金通知を行うことになる。
　管理サーバ１９０１は、振込を確認すると、振込通知に含まれる振込名義人名から、どの識別情報の受信に対して画面情報によって行われたかをテーブルなどを検索して取得し、管理データを生成し、また、実施形態１で説明したように、振り込みの決済処理を特定する番号を生成する。決済処理を特定する番号は、本実施形態では、「送り情報」と称することにする。送り情報は、例えば、利用者端末１９０４と管理サーバ１９０１とがステップＳ２００１とＳ２００２とで通信を行ったセッションのＩＤであってもよい。また、振込み名義人名送信部で送信された振込名義人名を用いてもよい。ステップＳ２００７の処理として、生成した送り情報と管理データとを保管サーバ１９０３へ送信する。保管サーバ１９０３は、送り情報と管理データとを関連付けて、その保管部に保持する。
　管理サーバ１９０１において、振込通知を受信する部を振込通知受信部と称する。また、管理データを生成するために、新たな照合用データを準備して、振込通知受信部が受信した振込通知に含まれる金額の額に相当する価値情報を関連づけてデータベース部１０１に記憶する部を照合用データ生成部と称する。また、新たに準備された照合用データから生成された管理データを送信する部を管理データ送信部と称する。また、本実施形態では、管理サーバ１９０１は、準備された照合用データと、識別情報受信部で受信された識別情報を関連付けてデータベース部１０１などに記憶する。
　ステップＳ２００８の処理として、管理サーバ１９０１は、入金が確認された旨と送り情報とを利用者端末１９０４へ返信する。なお、ステップＳ２００１とＳ２００２とにおいて利用者端末１９０４と管理サーバ１９０１との通信において、送り情報が、セッションＩＤや振込名義人名として利用者端末１９０４に送り情報が通知されていれば、ステップＳ２００８では、送り情報を利用者端末１９０４へ返信する必要はない。
　管理サーバ１９０１にて、その振込によって生成された送り情報を取得し、ステップＳ２００８の処理として、入金確認と送り情報とを利用者端末１９０４へ返信する。
　利用者端末１９０４が、入金確認と送り情報とを受信すると、図２２（ｃ）に示される画面が表示される。図２２（ｃ）に示される画面においては、「入金の確認がされましたので、管理データ受取を押して下さい」というメッセージと、「管理データ受取」という表示を有するボタンが表示される。なお、図２２（ｃ）の画面は、ブラウザによって表示される必要はなく、管理データ管理アプリケーションによって表示されてもよい。例えば、ステップＳ２００８にて返信される入金確認と送り情報とが、ＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ　Ｉｎｔｅｒｎｅｔ　Ｍａｉｌ　Ｅｘｔｅｎｓｉｏｎ）のフォーマットを用いて送信され、そのフォーマットにおいてＣｏｎｔｅｎｔ－Ｔｙｐｅなどによって、管理データ管理アプリケーションがアプリケーションプログラムとして用いられることが指定されていてもよい。このような指定により、ブラウザが入金確認と送り情報とを受信すると、管理データ管理アプリケーションが起動され、図２２（ｃ）に示される画面が表示できる。
　「管理データ受信」のボタンが押下されると、ステップＳ２００９の処理として、利用者端末１９０４から保管サーバ１９０３へ、送り情報が送信される。この送り情報が保管サーバ１９０３にて受信されると、ステップＳ２００６において格納部に送り情報と関連付けられて保管された管理データが読み出される。そして、ステップＳ２０１０の処理として、その管理データが保管サーバ１９０３から利用者端末１９０４に受信されて、利用者端末１９０４内に格納される。
　図２３は、管理サーバ１９０１が、ステップＳ２００１において利用者端末１９０４から識別情報を受信してから、ステップＳ２００８において入金確認と送り情報とを送信するまでの処理を行うために参照するテーブルの構成と格納されるデータの遷移を説明する。図２３（ａ）に示すように、管理サーバ１９０１は、「識別情報」、「振込番号」、「金額」、「送り情報」という名前の列により構成されるテーブルを保持し、管理を行う。
　管理サーバ１９０１がステップＳ２００１において識別情報を受信すると、そのテーブルに対して行データの挿入が行われる。識別情報が例えば９８７６５であれば、図２３（ｂ）に示されるように、識別情報の列の値が９８７６５である行がテーブルに挿入される。その行において、識別情報の列以外の列の値は、例えば、ＮＵＬＬ（図示せず）とされる。ＮＵＬＬとされることにより、まだ値が定まっていないことが表現される。
　識別情報がステップＳ２００１において受信され、その識別情報に基づいて振込名義人名が決定されると、挿入された行の振込番号の列の値が、その振込名義人名に更新される。例えば、振込名義人名が図２１（ｂ）に示されるように１２３４５であれば、図２３（ｃ）に示すように、識別情報の列の値が９８７６５である行の振込番号の列の値が１２３４５に更新される。
　管理サーバ１９０１がステップＳ２００６において振込通知を受信すると、その振込通知に含まれる振込名義人名を振込番号の列に有する行が検索され、振込通知に含まれる振込金額により金額の列の値が更新される。例えば、振込通知により、１２３４５という振込名義人名により５０００円が振り込まれたとすると、図２３（ｄ）に示すように、識別情報の列の値が９８７６５である行の金額の列の値が５０００に更新される。これにより、管理サーバ１９０１は、振込があったことが確認できるようになる。
　管理サーバ１９０１が送り情報を生成し、ステップＳ２００７において保管サーバ１９０３に、送り情報を送信すると、「送り情報」の列の値が更新される。例えば、１２３４５という振込名義人名により５０００円が振り込まれ、２４６８１０という送り情報が生成されると、図２３（ｅ）に示すように、識別情報の列の値が９８７６５である行の送り情報の列の値が２４６８１０に更新される。これにより、管理サーバ１９０１は、９８７６５という識別番号に対して、管理データを生成して、保管サーバ１９０３に送信したことが確認できるようになる。
　図２４は、利用者端末１９０４の機能ブロック図を示す。この機能ブロック図は、利用者端末１９０４にインストールされているアプリケーションプログラムの構成を示している。利用者端末１９０４には、ブラウザと管理データ管理アプリケーションとがインストールされている。ブラウザと管理データ管理アプリケーションとが協調して動作して決済処理から管理データの受信の処理を行う。
　図２５は、利用者端末１９０４にインストールされているブラウザと管理データ管理アプリケーションとが協調して、図２０に示される決済処理が行われ、管理データが生成されて利用者端末に受信されるまでの処理のシーケンス図を示す。
　ステップＳ２５０１は、ステップＳ２００１に対応している。ステップＳ２５０１においては、識別情報が、管理データ管理アプリケーションより送信されることを示している。管理データ管理アプリケーションを用いれば、ブラウザを用いるよりも容易に利用者端末１９０４のハードウェアなどにアクセスを行い、ＭＡＣアドレスなどのハードウェア固有の情報を取得することができる。
　なお、ステップＳ２５０１の処理を実行するには、利用者端末１９０４にて管理データ管理アプリケーションを起動する。管理データ管理アプリケーションの起動により、例えば、図２６に示されるように、「入金（ポイント購入）」、「ポイントの受取」、「ポイントによる支払」の表示を有するボタンを含む画面表示が利用者端末１９０４のディスプレイなどに表示がされる。「入金（ポイント購入）」のボタンが押下されると、管理データ管理アプリケーションは、識別情報を算出などして、管理サーバ１９０１へ送信する。
　ステップＳ２５０２は、ステップＳ２００２に対応している。ステップＳ２５０２においては、ステップＳ２５０１にて送信された識別情報に対して管理サーバ１９０１から返信される画面情報が、管理データ管理アプリケーションにより受信される。
　管理データ管理アプリケーションが画面情報を受信すると、ステップＳ２５０３の処理として、管理データ管理アプリケーションはブラウザを起動し、画面情報の記述に従った画面表示を行う処理が行われる。例えば、管理データ管理アプリケーションは、受信した画面情報を一時ファイルに書き込み、その一時ファイルの名前をコマンドの引数などとしてブラウザに与えてブラウザを起動する。例えば、一時ファイルの拡張子と関連付けられているブラウザが起動されるようになっている。
　ステップＳ２５０４、ステップＳ２５０５、ステップＳ２５０６、ステップＳ２５０７、ステップＳ２５０８は、それぞれステップＳ２００３、ステップＳ２００４、ステップＳ２００５、ステップＳ２００６、ステップＳ２００７、ステップＳ２００８に対応している。これらのステップの処理では、利用者端末１９０４では、ブラウザが管理サーバ１９０１、決済サーバ１９０２と通信を行う。
　ステップＳ２５０９にて、ブラウザが入金確認と送り情報とを管理サーバ１９０１より受信すると、ブラウザは、管理データ管理アプリケーションを起動し、送り情報を管理データ管理アプリケーションに処理をさせる。上述したように入金確認と送り情報とが、ＭＩＭＥのフォーマットを用いた情報としてブラウザにより受信されると、そのフォーマットにおいてＣｏｎｔｅｎｔ－Ｔｙｐｅなどによって、管理データ管理アプリケーションにより処理することが指定されているので、ブラウザは管理データ管理アプリケーションを起動し、起動した管理データ管理アプリケーションは、送り情報を取得する。ステップＳ２５１０の処理として、管理データ管理アプリケーションは、保管サーバ１９０３へ送り情報を送信する。保管サーバ１９０３から返信される管理データを受信する処理をステップＳ２５１１の処理として行う。管理データ管理アプリケーションが管理データを受信すると、受信した管理データを、利用者端末１９０４の記憶装置（ハードディスクなど）に書き込む。
　ブラウザから管理データ管理アプリケーションが起動された場合には、図２６の画面が表示されてもよい。利用者端末１９０４の利用者が「ポイントの受取」の表示を有するボタンを押下すると、ステップＳ２５１１とステップＳ２５１２との処理が開始されるようになっていてもよい。
　図２７は、管理データ管理アプリケーションのモジュール構成図を示す。管理データ管理アプリケーション２７００は、識別情報取得部２７０１と、送り情報管理部２７０２と、管理データ管理部２７０３と、送受信部２７０４と、制御部２７０５とを有している。
　識別情報取得部２７０１は、ステップＳ２５０１において送信される識別情報を取得する。例えば、利用者端末１９０４のハードウェアにシステムコールなどを用いてアクセスを行い、ＭＡＣアドレスや製造番号などを取得する。また、利用者端末１９０４の利用者のＩＤやパスワードなどの認証情報を識別情報として取得してもよい。また認証情報は、ファイルに格納されていたり、キーボードやカードリーダなどにより読み取られるようになっていたりしてもよい。また、認証情報の一部に乱数が含まれる場合には、識別情報取得部２７０１がその乱数を生成するようになっていてもよい。
　また、識別情報取得部２７０１により取得された識別情報は、ステップＳ２５１１の処理により管理データが受信されるまで、利用者端末のハードディスクなどの二次記憶に記憶されるようになっていてもよい。管理データ管理アプリケーションが起動すると、二次記憶に識別情報が記憶されているかどうかを調べ、もし、記憶されていれば、受け取られていない管理データが保管サーバ１９０３に保管されている旨の表示を行い、利用者に注意を喚起してもよい。この場合、利用者が振込の依頼の処理を行っているのならば、管理データ管理アプリケーションは利用者にステップＳ２５０５の入金通知を管理サーバ１９０１に送信し、入金確認と送り情報を受信することができるように、ボタンなどを表示する。そして、そのボタンが押下されると、管理データ管理アプリケーションは入金通知を管理サーバ１９０１に送信する。
　送り情報管理部２７０２は、ステップＳ２３１０において、ブラウザから渡された送り情報を管理する。管理とは、データのファイルへの書き込み、読み出し、削除、更新を意味する。ステップＳ２５０９の処理により、ブラウザから管理データ管理アプリケーションが起動される際に、ブラウザから渡された送り情報を所定のファイルに書き込む。また、ステップＳ２５１１の処理により、管理データが受信されると、所定のファイルを削除したり、所定のファイルから送り情報を削除したりする。これにより、送り情報が受信されたが、受信されていない管理データの有無をしらべることができる。
　管理データ管理部２７０３は、管理データを管理する。ステップＳ２５１１にて受信された管理データは、管理データ管理部２７０３により、利用者端末１９０４の記憶装置（ハードディスクなど）に書き込まれ、また、管理データを用いた支払の処理の際に読み出し、削除、変更が行われる。
　送受信部２７０４は、管理サーバ１９０１、保管サーバ１９０３と通信を行うための部である。
　制御部２７０５は、識別情報取得部２７０１と、送り情報管理部２７０２と、管理データ管理部２７０３と、送受信部２７０４とを制御し、管理データの受信の処理、管理データを用いた支払の処理を行う。
　図２８は、管理データを用いた支払の処理のシーケンス図を示す。図２８は、保管サーバを介しての管理データの譲渡についてのシーケンス図である図１４に対応している。図１４での譲受者端末が図２８での販売サーバに対応し、譲渡者端末が利用者端末に対応している。本実施形態では、利用者端末の内部で管理データ管理アプリケーションとブラウザとが協調して動作している。また、販売サーバは、ＷＥＢサーバとしての機能を有しており、ＷＥＢページの閲覧要求があれば、要求されたＷＥＢページを返信する。
　ステップＳ２８０１において、利用者端末のブラウザなどへＵＲＬの入力や、ブラウザを操作してリンクを辿るなどの処理を行い、ウェブページの閲覧要求が販売サーバへ送信される。販売サーバが閲覧要求を受信すると、要求されたウェブページをステップＳ２８０２において返信する。
　ステップＳ２８０２においてブラウザに返信されるウェブページには、商品などの購入の申込を行うための画面の記述がされているとする。例えば、図２９に示すように、「○○」として、購入が行われる商品などの名称が表示され、代金が例えば１００円として表示される。また、「購入」という表示を有するボタンが表示されている。このボタンには、購入が行われる商品などの識別番号が関連付けられている。また、必要に応じて、ウェブページには商品の配送先などを入力するテキストエリアが含まれており、「購入」という表示を有するボタンが押下されると、そのテキストエリアに入力された情報が送信されるようになっていてもよい。
　「購入」という表示を有するボタンが押下されると、ステップＳ２８０３の処理として、購入情報が保管サーバに送信される。購入情報とは、販売サーバの識別情報、購入が行われる商品などの識別番号、商品などの数量、代金額を含む情報である。また、上述した商品などの発送先を含んでいてもよい。この購入情報は、図２９に示されるボタンに関連付けられた情報を用いて生成され、販売サーバに送信される。購入情報が販売サーバに送信されることにより、ブラウザを操作する利用者が販売サーバの運営者から商品などの購入の同意がされ、支払が管理データの譲渡によってされることの同意もされたことが示される。
　すなわち、ステップＳ２８０１からステップＳ２８０３までの処理が行われることにより、譲受端末としての販売サーバと譲渡者端末としての利用者端末との間で譲渡の合意がされることになる。従って、ステップＳ２８０１からステップＳ２８０３までの処理がステップＳ１４０１に対応していることになる。
　ステップＳ２８０４の処理として、販売サーバから支払指示とセッションＩＤがブラウザに送信される。支払指示には、譲渡されるべき価値の額（支払額）が含まれている。また、セッションＩＤは、上述の送り情報に対応する。支払指示とセッションＩＤとは、例えば、ＭＩＭＥフォーマットで記述され、Ｃｏｎｔｅｎｔ－Ｔｙｐｅなどによって、管理データ管理アプリケーションを用いて表示されることが指定されていてもよい。
　また、販売サーバは、保管サーバに対して、端数管理データ１とセッションＩＤを送信する。これは、利用者端末から送信される管理データによる支払を受けるためである。
　販売サーバから端数管理データ１とセッションＩＤを受信した保管サーバは、ステップＳ２８０６の処理として、端数管理データ１を管理サーバへ送信し、端数管理データ１が有効であるかどうかを判断させ、有効であれば、照合用データの書き換えを行わせ、その結果得られる管理データである端数管理データ２をステップ２８０７の処理において受信する。そして、送り情報と関連付けて保管する。
　したがって、ステップＳ２８０５、Ｓ２８０６、Ｓ２８０７の処理は、ステップＳ１４０２，Ｓ１４０３、Ｓ１４０４の処理に対応している。
　ステップＳ２８０４にて、販売サーバから支払指示とセッションＩＤを受信したブラウザは、管理データ管理アプリケーションを起動させ、販売サーバから受信した支払指示とセッションＩＤとの処理を行わせる。すなわち、起動した管理データ管理アプリケーションは、ステップＳ２８０９の処理として、ステップＳ２８０４で受信したセッションＩＤと支払指示に含まれる支払額とを、また、その支払額以上となるように管理データを管理データ管理部２７０３から選択して読み出して支払管理データ１として、保管サーバに送信する。支払額以上とは、選択された管理データが表す価値の額の合計額が、支払額以上となるこという。管理データ管理部２７０３から読み出される管理データは複数であってもよい。また、管理データ管理アプリケーションが起動すると、支払額を画面に表示し、ボタン押下を利用者に行わせるなどして、支払管理データの額などの確認を行わせてもよい。また、管理データ管理部２７０３で管理されている管理データが暗号化されて記憶されている場合には、復号のためのパスワードなどの入力が求められるようになっていてもよい。
　ステップＳ２８０９において、管理データ管理アプリケーションからセッションＩＤ、支払額、支払管理データ１を受信した保管サーバは、セッションＩＤに、支払額と支払管理データ１を関連付けて保管する。また、他にセッションＩＤに関連付けて保管されている管理データがあるかどうかの検索を行い、そのような管理データがあれば、ステップＳ２８１０以降の処理を行う。
　ステップＳ２８１０とステップＳ２８１１の処理は、ステップＳ１４０６、Ｓ１４０７の処理に対応している。保管サーバは、端数管理データ２と支払額と支払管理データ１を管理データに送信し、端数管理データ３、支払管理データ２と釣管理データとを受信する。
　ステップＳ２８１２の処理として、保管サーバは管理データ管理アプリケーションに釣管理データを送信する。この釣管理データの送信は、ステップＳ２８０９にて受信された支払額と支払管理データ１の返信として行われてもよい。
　ステップＳ２８１３の処理として、管理データ管理アプリケーションは、ブラウザを起動し、決済終了画面を表示させる。決済終了画面の記述は、ステップＳ２８１２にて、保管サーバが釣管理データとともに管理データ管理アプリケーションに送信するようになっていてもよい。さらに、決済終了画面の記述は、ステップＳ２８０５において、販売サーバが端数管理データ１とセッションＩＤとともに保管サーバに送信するようになっていてもよい。このように決済終了画面の記述が、販売サーバから送信され、保管サーバを経由して、利用者端末へ送信されることにより、電子的なデータそのものや電子的なデータのダウンロードなどのために使用するＵＲＬを決済終了画面の記述に含ませることにより、電子的なデータを販売に本実施形態を利用することができる。
　ステップＳ２８１４にて管理サーバから受信された端数管理データ３と支払管理データ２は、ステップＳ２８０５にて受信されたセッションＩＤとともに保管サーバから販売サーバへ送信される（ステップＳ２８１４）。端数管理データ３と支払管理データ２の送信は、ステップＳ２８０５にて販売サーバから送信された端数管理データ１とセッションＩＤに対する返信として行われてもよい。
　このように、支払指示とセッションＩＤとがブラウザなどにより受信されると、管理データ管理アプリケーションが起動し、管理データを用いた支払を行うことができるようになる。したがって、本実施形態においては、利用者は、ステップＳ２８０３にて購入情報を、ブラウザを用いて販売サーバに送信した後の決済の処理を行うために、従来技術におけるのと異なり、クレジットカード番号や振込先の口座番号などの煩雑なデータを入力する必要がなくなる。また、利用者端末１９０４に記憶された管理データを用いて支払を行うので、クレジットカードのようにその後の返済などについて心配する必要がない。したがって、利用者は簡便な操作で管理データを用いて支払を行うことができる。これにより、インターネットなどでの支払を安全かつ簡便に行うことができる。
　（実施形態６）
　本発明の実施形態６として、利用者が簡単にウェブサーバを用いた仮想的な店舗を開設できる技術について説明する。上述の実施形態５においては、販売サーバは保管サーバと通信を行う。このため、インターネットの一般的な利用者が自身のホームページを開設するために用いられているウェブサーバをそのまま販売サーバとして使用できない場合がある。そこで、本実施形態では、インターネットの一般的な利用者が自身のホームページを開設するために用いるウェブサーバと、保管サーバと通信を行い、利用者に代わって管理データの受信を行うように構成された販売サーバとの組み合わせについて説明を行う。
　図３０は、インターネットなどの通信網３００１を介して、販売サーバ３００２とウェブサーバ３００３とが利用者端末３００４から利用可能になっているシステムの概要を示す。販売サーバ３００２は、実施形態５にて説明した販売サーバである。例えば、販売サーバ３００２は、注文画面ファイル３００５をそのファイルシステムに格納しており、ステップＳ２８０１において、利用者端末３００４にインストールされたブラウザ３００７からの閲覧要求が受信されると、ステップＳ２８０２において、注文画面ファイル３００５を返信することができる。
　また、販売サーバ３００２は、特定の利用者のみが商品などの販売に用いるサーバではなく、複数の利用者が商品などの販売などに用いることができる。複数の利用者の間に特別な人間関係が存在していなくてもよい。複数の利用者が販売サーバ３００２を用いて商品などの販売を行う仮想的な店舗には、店舗を識別する情報として、店舗識別番号などがそれぞれ割り振られている。販売サーバ３００２の外部からは、店舗識別番号を用いて仮想的な店舗がアクセス可能であるとする。例えば、ある利用者が開設した店舗に４５６７という店舗識別番号が割り振られているとすると、４５６７を用いて、その店舗を販売サーバ３００２の外部からアクセスすることができる。
　ウェブサーバ３００３は、インターネットの一般的な利用者が自身のホームページを開設するために用いられているウェブサーバである。インターネットの一般的な利用者は、ウェブサーバ３００３に割り当てられた自分のスペースに、ウェブページ３００６を置く。このとき、ウェブページ３００６には、販売サーバ３００２に格納された注文画面ファイル３００５へのリンクを設けておく。このリンクのＵＲＬには、上述した店舗の識別情報が含まれて構成される。例えば、ＵＲＬには、ｓｈｏｐｉｄ＝４５６７などを含み、店舗の店舗識別番号が４５６７であることを表す。
　このようにリンクを設けることにより、インターネットの一般的な利用者は、ウェブページに商品などの広告を掲載し、その広告を見た利用者を注文画面ファイル３００５へ誘導し、商品などの販売の対価として得られる管理データを得ることが可能となる。
　販売サーバ３００２に店舗を開設した利用者は、例えば、ＦＴＰ（Ｆｉｌｅ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）などを用いて、販売サーバ３００２と通信を確立し、注文画面ファイル３００５や、注文を受け付けた旨を示す受注確認ファイル、注文を受け付けることができなかった旨を示す受注失敗ファイルなどをアップロードする。
　図３１は、販売サーバ３００２が、アップロードされた注文画面ファイルの管理を行うためのテーブルの構成の一例である。販売サーバ３００２の外部から店舗の識別情報を用いてアクセスが行われた場合には、このテーブルを参照し、識別情報で指定される店舗を開設した利用者がアップロードした注文画面ファイルなどを取得して返信などする。例えば、ステップＳ２８０１において、販売サーバ３００２にて店舗の店舗識別番号を含む閲覧要求が受信された場合には、販売サーバ３００２は、店舗の店舗識別番号をキーとして、図３１のテーブルを検索し、注文画面ファイルＩＤを得て、その注文画面ファイルＩＤで指定されるウェブページを読み出して、ステップＳ２８０２にて返信を行う。
　また、ステップＳ２８０４において、販売サーバ３００２にて購入情報が受信された場合には、販売サーバ３００２は、購入情報に含まれる店舗のＩＤを取得して、図３１のテーブルを検索し、受注確認ファイルＩＤと受注失敗ファイルＩＤとを得て、それらで指定されるウェブページを読み出して、ステップＳ２８０５にて、保管サーバへ端数管理データ１とセッションＩＤとともに送信する。
　図３２は、販売サーバ３００２のファイルシステムの構成の一例を示す。「ｓｈｏｐｉｄ＝４５６７」、「ｓｈｏｐｉｄ＝６７８９」は店舗の店舗識別番号に対応したフォルダ（ディレクトリ）を示している。以下では、このようなフォルダを店舗フォルダと称することにする。店舗フォルダの中に、注文画面ファイル、受注確認ファイル、受注失敗ファイルが格納される。また、管理ファイルは、店舗に支払われた管理データを格納しているファイルを示す。例えば、管理ファイル３２０１は、店舗識別番号として４５６７を有する店舗に譲渡された管理データを格納する。ステップＳ２８０５において送信される端数管理データは、店舗フォルダの管理ファイルから読み出される端数の額の管理データとなる。また、ステップＳ２８１５で販売サーバが受信する端数管理データと支払管理データは、店舗フォルダの管理フィルに格納される。
　店舗フォルダの管理ファイルに格納された管理データは、店舗の開設者がＦＴＰなどを用いてダウンロードすることが可能となっている。
　なお、管理サーバに不正なアクセスが行われ、店舗フォルダの管理ファイルに格納された管理データが不正にダウンロードされ、不正に使用されることを防止するために、店舗フォルダには、店舗の開設者の利用する端末装置の識別情報などを含むファイル３２０２がアップロードされる。ステップＳ２８０５において販売サーバから保管サーバに送られるデータの中に、ファイル３２０２を含めることにより、ステップＳ２８１５にて保管サーバから販売サーバに送信される端数管理データ、支払管理データが、店舗の開設者のみが使用可能にすることができる。これにより安全性を高めることが可能である。
　このように本実施形態によれば、誰でも仮想的な店舗を開設することができ、管理データにより支払を受けることができる。
　以上のように、本発明においては、金銭的な価値などと関連付けられた照合用データを含む管理データを、利用者端末に記憶し、記憶された管理データを譲渡することにより、金銭的な価値などを譲渡することが電子的に行うことができる。これにより、管理データによる支払をインターネット上で行うことが可能となる。
　従来、インターネットで金銭的な価値の譲渡を行うには、金銭的な価値と関連付けられたデータをサーバに保存して利用する技術と、金銭的な価値と関連付けられたデータをＩＣカードなどの記憶領域に記憶させ、そのＩＣカードなどを利用者に保持させて利用する技術に分類することができる。前者では、サーバにデータが管理されているので、安全性が高いが、支払などのためにデータの譲渡を行う都度、パスワードの入力などによって利用者を認証する必要がある。このため、使用が煩わしいという問題がある。一方、後者では、利用者はＩＣカードリーダなどにＩＣカードをかざすだけで支払が簡便に行うことができるが、データの偽造などの虞があり、また、ＩＣカードを紛失した場合に取り戻すことが困難であるという問題がある。また、前者、後者ともに、データのみを一般の利用者に譲渡するのは困難である。
　一方、本発明は、照合用データをサーバで管理し、同時に、照合用データを含む管理データを利用者の端末装置に記憶するという点で折衷型であり、安全性と支払の簡便さを併せ持っている技術を提供する。
　別の側面から説明を加えると、従来技術において通常のブラウザを用いて支払を行う場合には、クレジットカードや銀行振込、サーバ方のプリペイドマネーであっても、支払を行う者が正当な利用者であることを確認するために、カード番号、ＩＤやパスワード、アクセスコードなどの入力が求められる。これらのカード番号、ＩＤやパスワード、アクセスコードなどが覚えやすいものであると、セキュリティが脆弱となるので、複雑なものであることが好ましいとされ、複雑なものであると、記憶することが困難となるなどにより、逆に不便なシステムとなってしまう。
　一方、本発明では、実施形態１などにおいて説明したように、管理サーバにより発行された管理データを利用者端末に格納し、必要に応じて、管理データを譲渡することにより価値の移転が行われる。管理データが有効なものであるかどうかは、管理サーバのデータベース部に管理データの照合用データの記録の有無により判断がされる、管理サーバを介して譲渡を行う都度、照合用データの書き換えが行われる。このため、管理データを所持しているものが正当な権利者であることが推定でき、ＩＤやパスワード、アクセスコードなどによって正当な所有者であることを証明する必要が低減でき、セキュリティを保ちつつ、利便性を維持することが可能となる。
　また、実施形態５などにおいて説明したように、ブラウザを用いてインターネットのサイトに購入などの申込を行った場合、サイトからは送られる支払指示とセッションＩＤとを含む情報がブラウザにより受信されると、管理データ管理アプリケーションを自動的に起動させることができ、管理データ管理アプリケーションによる支払を行うことができる。セッションＩＤは、従来技術における例えば銀行口座に対応しているが、セッションＩＤはインターネットのサイトから送信されるので、利用者はセッションＩＤを入力する必要がなくなる。
　また、実施形態２などにおいて説明したように、管理データが表す価値に上限を持たせることもでき、管理データを紛失したとき際の損害が大きくならないようにすることができる。以上より、本願発明は、産業上有用である。

Claims (18)

  1. 　照合用データに、価値情報とその価値情報が表す価値を所有する者の所有者識別情報とを関連付けるデータベース部と、
    　第１の照合用データを含む第１の管理データを受信する管理データ受信部と、
    　前記第１の照合用データが前記データベース部により第１の価値情報に関連付けられていれば、新たな照合用データを準備して、前記第１の価値情報に前記新たな照合用データを関連付けるとともに前記第１の管理データに含まれる前記第１の照合用データを前記新たな照合用データに置換した第２の管理データを生成する置換部と、
    　前記第１の管理データに第１の所有者識別情報が含まれていれば、前記第１の所有者識別情報に前記新たな照合用データを関連付ける変更操作を前記データベース部に対して実行する所有者変更部と、
    　前記第２の管理データを送信する置換管理データ送信部と、
    　を有することを特徴とする管理サーバ。
  2. 　照合用データを含む管理データを受信する認証用管理データ受信部と、
    　前記認証用管理データ受信部で受信された管理データに含まれる照合用データに、前記データベース部によって関連付けられている所有者識別情報を検索する所有者識別情報検索部と、
    　前記所有者識別情報検索部により検索された所有者識別情報を送信する所有者識別情報送信部と、
    　を有することを特徴とする請求項１に記載の管理サーバ。
  3. 　前記所有者識別情報送信部は、所有者識別情報の送信先を認証しその認証が成功することを条件に前記検索された所有者識別情報を送信することを特徴とする請求項２に記載の管理サーバ。
  4. 　前記所有者情報送信部は、前記検索された所有者識別情報が複数あれば、それら所有者識別情報に対する認証を行い認証が成功する所有者識別情報を送信することを特徴とする請求項３に記載の管理サーバ。
  5. 　送信された所有者識別情報を受信する所有者識別情報受信部と、
    　前記所有者識別情報受信部で受信された所有者識別情報に、前記データベース部によって関連付けられている照合用データを検索する照合用データ検索部と、
    　前記照合用データ検索部で検索された照合用データを含む管理データを生成して送信する検索管理データ送信部と、
    　を有することを特徴とする請求項１から４のいずれか一に記載の管理サーバ。
  6. 　前記所有者識別情報受信部が受信する所有者識別情報の送信元を認証しその認証が成功することを条件に前記検索管理データ送信部が、検索された照合用データを含む管理データを生成して送信することを特徴とする請求項５に記載の管理サーバ。
  7. 　前記管理データ受信部は、
    　第１の管理データとして、第１の端末より送信された、上限の量以下の価値を表す第１の価値情報に関連付けられた第１の照合用データを含む管理データを受信し、
    　第２の端末より送信された、前記上限の量未満の価値を表す第３の価値情報に関連付けられた第３の照合用データを含む第３の管理データを受信する第３管理データ受信部を備え、
    　前記上限と前記第３の価値情報が表す価値との差を越えない価値を、前記第１の価値情報の価値から差し引き前記第３の価値情報が表す価値に加算するデータベース変更部と、
    を有し、前記置換管理データ送信部は、
    　前記第３の管理情報を前記第２の端末へ向けて送信することを特徴とする請求項１に記載の管理サーバ。
  8. 　端末装置より識別情報を受信する識別情報受信部と、
    　振込名義人名を生成し、前記端末装置へ送信する振込名義人名送信部と、
    　振り込まれた金銭の額と振り込みを行った振込名義人名を含む振込通知を受信する振込通知受信部と、
    　新たな照合用データを準備して、前記受信された振込通知に含まれる金銭の額に相当する価値情報を関連づける照合用データ生成部と、
    　前記照合用データを含む管理データを生成して送信する管理データ送信部と、
    を有し、
    　前記データベース部は、前記受信された識別情報を所有者情報として前記生成された管理データに含まれる照合用データに関連付ける請求項１に記載の管理サーバ。
  9. 　前記管理データ送信部は、振込通知により行われた決済処理を一意に特定するＩＤ情報を、前記端末装置と異なる第２のサーバに前記管理データとともに送信し、前記決済処理を一意に特定するＩＤ情報を前記端末装置に送信する請求項８に記載の管理サーバ。
  10. 　前記決済処理を一意に特定するＩＤ情報は、前記生成された振込名義人名である請求項９に記載の管理サーバ。
  11. 　管理サーバ装置によるデータの送受信方法であって、
    　前記管理サーバ装置が、照合用データに、価値情報とその価値情報が表す価値を所有する者の所有者識別情報とを関連付けて保持し、
    　前記管理サーバ装置が、第１の照合用データを含む第１の管理データを受信し、
    　前記管理サーバ装置が、前記第１の照合用データが第１の価値情報に関連付けられていれば、新たな照合用データを準備して、前記第１の価値情報に前記新たな照合用データを関連付けるとともに前記第１の管理データに含まれる前記第１の照合用データを前記新たな照合用データに置換した第２の管理データを生成し、
    　前記管理サーバ装置が、前記第１の管理データに第１の所有者識別情報が含まれていれば、前記第１の所有者識別情報に前記新たな照合用データを関連付け、
    　前記管理サーバ装置が、前記第２の管理データを送信することを特徴とする、価値情報に関連付けられたデータの送受信方法。
  12. 　前記管理サーバが、第１の端末より、上限の値以下の価値を表す第１の価値情報に関連付けられた第１の照合用データを含む第１の管理データを受信し、
    　前記管理サーバが、第２の端末より、前記上限の値未満の価値を表す第２の価値情報に関連付けられた第２の照合用データを含む第２の管理データを受信し、
    　前記管理サーバが、前記上限から前記第２の価値情報が表す価値の差を越えない価値を、前記第１の価値情報の価値から差し引き前記第２の価値情報が表す価値に加算し、
    　前記管理サーバが、前記第２の端末へ前記第２の管理データを含む管理データを送信し前記第１の端末と前記第２の端末との間で決済処理を行う請求項１１に記載のデータの送受信方法。
  13. 　前記管理サーバ装置が、第３の管理データを受信し、
    　前記管理サーバ装置が、前記第３の管理データに含まれる照合用データに関連付けられている所有者識別情報を検索し、
    　前記管理サーバ装置が、検索された所有者識別情報を送信することを特徴とする請求項１１に記載の、価値情報に関連付けられたデータの送受信方法。
  14. 　サーバ装置と決済サーバと保管サーバと利用者端末とのデータの送受信方法であって、
    　前記利用者端末が、管理サーバへ前記利用者端末の識別情報を送信し、
    　前記サーバ装置が、振り込みの決済処理を行う際の名義人名を前記管理サーバにて生成し、
    　前記サーバ装置が、前記生成された名義人名を前記利用者端末へ送信し、
    　前記利用者端末が、ブラウザを起動して前記名義人名を用いて前記決済サーバにて決済処理を行い前記決済処理を識別するＩＤ情報を取得し、
    　前記決済サーバが、前記管理サーバに、決済が行われた名義人名と金額とを含む決済情報を送信し、
    　前記管理サーバが、前記決済情報に含まれる金額の額に相当する価値情報に関連付けられた照合用情報を含んで生成された管理データに、前記識別情報を、価値を所有する者の識別情報として、関連付けてデータベースに記憶し、前記決済情報を識別するＩＤ情報と関連付けて前記保管サーバへ送信し、
    　前記利用者端末が、前記決済処理を行った通知を前記管理サーバへ送信し、
    　前記管理サーバが、前記名義人名を含む決済情報を受信した通知を前記利用者端末へ返信し、
    　前記利用者端末が、前記決済処理を識別するＩＤ情報を前記保管サーバへ送信し、
    　前記保管サーバが、前記利用者端末より送信されたＩＤ情報に関連付けて前記管理サーバが送信した管理情報を送信することを含む、価値情報に関連付けられたデータの送受信方法。
  15. 　管理データの譲渡を仲介するための保管サーバの動作方法であって、
    　価値情報に関連付けられた照合用データを含む管理データを送信する第１の端末とその管理データを受信する第２の端末とが、相互の間で通信セッションを確立し、
    　前記確立された通信セッションにより前記第１の端末と前記第２の端末とが、相互認証を行い、
    　前記保管サーバが、前記第１の端末より送信される管理データと前記確立された通信セッションの識別情報とを受信し、
    　前記保管サーバが、請求項１に記載の管理サーバと通信を行い、前記受信された管理データを前記管理サーバに送信し、前記管理データに含まれる照合用データを、新たに準備された照合用データに置換した置換済管理データを受信し、
    　前記保管サーバが、前記受信された通信セッションの識別情報に関連づけて前記置換済み管理データを保管し、
    　前記保管サーバが、前記第２の端末より、通信セッションの識別情報を受信してその通信セッションに関連づけられて保管されている置換済み管理データを返信することを特徴とする、価値情報に関連付けられたデータの処理方法。
  16. 　前記利用者端末が、前記サーバにおいて価値情報が関連付けられている照合用データを含む管理データを利用者端末に記憶し、
    　前記利用者端末が、ブラウザを起動し、商品の販売または役務の提供を行うための第２のサーバより、前記サーバと前記ブラウザとの通信のセッションＩＤと支払うべき価格情報とを、前記ブラウザを経由して受信し、
    　前記利用者端末が、前記記憶されている管理データを１以上選択して前記選択された管理データに関連付けられている価値情報の額を前記価格情報の額以上とし、
    　前記利用者端末が、前記選択された管理データを前記セッションＩＤとともに第３のサーバへ送信する請求項１５に記載のデータ送信方法。
  17. 　識別情報を管理サーバに送信する送信部と、
    　前記識別情報の送信の返信として、振り込みの決済処理を行う際の名義人名を表示するための画面情報を受信する受信部と、
    　前記受信された画面情報を表示し決済処理を行うブラウザを起動する起動部と、
    　前記起動されたブラウザによる決済処理の後、前記決済処理が行われたことの確認を前記管理サーバに要求する要求部と、
    　前記決済処理が行われたことの確認が前記管理サーバにされて前記決済処理にて振り込まれた金額の額に相当する価値情報及び前記識別情報が前記管理サーバにて関連付けられた照合用データを含む管理データを受信する管理データ受信部と
    を有する端末装置。
  18. 　前記管理データ受信部は、前記決済処理が行われたことの確認が前記管理サーバによって行われて前記管理サーバより受信される情報であって、前記管理サーバが前記決済処理を一意に特定するＩＤ情報を前記管理サーバと異なるサーバへ送信して、管理データを受信する請求項１７に記載の端末装置。
PCT/JP2009/054438 2008-03-19 2009-03-09 電子的価値情報管理サーバ WO2009116415A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010503834A JPWO2009116415A1 (ja) 2008-03-19 2009-03-09 電子的価値情報管理サーバ

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2008071971 2008-03-19
JP2008-071971 2008-03-19
JP2008-305426 2008-11-28
JP2008305426 2008-11-28

Publications (1)

Publication Number Publication Date
WO2009116415A1 true WO2009116415A1 (ja) 2009-09-24

Family

ID=41090820

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/054438 WO2009116415A1 (ja) 2008-03-19 2009-03-09 電子的価値情報管理サーバ

Country Status (2)

Country Link
JP (1) JPWO2009116415A1 (ja)
WO (1) WO2009116415A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003141430A (ja) * 2001-11-03 2003-05-16 Apuriko System:Kk 電子ファイルマネー決済システム
JP2003141368A (ja) * 2001-10-30 2003-05-16 Aiful Corp 返済処理システム、返済処理方法及び債権者システム
JP2006053846A (ja) * 2004-08-16 2006-02-23 Bitwallet Inc 貨幣情報処理サーバ、及び貨幣情報処理方法
JP2007094615A (ja) * 2005-09-28 2007-04-12 Kokuyo Co Ltd 機器制御システム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003141368A (ja) * 2001-10-30 2003-05-16 Aiful Corp 返済処理システム、返済処理方法及び債権者システム
JP2003141430A (ja) * 2001-11-03 2003-05-16 Apuriko System:Kk 電子ファイルマネー決済システム
JP2006053846A (ja) * 2004-08-16 2006-02-23 Bitwallet Inc 貨幣情報処理サーバ、及び貨幣情報処理方法
JP2007094615A (ja) * 2005-09-28 2007-04-12 Kokuyo Co Ltd 機器制御システム

Also Published As

Publication number Publication date
JPWO2009116415A1 (ja) 2011-07-21

Similar Documents

Publication Publication Date Title
KR101784219B1 (ko) 블록체인을 기반으로 하는 금융기관 제증명서류 위변조 검증시스템 및 방법
KR101637868B1 (ko) 블록체인을 기반으로 하는 금융기관 제증명서류 위변조 검증시스템 및 방법
KR101680540B1 (ko) 블록체인을 기반으로 하는 금융기관 제증명서류 위변조 검증시스템 및 방법
JP5721086B2 (ja) 電子マネーの管理方法
KR101155858B1 (ko) 전자 이체 시스템
US20120246075A1 (en) Secure electronic payment methods
KR20190028517A (ko) 트랜잭션 장치에 의한 디지털 자산 분산
US20090271321A1 (en) Method and system for verification of personal information
KR20030019466A (ko) 정보의 안전한 수집, 기억, 전송 방법 및 장치
JP2003510696A (ja) 不確定要素依存型支払いを含む電子取引をディレクトリ認証するとともに安全な電子銀行手形を介して実行する方法ならびにシステム
JP2018045540A (ja) 仮想通貨アドレスを含む預金口座情報開示システム
KR20190107601A (ko) 사용자 개시 연합 아이덴티티의 생성을 위한 방법 및 시스템
JP3982135B2 (ja) 予約証明証発行装置および方法
US20240095857A1 (en) Estate planning and beneficiary management system including digital assets
JPWO2008032821A1 (ja) データ送受信方法
CN112970234A (zh) 账户断言
KR102453918B1 (ko) 수출입 절차 자동화 시스템 및 그것의 제어 방법
US20120150710A1 (en) method and system for facilitating access to financial information
US11663590B2 (en) Privacy-preserving assertion system and method
WO2009116415A1 (ja) 電子的価値情報管理サーバ
JP4942245B2 (ja) クレジットカードを用いた決済処理方法
JP2002312707A (ja) クレジットカードを用いた決済処理方法
JP2000251146A (ja) Ｉｃカードを用いた電子チケッティング方法およびシステム
JP2011048782A (ja) 電子的価値情報管理サーバ及び電子的価値情報送受信方法
KR20200079931A (ko) 블록체인 네트워크를 활용한 전자티켓 발권 검증 방법

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: 09722500

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010503834

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09722500

Country of ref document: EP

Kind code of ref document: A1