CA2237678C - Secure flexible electronic submission acceptance system - Google Patents
Secure flexible electronic submission acceptance system Download PDFInfo
- Publication number
- CA2237678C CA2237678C CA002237678A CA2237678A CA2237678C CA 2237678 C CA2237678 C CA 2237678C CA 002237678 A CA002237678 A CA 002237678A CA 2237678 A CA2237678 A CA 2237678A CA 2237678 C CA2237678 C CA 2237678C
- Authority
- CA
- Canada
- Prior art keywords
- submission
- evidence
- directory
- completed
- submitter
- 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.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
- G06Q10/109—Time management, e.g. calendars, reminders, meetings or time accounting
-
- 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
- G06Q99/00—Subject matter not provided for in other groups of this subclass
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
Abstract
In an electronic filing system over a computer network, a central server sets the requirements for making submissions. These requirements include a time limit after the expiry of which, submissions will no longer be accepted. A gateway server polls the central server for the submission requirements, and establishes a directory in its own file system to which all potential submitters have write access until expiry of the time limit. On completion of its submission, a submitter generates evidence of the complete submission. The evidence can be in the form of a message digest. The submitter encrypts the evidence using the gateway server's public encryption key and then forwards the encrypted evidence to the gateway server. If the evidence is filed before expiry of the time limit, the gateway server permits the evidence to be written to the directory established for the submission requirements. Once the submitter has successfully filed its evidence, it can forward the complete submission to the gateway server. When the gateway server receives the complete submission, it decrypts the evidence, it may check the submitter's digital signature on the evidence, and it then compares the complete submission with the evidence. If the evidence is a message digest, the gateway server computes a message digest of the complete submission. If the two digests are identical, then it is clear that the submission was completed when the evidence was filed, before expiry of the deadline, and the gateway server can then forward the submission on to the central server.
Description
A SECURE FLEXIBLE ELECTRONIC SUBMISSION ACCEPTANCE SYSTEM
Field of the Invention This invention is in the area of electronic information transmission, and provides a time-sensitive document submission system in which the submitter receives immediate verification whether the submission has been made in time.
Background of the Invention As the Internet becomes a more reliable and accepted transmission medium, it can be used for all types of information interchange.
For example, US Patent No. 5,694,546 - Reisman describes a system for mass distribution by electronic transmission of information, such as periodicals. Using a current customer manifest, the server automates transmission of current issues and updates of the periodical information, and verifies with the customer that the transmission has been received in its entirety. Updating the customer's records can be totally automatic, or, as discussed in a preferred embodiment example in the patent, the customer's system clock can be monitored, and the customer alerted to the arrival of an update release date so that the customer can confirm that the system should seek and fetch the scheduled update, if available.
Another use of electronic transmission is for filing information to meet time deadlines. It is this. use to which the present invention is directed.
An example of time-sensitive filing is commercial tenders. An invitation to tender electronically is usually not different from more traditional formats; a non-extendible submission deadline is set for receipt of sealed bids, and only those tenders filed by the deadline are considered.
0l;her examples. of time-sensitive information submissions include:
~ applications for enrollment, ~ submission of educational assignments and examinations, ~ comments in response to requests for proposals, and ~ purchase orders that must be received before expiry of a fiscal period.
By using electronic transmission to send information that is time-sensitive (as well as non-time sensitive infornaation), the user is able to transmit, with certainty, the required information over a great distance in a short time, usually not exceeding a few hours. Compression technology permits lengthy documents to be sent. Encryption technology provides security where the information transmitted electronically is commercially sensitive or confidential.
Where the film~; of a submission must meet a time limit or deadline, the receiving server cannot rely oru the submitter's clock for controlling the submission gate because it is impossible to ensure the accuracy of the sender's clock, and, in a competitive situation, it is impossible to synchronize the clocks of all senders to ensure fairness.
However, the submitter usually wants to know as soon as possible whether a submission has met the tune limit and been accepted for filing. There are a number of alternate techniques, known in the art, to try to retiarn this type of information to the sender.
One technique is to enable the submitting application to try to check the date on-the-fly, while the submitter is still connected. However, this can be an expensive solution, particularly if database access is involved.
Another solution is to have the receiving processor check the submission at "submission time" to C.A9-98-009 de;termine whether the document is on time, and to return a message to the submitter as soon as the check is complete. Implementing this solution requires that the processor receiving submissions filed to meet a deadline, have an active agent to respond to each submission at the time that document arnves. It is difficult to implement this technique universally because:
1. Some environments do not readily provide an active agent to immediately process documents on arrival; and 2. Some servers may not have the processing capability required for the actions of active I 0 agents, particul~~rly where an invitation to tender is available to a wide constituency. As the deadline drew near, the volume of documents arriving could be huge. A scheme that requires active processing and checking of the arriving documents around that time would require corresponding "huge" performance from the processor. If the processor was able to process and respond on only some submissions, then the system would be unfair to submitters of those submissions that were 1 S missed by the processor.
If, in the above scheme, the receiving processor merely received and time stamped all documents for later checking for compliance with the deadline, the processing performance problem would be addressed, but no immediate feedback (deadline verification) would be provided to the submitter.
Another technique is to disable the receiving mechanism when the deadline arrives. However, this is extremely complex to implement because at the deadline time, there could be a huge backlog of files at different states and at different queues inside the system; some files being received, some avvaiting "connection open", etc. The system may not have a clean way of allowing the receiving application to chop off a queue. If disabling the receiving mechanism must wait until all queues are clear, the waiting time could be very unpredictable as files kept coming in to re-fill the queues. The deadline would lose its definition, and would not be the same for all submissions.
Field of the Invention This invention is in the area of electronic information transmission, and provides a time-sensitive document submission system in which the submitter receives immediate verification whether the submission has been made in time.
Background of the Invention As the Internet becomes a more reliable and accepted transmission medium, it can be used for all types of information interchange.
For example, US Patent No. 5,694,546 - Reisman describes a system for mass distribution by electronic transmission of information, such as periodicals. Using a current customer manifest, the server automates transmission of current issues and updates of the periodical information, and verifies with the customer that the transmission has been received in its entirety. Updating the customer's records can be totally automatic, or, as discussed in a preferred embodiment example in the patent, the customer's system clock can be monitored, and the customer alerted to the arrival of an update release date so that the customer can confirm that the system should seek and fetch the scheduled update, if available.
Another use of electronic transmission is for filing information to meet time deadlines. It is this. use to which the present invention is directed.
An example of time-sensitive filing is commercial tenders. An invitation to tender electronically is usually not different from more traditional formats; a non-extendible submission deadline is set for receipt of sealed bids, and only those tenders filed by the deadline are considered.
0l;her examples. of time-sensitive information submissions include:
~ applications for enrollment, ~ submission of educational assignments and examinations, ~ comments in response to requests for proposals, and ~ purchase orders that must be received before expiry of a fiscal period.
By using electronic transmission to send information that is time-sensitive (as well as non-time sensitive infornaation), the user is able to transmit, with certainty, the required information over a great distance in a short time, usually not exceeding a few hours. Compression technology permits lengthy documents to be sent. Encryption technology provides security where the information transmitted electronically is commercially sensitive or confidential.
Where the film~; of a submission must meet a time limit or deadline, the receiving server cannot rely oru the submitter's clock for controlling the submission gate because it is impossible to ensure the accuracy of the sender's clock, and, in a competitive situation, it is impossible to synchronize the clocks of all senders to ensure fairness.
However, the submitter usually wants to know as soon as possible whether a submission has met the tune limit and been accepted for filing. There are a number of alternate techniques, known in the art, to try to retiarn this type of information to the sender.
One technique is to enable the submitting application to try to check the date on-the-fly, while the submitter is still connected. However, this can be an expensive solution, particularly if database access is involved.
Another solution is to have the receiving processor check the submission at "submission time" to C.A9-98-009 de;termine whether the document is on time, and to return a message to the submitter as soon as the check is complete. Implementing this solution requires that the processor receiving submissions filed to meet a deadline, have an active agent to respond to each submission at the time that document arnves. It is difficult to implement this technique universally because:
1. Some environments do not readily provide an active agent to immediately process documents on arrival; and 2. Some servers may not have the processing capability required for the actions of active I 0 agents, particul~~rly where an invitation to tender is available to a wide constituency. As the deadline drew near, the volume of documents arriving could be huge. A scheme that requires active processing and checking of the arriving documents around that time would require corresponding "huge" performance from the processor. If the processor was able to process and respond on only some submissions, then the system would be unfair to submitters of those submissions that were 1 S missed by the processor.
If, in the above scheme, the receiving processor merely received and time stamped all documents for later checking for compliance with the deadline, the processing performance problem would be addressed, but no immediate feedback (deadline verification) would be provided to the submitter.
Another technique is to disable the receiving mechanism when the deadline arrives. However, this is extremely complex to implement because at the deadline time, there could be a huge backlog of files at different states and at different queues inside the system; some files being received, some avvaiting "connection open", etc. The system may not have a clean way of allowing the receiving application to chop off a queue. If disabling the receiving mechanism must wait until all queues are clear, the waiting time could be very unpredictable as files kept coming in to re-fill the queues. The deadline would lose its definition, and would not be the same for all submissions.
Another alternative is to require a positive two-way handshake process between sender and receiver before the submitting program begins to file the submission, such as described in the above-referenced US Patent No. 5,694,546. As described in the patent, the protocol used for the handshaking is relatively complex; it identifies the customer's transporter client system to the remote server (that will issue the periodical information) by product ID and user ID, and a password or other authentication code for the transporter log file. This technique also requires an active agent on the receiver side, s~o that the performance problems discussed above associated with active agents at deadline time could result in added problems if processor performance prevented establishing the handshake, so that the submitting program could not make the submission at all.
Previously filed Canadian Patent Application No. 2,228,331, titled "A Token-Based Deadline Enforcement System for Electronic Document Submission" (IBM Docket No. CA9-98-003), which is commonly assigned, provides a type of solution that does not depend on active agents, such as discussed above. Instead, a submission requirements centre collects information on submission requirements (eg., deadlines for submitting bids in response to commercial tenders), from the processing environments that generate the requirements. A gateway to a network of potential submitters polls the information collected in the submission requirements centre, and generates tokens corresponding to current submission time limits. These tokens are available to all potential submitters until expiry of the corresponding time limit for the submission. On receiving a request for electronic submission from a submitting program, the gateway searches its records for the token corresponding to the submission type. If the token is located, it is returned to the submitting program for packaging with the submission. If the token is not located, an electronic message, such as an error flag, is returned to the submitting program, and the submitter knows immediately that the submission did not meet the deadline. When a submission packaged with a valid token is received at the gateway, :it can be routed directly to the processing environment that generated the submission requirement. 'The valid token provides an on-time validity check; the receiving processing environment does not have to check the submission as it arnves to ensure that it has been filed on C.A9-98-009 time, but can delay processing to a convenient time, to verify compliance with substantive requirements for filing the submission. Thus, no processing is required for the documents when they arrive, yet the system provides the submitter with immediate feedback whether the submission has been accepted fir filing within the deadline. The possible performance problems in trying to process "tame of filing" for a large number of submissions filed virtually simultaneously as the submission deadline draws near, are avoided, and the submitter is saved network access costs in waiting for a verification of riling to be returned.
Summary of the Invention The present invention addresses the prior art issues (alleviating electronic transmission delays that could cause a submission to miss a deadline, and providing a submitter with rapid feedback whether a submission has been accepted for filing or not) in a different way.
The present invention provides a scheme to allow a submitter to "commit and lock-in" a submission completed before expiry of a deadline, in a very efficient manner.
The present invention provides many of the same advantages as those discussed in relation to the invention of our earlier filed token-based submission system. However, the present invention is particularly useful in the case of large electronic submission documents, that could be subject to delay in transmission, although it is clearly also useful for submitting smaller submissions as well.
As long as the submitter is able to submit, before expiry of the submission deadline, a small token or digest, as discussed in detail below, the system guarantees that the full submission will eventually be accepted, and that the eventual fizll submission is identical to the submission from which evidence w;~s presented.
Therefore, the present invention provides a method for enforcing time limits in a gateway server in an electronic filing system in which an electronic message containing evidence of submission C,A9-98-009 completion, such as a message digest, is received from a submitting program. A
directory having an unexpired submission time limit for storing the evidence is identified, and the evidence is stored in it. Ifno directory is identified, a first submission rejection indication is returned to the submitting program. On receipt of the complete submission, the complete submission is matched with the evidence filed in the directory, preferably by computing a message digest of the complete submission and comparing it to the evidence on file. If the complete submission does not match, a second submission rejection indication is returned to the submitting program.
Preferably, write access to the directory is removed once the submission time limit expires.
The invention also provides a gateway mechanism for enforcing time limits for filing electronic submissions in a network. 'The mechanism enables a server in the gateway mechanism to receive information related to a submission time limit from a submission processing environment and generate a storage directory in the server's file system with write access for all potential submitters within the submission time limit. The mechanism is enabled to (i) receive an electronic message containing evidence of submission completion from a submitter, (ii) verify write access to the storage directory, and (iii) i f the write access is verified, write the evidence to the storage directory, or else return an error indication to the submitter.
The mechanism is also enabled to remove the write access to the storage directory on expiry of the submission time limit, and match a complete submission received from the submitter with the evidence written to the storage directory, or else return an error indication to the submitter.
Preferably, the mechanism's means to match a complete submission with the evidence written to the storage directory include decrypting the evidence (if received in encrypted form) and verifying the submitter's digiaal signature, and transforming the complete submission to the same format as the evidence (for example, message digest), to compare that the transformed versions are identical.
Previously filed Canadian Patent Application No. 2,228,331, titled "A Token-Based Deadline Enforcement System for Electronic Document Submission" (IBM Docket No. CA9-98-003), which is commonly assigned, provides a type of solution that does not depend on active agents, such as discussed above. Instead, a submission requirements centre collects information on submission requirements (eg., deadlines for submitting bids in response to commercial tenders), from the processing environments that generate the requirements. A gateway to a network of potential submitters polls the information collected in the submission requirements centre, and generates tokens corresponding to current submission time limits. These tokens are available to all potential submitters until expiry of the corresponding time limit for the submission. On receiving a request for electronic submission from a submitting program, the gateway searches its records for the token corresponding to the submission type. If the token is located, it is returned to the submitting program for packaging with the submission. If the token is not located, an electronic message, such as an error flag, is returned to the submitting program, and the submitter knows immediately that the submission did not meet the deadline. When a submission packaged with a valid token is received at the gateway, :it can be routed directly to the processing environment that generated the submission requirement. 'The valid token provides an on-time validity check; the receiving processing environment does not have to check the submission as it arnves to ensure that it has been filed on C.A9-98-009 time, but can delay processing to a convenient time, to verify compliance with substantive requirements for filing the submission. Thus, no processing is required for the documents when they arrive, yet the system provides the submitter with immediate feedback whether the submission has been accepted fir filing within the deadline. The possible performance problems in trying to process "tame of filing" for a large number of submissions filed virtually simultaneously as the submission deadline draws near, are avoided, and the submitter is saved network access costs in waiting for a verification of riling to be returned.
Summary of the Invention The present invention addresses the prior art issues (alleviating electronic transmission delays that could cause a submission to miss a deadline, and providing a submitter with rapid feedback whether a submission has been accepted for filing or not) in a different way.
The present invention provides a scheme to allow a submitter to "commit and lock-in" a submission completed before expiry of a deadline, in a very efficient manner.
The present invention provides many of the same advantages as those discussed in relation to the invention of our earlier filed token-based submission system. However, the present invention is particularly useful in the case of large electronic submission documents, that could be subject to delay in transmission, although it is clearly also useful for submitting smaller submissions as well.
As long as the submitter is able to submit, before expiry of the submission deadline, a small token or digest, as discussed in detail below, the system guarantees that the full submission will eventually be accepted, and that the eventual fizll submission is identical to the submission from which evidence w;~s presented.
Therefore, the present invention provides a method for enforcing time limits in a gateway server in an electronic filing system in which an electronic message containing evidence of submission C,A9-98-009 completion, such as a message digest, is received from a submitting program. A
directory having an unexpired submission time limit for storing the evidence is identified, and the evidence is stored in it. Ifno directory is identified, a first submission rejection indication is returned to the submitting program. On receipt of the complete submission, the complete submission is matched with the evidence filed in the directory, preferably by computing a message digest of the complete submission and comparing it to the evidence on file. If the complete submission does not match, a second submission rejection indication is returned to the submitting program.
Preferably, write access to the directory is removed once the submission time limit expires.
The invention also provides a gateway mechanism for enforcing time limits for filing electronic submissions in a network. 'The mechanism enables a server in the gateway mechanism to receive information related to a submission time limit from a submission processing environment and generate a storage directory in the server's file system with write access for all potential submitters within the submission time limit. The mechanism is enabled to (i) receive an electronic message containing evidence of submission completion from a submitter, (ii) verify write access to the storage directory, and (iii) i f the write access is verified, write the evidence to the storage directory, or else return an error indication to the submitter.
The mechanism is also enabled to remove the write access to the storage directory on expiry of the submission time limit, and match a complete submission received from the submitter with the evidence written to the storage directory, or else return an error indication to the submitter.
Preferably, the mechanism's means to match a complete submission with the evidence written to the storage directory include decrypting the evidence (if received in encrypted form) and verifying the submitter's digiaal signature, and transforming the complete submission to the same format as the evidence (for example, message digest), to compare that the transformed versions are identical.
C.A9-98-009 The invention also provides a computer program product comprising a computer usable medium having computer readable program code means embodied therein for enforcing time limits in an electronic filing; system.
Brief Description of the Drawings Embodiments of the invention will now be described in detail in association with the accompanying drawings, in which:
Figures lA to 1C are schematic representations of a flexible electronic submission acceptance system, according to preferred embodiments of the invention;
Figure 2A is a flow diagram setting forth the steps for creating, and subsequently disabling, a directory in the Gateway mechanism for receiving "evidence" of submission completion in a Windows NT~ environment, according to one aspect of the invention;
Figures 2B is a flow diagram, similar to Figure 2A, setting forth a special routine for disabling the submitters' ability to drop off evidence, particularly applicable to UNIX~-based systems;
Figures 3A and 3B are flow diagrams setting forth alternate methods for submission and verification of'submission readiness evidence, according to the invention; and Figure 4 is a flow diagram setting forth the steps for filing a submission, following completion of the method in either Figure 3A or 3B.
Detailed Description of the Preferred Embodiments A flexible electronic submission acceptance system, according to the invention, comprises the basic components illustrated schematically in Figure 1. Figures 1 A and 1 B
illustrate alternate simplified systems with a single representation of each component discussed in relation to the system; Figure 1 (: illustrates a larger and more complex system of the same type.
RE:fernng first to Figure 1A, a Submissions Processor 10 is an entity that creates and generates the requirements for a submission, assigns the submission type and sets the deadline for receiving submissions intended to meet the requirements. As will become more apparent in relation to Figure 1 C, the Submissions Processor 10 that creates the requirements for a particular submission type, is also the entity treat receives the submissions filed to respond to the requirements, and processes those submissions, assuming that the submissions that reach it have been filed by the deadline.
Continuing with Figure 1A, the Submission Requirements Centre 12 is a server that collects information about all upcoming current submission requirements, the corresponding deadlines and the expected submission type. Generally, this information is collected at the Submissions Requirements Centre 12 when the Submissions Processor 10 generates a new set of requirements and transmits the set to the Submission Requirements Centre 12 via transmission 1. At the same tune, the existence of the requirements (such as an invitation to tender) is publicised to the prospective submitters via transmission 2.
The Submissior.~s Requirements Centre 12 makes the submission requirements information available to another component called the Electronic Submissions Gateway 14. This can happen when the Gateway 14 polls 3 the Submission Requirements Centre 12 for new submissions of a specific type.
In response, the: Centre 14 transmits 4 the new set of requirements.
The Electronic Submissions Gateway 14 is the server that interfaces 5, 6, 7 directly with submitting pr~grams 18 used by end users for filing their submissions. After the Gateway 14 determines that a submission came before the corresponding deadline following the invention described herein, it routes 8 the submission to the appropriate Submissions Processor 10.
Brief Description of the Drawings Embodiments of the invention will now be described in detail in association with the accompanying drawings, in which:
Figures lA to 1C are schematic representations of a flexible electronic submission acceptance system, according to preferred embodiments of the invention;
Figure 2A is a flow diagram setting forth the steps for creating, and subsequently disabling, a directory in the Gateway mechanism for receiving "evidence" of submission completion in a Windows NT~ environment, according to one aspect of the invention;
Figures 2B is a flow diagram, similar to Figure 2A, setting forth a special routine for disabling the submitters' ability to drop off evidence, particularly applicable to UNIX~-based systems;
Figures 3A and 3B are flow diagrams setting forth alternate methods for submission and verification of'submission readiness evidence, according to the invention; and Figure 4 is a flow diagram setting forth the steps for filing a submission, following completion of the method in either Figure 3A or 3B.
Detailed Description of the Preferred Embodiments A flexible electronic submission acceptance system, according to the invention, comprises the basic components illustrated schematically in Figure 1. Figures 1 A and 1 B
illustrate alternate simplified systems with a single representation of each component discussed in relation to the system; Figure 1 (: illustrates a larger and more complex system of the same type.
RE:fernng first to Figure 1A, a Submissions Processor 10 is an entity that creates and generates the requirements for a submission, assigns the submission type and sets the deadline for receiving submissions intended to meet the requirements. As will become more apparent in relation to Figure 1 C, the Submissions Processor 10 that creates the requirements for a particular submission type, is also the entity treat receives the submissions filed to respond to the requirements, and processes those submissions, assuming that the submissions that reach it have been filed by the deadline.
Continuing with Figure 1A, the Submission Requirements Centre 12 is a server that collects information about all upcoming current submission requirements, the corresponding deadlines and the expected submission type. Generally, this information is collected at the Submissions Requirements Centre 12 when the Submissions Processor 10 generates a new set of requirements and transmits the set to the Submission Requirements Centre 12 via transmission 1. At the same tune, the existence of the requirements (such as an invitation to tender) is publicised to the prospective submitters via transmission 2.
The Submissior.~s Requirements Centre 12 makes the submission requirements information available to another component called the Electronic Submissions Gateway 14. This can happen when the Gateway 14 polls 3 the Submission Requirements Centre 12 for new submissions of a specific type.
In response, the: Centre 14 transmits 4 the new set of requirements.
The Electronic Submissions Gateway 14 is the server that interfaces 5, 6, 7 directly with submitting pr~grams 18 used by end users for filing their submissions. After the Gateway 14 determines that a submission came before the corresponding deadline following the invention described herein, it routes 8 the submission to the appropriate Submissions Processor 10.
C.A9-98-009 Figure 1 B schematically illustrates an embodiment of the invention which could be implemented for a commercial tendering system for a large organisation. In this embodiment, the Submissions Processor 10 is a master buyer server operating under a Microsoft Windows NT
operating system to collect purchase requisitions from inside the organisation. The Electronics Submission Gateway 14a is a document information gateway operating under an IBM RS/6000~
operating system. In this embodiment, the Gateway 14a, itself, is the repository of information about current submission requirements from the Submission Processor 10. The Gateway 14a has a Submission Rexluirements camponent 12a that interfaces directly with the Submissions Processor 10 to collect this information, and to make it available internally, to ather components of the Gateway 14a.
The Submission Requirements component 12a also includes a tender bulletin board, preferably on a secure website, to notify external parties (i.e., potential suppliers) of calls for tender.
The potential suppliers make bid submissions to the system via submitting programs 18 operating on PC
operating systems with network/Internc;t access, such as IBM OS/2~ Warp, Microsoft Windows~ 95, etc.
Cammunications between the master buyer server/Submissions Processor 10 and Gateway 14a is handled by an C>S/2 Message Router 24 located in the Gateway 14a. The Submissions Processor 10 automatically wraps outgoing messages and unwraps incoming messages in order to ensure data integrity. Similarly, the Message Router 24 automatically wraps and unwraps messages going to and from the Submissions Processor 10. Messages within the Gateway environment, for example from the Message Router 24 to the Submission Requirements component 12a or between the Submission Requirements component 12a and other components in the Gateway 14a, are not wrapped.
The Gateway 14a has a firewall that protects it from the external network.
Communications with suppliers are handled by a security module 26 which automatically builds a secure structure before forwarding a message to a supplier over the network, and unpacks the secure structures it receives from the network in order to forward plain messages to other components in the Gateway 14a to process. The secure structure packages the token together with the submission in a single structure.
As discussed below, both the submitting program 18 and Gateway 14 may use message digest, or a similar technology, to lock in a proposed submission. Encryption and digital signature technologies may also be used to assure integrity, privacy, authentication, and non-repudiation of messages and submissions over the open network.
As Figure 1 C shows, the Submission Requirements Centre 12 can collect information on new requirements for multiple Submissions Processors 10, and can make those requirements available, in turn, to multiple Submissions Gateways 14. Similarly, each Electronic Submissions Gateway 14 can be responsible to poll multiple Submission Requirements Centres 12, provided that each Gateway 14 also has direct access (for the purpose of directing qualifying submissions) to all Submissions Processors 10 creating requirements collected by the Submission Requirements Centres 12.
1 S Submission requirements (deadlines, etc.) are created and their submission deadlines managed, according to preferred embodiments of the invention, following the steps set forth in the flow diagrams of Fi~;ures 2A and 2B.
In Figure 2A, a Submissions Processor generates a submission requirement and sets the deadline for accepting submissions that respond (block 120). Submission requirements generated by the Submissions Processor can include altering existing deadlines (shortening or extending them) and withdrawing existing submission requirements, as well as creating entirely new submission requirements. In the case of a new submission requirement, the Submission Processor assigns a directory for the requirement (block 122).
The Submissions Processor then sends the requirement to the Submissions Requirements Centre (block 124), and affected parties are notified of the requirement and of the assigned directory (block 126). In the case of the posting of a new submission requirement at the Submission Requirements Centre, the notification would invite prospective submitters to send in submissions. The type of notification used will depend upon the type of submissions sought. In the case of a commercial tender, the notification could include advertising in print media and on websites. The response of a submitting party, its submission of a proposal intended to meet the requirements, is set out in Figures 3 and 4.
Tlae Electronic Submissions Gateway polls the Submission Requirements Centre to check for new submission requirements and for changes to existing requirements created by Submissions Processors (black 128). Unless the Gateway has access to the notification of a new submission requirements sent out by the Processor, the Gateway won't know when a new submission requirement has become available. In that case, the Gateway would poll the Submission Requirements Centre constantly or at frequent intervals, to ensure that a new requirement is not missed for very long.
In response to determining that a new submission requirement has been created (block 130), the Gateway creates the assigned directory in its file system (block 132) specific to that submission requirement. TJhe file directory is used by the Gateway in verifying that submissions filed to meet the new requirements are received before expiry of the submission deadline, according to Figures 3 and 4.
The effect of deadline expiry must be simultaneous for all submitters. By continuously polling the Submission Requirements Centre, the Gateway also checks for deadlines on existing submission requirements that are about to expire or that have been withdrawn by the Submissions Processor (block 134). Some operating systems, such as Windows NT, allow the system administrator to grant access to users to add files to a directory, but not to erase them. In such a system, when the Gateway discovers the impending expiry of a requirements deadline, it simply schedules a future job or C,A9-98-009 process to disable permission to write to the directory (block 136). Different methods may be required for disabling access, depending on the characteristics of the operating system. One way to do this is in Windows NT to change the access control list of the area in memory where the directory is located so that submitters no longer have the authority to write to it. An alternate method for use in UNIX-based systems is illustrated in the flow diagram of Figure 2B, and discussed below.
Figure 3A is a flow diagram illustrating one embodiment of the process followed for a submitter to "lock in" its proposed submission prior to expiry of the deadline set by the Submission Processor that created the requirements.
Once a submitter completes the preparation of a submission (block 150), it generates "evidence"
of the completed submission (block 152). The submission completion evidence contains a relatively small amount of data that is quickly transmissible to the Electronic Submissions Gateway, in a form that will make it possible to correlate the evidence with the actual submission. One example of suitable "evide:nce" is a message digest of the actual submission. Message digest is a one-way hashing function which takes a message of arbitrary length and produces a compressed form called a "digest" or "signature". The "one-way" aspect refers to the fact that it is impossible to obtain the original document from the digest. Message digest is usually based on the conjecture that it is computationally infeasible to produce two different messages having the same message digest (this is referred to as "'collision resistance"), or to produce any message having a given pre-specified target message digest.
There are several existing digest functions that are well known. MD2 and MDS
message digest algorithms take as input a message of arbitrary length and produce as output a 128-bit digest of the input. SHA-1 (,Secure Hash Algorithm) is based on the published standard, Secure Hash Standard (FIPS 180) of the National Institute of Standards and Technology (NIST).
Taking bit strings as its input, the SHA :produces a 160-bit message digest of a longer message or file.
The message digest is computed using a sophisticated cryptographic algorithm such that any change to the data being hashed will, in a very high probability, change the hash value.
In order to ensure that submitters remain ignorant of the submissions of others, the submitter encrypts the identity of its readiness evidence using the Gateway's public encryption key (block 154), prior to sc,nding the evidence to the Electronic Submissions Gateway (block 156).
All submission readiness evidence for a single requirement arnves in the single directory of the Gateway's file :>ystem created for the requirement set (as per block 132 in Figure 2). As mentioned above, some operating systems allow the system administrator to grant access to users to add files to a directory, I>ut not to erase them. When an operating system allows such granularity in access control, it has th.e added advantage that it automatically provides security in an electronic submission system by preventing submitters from erasing submissions filed by others.
However, the common write-to area of the directory provides an opportunity for submitter fraud in the absence of additional security measures. Specifically, submitters may try to send unauthorised evidence on each other's behalf. To ensure that submission evidence is sent in by the purported submitter and prevent submitters sending in evidence in the name of others, each submitter can be required to include a digital signature with its submission readiness evidence when formulating the message for transmission to the Gateway (block 152).
Since the submission evidence will be used to prove that the submission was indeed completed before expiry crf the submission deadline, and corresponds to a submission requirement whose deadline has not: expired, the Gateway verifies whether the submitter can write to the directory (block 162). Access to the directory will be denied in the ordinary case where the Gateway has already disabled the submitters' ability to send submission readiness evidence (for example, the Gateway's file system access control has disabled permission to write to this directory, as per block 136 in Figure 2A), and a message (or other indicator, such as a return code) will be returned to the submitter indicating the filing was not successful (block 164). Access may also be denied if the invitation for submission is limited to a certain group of submitters. (For example, the submission of examination answers may be; limited to a particular scholastic class.) Where the submitter can write to the desilmated directory (blocks 162, 166), the Gateway returns a message to the submitter indicating that the submission readiness evidence has been successfully filed (block 168), thus providing the submitter with an immediate acknowledgement that the submission deadline has been met.
As mentioned above, UNIX-based systems usually do not allow add-only access to directories.
Therefore, access regulation to the directory must be implemented differently.
When a submitter wants to make a. submission, it creates a sub-directory within the common assigned directory for the requirement set. The sub-directory each submitter creates is "owned" by that submitter. It is only accessible to the submitter that created it and to the administrator of the Gateway server in which it was created; t:he sub-directory is not accessible to any other submitter.
Thus, after the Gateway has identified the submission requirement and directory, and determined whether the submitter can write to the identified directory, following the steps common to Figures 3A
and 3B, the Gateway determines whether the submitter owns a sub-directory within the directory created for the requirement set (block 170, Figure 3B). If the sub-directory does not exist, the Gateway allows the submitter to create its sub-directory (block 172). The submitter then writes the submission readiness evidence to the sub-directory it has created (block 174) and returns a message to the submitter indicating that the submission readiness evidence has been successfully filed (block 176).
When the submission deadline expires, permissions of the directory for the given submissions requirements arc: changed so that no submitters may create new sub-directories. However, in UNIX, a cheating subrnitter may create its own sub-directory, and write to it even without access to the parent directory in order to file evidence after expiry of the submission deadline. One way to prevent this is for the Gateway file administrator to schedule a job so that on expiry of the submission time limit, not only is access control to the directory changed (for example by remaining the main submissions directory), but the whole content of the directory is copied to another storage location to create a "sna:pshot" of the directory at the end of the time limit (block 138, Figure 2B).
Referring now to Figure 4, after the submitter has successfully sent the submission completion evidence, it can now transmit the actual submission to the Gateway (block 200). If the submission is large or if there are network delays, the submission may arrive at the Electronic Submissions Gateway after the submissions deadline has expired. However, this will not prevent the submission being received 'for filing.
When the Gateway finds a new submission (block 202), it looks for the corresponding submission readiness evidence (block 204). If no such evidence exists, the submission is rejected and a rejection message is returned to the submitter (block 206).
If the submission readiness evidence exists, the Gateway decrypts the stored evidence (block 208) and then verifif;s the submitter's digital signature on it to prove that the original submission from which the evidence was digested came from the expected submitter (block 210).
If it does not, the :20 submission is rc jected (block 206).
Once the Gateway verifies the submitter's identity, it verifies that the complete submission corresponds with the submission from which the evidence was created. This is done by computing the digest of the actual submission (block 212), and comparing it against the digest supplied in the :ZS evidence message (block 214). If the two digests do not match, then the submission must have been changed from its state before expiry of the submission deadline. The submission is rejected and a rejection message returned to the submitter (block 206).
If the two digests match, the submission is accepted and routed to the correct Submission Processor that created the requirements for the submission (block 216).
Embodiments of the invention that would be obvious to the person skilled in the art are intended to be included within the scope of the appended claims.
operating system to collect purchase requisitions from inside the organisation. The Electronics Submission Gateway 14a is a document information gateway operating under an IBM RS/6000~
operating system. In this embodiment, the Gateway 14a, itself, is the repository of information about current submission requirements from the Submission Processor 10. The Gateway 14a has a Submission Rexluirements camponent 12a that interfaces directly with the Submissions Processor 10 to collect this information, and to make it available internally, to ather components of the Gateway 14a.
The Submission Requirements component 12a also includes a tender bulletin board, preferably on a secure website, to notify external parties (i.e., potential suppliers) of calls for tender.
The potential suppliers make bid submissions to the system via submitting programs 18 operating on PC
operating systems with network/Internc;t access, such as IBM OS/2~ Warp, Microsoft Windows~ 95, etc.
Cammunications between the master buyer server/Submissions Processor 10 and Gateway 14a is handled by an C>S/2 Message Router 24 located in the Gateway 14a. The Submissions Processor 10 automatically wraps outgoing messages and unwraps incoming messages in order to ensure data integrity. Similarly, the Message Router 24 automatically wraps and unwraps messages going to and from the Submissions Processor 10. Messages within the Gateway environment, for example from the Message Router 24 to the Submission Requirements component 12a or between the Submission Requirements component 12a and other components in the Gateway 14a, are not wrapped.
The Gateway 14a has a firewall that protects it from the external network.
Communications with suppliers are handled by a security module 26 which automatically builds a secure structure before forwarding a message to a supplier over the network, and unpacks the secure structures it receives from the network in order to forward plain messages to other components in the Gateway 14a to process. The secure structure packages the token together with the submission in a single structure.
As discussed below, both the submitting program 18 and Gateway 14 may use message digest, or a similar technology, to lock in a proposed submission. Encryption and digital signature technologies may also be used to assure integrity, privacy, authentication, and non-repudiation of messages and submissions over the open network.
As Figure 1 C shows, the Submission Requirements Centre 12 can collect information on new requirements for multiple Submissions Processors 10, and can make those requirements available, in turn, to multiple Submissions Gateways 14. Similarly, each Electronic Submissions Gateway 14 can be responsible to poll multiple Submission Requirements Centres 12, provided that each Gateway 14 also has direct access (for the purpose of directing qualifying submissions) to all Submissions Processors 10 creating requirements collected by the Submission Requirements Centres 12.
1 S Submission requirements (deadlines, etc.) are created and their submission deadlines managed, according to preferred embodiments of the invention, following the steps set forth in the flow diagrams of Fi~;ures 2A and 2B.
In Figure 2A, a Submissions Processor generates a submission requirement and sets the deadline for accepting submissions that respond (block 120). Submission requirements generated by the Submissions Processor can include altering existing deadlines (shortening or extending them) and withdrawing existing submission requirements, as well as creating entirely new submission requirements. In the case of a new submission requirement, the Submission Processor assigns a directory for the requirement (block 122).
The Submissions Processor then sends the requirement to the Submissions Requirements Centre (block 124), and affected parties are notified of the requirement and of the assigned directory (block 126). In the case of the posting of a new submission requirement at the Submission Requirements Centre, the notification would invite prospective submitters to send in submissions. The type of notification used will depend upon the type of submissions sought. In the case of a commercial tender, the notification could include advertising in print media and on websites. The response of a submitting party, its submission of a proposal intended to meet the requirements, is set out in Figures 3 and 4.
Tlae Electronic Submissions Gateway polls the Submission Requirements Centre to check for new submission requirements and for changes to existing requirements created by Submissions Processors (black 128). Unless the Gateway has access to the notification of a new submission requirements sent out by the Processor, the Gateway won't know when a new submission requirement has become available. In that case, the Gateway would poll the Submission Requirements Centre constantly or at frequent intervals, to ensure that a new requirement is not missed for very long.
In response to determining that a new submission requirement has been created (block 130), the Gateway creates the assigned directory in its file system (block 132) specific to that submission requirement. TJhe file directory is used by the Gateway in verifying that submissions filed to meet the new requirements are received before expiry of the submission deadline, according to Figures 3 and 4.
The effect of deadline expiry must be simultaneous for all submitters. By continuously polling the Submission Requirements Centre, the Gateway also checks for deadlines on existing submission requirements that are about to expire or that have been withdrawn by the Submissions Processor (block 134). Some operating systems, such as Windows NT, allow the system administrator to grant access to users to add files to a directory, but not to erase them. In such a system, when the Gateway discovers the impending expiry of a requirements deadline, it simply schedules a future job or C,A9-98-009 process to disable permission to write to the directory (block 136). Different methods may be required for disabling access, depending on the characteristics of the operating system. One way to do this is in Windows NT to change the access control list of the area in memory where the directory is located so that submitters no longer have the authority to write to it. An alternate method for use in UNIX-based systems is illustrated in the flow diagram of Figure 2B, and discussed below.
Figure 3A is a flow diagram illustrating one embodiment of the process followed for a submitter to "lock in" its proposed submission prior to expiry of the deadline set by the Submission Processor that created the requirements.
Once a submitter completes the preparation of a submission (block 150), it generates "evidence"
of the completed submission (block 152). The submission completion evidence contains a relatively small amount of data that is quickly transmissible to the Electronic Submissions Gateway, in a form that will make it possible to correlate the evidence with the actual submission. One example of suitable "evide:nce" is a message digest of the actual submission. Message digest is a one-way hashing function which takes a message of arbitrary length and produces a compressed form called a "digest" or "signature". The "one-way" aspect refers to the fact that it is impossible to obtain the original document from the digest. Message digest is usually based on the conjecture that it is computationally infeasible to produce two different messages having the same message digest (this is referred to as "'collision resistance"), or to produce any message having a given pre-specified target message digest.
There are several existing digest functions that are well known. MD2 and MDS
message digest algorithms take as input a message of arbitrary length and produce as output a 128-bit digest of the input. SHA-1 (,Secure Hash Algorithm) is based on the published standard, Secure Hash Standard (FIPS 180) of the National Institute of Standards and Technology (NIST).
Taking bit strings as its input, the SHA :produces a 160-bit message digest of a longer message or file.
The message digest is computed using a sophisticated cryptographic algorithm such that any change to the data being hashed will, in a very high probability, change the hash value.
In order to ensure that submitters remain ignorant of the submissions of others, the submitter encrypts the identity of its readiness evidence using the Gateway's public encryption key (block 154), prior to sc,nding the evidence to the Electronic Submissions Gateway (block 156).
All submission readiness evidence for a single requirement arnves in the single directory of the Gateway's file :>ystem created for the requirement set (as per block 132 in Figure 2). As mentioned above, some operating systems allow the system administrator to grant access to users to add files to a directory, I>ut not to erase them. When an operating system allows such granularity in access control, it has th.e added advantage that it automatically provides security in an electronic submission system by preventing submitters from erasing submissions filed by others.
However, the common write-to area of the directory provides an opportunity for submitter fraud in the absence of additional security measures. Specifically, submitters may try to send unauthorised evidence on each other's behalf. To ensure that submission evidence is sent in by the purported submitter and prevent submitters sending in evidence in the name of others, each submitter can be required to include a digital signature with its submission readiness evidence when formulating the message for transmission to the Gateway (block 152).
Since the submission evidence will be used to prove that the submission was indeed completed before expiry crf the submission deadline, and corresponds to a submission requirement whose deadline has not: expired, the Gateway verifies whether the submitter can write to the directory (block 162). Access to the directory will be denied in the ordinary case where the Gateway has already disabled the submitters' ability to send submission readiness evidence (for example, the Gateway's file system access control has disabled permission to write to this directory, as per block 136 in Figure 2A), and a message (or other indicator, such as a return code) will be returned to the submitter indicating the filing was not successful (block 164). Access may also be denied if the invitation for submission is limited to a certain group of submitters. (For example, the submission of examination answers may be; limited to a particular scholastic class.) Where the submitter can write to the desilmated directory (blocks 162, 166), the Gateway returns a message to the submitter indicating that the submission readiness evidence has been successfully filed (block 168), thus providing the submitter with an immediate acknowledgement that the submission deadline has been met.
As mentioned above, UNIX-based systems usually do not allow add-only access to directories.
Therefore, access regulation to the directory must be implemented differently.
When a submitter wants to make a. submission, it creates a sub-directory within the common assigned directory for the requirement set. The sub-directory each submitter creates is "owned" by that submitter. It is only accessible to the submitter that created it and to the administrator of the Gateway server in which it was created; t:he sub-directory is not accessible to any other submitter.
Thus, after the Gateway has identified the submission requirement and directory, and determined whether the submitter can write to the identified directory, following the steps common to Figures 3A
and 3B, the Gateway determines whether the submitter owns a sub-directory within the directory created for the requirement set (block 170, Figure 3B). If the sub-directory does not exist, the Gateway allows the submitter to create its sub-directory (block 172). The submitter then writes the submission readiness evidence to the sub-directory it has created (block 174) and returns a message to the submitter indicating that the submission readiness evidence has been successfully filed (block 176).
When the submission deadline expires, permissions of the directory for the given submissions requirements arc: changed so that no submitters may create new sub-directories. However, in UNIX, a cheating subrnitter may create its own sub-directory, and write to it even without access to the parent directory in order to file evidence after expiry of the submission deadline. One way to prevent this is for the Gateway file administrator to schedule a job so that on expiry of the submission time limit, not only is access control to the directory changed (for example by remaining the main submissions directory), but the whole content of the directory is copied to another storage location to create a "sna:pshot" of the directory at the end of the time limit (block 138, Figure 2B).
Referring now to Figure 4, after the submitter has successfully sent the submission completion evidence, it can now transmit the actual submission to the Gateway (block 200). If the submission is large or if there are network delays, the submission may arrive at the Electronic Submissions Gateway after the submissions deadline has expired. However, this will not prevent the submission being received 'for filing.
When the Gateway finds a new submission (block 202), it looks for the corresponding submission readiness evidence (block 204). If no such evidence exists, the submission is rejected and a rejection message is returned to the submitter (block 206).
If the submission readiness evidence exists, the Gateway decrypts the stored evidence (block 208) and then verifif;s the submitter's digital signature on it to prove that the original submission from which the evidence was digested came from the expected submitter (block 210).
If it does not, the :20 submission is rc jected (block 206).
Once the Gateway verifies the submitter's identity, it verifies that the complete submission corresponds with the submission from which the evidence was created. This is done by computing the digest of the actual submission (block 212), and comparing it against the digest supplied in the :ZS evidence message (block 214). If the two digests do not match, then the submission must have been changed from its state before expiry of the submission deadline. The submission is rejected and a rejection message returned to the submitter (block 206).
If the two digests match, the submission is accepted and routed to the correct Submission Processor that created the requirements for the submission (block 216).
Embodiments of the invention that would be obvious to the person skilled in the art are intended to be included within the scope of the appended claims.
Claims (19)
1. A method for enforcing time limits in a gateway server in an electronic filing system, comprising steps of:
receiving, from a submitting program, a first electronic message containing evidence of a completed submission but not containing said completed submission;
identifying a write-enabled directory for storing said evidence and writing said evidence in the directory, else returning a first submission rejection indication to the submitting program; and on receipt of a subsequent message containing the completed submission, computing second evidence from the completed submission and matching the second evidence with the evidence written in the directory, else returning a second submission rejection indication to the submitting program.
receiving, from a submitting program, a first electronic message containing evidence of a completed submission but not containing said completed submission;
identifying a write-enabled directory for storing said evidence and writing said evidence in the directory, else returning a first submission rejection indication to the submitting program; and on receipt of a subsequent message containing the completed submission, computing second evidence from the completed submission and matching the second evidence with the evidence written in the directory, else returning a second submission rejection indication to the submitting program.
2. The method, according to Claim 1, wherein the step of matching the second evidence with the evidence written in the directory comprises the step of:
verifying the submitting program's identity through digital signature.
verifying the submitting program's identity through digital signature.
3. The method, according to Claim 1, further comprising steps of:
receiving a submission requirement including an unexpired submission time limit and generating the directory with write access for submitting programs; and removing write access to the directory on expiry of the submission time limit.
receiving a submission requirement including an unexpired submission time limit and generating the directory with write access for submitting programs; and removing write access to the directory on expiry of the submission time limit.
4. The method, according to Claim 3, wherein the step of removing write access to the directory comprises changing access policy for the directory.
5. The method, according to Claim 4, wherein the step of removing write access to the directory comprises changing access policy for the directory and, immediately after expiry of the submission time limit, copying all messages stored in the directory to another storage area:
6. A method for enforcing time limits in a gateway server in an electronic filing system, comprising steps of:
receiving, from a submitting program, a first electronic message containing a first message digest of a completed submission but not containing said completed submission;
identifying a write-enabled directory for storing said first message digest and writing said first message digest in the directory, else returning a first submission rejection indication to the submitting program; and on receipt of a subsequent electronic message containing the completed submission, computing a second message digest of the completed submission, and matching the second message digest with the first message digest written in the directory, else returning a second submission rejection indication to the submitting program.
receiving, from a submitting program, a first electronic message containing a first message digest of a completed submission but not containing said completed submission;
identifying a write-enabled directory for storing said first message digest and writing said first message digest in the directory, else returning a first submission rejection indication to the submitting program; and on receipt of a subsequent electronic message containing the completed submission, computing a second message digest of the completed submission, and matching the second message digest with the first message digest written in the directory, else returning a second submission rejection indication to the submitting program.
7. The method, according to Claim 6, further comprising steps of:
receiving a submission requirement including an unexpired submission time limit and generating the directory with write access for submitting programs; and removing write access to the directory on expiry of the submission time limit.
receiving a submission requirement including an unexpired submission time limit and generating the directory with write access for submitting programs; and removing write access to the directory on expiry of the submission time limit.
8. The method, according to Claim 7, wherein the step of removing write access to the directory comprises changing access policy for the directory.
9. The method, according to Claim 7, wherein the step of removing write access to the directory comprises changing access policy for the directory and, immediately after expiry of the submission time limit, copying all messages stored in the directory to another storage area.
10. In a network, a gateway mechanism for enforcing time limits for filing electronic submissions, comprising:
means in a server in the gateway mechanism for receiving information related to a submission time limit from a submission processing environment and for generating a storage directory in the server's file system with write access for all potential submitters within the submission time limit;
means for (i) receiving, from a submitter, a first electronic message containing evidence of a completed submission but not containing said completed submission, (ii) verifying write access to the storage directory, and (iii) if the write access is verified, writing the evidence to the storage directory, else returning an error indication to the submitter;
means for removing the write access to the storage directory on expiry of the submission time limit;
means for computing second evidence from the completed submission upon receiving said completed submission from the submitter in a subsequent electronic message;
and means for matching the second evidence with the evidence written to the storage directory, else returning an error indication to the submitter.
means in a server in the gateway mechanism for receiving information related to a submission time limit from a submission processing environment and for generating a storage directory in the server's file system with write access for all potential submitters within the submission time limit;
means for (i) receiving, from a submitter, a first electronic message containing evidence of a completed submission but not containing said completed submission, (ii) verifying write access to the storage directory, and (iii) if the write access is verified, writing the evidence to the storage directory, else returning an error indication to the submitter;
means for removing the write access to the storage directory on expiry of the submission time limit;
means for computing second evidence from the completed submission upon receiving said completed submission from the submitter in a subsequent electronic message;
and means for matching the second evidence with the evidence written to the storage directory, else returning an error indication to the submitter.
11. The mechanism, according to Claim 10, wherein the means for receiving information related to a time limit from a submission processing environment comprises:
a submission repository adapted to receive information related to current submission requirements from the submission processing environment; and means to poll the submission repository to update the submission time limit.
a submission repository adapted to receive information related to current submission requirements from the submission processing environment; and means to poll the submission repository to update the submission time limit.
12. The mechanism, according to Claim 10, wherein the means for removing write access to the storage directory comprises means for changing access policy for the storage directory.
13. The mechanism, according to Claim 10, wherein the means for removing write access to the storage directory comprises means for changing access policy for the storage directory and means for creating a copy in another storage location of the storage directory as the time limit expires.
14. The mechanism, according to Claim 10, wherein the means for matching the second evidence with the evidence written to the storage directory comprises verifying the submitter's identity by digital signature.
15. The mechanism, according to Claim 10, wherein:
the evidence comprises a message digest of the completed submission;
the means for computing second evidence from the completed submission comprise means at the server for computing a second message digest from the received completed submission; and the means for matching the second evidence with the evidence written to the storage directory comprise means at the server for comparing the second evidence to the evidence written to the storage directory; and further comprising means for routing the completed submission to the submission processing environment if the means for comparing determines that the second evidence and the evidence written to the storage directory are identical.
the evidence comprises a message digest of the completed submission;
the means for computing second evidence from the completed submission comprise means at the server for computing a second message digest from the received completed submission; and the means for matching the second evidence with the evidence written to the storage directory comprise means at the server for comparing the second evidence to the evidence written to the storage directory; and further comprising means for routing the completed submission to the submission processing environment if the means for comparing determines that the second evidence and the evidence written to the storage directory are identical.
16. The mechanism, according to Claim 10, wherein the evidence comprises a message digest of the completed submission computed by the submitter, and wherein the means for computing second evidence from the completed submission comprises means at the server to compute a new message digest of the completed submission.
17. A computer program product comprising a computer usable medium having computer readable program code means embodied thereon for enforcing time limits in an electronic filing system, the computer readable program product comprising:
computer readable program code means for causing a computer to receive, from a submitting program, a first electronic message containing evidence of a completed submission but not containing said completed submission;
computer readable program code means for causing the computer to identify a write-enabled directory for storing said evidence and to write said evidence in the directory, else return a first submission rejection indication to the submitting program; and computer readable program code means, on receipt of a subsequent electronic message containing the completed submission, for causing the computer to compute second evidence from the completed submission and to match the second evidence with the evidence written in the directory, else return a second submission rejection indication to the submitting program.
computer readable program code means for causing a computer to receive, from a submitting program, a first electronic message containing evidence of a completed submission but not containing said completed submission;
computer readable program code means for causing the computer to identify a write-enabled directory for storing said evidence and to write said evidence in the directory, else return a first submission rejection indication to the submitting program; and computer readable program code means, on receipt of a subsequent electronic message containing the completed submission, for causing the computer to compute second evidence from the completed submission and to match the second evidence with the evidence written in the directory, else return a second submission rejection indication to the submitting program.
18. A computer program produce comprising a computer usable medium having computer readable program code means embodied thereon for enforcing time limits in an electronic filing system, the computer readable program product comprising:
computer readable program code means for causing a computer to receive, from a submitting program, a first electronic message containing a first message digest of a completed submission, wherein said first electronic message does not contain said completed submission;
computer readable program code means for causing the computer to identify a write-enabled directory for storing said first message digest and to write said first message digest in the directory, else return a first submission rejection message to the submitting program;
and computer readable program code means, on receipt of a subsequent message containing the completed submission, for causing the computer to compute a new message digest of the completed submission and to match the new message digest with the first message digest written in the directory, else return a second submission rejection message to the submitting program.
computer readable program code means for causing a computer to receive, from a submitting program, a first electronic message containing a first message digest of a completed submission, wherein said first electronic message does not contain said completed submission;
computer readable program code means for causing the computer to identify a write-enabled directory for storing said first message digest and to write said first message digest in the directory, else return a first submission rejection message to the submitting program;
and computer readable program code means, on receipt of a subsequent message containing the completed submission, for causing the computer to compute a new message digest of the completed submission and to match the new message digest with the first message digest written in the directory, else return a second submission rejection message to the submitting program.
19. A computer readable memory for storing instructions usable in the execution in a computer of any one of the methods of claims 1 to 9.
Priority Applications (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002237678A CA2237678C (en) | 1998-05-14 | 1998-05-14 | Secure flexible electronic submission acceptance system |
| TW087110391A TW380224B (en) | 1998-05-14 | 1998-06-26 | A flexible electronic submission acceptance system |
| US09/204,778 US6604197B1 (en) | 1998-05-14 | 1998-12-03 | Secure flexible electronic submission acceptance system |
| KR1019990013123A KR100349224B1 (en) | 1998-05-14 | 1999-04-14 | A secure flexible electronic submission |
| SG9901937A SG81275A1 (en) | 1998-05-14 | 1999-04-23 | A secure flexible electronic submission acceptance system |
| GB9910723A GB2339124B (en) | 1998-05-14 | 1999-05-11 | A secure flexible electronic submission acceptance system |
| JP13075799A JP3914351B2 (en) | 1998-05-14 | 1999-05-12 | Method, gateway system and recording medium for enhancing deadline management |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002237678A CA2237678C (en) | 1998-05-14 | 1998-05-14 | Secure flexible electronic submission acceptance system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2237678A1 CA2237678A1 (en) | 1999-11-14 |
| CA2237678C true CA2237678C (en) | 2003-08-05 |
Family
ID=4162431
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002237678A Expired - Fee Related CA2237678C (en) | 1998-05-14 | 1998-05-14 | Secure flexible electronic submission acceptance system |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US6604197B1 (en) |
| JP (1) | JP3914351B2 (en) |
| KR (1) | KR100349224B1 (en) |
| CA (1) | CA2237678C (en) |
| GB (1) | GB2339124B (en) |
| SG (1) | SG81275A1 (en) |
| TW (1) | TW380224B (en) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7647647B2 (en) * | 2004-08-05 | 2010-01-12 | International Business Machines Corporation | System, method and program product for temporally authorizing program execution |
| EP1628429A3 (en) * | 2004-08-19 | 2011-06-01 | Infineon Technologies AG | Method for transmitting information with an acknowledgement scheme and respective communication system |
| DE602004005992T2 (en) * | 2004-10-04 | 2008-01-17 | Sap Ag | Data processing system and method |
| EP1848143A4 (en) | 2005-02-10 | 2010-04-14 | Nec Corp | Member certificate acquiring device, member certificate issuing device, group signing device, and group signature verifying device |
| US20060288050A1 (en) * | 2005-06-15 | 2006-12-21 | International Business Machines Corporation | Method, system, and computer program product for correlating directory changes to access control modifications |
| FR3085506A1 (en) * | 2018-08-30 | 2020-03-06 | Raphael Louiset | SECURE METHOD AND SYSTEM FOR DELAYED SHARING OF DATA BETWEEN MULTIPLE TRANSMITTING USERS AND MULTIPLE RECIPIENT USERS, WITH BLOCKCHAIN TIMING. |
| FR3085504A1 (en) * | 2018-08-30 | 2020-03-06 | Raphael Louiset | SECURE METHOD OF DELAYED SHARING OF DATA BETWEEN A TRANSMITTING USER AND A RECIPIENT USER, WITH LOCAL CREATION OF A CONTAINER AND TIMING ON BLOCKCHAIN. |
| FR3085503A1 (en) * | 2018-08-30 | 2020-03-06 | Raphael Louiset | SECURE METHOD AND SYSTEM FOR DELAYED SHARING OF DATA BETWEEN SEVERAL TRANSMITTING USERS AND A RECIPIENT USER, WITH TIMERING ON BLOCKCHAIN. |
| FR3085502A1 (en) * | 2018-08-30 | 2020-03-06 | Raphael Louiset | SECURE METHOD AND SYSTEM FOR DELAYED SHARING OF DATA BETWEEN AT LEAST ONE SENDING USER AND AT LEAST ONE RECIPIENT USER, WITH TIMING BY MULTIPLE QUERYING OF A BLOCKCHAIN. |
| FR3085508B1 (en) * | 2018-08-30 | 2020-12-04 | Raphael Louiset | SECURE PROCESS FOR DELAYED DATA SHARING BETWEEN AT LEAST ONE SENDING USER AND AT LEAST ONE RECIPIENT USER, WITH TIME-STAMP ON BLOCKCHAIN. |
| FR3085509A1 (en) * | 2018-08-30 | 2020-03-06 | Raphael Louiset | SECURE SYSTEM AND METHOD FOR DELAYED SHARING OF DATA BETWEEN A TRANSMITTING USER AND A RECIPIENT USER, WITH REMOTE CREATION OF A CONTAINER AND TIMING ON BLOCKCHAIN. |
| FR3085507A1 (en) * | 2018-08-30 | 2020-03-06 | Raphael Louiset | SECURE METHOD AND SYSTEM FOR DELAYED SHARING OF DATA BETWEEN A TRANSMITTING USER AND MULTIPLE RECIPIENT USERS, WITH REMOTE CREATION OF A CONTAINER AND TIMING ON BLOCKCHAIN. |
| FR3085505B1 (en) * | 2018-08-30 | 2020-12-04 | Raphael Louiset | SECURE METHOD AND SYSTEM FOR DELAYED DATA SHARING BETWEEN AT LEAST ONE SENDING USER AND AT LEAST ONE RECIPIENT USER, UNDER THE CONTROL OF A TRUSTED THIRD PARTY. |
Family Cites Families (16)
| 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 |
| US5247647A (en) * | 1988-07-28 | 1993-09-21 | International Business Machines Corp. | Detection of deletion of stored data by concurrently executing processes in a multiprocessing data processing system |
| US5182705A (en) * | 1989-08-11 | 1993-01-26 | Itt Corporation | Computer system and method for work management |
| US5136646A (en) * | 1991-03-08 | 1992-08-04 | Bell Communications Research, Inc. | Digital document time-stamping with catenate certificate |
| US5266942A (en) * | 1991-08-21 | 1993-11-30 | Stoller Gerald S | Security system with memory in transmitter and receiver |
| US5469576A (en) * | 1993-03-22 | 1995-11-21 | International Business Machines Corporation | Front end for file access controller |
| JPH07177142A (en) * | 1993-10-27 | 1995-07-14 | Hitachi Ltd | Message guarantee system |
| US5721904A (en) * | 1993-12-20 | 1998-02-24 | Hitachi, Ltd. | Database access system and method of controlling access management to a database access system for a plurality of heterogeneous database servers using SQL |
| US5615268A (en) | 1995-01-17 | 1997-03-25 | Document Authentication Systems, Inc. | System and method for electronic transmission storage and retrieval of authenticated documents |
| US5553145A (en) * | 1995-03-21 | 1996-09-03 | Micali; Silvia | Simultaneous electronic transactions with visible trusted parties |
| US5970143A (en) * | 1995-11-22 | 1999-10-19 | Walker Asset Management Lp | Remote-auditing of computer generated outcomes, authenticated billing and access control, and software metering system using cryptographic and other protocols |
| US5638446A (en) * | 1995-08-28 | 1997-06-10 | Bell Communications Research, Inc. | Method for the secure distribution of electronic files in a distributed environment |
| US5987134A (en) * | 1996-02-23 | 1999-11-16 | Fuji Xerox Co., Ltd. | Device and method for authenticating user's access rights to resources |
| US6223286B1 (en) * | 1996-03-18 | 2001-04-24 | Kabushiki Kaisha Toshiba | Multicast message transmission device and message receiving protocol device for realizing fair message delivery time for multicast message |
| US5931917A (en) * | 1996-09-26 | 1999-08-03 | Verifone, Inc. | System, method and article of manufacture for a gateway system architecture with system administration information accessible from a browser |
| US5987611A (en) * | 1996-12-31 | 1999-11-16 | Zone Labs, Inc. | System and methodology for managing internet access on a per application basis for client computers connected to the internet |
-
1998
- 1998-05-14 CA CA002237678A patent/CA2237678C/en not_active Expired - Fee Related
- 1998-06-26 TW TW087110391A patent/TW380224B/en not_active IP Right Cessation
- 1998-12-03 US US09/204,778 patent/US6604197B1/en not_active Expired - Lifetime
-
1999
- 1999-04-14 KR KR1019990013123A patent/KR100349224B1/en not_active IP Right Cessation
- 1999-04-23 SG SG9901937A patent/SG81275A1/en unknown
- 1999-05-11 GB GB9910723A patent/GB2339124B/en not_active Expired - Lifetime
- 1999-05-12 JP JP13075799A patent/JP3914351B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| SG81275A1 (en) | 2001-06-19 |
| JP3914351B2 (en) | 2007-05-16 |
| GB2339124A (en) | 2000-01-12 |
| GB9910723D0 (en) | 1999-07-07 |
| KR100349224B1 (en) | 2002-08-19 |
| CA2237678A1 (en) | 1999-11-14 |
| GB2339124B (en) | 2002-12-24 |
| US6604197B1 (en) | 2003-08-05 |
| TW380224B (en) | 2000-01-21 |
| JP2000040044A (en) | 2000-02-08 |
| KR19990087917A (en) | 1999-12-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6182124B1 (en) | Token-based deadline enforcement system for electronic document submission | |
| CN111723355B (en) | Information management in a database | |
| US20200267163A1 (en) | Blockchain for Documents Having Legal Evidentiary Value | |
| CN110582775B (en) | Method for managing files based on blockchain by utilizing UTXO (universal time-series oscillator) foundation protocol and file management server using same | |
| US7082538B2 (en) | Electronically verified digital signature and document delivery system and method | |
| US8903788B2 (en) | Synchronizing distributed work through document logs | |
| US6510513B1 (en) | Security services and policy enforcement for electronic data | |
| US20030028495A1 (en) | Trusted third party services system and method | |
| CA2237678C (en) | Secure flexible electronic submission acceptance system | |
| US20020023220A1 (en) | Distributed information system and protocol for affixing electronic signatures and authenticating documents | |
| US20080270571A1 (en) | Method and system of verifying permission for a remote computer system to access a web page | |
| CN111796968A (en) | Database transaction guaranteed submission | |
| US20210352077A1 (en) | Low trust privileged access management | |
| WO2008063850A2 (en) | System and methods for digital file management and authentication | |
| KR100932266B1 (en) | How to provide electronic document relay service | |
| US20040064703A1 (en) | Access control technique using cryptographic technology | |
| US8448228B2 (en) | Separating authorization identity from policy enforcement identity | |
| US7441115B2 (en) | Method for verifying a digital signature | |
| EP1162781B1 (en) | System and method for generation of a signature certificate in a public key infrastructure | |
| US7660992B2 (en) | Electronic data storage system and method thereof | |
| US20070079382A1 (en) | Authorizing computer services | |
| CN1985460B (en) | Communication-efficient real time credentials for OCSP and distributed OCSP | |
| WO2004012415A1 (en) | Electronic sealing for electronic transactions | |
| Lowry | Location-independent information object security | |
| EP1798916B1 (en) | Regulating an extensibility point's access to a wrapped e-mail message |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |