US20020010749A1 - Message guaranty system - Google Patents

Message guaranty system Download PDF

Info

Publication number
US20020010749A1
US20020010749A1 US09/949,090 US94909001A US2002010749A1 US 20020010749 A1 US20020010749 A1 US 20020010749A1 US 94909001 A US94909001 A US 94909001A US 2002010749 A1 US2002010749 A1 US 2002010749A1
Authority
US
United States
Prior art keywords
evidence
message
server
reception
information
Prior art date
Legal status (The legal status 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 status listed.)
Abandoned
Application number
US09/949,090
Inventor
Yoko Saito
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to US09/949,090 priority Critical patent/US20020010749A1/en
Publication of US20020010749A1 publication Critical patent/US20020010749A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/085Payment architectures involving remote charge determination or related payment systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821Electronic credentials

Definitions

  • the present invention relates to a message guaranty system and, more particularly, to a message guaranty system capable of guaranteeing that messages have indeed been transmitted and received between terminals connected on a network system.
  • One such method involves having the transmitting and receiving workstations each manage a message start serial number and a message end serial number which are assigned to each message sent from one side to the other.
  • Another method requires establishing a sequence in which the receiving workstation returns an acknowledgement in response to each message received from the transmitting workstation.
  • the former conventional method (of managing message serial numbers) requires that four serial numbers, i.e., the message start and message end serial assigned to each of the transmitting and receiving terminals, coincide with one another before transmission or reception of any message.
  • the transmitting terminal transmits the message
  • the receiving terminal increments its message start serial number by 1.
  • the receiving terminal increments its message start serial number by 1.
  • the receiving terminal then processes the message.
  • the receiving terminal increments its message end serial number by 1 and returns an acknowledgement message to the transmitting terminal. Having received the acknowledgment message, the transmitting terminal increments its message end serial number by 1. This terminates the entire processing of message transmission/reception.
  • This kind of message serial number management is carried out under the NIF/OSI (Network Interface Feature/Open Systems Interconnection) protocol. If there occurs a serial number mismatch between the transmitting and the receiving terminal, an error is suspected to have occurred in the message processing.
  • the latter conventional method (of establishing an acknowledgement sequence) requires that the receiving terminal must always return an acknowledgement message (ACK) in response to the message sent from the transmitting terminal.
  • ACK acknowledgement message
  • the return of the ACK message is supposed to guarantee an error-free message transmission.
  • a further method is proposed by Japanese Patent Laid-open No. Hei 4-227154 (cited reference 1).
  • the proposed method involves furnishing a securely managed encryption key and a powerful encryption algorithm whereby the transmitting terminal furnishes the target message with a token constituting a collection of specific information.
  • the receiving terminal uses the same encryption key and algorithm, the receiving terminal prepares an authentication token (a collection of information for authentication purposes) by which the token of the received message is checked for authenticity. If any dispute occurs between the transmitting and receiving parties regarding the transmission or reception of a particular message, the two parties alone are responsible for resolving it.
  • the reliable third party delivers a message to its destination on behalf of the transmitting terminal, the transmission and reception of the message are carried out more securely than ever.
  • the inventive system acting as the thirty party effectively guarantees to any transmitting terminal both the transmission of the message in question and the reception thereof by the intended receiving terminal.
  • the inventive message guaranty system for use with a plurality of terminals connected on a network furnishes each message sent from a transmitting to a receiving terminal with evidence information which is prepared by a third party and which attests to the transmission and reception of the message, whereby the transmission of any disputed message by the transmitting terminal or the reception of that message by the receiving terminal is subsequently certified.
  • the evidence information includes the terminal name of the transmitting terminal (transmitter identifier), the terminal name of the receiving terminal (receiver identifier), time of message transmission, and the message length.
  • the message guaranty system of the invention comprises evidence information preparing means for having a reliable third party prepare evidence information attesting to the transmission and reception of any message within the network, and evidence information converting means for converting the evidence information into an encryption format or other suitable form that will thwart any unscrupulous attempts to forge or falsify that information.
  • the message guaranty system of the invention includes third party verification means for verifying the authenticity of evidence information about a particular message when such verification is requested by a plurality of terminals.
  • any message sent from the transmitting terminal to the receiving terminal is furnished with evidence information which, prepared by the reliable third party, attests to the transmission and reception of that message.
  • the highly reliable evidence information demonstrates unfailingly whether a particular message was actually delivered from one party to another. This feature facilitates the resolution of any message-related dispute between two contending parties.
  • the evidence information preparing means of the invention prepares evidence information on the basis of such message-related information as the terminal name of the transmitting terminal (transmitter identifier), the terminal name of the receiving terminal (receiver identifier), time of message transmission, and the message length. Analyzing this evidence information provides a highly accurate verdict on the disputed message.
  • the evidence information converting means of the invention converts the evidence information into an encryption format or other suitable form that will thwart any malicious or unscrupulous attempts to forge or falsify that information. This feature allows the inventive system to attest to the transmission and reception of any message with more certainty than ever.
  • FIG. 3 is a flowchart of steps constituting the process in which to prepare the evidence E 1 attesting to the transmission of the message M 1 ;
  • FIG. 4 is a flowchart of steps detailing what takes place in step 102 of FIG. 3;
  • FIG. 5 is a view illustrating the process in which the first embodiment verifies the evidence E 1 attesting to the transmission of the message M 1 ;
  • FIG. 6 is a flowchart of steps constituting the process in which to verify the evidence E 1 attesting to the transmission of the message M 1 ;
  • FIG. 8 is a view outlining the process in which the first embodiment prepares evidence E 2 attesting to the reception of the message M 1 ;
  • FIG. 9 is a flowchart of steps in which to prepare the evidence E 2 attesting to the reception of the message M 1 ;
  • FIG. 10 is a view illustrating the process in which the first embodiment verifies the evidence E 2 attesting to the reception of the message E 1 ;
  • FIG. 11 is a flowchart of steps constituting the process in which to verify the evidence E 2 attesting to the reception of the message E 1 ;
  • FIG. 13 is a view outlining the process in which the second embodiment prepares evidence E 3 attesting to the transmission of a message M 2 ;
  • FIG. 14 is a flowchart of steps in which to prepare the evidence E 3 attesting to the transmission of the message M 2 ;
  • FIG. 15 is a view illustrating the process in which the second embodiment verifies the evidence E 3 attesting to the transmission of the message M 2 ;
  • FIG. 16 is a flowchart of steps constituting the process in which to verify the evidence E 3 attesting to the transmission of the message M 2 ;
  • FIG. 17 is a view illustrating the process in which the second embodiment verifies evidence E 4 attesting to the reception of the message E 2 ;
  • FIG. 18 is a flowchart of steps constituting the process in which to verify the evidence E 4 attesting to the reception of the message M 2 ;
  • FIG. 19 is a view outlining the process in which the second embodiment prepares evidence attesting to the transmission of a message from a message control server 4 to a plurality of transmitting servers 40 through 42 ;
  • FIG. 20 is a flowchart of steps constituting the process in which to prepare the evidence attesting to the transmission of a message from the message control server 4 to the multiple transmitting servers 40 through 42 .
  • FIG. 1 is a schematic diagram of a message guaranty system practiced as a first embodiment of the invention and including a network system 1 .
  • the network 1 is connected with an evidence preparing server 2 , an evidence verifying server 3 , and workstations (each called a WS) 10 through 12 , 20 , and 30 through 32 .
  • the first embodiment is characterized in that the servers 2 and 3 are each constituted not by any configured workstation but by a reliable third party.
  • the first embodiment has the evidence preparing server 2 and the evidence verifying server 3 implemented separately for explanatory purposes, they may be integrated in a single server unit.
  • an application program (called an AP) 13 started on a WS 10 illustratively transmits a message M 1 to an AP 21 on a WS 20
  • the evidence preparing server 2 prepares evidence information (or simply called evidence) E 1 attesting to the transmission of the message M 1 from the AP 13 on the WS 10 to the AP 21 on the WS 20 . How the evidence preparing server 2 prepares the evidence E 1 will be described later in detail with reference to FIG. 4.
  • the WS 10 furnishes the target message M 1 with the evidence E 1 prepared by the evidence preparing server 2 and transmits the message along with the evidence to the WS 20 (to be described later with reference to FIG. 2).
  • the evidence verifying server 3 acts to verify the authenticity of the evidence information thus prepared. Such verification of evidence is generally conducted in case of a message processing discrepancy resulting in a dispute between, say, the WS 10 and the WS 20 . It is also possible for the WS 20 to request evidence verification upon receipt of the message M 1 along with the evidence E 1 .
  • One such example is that of FIG. 5, to be described later, in which the AP 21 on the WS 20 requests the evidence verifying server 3 to verify the authenticity of the evidence E 1 .
  • the server 2 checks to see if the request is valid (step 101 ). If the request is found to be valid, the evidence preparing server 2 accepts the message M 1 and prepares the evidence E 1 based on the message contents (step 102 ). The evidence preparing server 2 retains the evidence E 1 thus prepared (how to retain it is a local matter) and returns the same evidence to the WS 10 (step 103 ).
  • step 104 If the request made by the AP 13 is found to be invalid in step 101 , that request is reported to a security authority (step 104 ).
  • the security authority is provided on the network for the purpose of having overall control on message-related problems on the network.
  • the security authority is responsible for proper enforcement of security-related rules and regulations (i.e., security policy) within the management domain indicated in FIG. 1. If a security breach is detected within the management domain (in step 101 ), the evidence preparing server 2 must notify the security authority of that breach.
  • security policy security-related rules and regulations
  • the evidence preparing server 2 acquires from the WS 10 information comprising the message name, the transmitter identifier (identifying, e.g., WS 10 paired with AP 13 ), the receiver identifier (identifying, e.g., WS 20 paired with AP 21 ), the time of transmission of the message M 1 , and the length of the message M 1 (step 1021 ).
  • the evidence E 1 is prepared on the basis of these items of information.
  • the evidence preparing server 2 encrypts the evidence E 1 using an encryption algorithm known only to this server (step 1024 ).
  • the WS 10 furnishes the target message M 1 with evidence E 1 ′ (E(E 1 )) prepared by the evidence preparing server 2 , and transmits the message M 1 along with the evidence to the WS 20 .
  • the evidence verifying server 3 receives the message M 1 and checks to see if the evidence E 1 attached to the message M 1 is valid (step 201 ). If the evidence E 1 is found to be valid, the evidence verifying server 3 retains the evidence E 1 (how to retain it is a local matter) and returns the result of the verification to the WS 20 (step 202 ). If the evidence E 1 is found to be invalid in step 201 , the security authority is notified thereof (step 203 ).
  • step 201 The process in which the evidence verifying server 3 verifies the evidence E 1 (i.e., step 201 ) is depicted in more detail in FIG. 7.
  • the evidence preparing server 2 and the evidence verifying server 3 exist as different server units, it is necessary to install beforehand a common encryption algorithm in both servers. In that case, the evidence verifying server 3 needs to be supplied, in advance during the processing of FIG. 4, with the evidence E 1 prepared by the evidence preparing server 2 .
  • the evidence verifying server 3 checks to see if conversion (i.e., decryption) of the evidence E 1 attached to the message M 1 from the WS 20 is requested.
  • the evidence verifying server 3 decrypts the evidence E 1 using the encryption algorithm (steps 2011 and 2012 ).
  • the information contained in the decrypted evidence E 1 is then analyzed and checked against such items of information as the transmitter identifier (identifying, e.g., WS 10 paired with AP 13 ), the receiver identifier (identifying, e.g., WS 20 paired with AP 21 ), the time of transmission of the message M 1 , and the length of the message M 1 (step 2013 ).
  • the evidence verifying server 3 determines whether the evidence E 1 is valid as evidence information relevant to the message M 1 .
  • the evidence E 1 from the WS 20 may alternatively be checked against the evidence E 1 received directly from the evidence preparing server 2 (prepared in the processing of FIG. 4) for coincidence. The coincidence of the evidence from the two different sources should enable more accurate message verification.
  • the evidence verifying server 3 After step 202 , the evidence verifying server 3 returns to the WS 20 the result of verification of the evidence E 1 , and requests the evidence preparing server 2 to prepare information (herein called evidence E 2 ) attesting to the reception of the message M 1 by the WS 20 from the WS 10 .
  • the sequence in which to request the preparation of the evidence E 2 is shown in FIG. 8.
  • the evidence verifying server 3 first requests the evidence preparing server 2 to prepare the evidence E 2 attesting to the reception of the message M 1 by the WS 20 from the AP 13 on the WS 10 (step 301 ). In turn, the evidence preparing server 2 prepares the evidence E 2 attesting to that effect (step 302 ). Concrete steps to prepare the evidence E 2 comply with the processing of FIG. 4. It should be noted that in place of TM 1 (time of transmission of the message M 1 ), the time at which the WS 20 received the message M 1 is designated. The evidence preparing server 2 retains the evidence E 2 (how to retain it is a local matter) and returns the same evidence to the evidence verifying server 3 (step 303 ). The evidence verifying server 3 retains the received evidence E 2 along with the evidence E 1 stored previously (step 304 ).
  • the evidence verifying server 3 requests the evidence preparing server 2 to prepare the evidence E 2 in the above example
  • the AP 21 on the WS 20 may alternatively request the evidence preparing server 2 to prepare the evidence E 2 .
  • the evidence verifying server 3 receives the evidence E 1 from the WS 10 and checks to see if there exists evidence E 2 corresponding to the evidence E 1 (step 402 ). The evidence verifying server 3 then returns to the WS 10 the result of the verification attesting to the presence or the absence of the evidence E 2 (step 403 ). If the request is found to be invalid in step 401 , the security authority is notified thereof (step 404 ). If the result from the evidence verifying server 3 indicates the presence of the evidence E 2 corresponding to the evidence E 1 , the WS 10 knows that the WS 20 indeed received the message M 1 .
  • FIG. 12 is a schematic diagram of a message guaranty system practiced as the second embodiment of the invention and including a network system 1 .
  • the network 1 is connected with a message control server 4 , an evidence preparing server 2 , an evidence verifying server 3 , and workstations (WS) 10 through 12 , 20 , and 30 through 32 .
  • the second embodiment differs from the first embodiment in that the second includes the message control server 4 . The rest is the same as the first embodiment.
  • the message control server 4 provides control illustratively on the transmission and reception of messages between the AP 13 on the WS 10 and the AP 21 on the WS 20 , on the evidence preparing server 2 and on the evidence verifying server 3 .
  • the second embodiment has a plurality of servers implemented separately for explanatory purposes, they may be integrated in one or two server units.
  • the server 2 checks to see if that request is valid (step 501 ). If the request is found to be valid, the evidence preparing server 2 receives the message M 2 and prepares the evidence E 3 based on the message contents (step 502 ). The contents of the evidence E 3 are the same as those of the evidence E 1 and will not be described further. The evidence preparing server 2 retains the evidence E 3 thus prepared and returns the same evidence to the WS 10 (step 503 ).
  • the evidence verifying server 3 retains the evidence E 3 and returns the result of the verification to the message control server 4 (step 603 ).
  • the message control server 4 prepares management information MO for its own management, attaches the information MO to the message M 2 and transmits the same information to the WS 20 (step 604 ).
  • the management information MO serves as evidence information attesting to the fact that the message transmission from the WS 10 to the WS 20 is delegated to the message control server 4 .
  • the management information MO complies with the format determined by the message control server 4 .
  • the information includes such items as the transmitting terminal name, receiving terminal name, message ID, and ID of the message control server 4 .
  • the message control server 4 prepares information (called evidence E 4 ) attesting to the reception of the message M 2 by the WS 20 from the WS 10 (step 605 ).
  • the message control server 4 may get the evidence preparing server 2 to prepare the evidence E 4 .
  • the evidence E 4 thus prepared is sent to both the message control server 4 and the evidence verifying server 3 for storage.
  • the evidence verifying server 3 finds the evidence E 3 invalid following the receipt of the request for its verification, the evidence verifying server 3 notifies the security authority thereof (step 606 ).
  • the message control server 4 may additionally furnish the message with information for ascertaining the willingness on the part of the WS 20 to really perform the transaction.
  • step 701 the evidence verifying server 3 checks to see if that request is valid. If the request is found to be valid, the evidence verifying server 3 receives the evidence E 3 and verifies whether there exists evidence E 4 corresponding to the evidence E 3 (step 702 ). The result of the verification is returned to the WS 10 (step 703 ). If the request is found to be invalid in step 701 , the security authority is notified thereof (step 704 ).
  • the message control server 4 intervenes in the transmission of a message from the WS 10 to the WS 20 .
  • the message control server 4 prepares evidence attesting both to the message transmission from the transmitting terminal and to the message reception by the receiving terminal. This makes it impossible not only for the transmitting terminal to deny it ever issued the message M 2 ; it also makes it impossible for the receiving terminal to claim that it never received the message M 2 for such putative reasons as a network system error.
  • the above embodiments utilize encryption in preventing malicious or unscrupulous attempts to forge or falsify evidence information.
  • the hash function may be employed to provide against tampering.
  • the above embodiments use evidence information attesting to the transmission and reception of a message effected by the transmitting and the receiving terminal (WS 10 and WS 20 ), respectively.
  • An alternative embodiment may use security information for verifying the security of a message to be sent from the transmitting terminal to the receiving terminal.
  • the embodiment includes security information preparing means (corresponding to the evidence preparing server 2 ) for preparing security information attesting to the security of the message to be sent from the transmitting terminal, the preparation being effected upon receipt of a request for such security information.
  • the security information thus prepared is retained by the preparing means, and is also transmitted to the transmitting terminal.
  • any message sent from the transmitting terminal to the receiving terminal is furnished with evidence information which, prepared by the reliable third party, attests to the transmission and reception of that message.
  • the highly reliable evidence information demonstrates unfailingly whether a particular message was actually delivered from one party to another, thereby guaranteeing the security of the message in question. This feature permits accurate, discrepancy-free exchanges of messages between the parties concerned and facilitates the resolution of any message-related dispute therebetween.
  • the evidence information preparing means of the invention prepares evidence information on the basis of such message-related information as the transmitter identifier, the receiver identifier, the time of message transmission and the message length. Analyzing this evidence information provides a highly accurate verdict on the disputed message.
  • the evidence information converting means of the invention converts the evidence information into an encryption format or other suitable form that will thwart any malicious or unscrupulous attempts to forge or falsify that information. This feature allows the inventive system to attest to the transmission and reception of any message with more certainty than ever.
  • the delayed delivery means of the invention may be used to transmit a message along with its evidence information from the evidence server comprising that means directly to the receiving terminal on behalf of the transmitting terminal. Acting as it does, the delayed delivery means offers more secure delivery of messages between the transmitting and the receiving terminal.

Abstract

A message guaranty system for having a reliable third party (evidence preparing server) prepare evidence information attesting to the transmission and reception of a message by a transmitting and a receiving terminal. When the transmitting terminal furnishes the target message with evidence information before transmitting them to the destination, the system attests to the transmission and reception of that message once they are completed. When a message is to be sent illustratively from a workstation (WS) 1 to a workstation (WS) 2, the third-party evidence preparing server on the network first prepares transmission evidence based on a request from the WS 1 and sends it to the WS 1. The WS 1 sends the message along with the evidence to the WS 2. The evidence preparing server then prepares reception evidence based on a request from an evidence verifying server (a third party) acting for the WS 2. The reception evidence thus prepared is retained by the evidence preparing server and is also returned to the evidence varying server. The evidence verifying server retains the reception evidence. When an application program on the WS 1 requests verification of the reception evidence, the evidence verifying means verifies the presence of the reception evidence and returns the result of the verification to the WS 1.

Description

    BACKGROUND OF THE INVENTION
  • The present invention relates to a message guaranty system and, more particularly, to a message guaranty system capable of guaranteeing that messages have indeed been transmitted and received between terminals connected on a network system. [0001]
  • A number of conventional methods exist for guaranteeing the transmission and reception of messages between workstations connected on a network system. One such method involves having the transmitting and receiving workstations each manage a message start serial number and a message end serial number which are assigned to each message sent from one side to the other. Another method requires establishing a sequence in which the receiving workstation returns an acknowledgement in response to each message received from the transmitting workstation. [0002]
  • More specifically, the former conventional method (of managing message serial numbers) requires that four serial numbers, i.e., the message start and message end serial assigned to each of the transmitting and receiving terminals, coincide with one another before transmission or reception of any message. When the transmitting terminal transmits the message, the receiving terminal increments its message start serial number by 1. With the message received, the receiving terminal increments its message start serial number by 1. The receiving terminal then processes the message. With the message processing completed, the receiving terminal increments its message end serial number by 1 and returns an acknowledgement message to the transmitting terminal. Having received the acknowledgment message, the transmitting terminal increments its message end serial number by 1. This terminates the entire processing of message transmission/reception. This kind of message serial number management is carried out under the NIF/OSI (Network Interface Feature/Open Systems Interconnection) protocol. If there occurs a serial number mismatch between the transmitting and the receiving terminal, an error is suspected to have occurred in the message processing. [0003]
  • The latter conventional method (of establishing an acknowledgement sequence) requires that the receiving terminal must always return an acknowledgement message (ACK) in response to the message sent from the transmitting terminal. The return of the ACK message is supposed to guarantee an error-free message transmission. [0004]
  • A further method is proposed by Japanese Patent Laid-open No. Hei 4-227154 (cited reference 1). The proposed method involves furnishing a securely managed encryption key and a powerful encryption algorithm whereby the transmitting terminal furnishes the target message with a token constituting a collection of specific information. Using the same encryption key and algorithm, the receiving terminal prepares an authentication token (a collection of information for authentication purposes) by which the token of the received message is checked for authenticity. If any dispute occurs between the transmitting and receiving parties regarding the transmission or reception of a particular message, the two parties alone are responsible for resolving it. [0005]
  • The above conventional methods are effective in detecting mismatches in message processing but fail to provide for eventualities in which the transmitting or receiving party denies having transmitted or received a specific message. Although the system of the cited [0006] reference 1 provides high degrees of message authentication, the fact that any dispute is left to be resolved not by any reliable third party but only by the parties concerned does not make the system suitable for an open, distributed environment.
  • SUMMARY OF THE INVENTION
  • It is therefore an object of the present invention to overcome the above and other deficiencies and disadvantages of the prior art and to provide a message guaranty system having a third party intervene in the transmission and reception of a message by a transmitting and a receiving terminal, the system guaranteeing that every message it mediated was indeed transmitted by the transmitting terminal and received by the receiving terminal. This invention differs from that of the cited [0007] reference 1 in that this invention gets a reliable third party in a neutral position to prepare evidence information regarding each message handled and that any dispute is resolved by the third party verifying the authenticity of the evidence information about the message in question.
  • It is another object of the present invention to provide a message guaranty system offering a delayed delivery service that takes a message from a transmitting terminal and delivers the message to its destination on behalf of the transmitting terminal, the system verifying the authenticity of the evidence information regarding any message so delivered which may be disputed between a plurality of terminals. When the reliable third party delivers a message to its destination on behalf of the transmitting terminal, the transmission and reception of the message are carried out more securely than ever. The inventive system acting as the thirty party effectively guarantees to any transmitting terminal both the transmission of the message in question and the reception thereof by the intended receiving terminal. [0008]
  • In achieving the foregoing and other objects of the present invention, there is provided a message guaranty system featuring the following points: [0009]
  • (1) The inventive message guaranty system for use with a plurality of terminals connected on a network furnishes each message sent from a transmitting to a receiving terminal with evidence information which is prepared by a third party and which attests to the transmission and reception of the message, whereby the transmission of any disputed message by the transmitting terminal or the reception of that message by the receiving terminal is subsequently certified. [0010]
  • (2) The evidence information includes the terminal name of the transmitting terminal (transmitter identifier), the terminal name of the receiving terminal (receiver identifier), time of message transmission, and the message length. [0011]
  • (3) The message guaranty system of the invention comprises evidence information preparing means for having a reliable third party prepare evidence information attesting to the transmission and reception of any message within the network, and evidence information converting means for converting the evidence information into an encryption format or other suitable form that will thwart any unscrupulous attempts to forge or falsify that information. [0012]
  • (4) The message guaranty system of the invention includes, within the connected network, delayed delivery means for transmitting a message to the receiving terminal on behalf of the transmitting terminal when such transmission is requested by the latter, so as to ensure more secure delivery of that message. [0013]
  • (5) The message guaranty system of the invention includes third party verification means for verifying the authenticity of evidence information about a particular message when such verification is requested by a plurality of terminals. [0014]
  • In operation, the message guaranty system of the above constitution offers the following advantages: [0015]
  • (1) According to the invention, any message sent from the transmitting terminal to the receiving terminal is furnished with evidence information which, prepared by the reliable third party, attests to the transmission and reception of that message. The highly reliable evidence information demonstrates unfailingly whether a particular message was actually delivered from one party to another. This feature facilitates the resolution of any message-related dispute between two contending parties. [0016]
  • (2) The evidence information preparing means of the invention prepares evidence information on the basis of such message-related information as the terminal name of the transmitting terminal (transmitter identifier), the terminal name of the receiving terminal (receiver identifier), time of message transmission, and the message length. Analyzing this evidence information provides a highly accurate verdict on the disputed message. [0017]
  • (3) The evidence information converting means of the invention converts the evidence information into an encryption format or other suitable form that will thwart any malicious or unscrupulous attempts to forge or falsify that information. This feature allows the inventive system to attest to the transmission and reception of any message with more certainty than ever. [0018]
  • (4) As mentioned, any message sent from the transmitting terminal to the receiving terminal is equipped with evidence information which is prepared and converted by the evidence information preparing and converting means and which attests to the transmission and reception of that message. This evidence information demonstrates whether a particular message was actually delivered from one party to another. If more security is desired in delivering a message, the delayed delivery means of the invention is used to transmit a message along with its evidence information from an evidence server comprising that means directly to the receiving terminal on behalf of the transmitting terminal. Interposed between the transmitting and the receiving terminal, the delayed delivery means offers more secure delivery of messages therebetween and directly attests to the transmission and reception of any of the messages so delivered. [0019]
  • (5) If a message-related dispute occurs between a plurality of communicating terminals and if these terminals request verification of the evidence information regarding the disputed message, the verification means of the invention verifies the authenticity of the evidence information in question. [0020]
  • Other objects and advantages of the invention will become apparent from the examination of the present disclosure.[0021]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a schematic diagram of a message guaranty system practiced as a first embodiment of the invention; [0022]
  • FIG. 2 is a view outlining the process in which the first embodiment prepares evidence E[0023] 1 attesting to the transmission of a message M1;
  • FIG. 3 is a flowchart of steps constituting the process in which to prepare the evidence E[0024] 1 attesting to the transmission of the message M1;
  • FIG. 4 is a flowchart of steps detailing what takes place in [0025] step 102 of FIG. 3;
  • FIG. 5 is a view illustrating the process in which the first embodiment verifies the evidence E[0026] 1 attesting to the transmission of the message M1;
  • FIG. 6 is a flowchart of steps constituting the process in which to verify the evidence E[0027] 1 attesting to the transmission of the message M1;
  • FIG. 7 is a flowchart of steps detailing what takes place in [0028] step 201 of FIG. 6;
  • FIG. 8 is a view outlining the process in which the first embodiment prepares evidence E[0029] 2 attesting to the reception of the message M1;
  • FIG. 9 is a flowchart of steps in which to prepare the evidence E[0030] 2 attesting to the reception of the message M1;
  • FIG. 10 is a view illustrating the process in which the first embodiment verifies the evidence E[0031] 2 attesting to the reception of the message E1;
  • FIG. 11 is a flowchart of steps constituting the process in which to verify the evidence E[0032] 2 attesting to the reception of the message E1;
  • FIG. 12 is a schematic diagram of a message guaranty system practiced as a second embodiment of the invention; [0033]
  • FIG. 13 is a view outlining the process in which the second embodiment prepares evidence E[0034] 3 attesting to the transmission of a message M2;
  • FIG. 14 is a flowchart of steps in which to prepare the evidence E[0035] 3 attesting to the transmission of the message M2;
  • FIG. 15 is a view illustrating the process in which the second embodiment verifies the evidence E[0036] 3 attesting to the transmission of the message M2;
  • FIG. 16 is a flowchart of steps constituting the process in which to verify the evidence E[0037] 3 attesting to the transmission of the message M2;
  • FIG. 17 is a view illustrating the process in which the second embodiment verifies evidence E[0038] 4 attesting to the reception of the message E2;
  • FIG. 18 is a flowchart of steps constituting the process in which to verify the evidence E[0039] 4 attesting to the reception of the message M2;
  • FIG. 19 is a view outlining the process in which the second embodiment prepares evidence attesting to the transmission of a message from a [0040] message control server 4 to a plurality of transmitting servers 40 through 42; and
  • FIG. 20 is a flowchart of steps constituting the process in which to prepare the evidence attesting to the transmission of a message from the [0041] message control server 4 to the multiple transmitting servers 40 through 42.
  • DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • Preferred embodiments of the invention will now be described with reference to the accompanying drawings. FIG. 1 is a schematic diagram of a message guaranty system practiced as a first embodiment of the invention and including a [0042] network system 1. In FIG. 1, the network 1 is connected with an evidence preparing server 2, an evidence verifying server 3, and workstations (each called a WS) 10 through 12, 20, and 30 through 32. The first embodiment is characterized in that the servers 2 and 3 are each constituted not by any configured workstation but by a reliable third party. Although the first embodiment has the evidence preparing server 2 and the evidence verifying server 3 implemented separately for explanatory purposes, they may be integrated in a single server unit. When an application program (called an AP) 13 started on a WS 10 illustratively transmits a message M1 to an AP 21 on a WS 20, the evidence preparing server 2 prepares evidence information (or simply called evidence) E1 attesting to the transmission of the message M1 from the AP 13 on the WS 10 to the AP 21 on the WS 20. How the evidence preparing server 2 prepares the evidence E1 will be described later in detail with reference to FIG. 4.
  • The [0043] WS 10 furnishes the target message M1 with the evidence E1 prepared by the evidence preparing server 2 and transmits the message along with the evidence to the WS 20 (to be described later with reference to FIG. 2).
  • The [0044] evidence verifying server 3 acts to verify the authenticity of the evidence information thus prepared. Such verification of evidence is generally conducted in case of a message processing discrepancy resulting in a dispute between, say, the WS 10 and the WS 20. It is also possible for the WS 20 to request evidence verification upon receipt of the message M1 along with the evidence E1. One such example is that of FIG. 5, to be described later, in which the AP 21 on the WS 20 requests the evidence verifying server 3 to verify the authenticity of the evidence E1.
  • How the evidence E[0045] 1 for the message M1 is prepared will now be described with reference to FIG. 2 and to the flowchart of FIG. 3. When the AP 13 on the WS 10 requests the evidence preparing server 2 to prepare the evidence E1 for the message M1, the server 2 checks to see if the request is valid (step 101). If the request is found to be valid, the evidence preparing server 2 accepts the message M1 and prepares the evidence E1 based on the message contents (step 102). The evidence preparing server 2 retains the evidence E1 thus prepared (how to retain it is a local matter) and returns the same evidence to the WS 10 (step 103). If the request made by the AP 13 is found to be invalid in step 101, that request is reported to a security authority (step 104). The security authority is provided on the network for the purpose of having overall control on message-related problems on the network. The security authority is responsible for proper enforcement of security-related rules and regulations (i.e., security policy) within the management domain indicated in FIG. 1. If a security breach is detected within the management domain (in step 101), the evidence preparing server 2 must notify the security authority of that breach. The kind of security policy and the manner of implementing it, as well as ways to analyze security breaches, are not directly relevant to this invention and will not be discussed herein.
  • The process in which the [0046] evidence preparing server 2 prepares the evidence E1 (i.e., step 102) will now be described in more detail with reference to FIG. 4. The evidence preparing server 2 acquires from the WS 10 information comprising the message name, the transmitter identifier (identifying, e.g., WS 10 paired with AP 13), the receiver identifier (identifying, e.g., WS 20 paired with AP 21), the time of transmission of the message M1, and the length of the message M1 (step 1021). The evidence E1 is prepared on the basis of these items of information. If it is necessary to convert the evidence information into an encryption format immune to forgery or falsification (step 1023), the evidence preparing server 2 encrypts the evidence E1 using an encryption algorithm known only to this server (step 1024). The WS 10 furnishes the target message M1 with evidence E1′ (E(E1)) prepared by the evidence preparing server 2, and transmits the message M1 along with the evidence to the WS 20.
  • How the evidence E[0047] 1 of the message M1 is verified will now be described with reference to FIGS. 5 and 6. In response to a request by the AP 21 on the WS 20 for verification of the evidence E1, the evidence verifying server 3 receives the message M1 and checks to see if the evidence E1 attached to the message M1 is valid (step 201). If the evidence E1 is found to be valid, the evidence verifying server 3 retains the evidence E1 (how to retain it is a local matter) and returns the result of the verification to the WS 20 (step 202). If the evidence E1 is found to be invalid in step 201, the security authority is notified thereof (step 203).
  • The process in which the [0048] evidence verifying server 3 verifies the evidence E1 (i.e., step 201) is depicted in more detail in FIG. 7. Where the evidence preparing server 2 and the evidence verifying server 3 exist as different server units, it is necessary to install beforehand a common encryption algorithm in both servers. In that case, the evidence verifying server 3 needs to be supplied, in advance during the processing of FIG. 4, with the evidence E1 prepared by the evidence preparing server 2. The evidence verifying server 3 checks to see if conversion (i.e., decryption) of the evidence E1 attached to the message M1 from the WS 20 is requested. If such a request is found to have been made, the evidence verifying server 3 decrypts the evidence E1 using the encryption algorithm (steps 2011 and 2012). The information contained in the decrypted evidence E1 is then analyzed and checked against such items of information as the transmitter identifier (identifying, e.g., WS 10 paired with AP 13), the receiver identifier (identifying, e.g., WS 20 paired with AP 21), the time of transmission of the message M1, and the length of the message M1 (step 2013). With these items of information verified, the evidence verifying server 3 determines whether the evidence E1 is valid as evidence information relevant to the message M1. At this point, the evidence E1 from the WS 20 may alternatively be checked against the evidence E1 received directly from the evidence preparing server 2 (prepared in the processing of FIG. 4) for coincidence. The coincidence of the evidence from the two different sources should enable more accurate message verification.
  • After [0049] step 202, the evidence verifying server 3 returns to the WS 20 the result of verification of the evidence E1, and requests the evidence preparing server 2 to prepare information (herein called evidence E2) attesting to the reception of the message M1 by the WS 20 from the WS 10. The sequence in which to request the preparation of the evidence E2 is shown in FIG. 8.
  • How the evidence E[0050] 2 attesting to the reception of the message M1 is prepared will now be described with reference to FIGS. 8 and 9. It may happen that the system is so configured that the evidence preparing server 2 and evidence verifying server 3 are implemented in the same server unit. In that case, all exchanges between the two servers in FIGS. 8 and 9 can be omitted.
  • The [0051] evidence verifying server 3 first requests the evidence preparing server 2 to prepare the evidence E2 attesting to the reception of the message M1 by the WS 20 from the AP 13 on the WS 10 (step 301). In turn, the evidence preparing server 2 prepares the evidence E2 attesting to that effect (step 302). Concrete steps to prepare the evidence E2 comply with the processing of FIG. 4. It should be noted that in place of TM 1 (time of transmission of the message M1), the time at which the WS 20 received the message M1 is designated. The evidence preparing server 2 retains the evidence E2 (how to retain it is a local matter) and returns the same evidence to the evidence verifying server 3 (step 303). The evidence verifying server 3 retains the received evidence E2 along with the evidence E1 stored previously (step 304).
  • Although the [0052] evidence verifying server 3 requests the evidence preparing server 2 to prepare the evidence E2 in the above example, the AP 21 on the WS 20 may alternatively request the evidence preparing server 2 to prepare the evidence E2.
  • How to attest to the transmission and reception of a message will now be described with reference to FIGS. 10 and 11. FIG. 10 is a view illustrating the process in which the first embodiment verifies the evidence E[0053] 2 attesting to the reception of the message E1. If a message processing discrepancy occurs and results in a dispute between the WS 10 and the WS 20, the processing of FIG. 10 is generally carried out for verification. FIG. 11 is a flowchart of steps corresponding to the processing of FIG. 10. Given a request from the AP 13 on the WS 10 for verification of the evidence E2, the evidence verifying server 3 checks to see if the request is valid (step 401). If the request is found to be valid, the evidence verifying server 3 receives the evidence E1 from the WS 10 and checks to see if there exists evidence E2 corresponding to the evidence E1 (step 402). The evidence verifying server 3 then returns to the WS 10 the result of the verification attesting to the presence or the absence of the evidence E2 (step 403). If the request is found to be invalid in step 401, the security authority is notified thereof (step 404). If the result from the evidence verifying server 3 indicates the presence of the evidence E2 corresponding to the evidence E1, the WS 10 knows that the WS 20 indeed received the message M1.
  • A second embodiment of the invention will now be described with reference to FIGS. 12 through 20. FIG. 12 is a schematic diagram of a message guaranty system practiced as the second embodiment of the invention and including a [0054] network system 1. In FIG. 12, the network 1 is connected with a message control server 4, an evidence preparing server 2, an evidence verifying server 3, and workstations (WS) 10 through 12, 20, and 30 through 32. The second embodiment differs from the first embodiment in that the second includes the message control server 4. The rest is the same as the first embodiment. The message control server 4 provides control illustratively on the transmission and reception of messages between the AP 13 on the WS 10 and the AP 21 on the WS 20, on the evidence preparing server 2 and on the evidence verifying server 3. Although the second embodiment has a plurality of servers implemented separately for explanatory purposes, they may be integrated in one or two server units.
  • How to prepare evidence E[0055] 3 for a message M2 will now be described with reference to FIGS. 13 and 14. When the AP 13 on the WS 10 requests the evidence preparing server 2 to prepare the evidence E3 attesting to the transmission of the message M2 from the AP 13, the server 2 checks to see if that request is valid (step 501). If the request is found to be valid, the evidence preparing server 2 receives the message M2 and prepares the evidence E3 based on the message contents (step 502). The contents of the evidence E3 are the same as those of the evidence E1 and will not be described further. The evidence preparing server 2 retains the evidence E3 thus prepared and returns the same evidence to the WS 10 (step 503). Where the evidence preparing server 2 and the evidence verifying server 3 are separately implemented, the evidence preparing server 2 sends the evidence E3 to the evidence verifying server 3 as well. If the request by the AP 13 is found to be invalid in step 501, the security authority is notified thereof (step 504).
  • The [0056] WS 10 furnishes the message M2 with the evidence E3 prepared by the evidence preparing server 2 and transmits the message M2 along with the evidence E3 to the message control server 4. This procedure is effective where the transmission of a message from the WS 10 to the WS 20 is delegated to the message control server 4 to ensure higher levels of security.
  • FIG. 15 is a view illustrating the process in which the second embodiment verifies the evidence E[0057] 3 attesting to the transmission of the message M2. What takes place in the setup of FIG. 15 will be described below in more detail with reference to the flowchart of FIG. 16. The message control server 4 requests the evidence verifying server 3 to verify the evidence E3 (step 601). When so requested by the message control server 4, the evidence verifying server 3 checks to see if the evidence E3 attached to the message M3 is valid (step 602). The method of verifying the evidence E3 is the same as that of verifying the evidence E1 described with reference to FIG. 7 and will not be described further. If the result of the verification is correct, the evidence verifying server 3 retains the evidence E3 and returns the result of the verification to the message control server 4 (step 603). The message control server 4 prepares management information MO for its own management, attaches the information MO to the message M2 and transmits the same information to the WS 20 (step 604). The management information MO serves as evidence information attesting to the fact that the message transmission from the WS 10 to the WS 20 is delegated to the message control server 4. In that respect, the management information MO complies with the format determined by the message control server 4. Illustratively, the information includes such items as the transmitting terminal name, receiving terminal name, message ID, and ID of the message control server 4. Furthermore, with the message M2 delivered to the WS 20, the message control server 4 prepares information (called evidence E4) attesting to the reception of the message M2 by the WS 20 from the WS 10 (step 605). Where the servers 2, 3 and 4 are separately implemented, the message control server 4 may get the evidence preparing server 2 to prepare the evidence E4. The evidence E4 thus prepared is sent to both the message control server 4 and the evidence verifying server 3 for storage. On the other hand, if the evidence verifying server 3 finds the evidence E3 invalid following the receipt of the request for its verification, the evidence verifying server 3 notifies the security authority thereof (step 606).
  • For delivery of the message from the [0058] message control server 4 to the WS 20, the message control server 4 may additionally furnish the message with information for ascertaining the willingness on the part of the WS 20 to really perform the transaction.
  • FIG. 17 is a view illustrating the process in which the second embodiment verifies evidence E[0059] 4 attesting to the reception of the message E2. If a message processing discrepancy occurs and results in a dispute between the WS 10 and the WS 20, the processing of FIG. 17 is carried out for verification. What takes place in the setup of FIG. 17 will now be described in more detail with reference to the flowchart of FIG. 18. Although the evidence verifying server 3 is generally responsible for this verification process, the message control server 4 may take over the process instead. (FIGS. 17 and 18 show an example in which the message control server 4 carries out the verification process.) When the AP 13 on the WS 10 requests the evidence verifying server 3 to verify the evidence E4, the evidence verifying server 3 checks to see if that request is valid (step 701). If the request is found to be valid, the evidence verifying server 3 receives the evidence E3 and verifies whether there exists evidence E4 corresponding to the evidence E3 (step 702). The result of the verification is returned to the WS 10 (step 703). If the request is found to be invalid in step 701, the security authority is notified thereof (step 704).
  • FIG. 19 is a view outlining the process in which the second embodiment prepares evidence attesting to the transmission of a message from the [0060] message control server 4 to a plurality of transmitting servers 40 through 42. The processing of FIG. 19 is the same as that of FIG. 12 in terms of interposing the message control server 4 between the transmitting and the receiving terminal. What makes the processing of FIG. 19 different from that of FIG. 12 is that the former involves the use of a plurality of transmitting servers for the actual transmission and reception of messages. The message control server 4 must prepare evidence information upon verifying the transmission and reception of any message between these transmitting servers. What takes place in the setup of FIG. 19 will now be described with reference to the flowchart of FIG. 20. The message control server 4 transmits to transmitting servers 4 i (i=0−2) the message M2 furnished with the evidence E3 and management information MO (step 801). The transmitting servers 4 i are each a server with a transmitting and receiving (i.e., repeating) function and an evidence preparation and storage function. As such, the transmitting servers 4 i prepare evidence Ej (j=5−7) attesting to the transmission of the message and store that evidence (step 802). The evidence Ej thus prepared is returned to the message control server 4, and the message M2 is sent to the transmitting servers 4 i +1 (step 803). The message control server 4 prepares the evidence E4 based on the returned evidence Ej (step 804). The procedure above allows the message control server 4 to manage and verify in a comprehensive manner the routes through which the message M2 passed.
  • With the second embodiment, the transmitting terminal requests the receiving terminal to prepare and verify the evidence E[0061] 1 through evidence E3. Alternatively, the receiving terminal may request the transmitting terminal to do the same.
  • As described, the [0062] message control server 4 intervenes in the transmission of a message from the WS 10 to the WS 20. By way of such intervention, the message control server 4 prepares evidence attesting both to the message transmission from the transmitting terminal and to the message reception by the receiving terminal. This makes it impossible not only for the transmitting terminal to deny it ever issued the message M2; it also makes it impossible for the receiving terminal to claim that it never received the message M2 for such putative reasons as a network system error.
  • The above embodiments utilize encryption in preventing malicious or unscrupulous attempts to forge or falsify evidence information. Alternatively, the hash function may be employed to provide against tampering. [0063]
  • The above embodiments use evidence information attesting to the transmission and reception of a message effected by the transmitting and the receiving terminal ([0064] WS 10 and WS 20), respectively. An alternative embodiment may use security information for verifying the security of a message to be sent from the transmitting terminal to the receiving terminal. In that case, the embodiment includes security information preparing means (corresponding to the evidence preparing server 2) for preparing security information attesting to the security of the message to be sent from the transmitting terminal, the preparation being effected upon receipt of a request for such security information. The security information thus prepared is retained by the preparing means, and is also transmitted to the transmitting terminal. The embodiment further includes verifying means for verifying whether particular security information is valid upon receipt of a request from either the transmitting or the receiving terminal for verification of the security information in question. If the security information is found to be valid, that information is retained, and the other terminal is notified of the result of the verification.
  • Another alternative embodiment may comprise control means (corresponding to the message control server [0065] 4) for control on the exchanges of messages between a plurality of terminals, on the security information preparing means, and on the verifying means. The kinds of control involved pertain to the preparation of receipt information attesting to the reception of a message by the receiving terminal, to the request for the preparing means to prepare security information, and to the request for the verifying means to verify security information and exchange-related information.
  • As described, the message guaranty system according to the invention offers the following advantages: [0066]
  • (1) According to the message guaranty system of the invention, any message sent from the transmitting terminal to the receiving terminal is furnished with evidence information which, prepared by the reliable third party, attests to the transmission and reception of that message. The highly reliable evidence information demonstrates unfailingly whether a particular message was actually delivered from one party to another, thereby guaranteeing the security of the message in question. This feature permits accurate, discrepancy-free exchanges of messages between the parties concerned and facilitates the resolution of any message-related dispute therebetween. [0067]
  • (2) The evidence information preparing means of the invention prepares evidence information on the basis of such message-related information as the transmitter identifier, the receiver identifier, the time of message transmission and the message length. Analyzing this evidence information provides a highly accurate verdict on the disputed message. [0068]
  • (3) The evidence information converting means of the invention converts the evidence information into an encryption format or other suitable form that will thwart any malicious or unscrupulous attempts to forge or falsify that information. This feature allows the inventive system to attest to the transmission and reception of any message with more certainty than ever. [0069]
  • (4) The delayed delivery means of the invention may be used to transmit a message along with its evidence information from the evidence server comprising that means directly to the receiving terminal on behalf of the transmitting terminal. Acting as it does, the delayed delivery means offers more secure delivery of messages between the transmitting and the receiving terminal. [0070]
  • (5) If a message-related dispute occurs between a plurality of communicating terminals and if these terminals request verification of the evidence information regarding the disputed message, the verification means of the third party verifies the authenticity of the evidence information in question. [0071]
  • As many apparently different embodiments of this invention may be made without departing from the spirit and scope thereof, it is to be understood that the invention is not limited to the specific embodiments thereof except as defined in the appended claims. [0072]

Claims (5)

What is claimed is:
1. A message guaranty system connected with a plurality of terminals on a network, comprising:
message delivery means for delivering a message from a transmitting terminal to a receiving terminal;
evidence information preparing means for getting a third party to prepare evidence information attesting to the transmission and reception of said message; and
evidence information furnishing means for furnishing to said message said evidence information prepared by said evidence information preparing means.
2. A message guaranty system according to claim 1, wherein said evidence information preparing means includes converting means for converting said evidence information into a format immune to intentional tampering.
3. A message guaranty system according to claim 1, further comprising verifying means for verifying the authenticity of said evidence information when the verification thereof is requested.
4. A message guaranty system according to claim 1, further comprising delayed message delivery means for delivering said message directly to said receiving terminal on behalf of said transmitting terminal when said transmitting terminal requests said delivering of said message.
5. A message guaranty system according to any one of claims 1 through 3, wherein said evidence information comprises the terminal name of said transmitting terminal, the terminal name of said receiving terminal, the time of transmission of said message, and the length of said message.
US09/949,090 1993-10-27 2001-09-10 Message guaranty system Abandoned US20020010749A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US09/949,090 US20020010749A1 (en) 1993-10-27 2001-09-10 Message guaranty system

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
JP26859593 1993-10-27
JP05-268595 1993-10-27
JP06-48366 1994-03-18
JP6048366A JPH07177142A (en) 1993-10-27 1994-03-18 Message guarantee system
US08/328,885 US6115735A (en) 1993-10-27 1994-10-25 Message guaranty system
US09/592,667 US6289374B1 (en) 1993-10-27 2000-06-13 Message guaranty system
US09/949,090 US20020010749A1 (en) 1993-10-27 2001-09-10 Message guaranty system

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/592,667 Division US6289374B1 (en) 1993-10-27 2000-06-13 Message guaranty system

Publications (1)

Publication Number Publication Date
US20020010749A1 true US20020010749A1 (en) 2002-01-24

Family

ID=26388612

Family Applications (3)

Application Number Title Priority Date Filing Date
US08/328,885 Expired - Fee Related US6115735A (en) 1993-10-27 1994-10-25 Message guaranty system
US09/592,667 Expired - Fee Related US6289374B1 (en) 1993-10-27 2000-06-13 Message guaranty system
US09/949,090 Abandoned US20020010749A1 (en) 1993-10-27 2001-09-10 Message guaranty system

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US08/328,885 Expired - Fee Related US6115735A (en) 1993-10-27 1994-10-25 Message guaranty system
US09/592,667 Expired - Fee Related US6289374B1 (en) 1993-10-27 2000-06-13 Message guaranty system

Country Status (2)

Country Link
US (3) US6115735A (en)
JP (1) JPH07177142A (en)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1115666A (en) * 1997-06-10 1999-01-22 Internatl Business Mach Corp <Ibm> Computer system, message monitoring method and message transmission method
AU757557B2 (en) * 1997-11-13 2003-02-27 Intellectual Ventures I Llc File transfer system
CA2237678C (en) * 1998-05-14 2003-08-05 Ibm Canada Limited-Ibm Canada Limitee Secure flexible electronic submission acceptance system
AU6610300A (en) 1999-07-28 2001-02-19 Terrance A. Tomkow System and method for verifying delivery and integrity of electronic messages
US7966372B1 (en) 1999-07-28 2011-06-21 Rpost International Limited System and method for verifying delivery and integrity of electronic messages
JP2001273388A (en) * 2000-01-20 2001-10-05 Hitachi Ltd System and method for security management
JP2001282686A (en) * 2000-03-31 2001-10-12 Sony Corp System, device and method for communication content certification, and recording medium
US7080046B1 (en) 2000-09-06 2006-07-18 Xanboo, Inc. Method for amortizing authentication overhead
US7380126B2 (en) * 2001-06-01 2008-05-27 Logan James D Methods and apparatus for controlling the transmission and receipt of email messages
ATE444535T1 (en) * 2002-05-15 2009-10-15 Nxp Bv READER WITH PROTECTION AGAINST TRANSMISSION ERRORS
US7707624B2 (en) 2002-11-26 2010-04-27 Rpost International Limited System for, and method of, proving the transmission, receipt and content of a reply to an electronic message
US7698558B2 (en) * 2003-11-21 2010-04-13 Rpost International Limited System for, and method of, providing the transmission, receipt and content of an e-mail message
US7457955B2 (en) * 2004-01-14 2008-11-25 Brandmail Solutions, Inc. Method and apparatus for trusted branded email
EP2201737A2 (en) * 2007-10-20 2010-06-30 Penango, Inc. Methods and systems for indicating trustworthiness of secure communications
US20090113328A1 (en) * 2007-10-30 2009-04-30 Penango, Inc. Multidimensional Multistate User Interface Element
JP5045472B2 (en) * 2008-02-07 2012-10-10 富士通株式会社 Mail management apparatus, mail management method, and mail management program
US8478981B2 (en) 2008-02-27 2013-07-02 Rpost International Limited Method of adding a postscript message to an email
US9455992B2 (en) * 2009-06-12 2016-09-27 Microsoft Technology Licensing, Llc Trusted hardware component for distributed systems
US8527769B2 (en) * 2011-02-01 2013-09-03 Microsoft Corporation Secure messaging with read-undeniability and deletion-verifiability
US9160725B2 (en) 2011-09-23 2015-10-13 Rpost Communications Limited Computer implemented system and method for authenticating a sender of electronic data to a recipient
US8972732B2 (en) * 2012-12-12 2015-03-03 Microsoft Technology Licensing, Llc Offline data access using trusted hardware

Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4458109A (en) * 1982-02-05 1984-07-03 Siemens Corporation Method and apparatus providing registered mail features in an electronic communication system
US4837798A (en) * 1986-06-02 1989-06-06 American Telephone And Telegraph Company Communication system having unified messaging
US4885777A (en) * 1985-09-04 1989-12-05 Hitachi, Ltd. Electronic transaction system
US5018196A (en) * 1985-09-04 1991-05-21 Hitachi, Ltd. Method for electronic transaction with digital signature
US5022080A (en) * 1990-04-16 1991-06-04 Durst Robert T Electronic notary
US5136647A (en) * 1990-08-02 1992-08-04 Bell Communications Research, Inc. Method for secure time-stamping of digital documents
US5157726A (en) * 1991-12-19 1992-10-20 Xerox Corporation Document copy authentication
US5208858A (en) * 1990-02-05 1993-05-04 Siemens Aktiengesellschaft Method for allocating useful data to a specific originator
US5226079A (en) * 1990-11-09 1993-07-06 International Business Machines Corporation Non-repudiation in computer networks
US5303303A (en) * 1990-07-18 1994-04-12 Gpt Limited Data communication system using encrypted data packets
US5339361A (en) * 1992-12-04 1994-08-16 Texas Instruments Incorporated System and method for authenticating transmission and receipt of electronic information
US5349642A (en) * 1992-11-03 1994-09-20 Novell, Inc. Method and apparatus for authentication of client server communication
US5408642A (en) * 1991-05-24 1995-04-18 Symantec Corporation Method for recovery of a computer program infected by a computer virus
US5442708A (en) * 1993-03-09 1995-08-15 Uunet Technologies, Inc. Computer network encryption/decryption device
US5444782A (en) * 1993-03-09 1995-08-22 Uunet Technologies, Inc. Computer network encryption/decryption device
US5455407A (en) * 1991-11-15 1995-10-03 Citibank, N.A. Electronic-monetary system
US5497422A (en) * 1993-09-30 1996-03-05 Apple Computer, Inc. Message protection mechanism and graphical user interface therefor
US5502766A (en) * 1992-04-17 1996-03-26 Secure Computing Corporation Data enclave and trusted path system
US5621727A (en) * 1994-09-16 1997-04-15 Octel Communications Corporation System and method for private addressing plans using community addressing
US5916307A (en) * 1996-06-05 1999-06-29 New Era Of Networks, Inc. Method and structure for balanced queue communication between nodes in a distributed computing application

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US34954A (en) * 1862-04-15 Cord-windek
US5931961A (en) * 1996-05-08 1999-08-03 Apple Computer, Inc. Discovery of acceptable packet size using ICMP echo

Patent Citations (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4458109A (en) * 1982-02-05 1984-07-03 Siemens Corporation Method and apparatus providing registered mail features in an electronic communication system
US4885777A (en) * 1985-09-04 1989-12-05 Hitachi, Ltd. Electronic transaction system
US5018196A (en) * 1985-09-04 1991-05-21 Hitachi, Ltd. Method for electronic transaction with digital signature
US4837798A (en) * 1986-06-02 1989-06-06 American Telephone And Telegraph Company Communication system having unified messaging
US5208858A (en) * 1990-02-05 1993-05-04 Siemens Aktiengesellschaft Method for allocating useful data to a specific originator
US5022080A (en) * 1990-04-16 1991-06-04 Durst Robert T Electronic notary
US5303303A (en) * 1990-07-18 1994-04-12 Gpt Limited Data communication system using encrypted data packets
US5136647A (en) * 1990-08-02 1992-08-04 Bell Communications Research, Inc. Method for secure time-stamping of digital documents
USRE34954E (en) * 1990-08-02 1995-05-30 Bell Communications Research, Inc. Method for secure time-stamping of digital documents
US5226079A (en) * 1990-11-09 1993-07-06 International Business Machines Corporation Non-repudiation in computer networks
US5408642A (en) * 1991-05-24 1995-04-18 Symantec Corporation Method for recovery of a computer program infected by a computer virus
US5455407A (en) * 1991-11-15 1995-10-03 Citibank, N.A. Electronic-monetary system
US5157726A (en) * 1991-12-19 1992-10-20 Xerox Corporation Document copy authentication
US5502766A (en) * 1992-04-17 1996-03-26 Secure Computing Corporation Data enclave and trusted path system
US5349642A (en) * 1992-11-03 1994-09-20 Novell, Inc. Method and apparatus for authentication of client server communication
US5339361A (en) * 1992-12-04 1994-08-16 Texas Instruments Incorporated System and method for authenticating transmission and receipt of electronic information
US5444782A (en) * 1993-03-09 1995-08-22 Uunet Technologies, Inc. Computer network encryption/decryption device
US5442708A (en) * 1993-03-09 1995-08-15 Uunet Technologies, Inc. Computer network encryption/decryption device
US5497422A (en) * 1993-09-30 1996-03-05 Apple Computer, Inc. Message protection mechanism and graphical user interface therefor
US5621727A (en) * 1994-09-16 1997-04-15 Octel Communications Corporation System and method for private addressing plans using community addressing
US5916307A (en) * 1996-06-05 1999-06-29 New Era Of Networks, Inc. Method and structure for balanced queue communication between nodes in a distributed computing application

Also Published As

Publication number Publication date
JPH07177142A (en) 1995-07-14
US6289374B1 (en) 2001-09-11
US6115735A (en) 2000-09-05

Similar Documents

Publication Publication Date Title
US6289374B1 (en) Message guaranty system
US6408392B2 (en) Method and apparatus for providing configuration information in a network
US5774552A (en) Method and apparatus for retrieving X.509 certificates from an X.500 directory
US6732270B1 (en) Method to authenticate a network access server to an authentication server
US7457848B2 (en) Over-network resource distribution system and mutual authentication system
CN110572418B (en) Vehicle identity authentication method and device, computer equipment and storage medium
CN109413076B (en) Domain name resolution method and device
US20090144541A1 (en) Method and apparatus of mutual authentication and key distribution for downloadable conditional access system in digital cable broadcasting network
CN109191144A (en) A kind of laboratory information business management system and working method based on block chain
US20030018896A1 (en) Method, systems and computer program products for checking the validity of data
WO2000042730A1 (en) Seamless integration of application programs with security key infrastructure
CN107483415B (en) Bidirectional authentication method for shared electricity utilization interactive system
EP1493243B1 (en) Secure file transfer
WO1998035474A1 (en) Secure packet radio network
CN100377525C (en) Method for realizing stream medium business service
CN112667928A (en) Prefix and identification data secure subscription method and system based on Handle system
CN113992336B (en) Encryption network offline data trusted exchange method and device based on block chain
WO2013080039A2 (en) Auditable multiclaim security token
JPH1079732A (en) Network security system and method therefor
KR100837754B1 (en) Apparatus for Time and Contents Stamping for Electronic Notes and Method Thereof
US20060245594A1 (en) Mobile terminal and authentication method
CN112667929B (en) Prefix and identification data safe pushing method and system based on Handle system
US20050125658A1 (en) Information processing apparatus
CN113556365B (en) Authentication result data transmission system, method and device
KR100249850B1 (en) Proof of message delivery method using message verification

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION