WO2012005546A2 - 전자문서 유통 시스템 및 전자문서 유통 방법 - Google Patents

전자문서 유통 시스템 및 전자문서 유통 방법 Download PDF

Info

Publication number
WO2012005546A2
WO2012005546A2 PCT/KR2011/005027 KR2011005027W WO2012005546A2 WO 2012005546 A2 WO2012005546 A2 WO 2012005546A2 KR 2011005027 W KR2011005027 W KR 2011005027W WO 2012005546 A2 WO2012005546 A2 WO 2012005546A2
Authority
WO
WIPO (PCT)
Prior art keywords
distribution
message
electronic document
electronic
address
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.)
Ceased
Application number
PCT/KR2011/005027
Other languages
English (en)
French (fr)
Korean (ko)
Other versions
WO2012005546A3 (ko
Inventor
안대섭
이중구
공성필
임영철
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.)
NATIONAL IT INDUSTRY PROMOTION AGENCY
Original Assignee
NATIONAL IT INDUSTRY PROMOTION AGENCY
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 NATIONAL IT INDUSTRY PROMOTION AGENCY filed Critical NATIONAL IT INDUSTRY PROMOTION AGENCY
Priority to CN201180043451.8A priority Critical patent/CN103124981B/zh
Priority to JP2013518281A priority patent/JP2013535858A/ja
Priority to US13/808,576 priority patent/US9143358B2/en
Priority to EP11803832.2A priority patent/EP2602758B1/en
Priority to SG2013001870A priority patent/SG187006A1/en
Publication of WO2012005546A2 publication Critical patent/WO2012005546A2/ko
Publication of WO2012005546A3 publication Critical patent/WO2012005546A3/ko
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/50—Business processes related to the communications industry
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/60—Business processes related to postal services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/214—Monitoring or handling of messages using selective forwarding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Definitions

  • the present invention relates to an electronic document distribution system and an electronic document distribution method capable of establishing an electronic document distribution system that can be secured by the general individual, small companies, along with companies / institutions.
  • the present invention is to solve the conventional problems as described above, the object of the present invention is that the electronics that can ensure the reliability of the general individual, small businesses, such as companies / institutions that can have a certain scale electronic document distribution system It is to provide a document distribution system and an electronic document distribution method.
  • Electronic document distribution system having the above object, in the system for distributing the electronic document, a distribution for transmitting and receiving a message based on the electronic address and issuing and managing the distribution certificate for the message transmission and reception
  • a transceiving entity for distributing electronic documents through a messaging server Register / manage the electronic address of the send / receive entity, set an electronic document distribution path between the send / receive entity, provide a standard format of the electronic document to the send / receive entity, and when an error occurs in the electronic document distribution process between the send / receive entity
  • a distribution hub that acts on behalf of sending messages and issues distribution certificates; And store and receive a distribution certificate, and be a trusted third party storage institution; It includes.
  • an electronic document distribution system in a method for distributing an electronic document in an electronic document distribution system including a transmitting and receiving entity and a distribution hub, (a) the transmitting entity is a receiving entity.
  • step (b) After acquiring physical address information corresponding to the address information through the distribution hub, transmitting a message attached to the electronic document to the physical address; (b) the receiving entity receiving the message, issuing a receipt certificate or error certificate according to a result of conformance verification for the received message and the transmitting entity and delivering the received certificate or error certificate to the transmitting entity; And (c) the sender who failed to send a message to the receiving entity requests the message transmission agent to the distribution hub, and the distribution hub that receives the request for the message transmission agent issues a certificate of transmission to the sender and sends the message to the receiving entity. After performing step (b); It includes.
  • the present invention having the configuration and method as described above has the effect that it is possible to build an electronic document distribution system that can be secured by individuals, small businesses, such as companies / institutions.
  • FIG. 1 is a view showing a configuration example of an electronic document distribution system according to a preferred embodiment of the present invention.
  • FIG. 2 is a diagram for explaining the distribution messaging server of FIG.
  • FIG. 3 is a diagram for explaining the distribution client of FIG.
  • FIG. 4 is a diagram for explaining the address directory server of FIG. 1.
  • FIG. 4 is a diagram for explaining the address directory server of FIG. 1.
  • FIG. 5 is a view for explaining the electronic document format register of FIG.
  • FIG. 6 is a view for explaining the distribution relay server of FIG.
  • FIG. 7 is a diagram for explaining an external linkage gateway of FIG. 1.
  • FIG. 8 is a view for explaining the validity range of the authorized electronic address in the electronic document distribution system of FIG.
  • FIG. 9 is a view for explaining the application / issuance and operation system of the authorized electronic address in a preferred embodiment of the present invention.
  • 10 to 13 are diagrams for explaining message security when distributing electronic documents in a preferred embodiment of the present invention.
  • FIG. 18 is a diagram for explaining a physical address obtaining process in a preferred embodiment of the present invention.
  • 19 to 21 are diagrams for explaining a distribution relay support process in a preferred embodiment of the present invention.
  • 22 to 24 are views for explaining a management process, such as registration of a public electronic address in a preferred embodiment of the present invention.
  • 25 and 26 are diagrams for explaining an electronic document format application process in a preferred embodiment of the present invention.
  • 27 to 29 are diagrams for explaining a spam message processing process in a preferred embodiment of the present invention.
  • 30 and 31 are conceptual views illustrating an electronic document reading service in a preferred embodiment of the present invention.
  • FIG. 32 illustrates a conceptual diagram of an external linkage gateway server in a preferred embodiment of the present invention.
  • 33 is a view for explaining a procedure in which an electronic document is distributed in association with an external system in a preferred embodiment of the present invention.
  • 34 to 38 are views for explaining the configuration of a communication protocol for operating in conjunction with each other between components for electronic document distribution under the electronic document distribution system according to an embodiment of the present invention.
  • 39 to 43 are diagrams for explaining an error handling method under an electronic document distribution system according to a preferred embodiment of the present invention.
  • 44 to 51 are diagrams for explaining a linkage interface between a distribution messaging server and an address directory server in an electronic document distribution system according to a preferred embodiment of the present invention.
  • 52 to 63 are diagrams for explaining a linkage interface between distribution messaging servers in an electronic document distribution system according to a preferred embodiment of the present invention.
  • 64 to 78 are diagrams for explaining a linkage interface between a distribution client and a distribution messaging server in an electronic document distribution system according to a preferred embodiment of the present invention.
  • 79 to 71 are diagrams for explaining a linkage interface between a distribution messaging server and a distribution relay server in an electronic document distribution system according to a preferred embodiment of the present invention.
  • FIG. 82 is a flowchart illustrating a procedure for receiving a registration as a public electronic address by authenticating a distribution messaging server system according to another embodiment of the present invention.
  • FIG. 83 illustrates a procedure for reporting a spam message to an electronic document distribution hub when a transmitting / receiving entity serves as a receiver according to another embodiment of the present invention.
  • FIG. 84 is a view showing a procedure in the case of confirming in real time whether to reject a transmission counterpart when a transmitting / receiving entity serves as a receiver according to another embodiment of the present invention.
  • FIG. 85 is a view showing a procedure for periodically checking whether to reject a transmission counterpart when a transmitting / receiving entity serves as a receiver according to another embodiment of the present invention.
  • 86 to 100 are views for explaining a distribution messaging server system according to another embodiment of the present invention.
  • 101 to 105 are diagrams for explaining a distribution protocol applied to an electronic document distribution system and method according to another embodiment of the present invention.
  • 106 and 107 are diagrams for explaining an electronic document format register according to another embodiment of the present invention.
  • FIG. 108 is a diagram for explaining an electronic document packaging applied to an electronic document distribution system and method according to another embodiment of the present invention.
  • 109 through 114 are diagrams for explaining a distribution client application according to another embodiment of the present invention.
  • FIG. 115 illustrates a system for issuing an electronic address by an address directory server according to another embodiment of the present invention.
  • FIG. 116 is a diagram illustrating a process of issuing an electronic address by an address directory server according to another embodiment of the present invention.
  • FIG. 116 is a diagram illustrating a process of issuing an electronic address by an address directory server according to another embodiment of the present invention.
  • 117 and 118 illustrate an example of a process of retrieving address information through an address directory server according to another embodiment of the present invention.
  • Figure 1 shows an example of the configuration of the electronic document distribution system according to a preferred embodiment of the present invention.
  • an electronic document distribution system transmits and receives a message through a distribution messaging server that transmits and receives a message based on an electronic address and issues and manages a distribution certificate for message transmission and reception.
  • An electronic document distribution hub 102 for performing a message transmission and issuing a distribution certificate when an error occurs in the electronic document distribution process; And receive and store distribution certificates, and trustworthy third-party archives (public offices, authorized electronic document archives; 103); It is configured to include.
  • the distribution messaging server of the transmitting / receiving entity 101 stores the transmitted / received messages in the message box including status information for each user, and stores the message transmission / reception history in a medium which cannot be edited or deleted for a predetermined period, and distributes the message for transmission / reception. Issuing a certificate to the third-party storage organization for storage, and in connection with the address directory server of the electronic document distribution hub 102 to the electronic address registration, search, modification, deletion of the transmission and reception entity 101 It allows you to use a function that includes, and transfers the messages stored for a predetermined period to the external storage device.
  • the electronic address may include a user identifier obtained by the transmitting and receiving entity 101 through an address directory server of the electronic document distribution hub 102; An additional identifier that is a unique value assigned by the send / receive entity 101 when necessary, and is a value unique within the send / receive entity 101; A delimiter located between the user identifier and the additional identifier; It includes.
  • the electronic document distribution hub 102 is provided with an electronic document format register.
  • the electronic document format register performs management including registration, deletion, and information modification of an electronic document standard form. And classify additionally according to the above and perform management including registration and modification of the context in which the electronic document standard can be used.
  • the electronic document distribution hub 102 is provided with a distribution relay server for performing a message transmission and issuing a distribution certificate when an error occurs in the electronic document distribution process between the transmission and reception entity 101, the distribution relay server is a transmission and reception entity
  • the distribution relay server is a transmission and reception entity
  • a transmission certificate is issued to the transmission / reception entity 101 that has requested the message transmission after the message transmission is performed, and when the transmission of the requested message has failed, the transmission / reception entity 101 that has requested the message transmission. Send an error message to the.
  • the electronic document distribution hub 102 has an external linkage gateway server for linkage with an external system, and the external linkage gateway server has a distribution messaging server for transmitting and receiving a message based on an electronic address, and the linked external system.
  • Verification / translation function of sending / receiving electronic address between and electronic document distribution system, message verification / translation function between associated external system and electronic document distribution system, security verification applied to electronic document between linked external system and electronic document distribution system / It provides the function of converting and verifying the suitability of the electronic document between the connected external system and the electronic document distribution system and converting each other.
  • FIGS. 1 to 118 The electronic document distribution system and the electronic document distribution method using the same according to the preferred embodiment of the present invention having the above-described configuration will be described in detail with reference to FIGS. 1 to 118 as follows. In the following description of the present invention in detail, reference numerals of FIG. 1 will be omitted.
  • the requirements of the distribution system of the electronic document distribution system according to the present invention are as follows 1 to 7.
  • the sender / receiver entity participating in the distribution system and the sender / receiver must send and receive electronic documents in a predefined manner and agree to the service level agreement (SLA) of the management authority or the electronic document relay.
  • SLA service level agreement
  • the authorized electronic address which is the information for identifying the sender and receiver and the authorized sender and receiver in the distribution system, shall be assigned to a corporation or individual unit and registered and managed by the registrar.
  • a distribution certificate When distributing electronic documents in the distribution system, a distribution certificate must be generated and transmitted and stored to the sending entity and the third-party archiving organization that participated in the distribution.
  • a gateway that supports linkage with external systems other than distribution systems should be provided.
  • the electronic document distribution system is based on an authorized electronic address, and is based on P2P communication for sending and receiving electronic documents between transmitting and receiving entities owning a distribution messaging server.
  • the structure of the electronic document distribution system according to the present invention is as shown in Figure 1, the description of the components in the system is as shown in Table 1 and Table 2 below, the main process is shown in Table 3 below.
  • Table 1 number Object name Explanation One Send and receive objects A company or institution that has a system necessary for the distribution of electronic documents, such as a distribution messaging server, and participates in the distribution of electronic documents in a manner promised in the distribution system.
  • General concepts including electronic document relay 2 Electronic document repeater Third-party organizations certified to provide electronic document distribution services to senders and receivers who do not have the necessary systems for distribution of electronic documents, such as distribution messaging servers. 3 Electronic Document Distribution Hub It is the collective name for systems that support the distribution of electronic documents between sending and receiving entities. It performs tasks such as address management, routing, error and security processing, and external connection. 4 Transceiver End user who sends and receives actual electronic documents as a basic unit for distributing electronic documents.
  • General concepts including authorized senders 5 Authorized Transceiver Sender / receiver using electronic document distribution service by signing up for electronic document relay 6 Third Party Archive Corporations that hold or certify electronic documents for others or perform other business-related tasks as designated by the Minister of Knowledge Economy.
  • Object name Explanation One Distribution Messaging Server A messaging system that distributes electronic documents in a promised manner on behalf of the sender and receiver.
  • 2 Distributor client A general term for an application used by a sender and receiver to distribute electronic documents. An application that provides functions such as editing a message and sending and receiving a message through a distribution messaging server (eg, Outlook, webmail client, etc.).
  • 3 Address directory server A system that registers and manages the sending and receiving entities participating in the electronic document distribution system based on the authorized electronic address and the authorized electronic address of the sender and provides the necessary address information for sending and receiving.
  • 4 Electronic Document Format Register A system that registers, manages, and provides standard forms of structured electronic documents such as orders, invoices, and tax invoices for publicly available to send and receive entities.
  • Distribution relay server When an error occurs in the distribution of electronic documents between sending and receiving entities in the distribution system, a system that transfers messages on behalf of the sending entity 6 External Linkage Gateway Server A system that acts as a reliable channel for the distribution system to connect with external systems 7 NTP Server A server that sends time to systems that request time in the distribution system as a Network Time Protocol server. 8 Registration agency system System for registration agencies to handle applications such as registration and registration of authorized electronic addresses
  • the distribution messaging server is a messaging system within the sending and receiving entity and plays a key role in the distribution of electronic documents.
  • the distribution messaging server physically has one IP address, but must be able to issue and manage multiple user accounts for lower users.
  • the distribution messaging server In order to manage each user account, the distribution messaging server must manage the inbox for each user account, and the distribution messaging server is responsible for managing users' accounts and inboxes safely and reliably.
  • Table 4 number Function name Explanation One Send and receive messages -Send and receive messages according to distribution protocols 2
  • Inbox management by user -Received message is stored in the message box according to user account or internal delimiter.
  • the sent document stored in the message box is managed status information in 6 steps: 1) Sending: After receiving the document, no response is received from the receiver. Completion: Received 'receipt certificate' from the recipient's distribution messaging server.3) Outsourcing: After transmission failure, the transmission relayed to the distribution relay server. 4) Transmission failure: An error occurred in the distribution messaging server of the receiver.
  • Reading failed When an error occurs while the receiver is reading the message 6) Reading completed: 'Reading certificate' is received from the recipient's distribution messaging server -Received document stored in Inbox manages status information of the next 4 steps1) Verification error: Received message 2) Before acknowledgment: Before the recipient of the document reads the list of received documents 3) Acknowledgment: The recipient of the document reads the list of received documents 4) Confirmation of reading: The recipient of the document details the received document Read the contents-When the request for deletion is received by the receiver, the received document should be physically deleted.-The outgoing message, the receipt certificate, the reading certificate, etc.
  • Transmission history management The distribution messaging server must be able to store the transmission and reception history for a certain period of time in a medium that cannot be edited and deleted.-1) Transmission history information to be kept.
  • Hash value 2 Receiving history: Hash value for sender, receiver (including user account), reception time, received document 4
  • Message supplement -Message security functions digital signature, signature verification, encryption / decryption, etc. suggested by distribution protocol must be performed 5
  • Message packaging and validation processing The document to be sent must be packaged in a message structure defined in the distribution protocol before transmission. The received document must be verified and parsed by the message structure defined in the distribution protocol after extraction and the necessary information can be extracted.
  • Distribution certificate id Distribution certificate id, issuing time, related message id, original distribution certificate (optional), registration certificate of the third party storage institution received after storage in the third party storage institution, etc.
  • Address directory server linkage -Must be able to manage address information according to address information registration and retrieval process provided by address directory server-Must have client function to call service provided by address directory server-Address information provided by address directory server A service client function must be provided that remotely invokes the registration, search, modification, and deletion functions.
  • the distribution messaging server transmits the storage request message to the distribution messaging server installed outside the third-party archiving institution for the request for archiving the distribution certificate.
  • the distribution messaging server of the third-party archiving agency sends the distribution certificate to the third-party archiving institution.
  • Invoke custody request client for archiving -If the distribution messaging server of a third party archiving agency generates a distribution certificate directly, call the custody request client at the time of creation.
  • Requesting storage from a third party 9 Internal System Interface If the distribution messaging server is a corporate internal system rather than a distribution client, it must provide functions that can be directly linked with the internal corporate system.
  • Distribution client management Manage user account, user authentication, environment information related to distribution client 11
  • -Environmental information management Environment information management for the entire distribution messaging server and environment setting function for each user must be provided-Form management 12
  • Message Retention Management -System function to transfer to external storage for automatic preservation of messages stored for more than 1 year
  • the distribution client is an application that provides a user interface (UI) for transmitting and receiving messages, viewing and managing received electronic documents, etc. for the transceivers participating in the distribution system.
  • the distribution client cannot send or receive documents on its own and must be associated with a distribution messaging server.
  • the distribution client requests the message transmission through the distribution messaging server or inquires the message received through the distribution messaging server.
  • the distribution messaging server manages the message box for each user account, and the distribution client should be able to access only the messages stored in the user's account by checking the user account information among the received documents.
  • the distribution client may be implemented as a C / S type application or a web type screen by a request of a transmitting / receiving entity.
  • Table 5 number Function name Explanation One User authentication -The distribution client must receive the login session information after checking the user account from the distribution messaging server.-The method for the distribution client to authenticate the user is 1) user authentication based on the certificate or 2) ID / PW based. User authentication, etc.-When operating based on ID / PW, security policy for PW should be enforced. Weekly PW change, difficult letter / number combination, IP address change prohibition, etc. 2 Generate message -The distribution client must provide a user interface to compose a new message.-Providing entry of items that are not preset values by environmental information among basic information required to transmit a message.
  • View message list and view details -The distribution client must provide the function to query the list of each message corresponding to the user account.-The client should provide the function to view the detailed information of the message, including the attached document.
  • Message folder management The distribution client must inform the user of the status of each message according to the status information provided by the distribution messaging server for the sending and receiving messages based on the distribution box of the distribution messaging server. Providing the ability to define and manage your own message folders is optional.
  • Basic and environmental information management -The distribution client must provide the function to manage the necessary environmental information related to sending and receiving messages.-The distribution client must be synchronized with the environmental information managed by the distribution messaging server.
  • Message security processing -Must be able to secure messages such as digital signature or encryption / decryption
  • Register and retrieve document templates -Ability to register an electronic document form register or an electronic document form located outside as a distribution client-A function to search an electronic document form within a distribution client 10
  • Address Book Management -Function to manage frequently used public electronic addresses, etc. Optionally implement the function to automatically register and manage public electronic addresses through received messages 11
  • Link with in-house system -Linkage function such as registering electronic documents in messages with groupware and work-related systems in the enterprise 12
  • the relevant information such as distribution certificate and log information should be comprehensively processed to understand the context related to the message.
  • the address directory server is a system for managing the address information for the sender / receiver entity and the authorized sender / receiver, and provide a physical address.
  • the address directory server provides the following basic functions: 1 and 2.
  • IP address physical address
  • the address directory server basically has a function of managing whitelist information.
  • the address directory server receives a report of a spam message from a user and manages blacklist information based on the report.
  • the address directory server provides information related to the public electronic address to the send / receive entity or authorized sender through the web portal screen, and the distribution messaging server and related applications can use the services provided by the address directory server through the associated interface.
  • FIG. 4 A functional conceptual diagram of the address directory server is shown in FIG. 4, and a description of the functions is shown in Table 6 below.
  • Table 6 number Function name Explanation One Certified Electronic Address Management -Management of new registration and change of public e-mail address of the sending and receiving entity and the authorized e-mail address.
  • Spam report management -Receipt of reports on spam received from distribution clients and result notification 3
  • White / Black List Management -Create and manage / storage whitelist a list of authorized electronic addresses-Receive and process search requests for whitelists-Manage and create blacklists for publicly available electronic addresses used for inappropriate purposes such as spam-Search functions for blacklists
  • Web portal management -Provide user interface related to address management-Provide system administrator interface related to address management-Manage system environment information of address directory server-Manage various statistical information related to address
  • the electronic document format register is a system provided by the electronic document distribution hub so that it can be automatically processed by using a standard electronic document previously promised between transmitting and receiving entities, or an electronic document in an e-form form can be utilized.
  • the electronic document form register provides a server engine that manages electronic document forms, an interface that provides a function for a distribution client to search and download, and a web portal interface.
  • FIG. 5 A functional conceptual diagram of the electronic document format register is shown in FIG. 5, and a description of the functions is given in Table 7 below.
  • the distribution relay server is a system in the electronic document distribution hub. When an error occurs in the electronic document distribution process between the sending and receiving entities in the distribution system, the distribution relay server substitutes the message for the transmitting entity.
  • the distribution relay server internally integrates the functions of the distribution messaging server, it not only provides basic electronic document transmission and reception services, but also connects services such as reception of relay requests only by the distribution relay server and transmission of error messages in the event of a final failure. Provided to distribution messaging server through interface.
  • FIG. 6 A functional conceptual diagram of the distribution relay server is shown in FIG. 6, and a description of the functions is shown in Table 8 below.
  • Table 8 number Function name Explanation One Message Routing Information Processing Routing function for distribution messaging server in sending / receiving object 2 Reprocessing in case of transmission error Function to handle resend when error occurs when sending message to receiving object 3 Send certificate Issuing certificate of transmission to sending entity requesting message transmission 4 Error message sent when transmission fails Sending error message to sending object when requested message transmission fails 5 Electronic document relay request Function to request message relay in connection with distribution messaging server 6 History / statistical information management Store and process history or statistical information related to message distribution 7 Relay Status Monitoring Provides relay relay status for sending / receiving object and relay status monitoring function by system administrator
  • Externally linked gateway server is a system that acts as a reliable path for linking external systems with existing distribution systems that are difficult to include or operate in the distribution system.
  • An external gateway server can be used as a channel for linking these systems. It can serve as a channel for linking with the public sector as well as other external systems.
  • FIG. 7 A functional conceptual diagram of an external linkage gateway server is shown in FIG. 7, and a description of the functions is shown in Table 9 below.
  • Table 9 number Function name Explanation One Distribution Messaging Server Module Use some of the features on the Distribution Messaging Server 2 Validation / Conversion Module Module to verify / convert corresponding to each external system to be linked 3 Electronic Address Verification / Translation Verification and translation function of sending and receiving address between distribution system and external linked system 4 Message package verification / conversion Verification and conversion function of message package between distribution system and external linkage system 5 Electronic document security verification / conversion Security verification and conversion function applied to electronic documents between distribution system and external linked system 6 Document Conformance Verification / Conversion Ability to verify the suitability of electronic documents between distribution systems and externally linked systems and to convert each other. 7 System administration System management of the external linkage gateway server 8 Statistical Information Inquiry Statistical information search function related to the use of external linkage gateway
  • the public electronic address consists of a combination of sharp [#], numeric [0-9], hyphen [-], and period [.].
  • the structure of the authorized electronic address is shown in Table 10 below.
  • the first part of "#” consists of a combination of letters [AZ] [az], Hangul [completed Hangul 2,350 characters], number [0-9], hyphen [-], and period [.].
  • additional user identifiers may be used.
  • the user addition identifier is self-managed by the electronic document distribution messaging server.
  • the user additional identifier of the authorized electronic address shall not start or end with a hyphen or period and shall be 30 bytes or less in length.
  • the user's additional identification code of the authorized electronic address shall not use social symbols, combinations of letters and numbers that harm the morals, and other restrictions set by the head of the management authority.
  • the public electronic address and the real physical address of the distribution message server have a relationship of 1: 1 or N: 1, and thus there is no case where one public electronic address has several physical addresses.
  • the entity shall be responsible for its own distribution by user additional identifier.
  • the sending / receiving entity shall prepare the policy and management method for user authentication corresponding to the user additional identification symbol, and should be thoroughly managed according to the method.
  • the sending and receiving entity should enter into a service level agreement (SLA) with the management authority, including the contents of the authorized electronic address including the internal identifier, before participating in the distribution system.
  • SLA service level agreement
  • the validity range of the authorized electronic address in the distribution system may be expressed as shown in FIG. 8.
  • the additional user identifier must be unique within the sending and receiving entity.
  • the method of assigning additional user identification symbols is based on the individual sending / receiving entity's responsibility.
  • the distribution of electronic documents by the user additional identification symbol is also the responsibility of the sending / receiving entity.
  • Such additional user identification symbols are not included in the scope of the distribution system, but may be defined by a service level agreement (SLA) with a management agency.
  • SLA service level agreement
  • the user additional identifier is used to distribute electronic documents for the convenience of the company, and is used only as information inside the company without registering in the address directory server.
  • the "ID” is composed of a combination of alphabets (or Korean numerals), hyphens [-] and periods [.],
  • the "separator” is #, and the "registrant” is English (or Korean, Number) and period [.].
  • Table 11 Component role Management Institution (Head of Certified Electronic Address Management) -Management authority manages the authorized electronic address information of the negotiated authority as the highest management authority of the authorized electronic address-Issue and change the unique public electronic address ID for the sending and receiving objects and authorized senders Registration agency -Organizations that apply for and review public electronic addresses with the authority of management authority Send and receive objects -The most basic unit of the authorized public e-mail address (registration address)-In the case of enterprises / institutions, issue, manage and guarantee uniqueness of user accounts or additional user identification symbols for multiple users under one public e-mail address.
  • Sender -Real users participating in the distribution of electronic documents have a publicly available electronic address with a user account opened through an electronic document relay, and are a sending and receiving unit that is legally responsible. Transmitting / receiving unit managed through User Add Identifier within, not legally responsible, not registered with e-mail directory server
  • the electronic document information package is required to support the automatic registration or processing of the electronic document in an enterprise internal system such as groupware by specifying metadata about the electronic document included in the message.
  • Electronic document information packages are not essential to the distribution of messages and can therefore be used selectively where they are needed for business purposes. However, when using the product, the following requirements must be observed.
  • the electronic document information package shall be transmitted in a file separate from the electronic document included in the message.
  • the metadata of the electronic document information package is shown in Table 12 below.
  • Electronic document type classification necessary Identifier distinguishing whether the electronic document is an electronic document registered in the electronic document form register, an electronic document used in an enterprise / institution, or an own electronic document 0: Electronic document in the electronic document form register 1 Commonly used electronic document2: Electronic document used by itself 4 Electronic document type identifier Select Identifier that identifies the type when the electronic document type distinction is 0 or 1 5 Electronic signature value Select Digital signature value for the electronic document 6 Other information Select Other information related to electronic documents
  • the security of the distributed message includes 1 non repudiation of transmission / reception, 2 guarantee of integrity of transmission message, 3 authentication of transmission party, and 4 security of transmission message.
  • 1, 2, 3 may be supported by the sender's digital signature for the transmission message, and 4 should be provided through encryption of the transmission message.
  • Security applied in the distribution of electronic documents between distribution messaging servers which are the most basic of the distribution system, supports message electronic signature and encryption as shown in FIG. In each section, network encryption should be applied for transmission security.
  • the digital signature on the content is a unique area for each application and is not mentioned in the description of the present invention.
  • the encryption of the receiver public key is basic, but if there is no certificate of the receiver or the receiver is an internal transceiver, only the receiver object encryption can be selected.
  • the authentication information is mainly used for the purpose of authenticating the client to the distribution messaging server.
  • the distribution messaging server may adopt various authentication methods such as ID / PW based, token information based on single sign on (SSO), in addition to certificate-based digital signature.
  • the distribution messaging server must be digitally signed based on its own certificate when connecting to other systems (other distribution messaging servers, address directory servers, distribution relay servers). All distribution messages for linkage between components in the distribution system should basically be digital signatures, but the digital signature between the distribution client and the distribution messaging server is optional and applies only to certificate-based user authentication. In this case, however, the distribution messaging server must take full responsibility for user authentication, integrity, and non-repudiation of transmission / reception of distribution messages with the distribution client.
  • Documents attached to the distribution system can be sent after the sender chooses encryption for security. This part is for confidentiality of documents and is different from network encryption, and even if network encryption is applied, the distribution document can be additionally encrypted.
  • the encrypted section may be from the distribution client of the sender to the distribution messaging server of the receiver or the distribution client of the sender to the distribution client of the receiver. If the receiver is an authorized sender / receiver and the public certificate is registered in the address directory server, encryption is performed in "2 sender to receiver” section. Otherwise, encryption is performed in "1 sender to receiver object” section. Is performed.
  • the sender When encrypting the attached document, if the sender is kept encrypted in the "1 sender to the receiving object" section, the sender can decrypt all three steps: the sender's distribution messaging server, the receiver's distribution messaging server, and the receiver's distribution client. It should be encrypted. If encryption is to be maintained in the section "2. From sender to receiver", the sender shall encrypt the sender's distribution messaging server and the receiver's distribution messaging server so that they can be decrypted.
  • the distribution messaging server of the sending object and the receiving object stores the attached electronic document in encrypted state for the history management.
  • the sender and receiver want to verify the distribution certificate based on the decrypted document, It should be possible. To this end, the distribution messaging server must continue to manage the private key and password for accessing the revoked certificate.
  • the ciphertext uses the Enveloped-Data Content Type represented by the ContentInfo structure presented in IETF RFC 3852 "Cryptographic Message Syntax" (CMS), which is used in various standards at home and abroad.
  • CMS Chromatometic Message Syntax
  • the IETF is the subject that defines the standards for Internet operating protocols such as TCP / IP.
  • the IETF is overseen by the Internet Architecture Board (IAB), the Internet Society's oversight body for the technological evolution of the Internet.
  • IETF members are selected from members of individuals or organizations of the Internet Society.
  • the standards produced by the IETF are represented in the form of RFCs, and many domestic and international PKI-based solutions (such as various certification systems, timestamps, and third-party archival standards) are based on these RFC standards documents.
  • CMS Cryptographic Message Syntax
  • the encryption targets of the delivered message are as follows.
  • Text and attached documents in the body of the message are each encrypted independently and stored in the location.
  • the first encryption target is the contents of the body to be delivered to the receiver, targeting the value in the ⁇ Text> item of the XML body.
  • Data complies with ASN.1 Basic Encoding Rules (BER) and ensures compliance with Distinguished Encoding Rules (DER).
  • BER Basic Encoding Rules
  • DER Distinguished Encoding Rules
  • MainText in Table 13 above is the text content.
  • Data to be encrypted after the second is an attached document attached from the third MIME, and is encrypted in each attachment document unit and then entered into the corresponding MIME.
  • AttachedDoc in Table 14 above is a binary attached document.
  • Table 15 below shows the composition of EnvelopedData of RFC 3852.
  • EnvelopedData SEQUENCE ⁇ version CMSversion, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, recipientInfos RecipientInfos, encryptedContentInfo EncryptedContentInfo, unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL ⁇
  • iginatorInfo is not used because there is no need to send CRL without using key management algorithm. (As defined in RFC 3852)
  • the recipient can pass a content-encryption key through KeyTransRecipientInfo of RecipientInfos.
  • the main text or AttachedDoc is encrypted based on the algorithm of Algorithm Identifier.
  • EncryptedContentInfo SEQUENCE ⁇ contentType ContentType, contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL ⁇
  • ContentType contains id-data (identifier-OID-information that tells what the encrypted data is).
  • contentEncryptionAlgorithm contains information about the symmetric key algorithm used for the actual encryption.
  • the input of encryptedContent is OCTET STRING (Binary value) which encrypts the DER encoded value of TaxInvoicePackage defined above by the algorithm defined in contentEncryptionAlgorithm.
  • the object to be decrypted is the sending object and the receiving object, the receiver is possible only when there is a public certificate, so the actual RecipientInfos have at least two to three RecipientInfo.
  • the cryptographic certificate uses RSA, it should be configured using only ktri (sending a symmetric key that encrypts data using a partner RSA public key, etc.).
  • Object Identifier for message composition is as follows 1 and 2.
  • 1EnvelopedData Type RFC3852
  • ContentInfo The format that delivers actual data in CMS is a structure called ContentInfo, and it is information to put in ContentType to check what data is inside.
  • Table 18 -id-envelopedData- OBJECT IDENTIFIER ⁇ iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs7 (7) 3 ⁇
  • ContentType of EncryptedContentInfo Information that is put in ContentType to check what data is in the EncryptedContentInfo structure, which is a structure that puts encrypted data.
  • the public key algorithm uses the RSA based algorithm because the certificate used is a cryptographic certificate of the GPKI or NPKI scheme.
  • the symmetric key algorithm one of three symmetric key cryptographic algorithms (SEED, ARIA, 3DES) Should be chosen and used.
  • the sender may support only one of the three symmetric key encryption algorithms, but the receiver must support all three algorithms.
  • Asymmetric Key Algorithm It is used to securely transmit symmetric key information that is randomly generated and encrypts data to the other party.
  • An example is shown in Table 20 below.
  • the sender To generate the ciphertext, it is possible to obtain the certificate of the receiver side to decrypt the actual data.
  • the sender To obtain a certificate, the sender must obtain a certificate for the recipient (or recipient) in conjunction with the address directory server. At this time, the interval in which confidentiality is maintained depends on whether the acquired certificate is a certificate of a receiving object or a certificate of an authorized recipient.
  • the sender When the sender selects encryption for the transmission message, the sender performs encryption based on the obtained receiver (or receiving object) certificate and then sends the message to the receiver. Even if an error occurs during the message transmission process and a message is sent to the distribution relay hub, the encrypted content is transmitted without change.
  • FIG. 12 shows an encrypted text delivered to an actual receiver, and it will be possible to more accurately grasp the association of actual values.
  • -ContentInfo It is expressed in RFC 3852 and is a kind of container that puts SignedData, EnvelopedData, EncryptedData, etc., which are configuration data of RFC 3852.
  • the contentType of the structure indicates what information the content is. In this guideline, an identifier of id-envelopedData should be inserted.
  • EnvelopedData A structure for passing encrypted information (see the description in the previous section).
  • EncryptedContentInfo A structure that holds encrypted information.
  • the contentType of the structure indicates what information the encryptedContent is.
  • the identifier (id-data) should be inserted.
  • the contentEncryptionAlgorithm must put an identifier (OID) for one of SEED, ARIA, or 3DES, and puts data encrypted by the algorithm using OCTET STRING (binary data) using a randomly generated secret key in encryptedContent.
  • RecipientInfo This structure selects which method to use to decrypt the receiver. This guideline should use KeyTransRecipientInfo.
  • KeyTransRecipientInfo This structure is used to encrypt and deliver the random private key which encrypted above encryptedContent so that receiver can decrypt using receiver's public key.
  • Encrypted secret key is put in encryptedKey and includes RecipientIdentifier which is information about who used public key and KeyEncryptionAlgorithmIdentifier which is algorithm information used to encrypt secret key.
  • the receiver receiving the encrypted electronic document decrypts the encrypted body and the attached document according to the procedure described with reference to FIG. 12.
  • the recipient can obtain the plain text body and the attached document by decrypting the encrypted body and the attached document, respectively.
  • Step 1 Extract the EnvelopedData structure from the ciphertext and read it
  • Step 2 Extract the decryption information structure (RecipientInfo) from the EnvelopedData structure and obtain encrypted symmetric key information (KeyTransRecipientInfo) from the extracted decryption information structure.
  • RecipientInfo decryption information structure
  • KeyTransRecipientInfo encrypted symmetric key information
  • Step 3 The receiver decrypts the encryptedKey extracted from the encrypted symmetric key information with the receiver's private key (mapped with the certificate's public key) to obtain the symmetric key used to encrypt the body and the attached document.
  • Step 4 Get the encrypted structure of the body or attached document from the EnvelopedData structure extracted in step 1.
  • Step 5 Decrypt the encrypted text or attached document extracted in Step 4 using the symmetric key obtained in Step 3.
  • Step 6 Obtain the final decrypted text and attached documents.
  • Networks in all sections of the electronic document distribution (between the sender's distribution client and distribution messaging server, between the sender's and receiver's distribution messaging server, and the receiver's distribution messaging server and distribution client) for the confidentiality of messages distributed between the sender and receiver.
  • SSL Secure Sockets Layer
  • the message transceiving process is a process in which documents are exchanged with each other, such as mail or e-mail, in a form of directly sending and receiving messages between a sender and a receiver.
  • Table 22 number Process name Explanation One Obtain physical address and security information for the recipient ⁇
  • the sending object obtains this by requesting the address directory server for the physical address information and security information (if the receiving password for the outgoing message) to which the actual message should be delivered, based on the address information of the other party.
  • the address directory server checks whether the requesting public object's public electronic address is blacklisted or whitelisted (if it is on the blacklist, notifies the sending object of a message transmission error).
  • the sending entity packages the message according to the technical specifications and then performs the digital signature based on the public certificate of the distribution messaging server.
  • the distribution messaging server packages the message to the physical address obtained and sends the electronic signature message.
  • the distribution messaging server of the receiving object verifies the basic packaging structure of the message, the validity of the digital signature, and the suitability of the sender, and then generates a receipt certificate or an error message for acknowledgment.
  • the created receiving certificate is transmitted to the sending entity.
  • the distribution messaging server of the sending object receives the receiving certificate, 1) verifies the suitability of the receiving certificate, 2) attaches the verified information to the receiving certificate, and 3) the receiving certificate itself. Request for storage and storage to 3rd party archival organization 3 Acknowledgment of work recipient ⁇
  • the sender requests the certificate of reading of the receiving object at the time of message transmission, the receiving object generates and sends a reading certificate that can confirm the reading confirmation to the sending object at the time of reading the message.
  • the sending entity Upon transmission, the sending entity receives 1) verification of the validity of the reading certificate, 2) attaches the verified information to the reading certificate, 3) keeps the reading certificate in-house and asks the third party archiving agency, 4) receives it.
  • Send acknowledgment messages synchronously to the object 4 Issuance and Storage of Distribution Certificate ⁇
  • the sending entity receives the certificate for receiving, reading and sending according to each stage from the receiving entity or distribution relay server, and keeps it in the third-party storage institution. Secure grounds for proof
  • the message transmission / reception process can be divided into a transmission process and a reception process, and the transmission process is divided into synchronous transmission and asynchronous transmission by a linkage method between a distribution client and a distribution messaging server.
  • the synchronous message transmission and reception process when a distribution client of a sending entity requests transmission to a distribution messaging server, the synchronous message transmission and reception process is a real time transmission to the distribution messaging server of a receiving entity and a response is synchronously returned through the distribution messaging server of the sender. Synchronous processes can simplify the definition of business processes because the distribution client can immediately see the results of the transmission.
  • the asynchronous transmission process verifies only the validity of the transmission request to the distribution messaging server and returns an acknowledgment message for the request to the distribution client. This is a process of sending a real-time transmission to the distribution messaging server of the receiving entity and receiving a response synchronously through the distribution messaging server of the sending entity.
  • Asynchronous processes are used in situations where the client is unable to wait for a response because it takes a long time for the message to be sent, such as when the message to be sent is large or when multiple recipients are specified for a message.
  • the distribution client connects to the distribution messaging server and makes a request for receiving a message to get the message received from itself. ⁇ If there is a response message sent from the receiving object, the distribution client receives it as a response message. 5 Acknowledgment of work recipient ⁇ Same as above message sending / receiving process 6 Issuance and Storage of Distribution Certificate ⁇ Same as above message sending / receiving process
  • the process of receiving a message through the distribution client by the document receiver is shown in FIG.
  • the recipient's distribution messaging server receives the message from the sender, it sends a receipt in response to the message and puts the document in the final recipient's message box.
  • the distribution client requests the list of the received messages from the distribution messaging server from time to time, and if there is a newly received message, the distribution client receives the received message list as a response message, and gets the received document through the message requesting detailed information.
  • Table 25 number People Explanation One Receive a message ⁇
  • the receiving object When the receiving object receives a message, the receiving object returns a receiving response message for the received message to the sending object and keeps the received message in the user's mailbox. 2 Inbox List Get ⁇
  • the receiving client's distribution client authenticates with the associated distribution messaging server system and requests the receiving document.
  • the receiving object's distribution messaging server sends the list of received documents stored in the mailbox of the user who requested the receiving document to the distribution client in a synchronous response.
  • relay 3 Received Documents Get ⁇
  • the distribution client When the recipient requests to view the details of a message in the list of incoming messages, the distribution client requests the distribution messaging server system to deliver the details, including the attachment of the message.
  • the recipient's distribution messaging server system sends a message containing the reading certificate to the sender of the message when the user requests detailed information on the received document.
  • a reading certificate should be generated and delivered to the sender's distribution messaging server.
  • the receiving distribution messaging server delivers the decryption error message to the sender instead of the reading certificate.
  • the sending entity participating in the distribution system must know the physical real address information based on the public electronic address information before sending the message to the other party. Additionally, in order to encrypt the attached document, the recipient's disclosure in the address directory server is required. The key information must be obtained.
  • the procedure for acquiring the physical address of the public electronic address is an essential step, as described below.
  • the sending object queries the address directory server to obtain the physical address information and security information of the receiving object based on the address information of the receiving object.
  • the address directory server processes the query after receiving / verifying the query of the sending object.
  • the sender sends a message to the receiver by setting a route based on the received physical address.
  • the distribution messaging server of the receiving object receives it and distributes the message internally according to user account or internal delimiter.
  • the physical address of the authorized electronic address in the distribution system can be classified into two types, as shown below 1 and 2.
  • the distribution client When the distribution client enters the recipient's address information, it makes a request to the address directory server to get the physical address and the recipient's public key: 1) To check the validity of the certified electronic address in advance, 2) The distribution client Message encryption between the server and the distribution messaging server (sending object)
  • distribution messaging server gets physical address from address directory server
  • 19 is a process of acquiring the physical address and security information of the authorized electronic address.
  • the distribution system is based on direct communication (P2P) between the transmitting and receiving objects.
  • P2P direct communication
  • a relay process for relaying / representing the distribution is provided for the user's convenience and smooth support of the distribution.
  • the distribution relay server in the electronic document distribution hub proves the transmission object by entrusting / transmitting the message on behalf of the sending object. It reduces the system burden on the sending entity.
  • FIG. 23 is A basic flow is presented, and FIG. 24 shows a process in which a distribution relay server relays a message.
  • Table 26 below illustrates the distribution relay process step by step.
  • the sender sends a message to the receiver after packaging and securing the message.
  • the received distribution relay server synchronously issues and transmits a certificate to the sender.
  • Message consignment relay ⁇
  • Distribution relay server sends a message that has been relayed. If transmission fails, retries are attempted at regular intervals (the number of retries and the interval is determined according to the policy of the distribution relay server). Passing 3 Receive and read certificate ⁇ After the receiving object has received the message normally, the receiving certificate is sent to the distribution relay server. ⁇ After the recipient has read the electronic document, the receiving object sends the reading certificate directly to the sending object without passing through the distribution relay server.
  • a distribution certificate must be generated and stored in a third party repository. This is because the distribution certificate containing the distribution evidence can be stored in a legally recognized third-party storage institution, thereby obtaining legal estimation of the distribution fact.
  • the process of storing distribution certificates is a separate process from the distribution of electronic documents, and it is a supporting process to prove the fact of distribution.
  • all distribution messaging servers must be subscribed to a specific third party archiving agency with the ability to receive and store distribution certificates in advance.
  • the entire message may be stored in a third-party storage institution in addition to the distribution certificate.
  • Distribution messaging server of 3rd party custodian agency System that is required to send and receive distribution messaging with distribution messaging server in distribution system
  • Third party storage organization linked client module Module for communicating with the third party storage organization linked interface to store the distribution certificate received through the distribution messaging server of the third party storage institution.
  • a distribution messaging server may not be additionally required.
  • FIG. 28 illustrates a process of storing a distribution certificate between a transmitting and receiving entity and a third party storage institution operator.
  • the process of storing the distribution certificate is shown in Table 27 below.
  • the sender's distribution messaging server receives the distribution certificate from the recipient's distribution messaging server. ⁇ If the receiving certificate is received from the receiving distribution messaging server or if the receiving certificate is received from the relay hub, the distribution certificate is received by the response message. If you receive a certificate of receipt through a relay hub or receive a distribution certificate by request message 2 -If the validity of the received distribution certificate is verified, the distribution certificate and certificate verification information are transmitted to the distribution messaging server of the pre-set third-party archiving organization. Request for retransmission by notifying the verification error message ⁇ If the distribution certificate is received as a request message, send the verification error message as a response message (synchronous) ⁇ If the distribution certificate is received as the response message, send the verification error message with a new request message.
  • the public electronic address information management process includes a management process for registration, modification, and deletion associated with the public electronic address, and a blacklist / white list management process.
  • the management agency manages the authorized electronic address by setting up a certified electronic address registration agency for efficient management of the authorized electronic address.
  • the registration agency performs the following tasks: 1 to 4.
  • the management agency may select a third party archiving agency and an electronic document relay who satisfy the requirements as the registrar.
  • the information related to the registered official electronic address may be changed for various reasons, but the official electronic address and the owner information cannot be changed because they must maintain the same identity.
  • the authority to change information related to the public electronic address should be delegated to the registrar. However, historical information on the change of information should be kept in accordance with the service level agreement (SLA) between the management agency and the registrar.
  • SLA service level agreement
  • a related process is the same as that of FIG. 23, and referring to FIG. 23, only the authorized electronic address can be changed.
  • the public electronic address, registration number, and name cannot be changed, so the public electronic address must be withdrawn and newly created.
  • the authorized electronic address cannot be changed, and the registration number (business registration number) and the business name must be changed with the new official certificate received after being changed with the corresponding information.
  • the address directory server should be able to request temporary suspension of public electronic addresses.
  • the address directory server allows the user to select a temporary suspension of the official electronic address when leaving the public electronic address, thereby maintaining the official electronic address for a certain period of time when the registrar is changed.
  • the registered registered electronic address must be updated in accordance with the established service life. After registration of the public electronic address, the owner must renew before the expiration date set in accordance with the service policy. If the owner does not renew, the ownership of the public electronic address is lost and the public electronic address is automatically erased.
  • This process is to increase the utilization of the post-message distribution step.
  • This is to process the electronic documents contained in the message in an automatic or semi-automated manner in the corporate internal system.
  • the distribution messaging server is dedicated to sending and receiving messages between the parties, and the distribution client provides an interface for the sender and the receiver to easily send and receive messages.
  • the next step is to utilize the electronic document in the message.
  • the electronic document form register or electronic document form provides a method for more efficient operation of the electronic document utilization step.
  • This additional function introduces the electronic document exchange (EDI) function, which can automatically convert the electronic document received from the internal system of the receiving object by transmitting and receiving document data based on the promised electronic document format between the transmitting and receiving objects. It was.
  • EDI electronic document exchange
  • the form of the electronic document can be used in two ways as follows.
  • the enterprise, institution or individual user can retrieve the electronic document form registered in the electronic document form register, and then register and use it in the distribution client. There are two ways to use the electronic document format register as follows 1 and 2.
  • the electronic document is retrieved from the electronic document form register site, downloaded to the local PC, and registered and used in the distribution client.
  • the management institution should operate / manage systematically to have the following criteria.
  • Table 28 division Explanation Remarks area Distinguish whether the electronic document can be distributed internationally, in a specific region, or only in a specific country Sphere door Whether the syntax applied to the electronic document is EDIFACT based, XML based, or private format industry Used when the electronic document only applies to specific industries. For example, whether a purchase order is used in the trade sector or in the manufacturing, distribution, and logistics sectors. product
  • the electronic document uses a specific company product format. Whether it is in PDF format or a specific company e-Form format Enterprise Distinguish when the electronic document is only available to certain companies Other If it can be divided into other contexts (contexts) other than the above
  • FIG. 25 illustrates a basic flow of a process for utilizing an electronic document format register. Specifically, FIG. 25A illustrates a case in which an electronic document format register and a distribution client are directly connected. FIG. 25B shows an electronic document format register site. The case of using is shown.
  • Table 29 below describes the process of using forms in direct connection with distribution clients.
  • Table 29 Number division Explanation One Electronic Document Format Search Retrieve electronic document forms from the electronic document form register directly from the distribution client 2 Get Format If a form is found, import it to the distribution client 3 Form registration Registering a form imported into a distribution client with a distribution client 4 Import / Create Electronic Document Formats Import an electronic document form registered in a distribution client, create an electronic document, and attach it to a message
  • Table 30 below shows the process for using the Electronic Document Format Register site.
  • the purpose is to distribute the tasting at the site operated by the company, etc., for the purpose of doing business with the parties related to the particular company.
  • FIG. 26 illustrates a procedure using an agreed electronic document format, and a description of the process associated with FIG. 26 is given in Table 31 below.
  • Table 31 Number division Explanation One Electronic document template distribution Entity A distributes electronic document forms that can be handled by its system on its own website, allowing them to use them in their businesses. 2 Save Form to Local PC Enterprise B2 downloads form from website and saves it to local PC 3 Form registration Register the form stored on the local PC to the distribution client of Entity B 4 Import / Create Electronic Document Formats Import an electronic document form registered in a distribution client, create an electronic document, and attach it to a message 5 Send message Send messages through distribution messaging server 6 Automatic / semi-automatic processing of attached electronic documents Register the electronic document attached to the received message automatically or semi-automatically in the company A's internal system by converting
  • the sender transmits through the authorized distribution messaging server, and the receiver also receives through it. Therefore, the sender has an infrastructure to hold the sender accountable when spam is sent.
  • the distribution system provides a system that can manage the white list based on the certification list management, the black list with spam or malicious intention, and enhance the safety and reliability of the distribution system. .
  • the function to report spam message and to check the sending party is an essential function. All distribution messaging servers must build this function.
  • the address directory server that received the spam message report from the distribution messaging server returns a confirmation message that it was received.
  • the authority that manages the address directory server analyzes the message and examines the sender to examine and determine whether to add a blacklist for the sender's public electronic address.
  • the address directory server adds the public electronic address to the blacklist and notifies the sender of the blacklist addition.
  • the address directory server forwards the results of the spam message request to the spam reporter (recipient).
  • the receiver determines that the received message is a spam message, the receiver reports the spam message to the address directory server by the process shown in FIG. 27.
  • Blacklist If the sender's address is registered as a spammer, it is registered as a blacklist.
  • the management agency may decide to cancel the authentication of the distribution message server, and then cancel the authentication and delete it from the whitelist.
  • the receiving entity When the receiving entity receives the message, the receiving entity checks the whitelist and the blacklist of the address directory server to confirm whether the sending party is a reliable and legitimate user, and then decides whether to reject the receiving party.
  • the sender can be checked at the time of reception by checking 1 in real time or by checking the list managed in the form of cache in the distribution messaging server system of the receiver.
  • Real-time confirmation process At the time of receiving a message, the receiving object determines whether the address of the sending object is registered in the whitelist or blacklist in the address directory server and then decides whether to reject the message.
  • Table 33 number People One When the recipient's distribution messaging server receives the message, it sends an acknowledgment message to the address directory server to verify that it is a legitimate user. 2 The address directory server checks whether the address information of the requested user is included in the whitelist. 3 If the address is not on the whitelist, the address directory server immediately returns a result message indicating that the user is not registered to the verification requester. 4 The address directory server returns a result message for the blacklist registration to the verification requester. 5 If the receiver receives the result message from the address directory server as the sender is not a legitimate user (when it is not in the whitelist or is registered in the blacklist), the recipient processes the received message as a spam message and then receives the processing result message received from the address directory server. Record and keep track of spam messages 6 The processing history of spam messages must be kept for more than a month to confirm the validity of the rejection of the sender.
  • Periodic verification process Recipient receives periodic whitelist and blacklist from address directory server and manages itself and based on this, determines whether sender's address is registered in whitelist and blacklist, and then decides whether to reject the message.
  • Table 34 number People One Distribution messaging server of receiving object requests the latest whitelist and blacklist from address directory server in advance and manages itself. At this time, when the change of the list occurs, the automatic notification request is delivered together. (Even when the automatic change notification is requested, the request for bringing the latest list to the address directory server is periodically performed so that the list information does not differ more than 1 day. box) 2
  • the address directory server broadcasts the change to the user who requested the change notification when the change occurs in the whitelist and blacklist.
  • the distribution messaging server receiving the change of the list synchronizes by modifying the information of the self-managed list. 4 When a recipient receives a message, it checks its own managed list to determine whether the user is a legitimate user on the address directory server.
  • the receiver determines that the sender is not a legitimate user (when it is not in the white list or is registered in the black list) as a result of the self-managed list check, the receiver processes the received message as a spam message and records and archives the spam message receiving history. 6 The processing history of spam messages must be kept for more than a month so that the validity of the rejection of the sender can be verified.
  • 29 shows a process for periodically checking for managing spam messages between a distribution messaging server and an address directory server.
  • All errors for synchronous transmissions are based on retransmissions, since the sender can see them immediately.
  • the retransmission method is determined by the system policy of the company or organization participating in the distribution system, but for the same message transmission, the same messageId value is set and resent.
  • Types related to synchronous error handling are as follows 1 to 4.
  • Request message transmission failure When the sender transmits a message and a transmission error occurs, the request message cannot be delivered to the receiver. The sender recognizes the transmission failure through a timeout or network error message for the transmission attempt. .
  • 3rd stage synchronous error The distribution of messages between three entities linked to other distribution messaging servers, address directory servers and distribution relay hubs through distribution messaging servers is synchronously linked to immediately confirm the final result among the types of associations. Support the way. In the process, if an error occurs in the linkage step between the distribution messaging server and the receiver, the distribution messaging server immediately generates an error and then delivers it to the distribution messaging server as a response message.
  • the distribution of messages between three distribution clients connected to other distribution messaging servers, address directory servers, and distribution relay servers through distribution messaging servers also supports asynchronous connection so that distribution clients can operate independently of the final recipient's situation. do.
  • the final error for the asynchronous transmission cannot be immediately confirmed by the sender. Therefore, an error message for the distribution client should be generated when the distribution messaging server finally confirms the error, and the distribution client can receive it.
  • the electronic document reading service is a service that provides access to electronic documents stored in the sender's system or a third-party archival institution, rather than an exchange of electronic documents directly between the sender and the receiver.
  • the electronic document reading service uses the existing distribution system. However, the sender does not transmit the message containing the electronic document to the receiver, but transmits the message containing the right to view the electronic document stored in the sender system or the third-party archive.
  • the electronic document reading service can be divided into a method of using a sender using its own system and a method of using a third party.
  • FIG. 30 illustrates a flow of a sender using an electronic document reading service by using a system of his own. The procedure described in FIG. 30 is described in Table 35 below.
  • the sender should have a system that can provide the electronic document reading service in addition to the distribution system.
  • FIG. 31 illustrates a flow in which a transmitting entity uses an electronic document reading service by using a third party.
  • the procedure shown in FIG. 31 is described in Table 36 below.
  • Table 36 number People Explanation One Obtain public key of incoming object certificate Obtain the public key of the receiving object certificate from the address directory server when creating the e-mail viewing authority 2 Request for electronic document storage and reading service 2 Request for electronic document storage and reading service The sending entity keeps and requests an electronic document to a third-party archiving agency and requests a reading service for it. 3 Create a certificate with security rights such as access rights and DRM Create a certificate that applies security such as DRM and a security certificate such as DRM to view the electronic document 4 Send Certificate of Reading Authority Send the certificate to the receiving entity, including the right to view third-party custody. 5 Electronic document reading Recipients of the receiving entity have access to view third-party documents by accessing third-party archives.
  • Certificate of Distribution If the recipient of the third-party archival recipient receives the electronic document, a distribution certificate is created and stored. 7 Send Certificate of Distribution (Reading) In addition, the certificate of distribution (reading) is transmitted to the sending entity who requested the third-party archiving service.
  • the electronic document distribution system based on the authorized electronic address may be linked to the inside of the company / institution in the following ways.
  • the interworking method with the internal system is mainly used when a distribution messaging server is installed in a company or an institution.
  • the distribution client is developed as a system integration (SI) form in the internal system.
  • SI system integration
  • the method that does not interwork with the internal system is mainly suitable for the authorized sender who uses a user account issued by the electronic document relay, and is a distribution client application that is distributed by the electronic document relay using a web distribution client provided by the electronic document relay. Is installed on the local PC and used for details, see Table 39 below.
  • the web method is a web method that users access and process, so that individual users do not need to install a program on their local PC.
  • the individual user downloads the installation program, installs the program on the local PC, and connects to the distribution messaging server.
  • the distribution system has a distribution network based on its own system and the Internet. Electronic document distribution may be limited because it is only within the distribution system.
  • the distribution system has an external gateway server for the distribution of electronic documents with systems that are not directly connected.
  • FIG. 32 A basic conceptual diagram of an external linkage gateway server is shown in FIG. 32.
  • the external linkage gateway server acts as an intermediate waypoint.
  • One side has a distribution messaging server for the distribution system, and the other side has its own adapters for linking with external systems.
  • the business component is an agreement between the parties regarding the procedures, methods, etc. related to the linkage, and the management body and the external linked system management body shall enter into a service level agreement (SLA).
  • SLA service level agreement
  • Technical elements refer to technical elements related to user authentication, messaging, and message format necessary for the connection.
  • the sender shall write the stopover address and the final destination address.
  • the sender shall provide user information so that external system can authenticate the sender. If you have previously subscribed to an external system, you can use the authentication identifier of the external system.
  • the received message should be disassembled and assembled into the message suitable for external system.
  • External system linked with distribution system can be added or changed. Information on the external system is managed by the address directory server, and the distribution messaging server should query and process the address directory server if necessary.
  • a common basic communication protocol and a message exchange method are first defined, and a message structure for each link type is defined and presented as a standard.
  • the present invention is constructed by different environments and development methods. Linkages between components can be facilitated and interoperable.
  • the distribution linkage message is based on the "ebXML Message Services v2.0 specification" (hereinafter ebMS). It is defined as a more general form by extending it hierarchically.
  • the ebXML infrastructure consists of independent but closely related elements such as SOAP, SOAP with Attachment, Security, and Reliability.
  • the "Based Communication Protocol for Linkage” (hereinafter referred to as “Based Communication Protocol”) is based on these basic elements and defines the necessary elements in the distribution system and consists of an organic recombination form.
  • the underlying communication protocol consists of packaging that composes the message to be transmitted, message envelope construction, message security, and message transmission and reception, which finally transmits and receives the message.
  • the entire message structure of the distribution-related message complies with the ebMS v2.0 specification.
  • the message defined in this base communication protocol has two logical MIME parts.
  • the first MIME part contains a SOAP message, which in turn consists of a header and a body.
  • payload containers From the second MIME part, called payload containers, it contains application-level messages and attached documents.
  • This area describes common information for message distribution (such as message routing-related information, SOAP message exchange patterns, digital signatures, error information, and location information for second attached data).
  • the second MIME part attaches request and response messages for each interfacing interface, and the existence of the MIME part after the third is determined by the type of the interfacing interface. When delivering electronic documents or certificates using the distribution system, they are included in the third MIME part.
  • FIG. 34 The basic structure of the distribution association message is shown in FIG. 34.
  • 1 "SOAP-ENV: Header” is configured according to the distribution protocol standard, and consists of MesageHeader and Signature information.
  • 2 "SOAP-ENV: BODY” is distribution. Mainfest element information and user login information defined in the protocol specification are included.
  • 3 "Transport container # 1 (payload container # 1)” is a part including request message and response message. The details of the business document are defined according to the error message, and 4 "Transport Container # 2 (Payload Container # 2)" includes documents to be attached sequentially from Payload Container # 2 according to the type of the associated interface.
  • all MIME Header elements of the distribution association message must conform to the SOAP Messages with Attachments specification.
  • the Content-Type MIME Header in the message MUST have the same type attribute as the MIME media type of the MIME Body part containing the SOAP message document.
  • a MIME type of a SOAP message must have a value of "text / xml".
  • the root part shall contain a Content-ID MIME Header with a structure conforming to [RFC2045] and in addition to the required parameters for the Multipart / Related media type, a start parameter (optional in [RFC2387]) must always be present.
  • An example MIME Header of a multipart / related message package is shown in Table 40 below.
  • the first MIME Part header container must contain a SOAP message.
  • the MIME Content-Type header of the header container shall have the value "text / xml" according to the SOAP specification.
  • the Content-Type header must include a "charset" attribute. An example is shown in Table 41 below.
  • the MIME charset attribute is then used to identify the character family used to generate the SOAP message.
  • the encoding declaration of the MIME charset attribute value and the SOAP message located in the header container must match and its value must be UTF-8.
  • An example of a header container is shown in Table 42 below.
  • the number of payload containers may vary depending on the type of associated interface.
  • Each payload container must be referenced by a Manifest element in the SOAP Body according to the ebMS specification. Examples are shown in Table 43 below.
  • MIME headers may be added for convenience of implementation.
  • the added MIME Header must be an item specified in [RFC2045].
  • the additional MIME header does not need to be recognized and interpreted by the side not added.
  • extension element content must be restricted to a valid namespace.
  • All ebXML SOAP extension element contents defined in the present invention should be limited to the ebXML SOAP Envelope extension namespace.
  • Namespace declarations may be included in SOAP Envelop, Header, or Body elements, or may be included directly in each SOAP extension element.
  • SOAP Envelop is a root item of SOAP message and declares various namespaces in SOAP message.
  • the namespace to be declared is as follows.
  • the message envelope schema structure is shown in FIG. 35, and an example message envelope is shown in Table 45 below.
  • the SOAP Header element is the first child element of the SOAP Envelop element and includes extension elements such as the following 1 to 4.
  • MessageHeader Required element including routing information (To / From, etc.) of message and other context information about message.
  • ErrorList An element that contains the error history when returning an error message due to an error in processing a message such as message syntax verification, message digital signature verification, etc.
  • the SOAP Body element is the second child element of the SOAP Envelope element and contains an extension element such as Manifest.
  • Manifests are elements that point to data located elsewhere, such as a payload container or the web.
  • the manifest element must exist to refer to the payload container.
  • the manifest element is a composite of one or more reference elements. Each Reference element identifies data related to the message, either a remote resource that is included as part of the payload document (s) contained in the payload container or is accessible by a URL. It is recommended not to load payload data in the SOAP Body.
  • the purpose of the manifest is as follows 1 and 2.
  • Manifest element is composed of the following attributes and elements.
  • Reference element is a complex element composed of sub elements such as 1 to 2 below.
  • Schema elements Information about the schema (s) defining the instance document identified in the parent Reference element.
  • Description elements A description of the payload object referenced by the parent reference element.
  • the Reference element is itself a simple link to [XLINK].
  • XLINK is currently the W3C Candidate Recommendation (CR). Note that the use of XLINK is provided here as a term to clarify the association. The use of an XLINK processor or engine is not essential, but may be useful depending on your implementation requirements.
  • the Reference element contains the contents of the following attributes 1 through 5.
  • Xlink-type This attribute defines an element as an XLINK simple link. It has a fixed value of "simple"
  • Xlink href: This required attribute is the URI value of the referenced payload object. This should be based on a simple link in the [XLINK] specification.
  • Xlink role: This attribute identifies the payload object or resource that describes its purpose. If present, it must have a valid URI value per the [XLINK] specification.
  • the receiving MSH can ignore external namespace attributes in addition to those defined above.
  • Schema element must exist as a child of a Reference element if the referenced item has a schema (s) describing it (eg, XML Schema, DTD, or Database Schema). It is used to identify the schema and version, and defines the payload object identified by the parent Reference element.
  • Schema elements have the following attributes: 1 and 2.
  • the MIME with that content-id must be represented in the message's payload container. Otherwise, an error with errorCode as MimeProblem and severity as Error should be sent to the calling party. If the xml: href attribute does not contain a URI with a content id (URI scheme "cid"), the URI will not be interpreted and the implementation must decide whether or not to forward an error. If it is determined that an error should be delivered, an error with errorCode as MimeProblem and severity as Error should be sent to the calling party.
  • Table 46 shows the mainfest of a message with a typical payload MIME Body part.
  • the MessageHeader element is a mandatory element that must be present in every ebXML message and must be expressed as a child element of the SOAP Header element.
  • the MessageHeader element is a composite element consisting of the following subelements.
  • the schema structure of the MessageHeader is shown in FIG. 36.
  • the MessageHeader item code table is shown in Table 48 below, and the Service / Action items for each task are shown in Table 49 below.
  • SyncReply means synchronous transmission and has the following 1 to 4 attributes.
  • Distribution-linked messages must be electronically signed to counter the various risks that can occur during transmission and reception. Therefore, Signature element must exist as child element of SOAP Header.
  • the subject of digital signatures in distribution-related messages are the entire SOAP message and the messages and attachments contained in the payload container.
  • Each signature subject information is digested and included in the digital signature information, respectively.
  • the number of payload containers is repeatedly described.
  • the URI value describes the content ID value defined in the MIME Header of the attached document. (Digest target is Content part except Mime Header)
  • SignatureValue of SignedInfo is calculated based on the algorithm specified in SignedInfo as specified in [XMLDSIG].
  • the algorithm information used in the digital signature is as follows.
  • the algorithm basically follows the algorithm part (6.0 Algorithms) of W3C “XML-Signature Syntax and Processing” (RFC3275). It also uses the algorithm defined in TTAS.IF-RFC3075 "Extensibility Generation Language Digital Signature Syntax and Processing” (Korea Information and Communication Technology Association, 2004).
  • Algorithms used in message digital signatures conform to the relevant provisions of accredited certification schemes.
  • Algorithm that processes and selects the data that is actually signed from the entire XML data. There are various conversion algorithms, but only three of them are used. The first is the Enveloped Signature transformation because the digital signature follows the format contained within the signature subject, the second is the canonicalization described above, and the third is XPath Filtering to select the signature subject information.
  • the structure of the digital signature syntax is shown in FIG. 37, and an example of the digitally signed message is shown in Table 57 below.
  • ErrorList element should be created under Header and returned synchronously to sender when error occurs during communication protocol processing such as message syntax verification, message digital signature verification.
  • RefToMessageId must exist in the MessageHeader element and RefToMessageId must refer to the MessageId of the message in which the error has occurred.
  • the ErrorList element has the following attributes: 1 to 5.
  • the ErrorList element MUST NOT exist unless there are errors to be reported.
  • the structure of the ErrorList is as shown in FIG.
  • the highestSeverity attribute indicates the most severe state of all Error elements. In particular, if an Error element has severity set to Error, highestSeverity must be set to Error, otherwise highestSeverity must be set to Warning.
  • the Error element has the following attributes: 1 through 6.
  • the id attribute uniquely identifies the ErrorList element in the document.
  • the codeContext attribute represents the namespace or schema of errorCodes. It must be a URI.
  • the default value of this property is urn: oasis: names: tc: ebxml-msg: service: errors. If there is no default value for this attribute, the implementation of the specification indicates that it uses errorCodes.
  • the required errorCode attribute indicates the nature of the error in the message that contains the error.
  • the severity attribute which is a required attribute, indicates the severity of the error. Valid values are the same as Warning and Error. Warning indicates that an error exists but other messages in the conversation are being generated normally. Error indicates that an unrecoverable error exists in the message and no other messages are generated during the conversation.
  • the location attribute points to the message part where the error exists. If the error is in an ebXML element and the element is "well-formed" then the location attribute's content must be [Xpointer].
  • the content of the Description element provides a descriptive description of the error in the language defined by the xml: lang attribute. Usually this is a message generated by the XML parser or software that validates the message. This means that the content is defined by the vendor or developer of the software that created the Error element.
  • ErrorList is shown in Table 58 below.
  • Errors to report include message structure errors, messaging errors, and security errors.
  • Errors related to data communication protocols such as HTTP and Socket belonging to a lower layer than the distribution protocol defined in the present invention should be found and reported by a standard mechanism supported by the data communication protocol, and use the error reporting mechanism defined in the present invention. I never do that.
  • Error codes are classified by error object and type. Details are shown in Table 59 below.
  • HTTP response code defined in [RFC2616] should be used.
  • the main response codes are shown in Table 61 below.
  • the transmission between all distribution messaging servers and distribution message servers in the distribution system or between distribution messaging servers and distribution clients must use HTTP / S (Secure Hypertext Transfer Protocol) using Secure Socket Layer (SSL) V3.0 for network transmission security. Should be used.
  • HTTP / S Secure Hypertext Transfer Protocol
  • SSL Secure Socket Layer
  • an error occurrence type is largely divided into an error occurrence for a synchronous response and an error occurrence for an asynchronous response.
  • the distribution of all messages between two entities between a distribution messaging server, another distribution messaging server, an address directory server, a distribution client and a distribution relay server is a synchronous distribution.
  • the distribution of messages between three entities in which a distribution client is connected to another distribution messaging server, an address directory server, and a distribution relay server through a distribution messaging server may be linked in a synchronous or asynchronous manner depending on the type of connection.
  • All errors for synchronous transmissions are based on retransmissions, since the sender can see them immediately.
  • the retransmission method is determined according to the policy of the system of the company or organization participating in the distribution system, but the same message transmission is set by sending the same MessageId value again.
  • the same request is detected by detecting the receipt of duplicate messages even when the error in the message transmission process is not an error at the time of transmission but in the case of the receiver sending a response message synchronously after successful reception. Prevent duplicate processing.
  • the sender and receiver of a synchronous error can be a distribution messaging server, an address directory server, a distribution client, or a distribution relay server, depending on the type of association.
  • Request message transmission failure When the sender transmits a message and a transmission error occurs, the request message cannot be delivered to the receiver. . 39 shows a process when a request message transmission fails, the processing procedure is as follows 1) to 3).
  • a transmission error occurs during the message sender's transmission. Many cases are caused by a network error.
  • the sender recognizes the transmission failure error and retransmits the same message to the receiver with the same MessageId.
  • the receiver If the receiver receives the same message as the previous received message, the receiver sends an acknowledgment message with duplicate reception and internal processing.
  • FIG. 41 illustrates a process related to error message reception, and processing procedures are as follows 1) to 3).
  • 3rd stage synchronous error Distribution of messages between 3 entities linked to other distribution messaging server, address directory server and distribution relay server through distribution messaging server is synchronously linked to confirm the final result among the types of linkage. Support the room. If an error occurs in the linkage step between the distribution messaging server and the receiver during this process, the distribution messaging server should immediately generate an error and deliver it to the distribution messaging server as a response message. 42 illustrates a process related to a three-phase synchronous error, and processing procedures are as follows 1) to 3).
  • the error refers to the case where all errors occur in the synchronous transmission between the distribution messaging server and the receiver.
  • the distribution messaging server generates an error message for the distribution client when the error is recognized and delivers it to the distribution client as a response message.
  • the error message generated by the distribution messaging server is structured as shown in Table 62 below.
  • the distribution of messages between the three entities that the distribution client connects with other distribution messaging servers, address directory servers, and distribution relay servers through the distribution messaging server is an asynchronous method so that the distribution client user can operate independently of the situation of the end receiver. It also supports linkage.
  • the final error of the asynchronous transmission cannot be immediately confirmed by the sender, so that the distribution messaging server generates an error message for the distribution client at the time when the distribution messaging server finally confirms the error, so that the distribution client can receive it.
  • the error refers to the case where all errors occur in the synchronous transmission between the distribution messaging server and the receiver.
  • the distribution messaging server generates an error message for the distribution client and finally delivers it to the distribution client's inbox after retrying.
  • the distribution client recognizes an error about a previous request message through an error message received in its inbox at the step of requesting a reception message from a distribution messaging server.
  • the error message generated by the distribution messaging server is structured as shown in Table 63 below.
  • the address directory server is a system that manages the official electronic address information, which is the most basic element in the distribution system.
  • the interface between the distributed messaging server and the address directory server is divided into two main functions.
  • the first is an interface related to work such as registration of a public electronic address with a registrar
  • the second is an interface related to work such as physical address query / response and spam report with a distribution messaging server.
  • Interfaces related to business such as registration of authorized electronic addresses with the above registrars can be distinguished separately, but since the registrar is done by an electronic document relay or a third-party archival agency, an interface function is inserted into the distribution messaging server.
  • the distribution messaging server installed in the transmitting / receiving entity does not include the associated interface related to the registration of the public electronic address.
  • Table 64 shows the interface functions between the distributed messaging server and the address directory server.
  • Requestor is an electronic document relay Change of authorized electronic address information ⁇ Interface that receives the result after requesting the change to the address directory server in case of a change in the public information (ex: security information, ID) Delete public e-mail address ⁇ Address The interface that receives the result after requesting deletion to the address directory server when the public electronic address registered in the directory server is no longer used.
  • Address search retrieve physical address information ⁇ Interface that requests the user's security information (certificate certificate) and physical address information corresponding to the public electronic address information from the directory server and receives the result
  • the requestor is an entity sending and receiving with the electronic document relay Blacklist management Report Spam
  • the interface that reports the spam message to the address directory server and receives it as a result.
  • the address directory server sends the final message on whether the message is reported as spam or not to the sender and the spammer. Notified using Notification White list notification ⁇ Interface that whitelists the address directory server to send / receive objects Blacklist notification ⁇ Interface that blacklists address directory server to send / receive object
  • the digital signature information of the sending object must be included and transmitted.
  • the address directory server is used to perform the digital signature of the SOAP message. Additional sender information (CorpNum, RValue) required to verify that the owner of the certificate matches the corresponding sender (VID verification) must also be included and conveyed.
  • the information of additional sending objects shall be located as an extension element (any ## other position) under the MessageHeader element in the SOAP message of the request message.
  • the extended element structure is shown in Table 65 below, and an example of extended elements is shown in Table 66 below.
  • the SOAP message is located in the first MIME part of the message, and the distribution message for the corresponding request and response is located in the second MIME part.
  • the SOAP structure between the distributed messaging server and the address directory server is shown in FIG. 44.
  • the request distribution message structure is shown in Table 67 below, and an example message is shown in Table 68 below.
  • the response distribution message structure is shown in Table 69 below, and an example message is shown in Table 70 below.
  • the public e-mail address change interface is an interface where an electronic document relay requests a change of the public e-mail address information of the authorized sender and receiver registered in the address directory server and receives a response. After the transmission, the result of the change processing of the address directory server is received as a response message.
  • the message exchange flow associated with the authorized electronic address information change processing is illustrated in FIG. 46.
  • the request distribution message structure is shown in Table 71 below, and an example message is shown in Table 72 below.
  • the response distribution message structure is shown in Table 73 below, and an example message is shown in Table 74 below.
  • the public electronic address deletion interface is an interface where an electronic document relay requests a deletion of the public electronic address information of the public electronic address information of the authorized sender and receiver registered in the address directory server and receives a response. Is included in the request message and transmitted, and the result of the deletion process of the address directory server is received in the response message.
  • the message exchange flow associated with the public electronic address deletion process is illustrated in FIG. 47.
  • the request distribution message structure is shown in Table 75 below and an example message is shown in Table 76 below.
  • the response distribution message structure is shown in Table 77 below, and an example message is shown in Table 78 below.
  • ErrorCode enters the error code corresponding to the cause of the error if ResultCode is entered as a failure (0).
  • the physical address information retrieval interface is an interface where an electronic document relay or a transceiving entity receives a response from the address directory server by requesting the physical address information corresponding to the authorized electronic address of the electronic document recipient and the certificate information for message security processing. After receiving the request message, including the electronic address of the recipient and whether or not to request a public certificate in the request message, and receives the physical address information (IP address or domain address) and public certificate information of the electronic document recipient from the address directory server as a response message.
  • IP address or domain address IP address or domain address
  • the request distribution message structure is shown in Table 79 below, and an example message is shown in Table 80 below.
  • Spam message report accepting interface is an interface where an electronic document relay or a sender / receive entity reports a spam message to an address directory server.
  • the spam message is sent from the address directory server after the spam message is included in the request message. Receive a response message whether the report is received.
  • the address directory server notifies the report of the result of the spam message using the "message transmission" interface of the interfacing interface between the distribution messaging servers when the spam message is determined.
  • the message exchange flow related to the spam message report receiving process is illustrated in FIG. 49.
  • the request distribution message structure is shown in Table 83 below, and an example message is shown in Table 84 below.
  • ResultCode is the result of a simple receipt process for spam report messages.
  • the white list notification interface is an interface for notifying a sending / receiving entity of a white list (list of sending / receiving entities participating in the distribution system and a list of authorized electronic addresses of the sender and receiver).
  • the message exchange flow related to the white list notification is shown in FIG. 50.
  • the request distribution message structure is shown in Table 87 below, and an example message is shown in Table 88 below.
  • ResultCode is the result of a simple receipt process for spam report messages.
  • the blacklist notification interface is an interface for notifying a blacklist (rejection list) to a transmitting / receiving object. Notified blacklists are used for blacklist management by sending and receiving entities.
  • the message exchange flow related to the black list notification is shown in FIG. 51.
  • the request distribution message structure is shown in Table 91 below, and an example message is shown in Table 92 below.
  • the distribution messaging server basically has to establish a connection with the distribution messaging server established by another sending / receiving entity or an electronic document relay for sending and receiving messages.
  • a distribution certificate delivery linkage function must be additionally provided between the distribution messaging server of the third party archive provider and the other messaging server in order to store the distribution certificate in the third party archive.
  • the interfacing interface between distribution messaging servers is a protocol for transmitting and receiving messages and distribution certificates between messaging servers, and is divided into the interfaces shown in Table 95 below.
  • the SOAP message shall contain the sender's digital signature information and be delivered.
  • the receiver shall verify that the owner of the certificate used for the digital signature of the SOAP message matches the sender. Additional sender information (CorpNum, RValue) necessary for (VID verification) shall also be included and conveyed.
  • Additional sender information shall be located as an extension element (any ## other position) under the MessageHeader element in the SOAP message of request and response messages.
  • the extended element structure is shown in Table 96 below, and the schema structure is shown in Table 97 below.
  • the message transfer interface is used when a distribution messaging server transmits a message to another distribution messaging server.
  • the request format is as shown in FIG. 53.
  • the first MIME part includes a SOAP message
  • the second MIME part includes a request distribution message
  • the user attaches a document.
  • the structure of the request distribution message is shown in Table 98 below.
  • the response format is shown in FIG. 54.
  • a SOAP message is located in the first MIME part
  • a response distribution message is located in the second MIME part
  • a receipt certificate is located in the third MIME part. . If an error occurs in the processing of the request message, the third MIME part is not created.
  • the structure of the response distribution message is shown in Table 100 below, and the actual example is shown in Table 101 below.
  • the distribution certificate delivery interface is used when the distribution messaging server transmits a reading certificate to another distribution messaging server. It is also used when the distribution relay server sends an electronic document to the receiving distribution messaging server after sending an electronic document to the receiving distribution messaging server and sending the received certificate to the requesting distribution messaging server.
  • the message exchange flow related to the distribution certificate delivery process is shown in FIG. 55.
  • the distribution certificate delivery request format is shown in FIG. 56.
  • a SOAP message is located in the first MIME part
  • a request distribution message is located in the second MIME part
  • a distribution certificate is located in the third MIME part.
  • the request distribution message structure is shown in Table 102 below, and the actual example is shown in Table 103 below.
  • the distribution certificate delivery response format is as shown in FIG. 57 (if 57a is successful and 57b is an error), and in the entire message structure as shown in FIG. 57, if the processing of the request message is successful, it is received in the first MIME part. Acknowledgment Acknowledgment Only the SOAP message is located. In case of an error, the SOAP message is located in the first MIME part and the error response distribution message is located in the second MIME part.
  • the response distribution message structure is shown in Table 104 below, and Table 104 is applicable only when the processing result is an error.
  • the distribution certificate storage request interface is used when a distribution messaging server of a transmitting / receiving entity makes a request for storage of a distribution certificate to a distribution messaging server of a third-party storage institution operator in order to store the distribution certificate in a third-party storage organization.
  • the response message on this interface includes only the acknowledgment information, and the initial registration certificate issued as a result of storing the distribution certificate in the third party storage institution is requested to be stored using the "3rd party storage institution storage result delivery interface" described below. Deliver to distribution messaging server.
  • the request format for storing the distribution certificate is shown in FIG. 59.
  • the SOAP message is located in the first MIME part
  • the request distribution message is located in the second MIME part
  • the distribution certificate is located in the third MIME part. .
  • the requested distribution message structure is shown in Table 105 below, and the actual example is shown in Table 106 below.
  • the distribution certificate storage response format is as shown in FIG. 60 (if 60a is successful and 60b is an error), and in the entire message structure as shown in FIG. 60, if the processing of the request message is successful, it is received in the first MIME part. Acknowledgment Acknowledgment Only the SOAP message is located. In case of an error, the SOAP message is located in the first MIME part, and the error response distribution message is located in the second MIME part.
  • Table 107 The response distribution message structure is shown in Table 107 below. Table 107 is applicable only when the processing result is an error.
  • the third party storage organization storage result delivery interface is a distribution messaging server in which the distribution messaging server of the third party storage institution operator stores the distribution certificate in the third party storage institution and requests the storage certificate of the distribution certificate received as the result of the initial registration certificate. Used when sending to.
  • the message exchange flow related to the third-party archival institution storage result transfer processing is shown in FIG. 61.
  • the storage format of the third-party custody storage result is shown in FIG. 62.
  • a SOAP message is used for the first MIME part, a request distribution message for the second MIME part, and an initial registration certificate for the third MIME part. Is located. If an error occurs in the process of storing the distribution certificate in the third-party archive, the third MIME part is not created.
  • the requested distribution message structure is shown in Table 108 below, and the actual example is shown in Table 109 below.
  • the third-party custody storage result response format is shown in FIG. 63 (when 63a is successful and 63b is an error).
  • the first message is displayed when the processing of the request message is successful. Only acknowledgment Acknowledgement SOAP message is placed in the first MIME part. In case of an error, the SOAP message is located in the first MIME part and the error response distribution message is located in the second MIME part.
  • the response distribution message structure is shown in Table 110 below, and Table 110 is applicable only when the processing result is an error.
  • the distribution messaging server should provide the basic document transmission / reception function to the user in connection with the system (distribution client) for the user (internal transceiver or authorized transceiver) requesting the actual electronic document distribution.
  • the interfacing interface between the distribution client and the distribution messaging server is a protocol for primarily communicating with the distribution messaging server in order to transmit and receive electronic documents, and is divided into the interfaces shown in Table 111 below.
  • the SOAP message the first MIME part of the request message sent by the distribution client to the distribution messaging server, must be delivered with the user's digital signature information.
  • the owner of the certificate used by the distribution messaging server in the digital signature of the SOAP message is Additional user information (IDN, RValue) required to verify user conformity (VID verification) should also be included and conveyed.
  • This information should be placed as an extension element (any ## other position) under the MessageHeader element in the SOAP message of the request message.
  • the extended element structure is shown in Table 112 below, and an example of extended elements is shown in Table 113 below.
  • the message transfer request interface is used when a distribution client sends a message to a distribution messaging server for sending a message through the distribution messaging server.
  • the message transmission processing flow of the distribution client is as shown in FIG.
  • the message transmission request format of the distribution client is shown in FIG. 65.
  • a SOAP message is located in the first MIME part and a request distribution message is located in the second MIME part. If there is a document attached by the user, it is located from the third MIME part.
  • the requested distribution message structure is shown in Table 114 below, and the actual example is shown in Table 115 below.
  • Text can be omitted if the text is not needed for document delivery.
  • the distribution client message transmission response format is as shown in FIG. 66 (when 66a is successful and 66b is an error).
  • the first MIME part when the processing of the request message is successful. Only acknowledgment Acknowledgment SOAP message is located at.
  • SOAP message is located at the first MIME part and error response distribution message is located at the second MIME part.
  • the response distribution message structure is shown in Table 116, and Table 116 is applicable only when the processing result is an error.
  • the message list request interface is used when a distribution client requests a list of messages received by the distribution messaging server.
  • the message list processing flow of the distribution client is as shown in FIG.
  • the message list request format of the distribution client is shown in FIG. 68.
  • a SOAP message is located in the first MIME part and a request distribution message is located in the second MIME part.
  • the requested distribution message structure is shown in Table 117 below, and the actual example is shown in Table 118 below.
  • the message list response format of the distribution client is shown in Table 67.
  • the SOAP message is displayed in the first MIME part and the response distribution message is in the second MIME part (the list of distribution messages received by the distribution messaging server). This is located.
  • the response distribution message structure is shown in Table 119 below, and the actual example is shown in Table 120 below.
  • the message detail request interface is used when a distribution client requests a specific message and an attached document received by the distribution messaging server.
  • the detailed information request processing flow of the distribution client is illustrated in FIG. 69.
  • the message detail request format of the distribution client is shown in FIG. 70.
  • a SOAP message is located in the first MIME part and a request distribution message body is located in the second MIME part.
  • the request distribution message structure is shown in Table 121 below, and the actual example is shown in Table 122 below.
  • the response format of the message detail information of the distribution client is shown in FIG. 72.
  • the first MIME part includes a SOAP message
  • the second MIME part includes a response distribution message (distribution message detail information) and an attached document. If present, they are placed in order from the third MIME part.
  • the response distribution message structure is shown in Table 123 below, and the actual example is shown in Table 124 below.
  • the spam message reporting interface is used when a distribution client reports a spam message to a distribution messaging server.
  • the distribution messaging server reports the spam message to the address directory server and delivers the result to the distribution client.
  • the spam message report processing flow of the distribution client is shown in FIG. 73.
  • the spam message report format of the distribution client is shown in FIG. 74.
  • a SOAP message is located in the first MIME part and a request distribution message is located in the second MIME part.
  • the structure of the request distribution message is shown in Table 125 below, and an example message is shown in Table 126 below.
  • the response format of the spam message of the distribution client is shown in FIG. 75.
  • the SOAP message is displayed in the first MIME part and the response distribution message is in the second MIME part (the list of distribution messages received by the distribution messaging server). This is located.
  • ResultCode is the result of a simple receipt process for spam report messages.
  • the physical address lookup interface is used by the distribution client to request a physical address lookup from the distribution messaging server.
  • the distribution messaging server retrieves the physical address from the address directory server and delivers the result.
  • the physical address search request message format is shown in FIG. 77.
  • a SOAP message is located in the first MIME part and a request distribution message is located in the second MIME part.
  • the request distribution message structure is shown in Table 129 below, and an example message is shown in Table 130 below.
  • the physical address retrieval response message format is shown in FIG. 78.
  • the first MIME part has a SOAP message
  • the second MIME part has a response distribution message (list of distribution messages received at a distribution messaging server). Located.
  • the response distribution message structure is shown in Table 131 below, and the actual example is shown in Table 132 below.
  • the RAddress can be omitted (Endpoint and Cert are omitted as a result).
  • ErrorCode enters the error code corresponding to the cause of the error when ResultCode is entered as a failure (0), that is, when another error occurs except an error in the absence of an address.
  • the distribution relay server is a system for performing electronic document transmission on behalf of the transmission distribution messaging server when an error occurs during transmission of an electronic document directly between distribution messaging servers in an electronic document distribution system.
  • Distribution relay server is managed by ICT Industry Promotion Agency. All distribution messaging servers can be supported in case of errors in P2P distribution process in connection with distribution relay server.
  • connection interface between the distribution messaging server and the distribution relay server is a protocol for requesting transmission of an electronic document to the distribution relay server by the distribution messaging server, and is classified into an interface as shown in Table 133 below.
  • the SOAP message the first MIME part of the message, must contain the digital signature information of the distribution messaging server.
  • the distribution relay server is the owner of the certificate used for the digital signature of the SOAP message.
  • the additional distribution messaging server information (CorpNum, RValue) needed to verify that the server matches the distribution messaging server (VID verification) should also be included and delivered.
  • the information of the additional distribution messaging server shall be located as an extension element (any ## other location) under the MessageHeader element in the SOAP message.
  • the extended element structure is shown in Table 134 below, and an example of extended elements is shown in Table 135 below.
  • the message transmission request interface is used when a distribution messaging server requests a message transmission to a distribution relay server and receives a transmission certificate when a reception error on the other distribution messaging server occurs while transmitting a message to another distribution messaging server.
  • the distribution relay server immediately returns only the result of receiving the message transmission request from the distribution messaging server, and after receiving the message to the receiving distribution messaging server, the reception certificate received by using the above-mentioned "distribution certificate delivery interface" is used for distribution messaging.
  • the message relay processing flow is as shown in FIG.
  • the message relay request message format is shown in FIG. 80.
  • a SOAP message is located in the first MIME part and a request distribution message is located in the second MIME part. If there is a document attached by the user, it is located from the third MIME part.
  • the request distribution message structure is shown in Table 136 below, and the actual example is shown in Table 137 below.
  • the message relay response message format is shown in FIG. 81.
  • a SOAP message is located in the first MIME part
  • a response distribution message is located in the second MIME part
  • a transmission certificate is located in the third MIME part. If an error occurs in the processing of the request message, the third MIME part is not created.
  • the response distribution message structure is shown in Table 138 below, and the actual example is shown in Table 139 below.
  • Electronic document distribution is based on peer-to-peer communication where companies / institutions that comply with the standards for trust distribution directly exchange electronic documents with each other.
  • the basic element of the electronic document distribution system according to the present invention for performing such P2P communication is a standard specification-based distribution messaging server system that supports distribution between an address directory server managing address information and each send / receive entity. .
  • a basic structure for distributing electronic documents can be provided by a company or institution, and a distribution certificate is issued to prove document distribution between senders and receivers.
  • the legal basis for distribution can be secured by storing in a third party storage institution (public office, authorized electronic archives).
  • Electronic document distribution system in addition to the above basic elements, in order to facilitate the distribution of electronic documents to general users (company / organization, individual), the distribution client application (APP) that provides a user interface for the document transmission and reception function
  • APP distribution client application
  • Additional components include an electronic document form register that provides standard document forms to enhance the convenience of document preparation, and a public sector linkage gateway for relaying electronic documents with administrative agencies.
  • each send / receive entity In order for electronic document distribution to take place, first, there must be “1 send / receive entity”, which is the subject of distribution, and each send / receive entity must have “2 distribution messaging server system” that complies with the distribution messaging server standard to distribute documents. . In addition, there should be a “3 Address Directory Server” that registers and manages each send / receive object and a user's public electronic address as a basic component of electronic document distribution.
  • the unit of distribution is the sending / receiving entity.
  • the sending / receiving entity performs the sender or receiver according to the role of participating in the distribution.
  • the document (information) is distributed according to the distribution protocol specification through the server system.
  • All the sending / receiving entities participating in the distribution establish a distribution messaging server system that can send and receive documents according to the distribution messaging standard, and then register the physical address information of the distribution messaging server system in the address directory server to participate in the electronic document distribution. It will create a foundation. At this time, each transmitting and receiving entity has a real distribution user having at least one authorized electronic address.
  • the entity that can be recognized as a sending / receiving entity in the electronic document distribution is limited to an entity certified by the Information and Communications Industry Promotion Agency for standard conformance and interoperability after establishing a system that complies with the messaging server standard.
  • the distribution certificate shall be issued according to the standard and stored in the third-party storage institution.
  • the transmission and reception entity is divided into an entity that is responsible for the direct transmission of the electronic document as a legal owner and responsible for the electronic document, and an entity that acts on behalf of the electronic document for the user who is the owner and the responsible person of the electronic document in circulation.
  • the owner of the electronic document is a transmitting / receiving entity that transmits the electronic document directly
  • the standard suitability and interoperability of the distribution messaging server system can be authenticated, and the distribution document can be securely participated in the sending / receiving entity simply by keeping the distribution certificate in a third-party storage institution. have.
  • the sending / receiving entity that is responsible for the third party transmission on behalf of the electronic document owner (user)
  • it must prove that the sending / receiving entity manages the transmission message in a safe and reliable manner, and manages and authenticates the user information. do.
  • the third party custody carriers can transmit / receive such a third party for a limited time.
  • the distribution messaging server system In order to distribute electronic documents (information) based on the distribution messaging server standard, the distribution messaging server system must establish a function of retrieving address information and security-related information about the recipient in connection with a message transmission / reception function and an address directory server.
  • the distribution messaging server system physically has one electronic address (IP address), but can issue and manage a plurality of user accounts for lower users, and each user account has one public electronic address.
  • the distribution messaging server system must manage an electronic document mailbox for each user account in order to manage each user account, and the distribution messaging server system has a safe and reliable electronic document distribution responsibility on behalf of this user account.
  • the authentication system that authenticates the standard conformance and interoperability of the distribution messaging server system must manage the authenticated send and receive objects. If the address directory server requests verification of whether the authentication has passed during the registration of the public electronic address, the result is returned. Should give.
  • an enterprise / institution or individual user who wants to be a transmitting / receiving entity establishes a distribution messaging server system in accordance with the present technical standard.
  • the automated test tool provided by the authentication test bed verifies the standard conformance and interoperability of the deployed messaging server system.
  • the sending / receiving entity that has completed all its verifications requests an authentication test from the authentication test bed.
  • the sending / receiving entity prepares the next procedure for registering the public electronic address.
  • the authentication test bed delivers information about the send / receive entity that passed the authentication audit to the address directory server, and the address directory server uses this information as a condition of address registration.
  • the sending / receiving entity applies for issuing a unique ID to the address directory server in order to register the distributed messaging server system that has passed the authentication.
  • the distribution messaging server system can participate in the electronic document distribution.
  • a user account is opened, and in the case of a representative public electronic address, the user account requests registration of the public electronic address.
  • the distribution client APP refers to an application that provides a UI for sending and receiving documents, viewing and managing received documents, etc., for users participating in document distribution.
  • the distribution client APP cannot send and receive documents on its own and must be linked with the distribution messaging server system.
  • Documents created or attached to the distribution client APP are delivered to the distribution messaging server system to request transmission, and the documents received through the distribution messaging server system are inquired. If the distribution messaging server system manages the sending and receiving mailbox through a user account, the distribution client APP can access only the document through checking the user account information among the received documents.
  • the distribution client APP may be implemented as a C / S type application or a web type screen at the request of a user.
  • public sector linkage gateways relay documents between administrative, public institutions and private enterprises, institutions and individuals under the electronic document distribution system.
  • the Electronic Document Format Register can be used to create a sent document directly using Office tools for users who want to send electronic documents using a distributed messaging server system, but the standard document form can be used to help users create electronic documents more easily. It is a system that supports management such as document form registration and management, document form search, reading and downloading, document form deletion, and so on, for use by user applications such as distribution client APP while registering and managing the system.
  • the electronic document form register provides a standard interface that allows the server engine and client application (APP) that manages document standard forms to retrieve them, download them, and plug them into internal programs for use.
  • APP server engine and client application
  • the entire process for distributing electronic documents in electronic document distribution can be broadly classified into three stages: “1 preparation before distribution”, “2 electronic document distribution step”, and “3 proof for distribution”.
  • the "document transmission and reception method”, “distribution proof method” and “spam message processing method” will be described in detail with the detailed description of the three steps.
  • register manager registers standard document form to use using electronic document tasting register.
  • -Participants in the transmission and reception decide whether to build their own distribution messaging server system for trust distribution or to open and use user accounts in the existing distribution messaging server system.
  • a certification test is performed for the standard conformance and interoperability of the distribution messaging server system through a certification authority. After accessing the address directory server and requesting and issuing an ID of the send / receive object for the authorized distribution messaging server system, the user registers and manages the internal identifier for the internal real user.
  • the document sender selects a document to distribute or prepares a document to send through the document writer.
  • the distribution client APP obtains the physical address information and the public key information for encryption based on the public address of the receiving party in association with the address directory server. (Optionally, the Distribution Messaging Server does this if the Distribution Client APP does not obtain a physical address.)
  • the distribution client APP makes a request to the distribution messaging server based on the recipient's address information. (Both physical address information or authorized electronic address)
  • the distribution messaging server queries the address directory server for the physical address information of the receiver's transmitting / receiving entity based on the authorized electronic address.
  • the recipient shall generate a "receipt certificate" at the time of receipt of the document to confirm the receipt of the document and deliver it to the sender.
  • the recipient of the received document shall keep the "receipt certificate" in the third party archive.
  • the receiver delivers the received document to the person in charge of the actual document (user), and then generates a "reading certificate” and sends it to the sender when the person checks the received document.
  • the document sender who receives the "reading certificate” Keeps the "Certificate of Reading” in a third-party repository. (Issuance of Certificate of Reading applies only at the request of the sender.)
  • the sender attempts to deliver the document to the receiver but fails, the document is sent to the objective 3rd party electronic document distribution hub for proof of the attempted transmission, and the electronic document distribution hub that has been requested to send the document has been submitted.
  • the "Transmission Certificate” shall be issued and delivered to the sender, who shall receive the "Transmission Certificate” in the third-party archive.
  • the distribution messaging server system Through the distribution messaging server system, senders and receivers distribute documents electronically.
  • the distribution messaging server system sends and receives electronic documents according to distribution protocols.
  • For the distribution of trust messages all messages are composed of a combination of transmission and acknowledgment (or certificate of receipt) messages. Obtained through
  • Distribution certificate means a reliable way to prove the facts related to the transmission, reception, and viewing of electronic document distribution.
  • the “distribution certificate” is referred to collectively as the certificate issued for the acts related to electronic document distribution.
  • the distribution messaging server system issues a distribution certificate at the time of transmission and reception in order to verify the transmission and reception behavior, and stores the issued distribution certificate in a certified electronic document third-party storage institution to use as evidence of distribution behavior. Make sure
  • the distribution messaging server system proves the facts on the transmission, reception, and reading of electronic documents and generates distribution certificates for each fact.
  • the distribution certificate identifies distribution certificate identification information, distribution certificate creation time and expiration time, distribution certificate policy and distribution certificate. Include the subject.
  • the distribution certificate for the electronic document transmission is generated by the electronic document distribution hub and includes the sender identification information, the recipient identification information, the distribution identification information, the document identification information, and the request time of the electronic document transmission.
  • the distribution certificate for receiving the electronic document is generated by the receiver who has received the electronic document and includes the sender identification information, the recipient identification information, the distribution identification information, the document identification information, the electronic document transmission time, and the electronic document reception time.
  • the distribution certificate for reading the electronic document is generated by the user who has confirmed receipt of the electronic document, and the sender identification information, the recipient identification information, the distribution identification information, the document identification information, the electronic document transmission time, the electronic document reception time, and the electronic document reception are applied to the distribution certificate object.
  • a confirmation time must be included.
  • the distribution certificate thus generated should be digitally signed with an NPKI or GPKI certificate, the generated distribution certificate should be delivered to the sender of the electronic document, and all distribution certificates should be kept in a third-party archive.
  • Electronic document distribution basically transmits through the authorized distribution messaging server system, and the receiver also receives it by default, so it has an infrastructure to hold the sender accountable when sending spam.
  • a spammer establishes a user account in a distribution messaging server system and transmits using the same.
  • the current authentication method is only for the technical content of the system, when the spammer constructs the distribution messaging server system and technically authenticates it and then uses it as a spam sending means, it is initially blocked. This is not an easy situation.
  • the standard document distribution infrastructure provides a white list based on the authentication list management and a black list based on the spam target list management based on the user report method. To prevent spam messages by applying a process that can be unsubscribed.
  • the function to report spam message and to check the sending party is an essential function. All distribution messaging servers must build this function.
  • the receiver determines that the received message is a spam message
  • the receiver reports the spam message to the address directory server of the electronic document distribution hub by the process shown in FIG. 83, and the related procedure is as follows.
  • the receiver reports the message as a received message to the address directory server through the distribution messaging server system.
  • the address directory server that receives the spam message report from the distribution messaging server system returns a confirmation message indicating that the message has been received.
  • the ICT which manages the address directory server, analyzes the message and examines and determines whether to add a blacklist to the sender's public electronic address through a survey of the sender.
  • the address directory server adds the public electronic address to the blacklist and notifies the sender of the blacklist addition.
  • the address directory server delivers the processing result of the spam message request to the spam reporter (recipient).
  • the whitelist is recorded only with information on the messaging server system that is authenticated and registered by the sending distribution messaging server system, and the blacklist is registered when the sender's address is registered as a spammer. If duplicate spam addresses registered in the blacklist are generated through the same distribution messaging server system, the electronic document distribution hub may determine whether to cancel the authentication of the distribution messaging server system, and then cancel the authentication and delete the whitelist.
  • the receiver When the receiver receives the message, the receiver checks the whitelist and the blacklist of the address directory server to confirm whether or not the sender is a reliable and legitimate user, and then decides whether or not to reject the message. There is a periodic verification method to confirm the sender through real-time confirmation at the time of reception or through a list managed in a cache form in the distribution messaging server system of the receiver.
  • the process of checking the sender in real time is performed by determining whether the sender's address is registered in the whitelist or the blacklist at the address directory server at the time when the receiver receives the message, as shown in FIG.
  • the detailed processing procedure of the process of determining whether to reject the reception and performing the identification on the sender in real time is as follows.
  • the recipient's distribution messaging server system forwards a confirmation request message to the address directory server to confirm whether the user is a legitimate user.
  • the address directory server checks whether the address information of the requested user is included in the white list.
  • the address directory server immediately returns a result message indicating that the user is not registered to the verification requester. If the address is in the whitelist, the address directory server checks again whether the address is registered in the blacklist.
  • the address directory server returns a result message as to whether the blacklist has been registered to the requestor.
  • the recipient processes the received message as a spam message and receives the message from the address directory server. Record and store the result of receiving messages and spam messages.
  • the processing history of the spam message must be kept for at least one month, so that the validity of the rejection of the sender can be confirmed.
  • the process of periodically checking the sender is performed by receiving a whitelist and a blacklist from an address directory server in advance and manages itself based on the sender's address. After determining whether or not the message is registered in the list, it is determined whether to reject the message.
  • the detailed processing procedure of the process of periodically checking the sender is as follows.
  • the recipient's distribution messaging server system requests the latest whitelist and blacklist from the address directory server in advance and manages itself.
  • the automatic notification request is transmitted together.
  • the request for obtaining the latest list to the address directory server is periodically performed so that the list information does not differ by at least one day.
  • the address directory server broadcasts the change to the user who requested the change notification.
  • the user distribution messaging server system receiving the change to the list synchronizes by modifying the information of the self-managed list.
  • the recipient checks a self-managed list to see if he or she is a legitimate user on the address directory server.
  • the receiver determines that the sender is not a legitimate user (when it is not in the whitelist or is registered in the blacklist) as a result of the self-managed list check, the receiver processes the received message as a spam message and records the history of receiving the spam message. And keep it.
  • the processing history of the spam message must be kept for at least one month, so that the validity of the rejection of the sender can be confirmed.
  • Distribution messaging server system is largely composed of message transmission, message reception, mailbox management for incoming messages, message security (user authentication, document encryption / decryption, etc.), transmission / reception history management, address directory server connection, message verification, internal system connection interface, distribution It consists of issuance and management of certificates, and connection with third party custody institutions.
  • FIG. 86 illustrates a structure of the distribution messaging server system. Referring to FIG. 86, each of the components 1 to 9 of the distribution messaging server system will be described in detail as follows.
  • the status "in transmission” is a state in which no response is received from the receiver after the document is transmitted
  • the "transmission complete” state is a state in which a "receipt certificate” is received from the distribution messaging server system of the receiver, and the "transmission failed” state is received.
  • An error occurs inside the distributed messaging server system to return a SOAP Fault message, or a network error occurred during transmission or reception.
  • a "Contact Receive Complete” status indicates that the sending distribution messaging server system verified the document of the contact person from the receiver. You have received a "proof of reading”.
  • the "validation error” status is an error in the basic structure verification of the received message
  • the "before receipt confirmation” status is before the recipient of the receiving document reads the list of received documents in the mailbox
  • the "acknowledgement” status is the receipt document.
  • the person in charge reads the list of received documents in the mailbox
  • the "view confirmation” status indicates that the person in charge of the receiving document has read the details of the received document.
  • the recipient's distribution messaging server system issued a "reading certificate”. It will deliver to the sender later.
  • the transmission document, the acknowledgment message for the transmission, and the acknowledgment message of the recipient have related information so that they can be related to each other.
  • -Address information is managed according to the address information registration and search process provided by the address directory server.
  • -It basically performs the message security function (message digital signature, signature verification) suggested by distribution protocol.
  • the distribution messaging server system must keep / manage at least one year of sending / receiving history.
  • transmission history and reception history includes message id, related message id, sender (including user account), receiver, transmission time, and hash value for transmission document. Contains the hash value for the sender, receiver (including user account), reception time, and received document.
  • the distribution messaging server system issues and manages distribution certificates so that the contents of document transmission and reception can be proved.
  • the certificate of distribution is guaranteed to its credibility by requesting it to a third-party repository.
  • the distribution certificate issuance history includes distribution certificate id, distribution certificate issuance time, related message id, original distribution certificate (optional), and storage of third party storage institution. Contains archive-key information received afterwards.
  • the general sending / receiving entity transmits the request for storing the third party storage institution to the distribution messaging server system of the third party storage institution for the request for storing the distribution certificate (remote storage request).
  • the distribution messaging server system of the third-party archiving agency When the distribution messaging server system of the third-party archiving agency receives the request message for storing the authorized electronic archives, it calls the archiving request client for storing the distribution certificate to the third-party archiving agency.
  • the client for the distribution certificate storage request requests the storage to the third party storage organization according to the interworking interface specification of the third party storage organization.
  • the distribution certificate storage request module is stored in a third party when storing the distribution certificate. Request for storage by calling the interface client developed according to the organization interface specification.
  • the distribution messaging server system according to the present invention having the above components 1 to 9 is applied to a general transmission / reception entity (general operator) as shown in FIG.
  • the message is sent to the messaging server system to store the distribution certificate and processed by receiving the processing result.
  • the process of distributing a message directly between a sender and a receiver by using the distribution messaging server system according to the present invention having the components 1 to 9 as described above, includes: "acquiring physical address and security information for the receiver” and "2 message”. It consists of four steps, including “transmission and confirmation of transmission”, “3.3 receiving recipient's receipt”, “4. distribution certificate issuance and storage”, which will be described in detail with reference to FIG. .
  • the sender's system obtains this by requesting the address directory server for the physical address information and security information (if the receiving password for the outgoing message) to which the actual message should be delivered, based on the address information of the other party.
  • the physical address and security information for the recipient causes the distribution client APP to forward the recipient's physical address information to the distribution messaging server after making a request to the address directory server.
  • -Address information about the receiver can be obtained only by the id of the user (for example, social security number, business registration number, etc.), but in this case, it is possible only if the receiver allows the sender to search for id based address information.
  • This procedure can be omitted if the sender already knows the recipient's physical address information and security information.
  • the sender packages the message according to the distribution protocol specification and performs the digital signature based on the public certificate of the distribution messaging server system.
  • the retail messaging server system packages the previously obtained physical address and transmits the digitally signed message.
  • the receiving distribution messaging server system that receives the message verifies the basic packaging structure of the message, the validity of the digital signature, and the suitability of the sender (for details on verification, see “2.4.6 Message Verification”). Generate a receipt or error message for verification.
  • the receiving distribution messaging server system transmits the generated response message to the sender.
  • the transmission and acknowledgment process consists of synchronous message processing.
  • the receiver When the sender requests the confirmation message of the person in charge of the work at the time of message transmission, the receiver must generate and send a reading certificate that can confirm the confirmation of the person in charge to the sender at the time of the business acknowledgment of the message.
  • the original message sender sends the acknowledgment message synchronously.
  • the sender issues a certificate of receipt, reading and transmission at each stage and secures the basis of legal evidence on distribution by issuing it in a third-party storage institution.
  • the process of distributing a message directly between a sender and a receiver by using a distribution messaging server system includes the above-mentioned "acquisition of physical address and security information for the receiver", “2 message transmission and transmission confirmation", "3 tasks”.
  • "acknowledgement of the receiver” In addition to the "acknowledgement of the receiver", “4. issue and store the distribution certificate”, "5 error processing” is also performed.
  • the error handling function will be described in detail as follows.
  • All message sending and receiving processes in the distributed messaging server system are based on synchronous processing. Therefore, all errors on the transmission are based on retransmission because the sender can check them, and the same message transmission is sent again by setting the same MessageId value so that the receiver duplicates the error in the transmission of the acknowledgment message after successful reception. Allows you to detect receipt of a message.
  • the distribution messaging server system follows the processing flowchart as shown in FIG. 90 when the request message transmission fails. That is, if a transmission error occurs due to a network error during the message sender's transmission, if the sender receives an error message such as an HTTP error, the sender requests to resend the same message again, and the sender sends the message only when the recipient receives an acknowledgment message. Recognize it as a success.
  • an error message such as an HTTP error
  • the distribution messaging server system follows the processing flowchart as shown in FIG. 91 when the response message reception fails. That is, if the message is delivered to the receiver normally but the sender does not receive the acknowledgment message from the receiver, the sender recognizes it as a transmission failure error and resends the same message to the receiver with the same MessageId. If the same as the previous received message, the acknowledgment message is sent with duplicate reception and internal processing is performed.
  • the distribution messaging server system follows the processing flowchart as shown in FIG. 92 when the error message reception fails. That is, if the message sent by the sender to the receiver is correctly delivered, but there is an error in the transmission message itself, and the error message is responded, the sender has different message processing according to the type of error. It is not necessary and can be handled differently depending on the work situation.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • Marketing (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Health & Medical Sciences (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
PCT/KR2011/005027 2010-07-08 2011-07-08 전자문서 유통 시스템 및 전자문서 유통 방법 Ceased WO2012005546A2 (ko)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN201180043451.8A CN103124981B (zh) 2010-07-08 2011-07-08 电子文档流通系统和电子文档流通方法
JP2013518281A JP2013535858A (ja) 2010-07-08 2011-07-08 電子文書流通システムおよび電子文書流通方法
US13/808,576 US9143358B2 (en) 2010-07-08 2011-07-08 Electronic document communication system and electronic document communication method
EP11803832.2A EP2602758B1 (en) 2010-07-08 2011-07-08 Electronic document distribution system
SG2013001870A SG187006A1 (en) 2010-07-08 2011-07-08 Electronic document distribution system and electronic document distribution method

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
KR20100065985 2010-07-08
KR10-2010-0065985 2010-07-08
KR20100131936A KR20120005364A (ko) 2010-07-08 2010-12-21 전자 주소, 및 전자문서 유통 시스템
KR10-2010-0131936 2010-12-21
KR10-2010-0131935 2010-12-21
KR20100131935A KR20120005363A (ko) 2010-07-08 2010-12-21 전자문서 유통 시스템 및 전자문서 유통 방법
KR10-2011-0067185 2011-07-07
KR1020110067185A KR101266086B1 (ko) 2010-07-08 2011-07-07 전자문서 유통 시스템

Publications (2)

Publication Number Publication Date
WO2012005546A2 true WO2012005546A2 (ko) 2012-01-12
WO2012005546A3 WO2012005546A3 (ko) 2012-05-31

Family

ID=45611562

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/KR2011/005027 Ceased WO2012005546A2 (ko) 2010-07-08 2011-07-08 전자문서 유통 시스템 및 전자문서 유통 방법
PCT/KR2011/005039 Ceased WO2012005555A2 (ko) 2010-07-08 2011-07-08 전자문서 유통증명서 생성/발급 방법, 전자문서 유통증명서 검증 방법, 및 전자문서 유통시스템

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/KR2011/005039 Ceased WO2012005555A2 (ko) 2010-07-08 2011-07-08 전자문서 유통증명서 생성/발급 방법, 전자문서 유통증명서 검증 방법, 및 전자문서 유통시스템

Country Status (7)

Country Link
US (2) US9143358B2 (https=)
EP (2) EP2602758B1 (https=)
JP (3) JP2013535858A (https=)
KR (4) KR20120005363A (https=)
CN (2) CN103080958B (https=)
SG (3) SG187006A1 (https=)
WO (2) WO2012005546A2 (https=)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110419040A (zh) * 2017-04-27 2019-11-05 惠普发展公司，有限责任合伙企业 用于履行服务操作的控制器
US12137174B2 (en) 2021-07-27 2024-11-05 Fujitsu Limited Computer-readable recording medium storing information processing program, information processing apparatus, and system

Families Citing this family (88)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8826375B2 (en) * 2008-04-14 2014-09-02 Lookwithus.Com Inc. Rich media collaboration system
US8083129B1 (en) * 2008-08-19 2011-12-27 United Services Automobile Association (Usaa) Systems and methods for electronic document delivery, execution, and return
KR20120005363A (ko) * 2010-07-08 2012-01-16 정보통신산업진흥원 전자문서 유통 시스템 및 전자문서 유통 방법
EP2748963A4 (en) * 2011-09-30 2015-06-17 Ranganath C Abeyweera METHOD, SYSTEM AND DEVICE FOR COMMUNICATIONS CLIENT PROGRAM AND ASSOCIATED TRANSFER SERVER PROVIDING NAMED AND SECURE COMMUNICATIONS
CN103067338B (zh) * 2011-10-20 2017-04-19 上海贝尔股份有限公司 第三方应用的集中式安全管理方法和系统及相应通信系统
CA2796540A1 (en) * 2011-11-28 2013-05-28 Pika Technologies Inc. Transparent bridge device
US9367560B1 (en) * 2011-12-14 2016-06-14 Unboundid, Corp. Method, system and apparatus for synchronizing changes in a directory service
EP2632097A1 (en) * 2012-02-21 2013-08-28 Lleidanetworks Serveis Telemàtics S.A. Method for certifying delivery of SMS/MMS data messages to mobile terminals
US9344275B2 (en) 2012-05-08 2016-05-17 Arm Technologies Israel Ltd. System, device, and method of secure entry and handling of passwords
US9736121B2 (en) * 2012-07-16 2017-08-15 Owl Cyber Defense Solutions, Llc File manifest filter for unidirectional transfer of files
KR101223674B1 (ko) * 2012-09-06 2013-01-22 토피도 주식회사 샵 메일 전송 기능을 갖는 이 메일 클라이언트 데몬 시스템 및 이를 이용한 샵 메일 전송 방법
US20140082095A1 (en) * 2012-09-17 2014-03-20 Helen Y. Balinsky Workflow monitoring
KR20140048415A (ko) * 2012-10-12 2014-04-24 삼성전자주식회사 단말기의 전자편지지 다운로드서비스 제공 장치 및 방법
US9357382B2 (en) * 2012-10-31 2016-05-31 Intellisist, Inc. Computer-implemented system and method for validating call connections
KR102065390B1 (ko) 2013-02-15 2020-01-13 엘지이노텍 주식회사 발광소자, 발광소자 패키지 및 라이트 유닛
US9306887B1 (en) * 2013-03-14 2016-04-05 Dana Brunetti Systems and methods for implementing email delivery
US8739243B1 (en) 2013-04-18 2014-05-27 Phantom Technologies, Inc. Selectively performing man in the middle decryption
US10776384B1 (en) 2013-04-30 2020-09-15 Ping Identity Corporation Method, server and system for criteria-based assured replication
US9021575B2 (en) * 2013-05-08 2015-04-28 Iboss, Inc. Selectively performing man in the middle decryption
US9160718B2 (en) 2013-05-23 2015-10-13 Iboss, Inc. Selectively performing man in the middle decryption
US20140379584A1 (en) * 2013-06-25 2014-12-25 FraudFree Finance, LLC Anti-fraud financial transaction method
US9009461B2 (en) 2013-08-14 2015-04-14 Iboss, Inc. Selectively performing man in the middle decryption
KR101332607B1 (ko) * 2013-09-02 2013-11-25 서호진 공인전자주소 기반 전자문서유통체계에서 샵 메일의 전달 및 전달된 샵 메일의 유효성 검사 시스템 및 방법
US9710808B2 (en) * 2013-09-16 2017-07-18 Igor V. SLEPININ Direct digital cash system and method
US20150135338A1 (en) 2013-11-13 2015-05-14 Fenwal, Inc. Digital certificate with software enabling indicator
KR101425513B1 (ko) * 2014-02-12 2014-08-05 주식회사 티모넷 ＨＳＭ（Ｈａｒｄｗａｒｅ Ｓｅｃｕｒｉｔ Ｍｏｄｕｌｅ）과 인증 ＡＰＰＬＥＴ을 이용한 디바이스 인증 시스템
US9130996B1 (en) 2014-03-26 2015-09-08 Iboss, Inc. Network notifications
CN103997453B (zh) * 2014-05-13 2018-03-30 北京奇虎科技有限公司 一种与应用相关的信息处理的方法和装置
US9673998B2 (en) * 2014-05-15 2017-06-06 Futurewei Technologies, Inc. Differential cache for representational state transfer (REST) API
US9906367B2 (en) * 2014-08-05 2018-02-27 Sap Se End-to-end tamper protection in presence of cloud integration
CN105337950B (zh) * 2014-08-14 2019-02-19 阿里巴巴集团控股有限公司 一种表单填充方法及相关终端
KR102295570B1 (ko) * 2014-11-07 2021-08-30 주식회사 엘지유플러스 클라우드 프린팅 환경에서의 워터마크를 이용한 출력물 관리 방법
KR102256642B1 (ko) * 2014-12-04 2021-05-27 삼성전자주식회사 메시지 송수신 장치 및 메시지 송수신 방법
US20160162991A1 (en) * 2014-12-04 2016-06-09 Hartford Fire Insurance Company System for accessing and certifying data in a client server environment
US10079833B2 (en) * 2015-03-30 2018-09-18 Konica Minolta Laboratory U.S.A., Inc. Digital rights management system with confirmation notification to document publisher during document protection and distribution
KR101709197B1 (ko) * 2015-05-21 2017-02-22 (주)데이터코리아 어플리케이션을 기반으로 채권잔액확인서를 송수신하는 방법 및 어플리케이션
US10175977B2 (en) * 2015-11-04 2019-01-08 International Business Machines Corporation User profile based code review
US10839378B1 (en) * 2016-01-12 2020-11-17 21, Inc. Systems and methods for performing device authentication operations using cryptocurrency transactions
US11212363B2 (en) 2016-02-08 2021-12-28 Microstrategy Incorporated Dossier interface and distribution
US10791109B2 (en) 2016-02-10 2020-09-29 Red Hat, Inc. Certificate based expiration of file system objects
US10068074B2 (en) * 2016-03-25 2018-09-04 Credly, Inc. Generation, management, and tracking of digital credentials
US9680801B1 (en) 2016-05-03 2017-06-13 Iboss, Inc. Selectively altering references within encrypted pages using man in the middle
US10291604B2 (en) 2016-06-03 2019-05-14 Docusign, Inc. Universal access to document transaction platform
US20180006823A1 (en) * 2016-07-01 2018-01-04 Qualcomm Incorporated Multi-hop secure content routing based on cryptographic partial blind signatures and embedded terms
USRE49964E1 (en) 2016-10-04 2024-05-07 Samsung Electronics Co., Ltd Method and apparatus for transmitting a mission critical data message in a communication system
CN106789585A (zh) * 2016-12-27 2017-05-31 沃通电子认证服务有限公司 可验证电子邮件发送时间的方法及装置
CN106685979B (zh) * 2017-01-09 2019-05-28 北京信息科技大学 基于STiP模型的安全终端标识及认证方法及系统
JP6536609B2 (ja) * 2017-03-17 2019-07-03 富士ゼロックス株式会社 管理装置及びドキュメント管理システム
US11126665B1 (en) 2017-04-18 2021-09-21 Microstrategy Incorporated Maintaining dashboard state
KR101976665B1 (ko) * 2017-04-25 2019-08-28 주식회사 포시에스 영상 출력 장치들을 활용한 전자문서 정보 처리 장치 및 그의 정보 처리 방법
US11544669B2 (en) * 2017-06-26 2023-01-03 Oracle Financial Services Software Limited Computing framework for compliance report generation
CN107241341B (zh) * 2017-06-29 2020-07-07 北京五八信息技术有限公司 访问控制方法及装置
US11487868B2 (en) * 2017-08-01 2022-11-01 Pc Matic, Inc. System, method, and apparatus for computer security
US20190089692A1 (en) 2017-09-15 2019-03-21 Pearson Education, Inc. Time-based degradation of digital credentials in a digital credential platform
KR101951270B1 (ko) * 2017-09-28 2019-02-22 주식회사 스마트솔루션 메신저 인증 서버를 이용한 문서 발송 시스템 및 그 방법
US10803104B2 (en) 2017-11-01 2020-10-13 Pearson Education, Inc. Digital credential field mapping
US10607291B2 (en) 2017-12-08 2020-03-31 Nasdaq Technology Ab Systems and methods for electronic continuous trading of variant inventories
US10810350B2 (en) 2018-01-05 2020-10-20 Jpmorgan Chase Bank, N.A. System and method for aggregating legal orders
CN108540528B (zh) * 2018-03-07 2021-12-17 胡金钱 确认电子文书送达的方法及系统、计算机存储介质
CN108804238B (zh) * 2018-03-29 2022-03-04 中国工程物理研究院计算机应用研究所 一种基于远程过程调用的软总线通信方法
CN110324287B (zh) * 2018-03-31 2020-10-23 华为技术有限公司 接入认证方法、装置及服务器
US10742613B2 (en) * 2018-04-25 2020-08-11 Sap Se Pluggable framework for AS4 adapter generation
RU2702505C1 (ru) * 2018-08-07 2019-10-08 Акционерное общество Инжиниринговая компания "АСЭ" (АО ИК "АСЭ") Система управления электронным документооборотом
CN109150516A (zh) * 2018-08-31 2019-01-04 密信技术(深圳)有限公司 浏览器文件的签名及/或加密方法、装置、浏览器及介质
CN108989055A (zh) * 2018-08-31 2018-12-11 密信技术(深圳)有限公司 兼容不同类型文件的签名和加密方法、装置及存储介质
KR102158299B1 (ko) * 2019-01-23 2020-09-21 소프트캠프 주식회사 영업비밀에 관한 네트워크 기반의 문서 보호시스템
US10645197B1 (en) * 2019-04-19 2020-05-05 Clario Tech Limited Method and a system for a secure link-up to a non-secure synchronous connection and a machine-readable carrier configured for performing the method
JP7367443B2 (ja) 2019-10-09 2023-10-24 富士通株式会社 本人確認プログラム、管理装置及び本人確認方法
JP2021060915A (ja) * 2019-10-09 2021-04-15 富士通株式会社 本人確認プログラム、制御装置及び本人確認方法
CN113591439B (zh) * 2020-04-30 2023-07-11 抖音视界有限公司 一种信息交互方法、装置、电子设备及存储介质
WO2021218946A1 (zh) 2020-04-30 2021-11-04 北京字节跳动网络技术有限公司 信息交互方法、装置、电子设备及存储介质
FR3110801A1 (fr) * 2020-05-25 2021-11-26 Orange Procédé de délégation de la livraison de contenus à un serveur cache
CN111651196B (zh) * 2020-06-24 2024-06-21 腾讯科技（深圳）有限公司 文档发布方法、装置及服务器
KR102337673B1 (ko) 2020-07-16 2021-12-09 (주)휴먼스케이프 데이터 열람 검증 시스템 및 그 방법
KR102337677B1 (ko) 2020-07-16 2021-12-09 (주)휴먼스케이프 디지털 검증 지문 삽입 시스템 및 그 방법
JP7502618B2 (ja) 2020-07-20 2024-06-19 富士通株式会社 通信プログラム、通信装置、及び通信方法
TWI759908B (zh) * 2020-10-15 2022-04-01 威聯通科技股份有限公司 產生授權允許名單的方法與利用其之資安系統
JP7526655B2 (ja) * 2020-12-10 2024-08-01 富士通株式会社 情報処理プログラム、情報処理方法、情報処理装置および情報処理システム
KR102261527B1 (ko) 2021-01-14 2021-06-08 성균관대학교산학협력단 인휠 모터를 장착한 차량의 토크 벡터링 제어 장치 및 방법
US11556696B2 (en) * 2021-03-15 2023-01-17 Avaya Management L.P. Systems and methods for processing and displaying messages in digital communications
CN113126936B (zh) * 2021-04-23 2022-04-12 深圳市爱商在线科技有限公司 一种适配多种文档类型的打印控件
KR102470713B1 (ko) 2021-04-29 2022-11-25 (주)소프트제국 블록체인 did 기반 증명서 유통 서비스 제공 방법 및 장치
KR102599089B1 (ko) * 2021-10-06 2023-11-03 효성티앤에스 주식회사 전자문서 생성 방법 및 장치, 컴퓨터 판독 가능한 기록 매체 및 컴퓨터 프로그램
KR102498461B1 (ko) * 2022-04-25 2023-02-13 주식회사 디엠테크컨설팅 싱글사인온 제조정보 통합관리 시스템를 이용한 통합관리 방법
KR102479174B1 (ko) * 2022-07-05 2022-12-20 (주)링크허브 보안 전자 서명 관리 시스템 및 그 방법
KR102781390B1 (ko) * 2022-09-16 2025-03-14 주식회사 한글과컴퓨터 전자 문서에 대한 위변조 방지 처리를 수행할 수 있는 문서 폼 제공 서버 및 그 동작 방법
US20240114001A1 (en) * 2022-10-03 2024-04-04 Bank Of America Corporation System and method for server monitoring and problem resolution for electronic mail messages
KR102809674B1 (ko) * 2022-10-18 2025-05-21 주식회사 한글과컴퓨터 입력 필드의 셀 서식 정보를 기초로, 전자 문서에 대한 위변조 방지 처리를 수행할 수 있는 문서 폼 제공 서버 및 그 동작 방법

Family Cites Families (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2887806B2 (ja) 1989-08-18 1999-05-10 富士ゼロックス株式会社 ネットワークシステム及びメールゲートウエイ
JPH0535562A (ja) 1991-07-31 1993-02-12 Toshiba Corp 情報処理システムの文書管理装置
GB2287619A (en) 1994-03-03 1995-09-20 Ibm Security device for data communications networks
JPH07297822A (ja) 1994-04-21 1995-11-10 Hitachi Ltd メッセージ伝送システム
JPH08307448A (ja) * 1995-04-28 1996-11-22 Nippon Telegr & Teleph Corp <Ntt> 電子メールにおける受信通知方法およびその方法を適用した電子メール通信システム
JP3453459B2 (ja) 1995-06-19 2003-10-06 キヤノン株式会社 電子メールシステム及びその制御方法、並びに通信端末装置及びその制御方法
US6327656B2 (en) * 1996-07-03 2001-12-04 Timestamp.Com, Inc. Apparatus and method for electronic document certification and verification
US6584565B1 (en) * 1997-07-15 2003-06-24 Hewlett-Packard Development Company, L.P. Method and apparatus for long term verification of digital signatures
JP4237943B2 (ja) * 1998-09-21 2009-03-11 インターナショナル・ビジネス・マシーンズ・コーポレーション 電子取引においてセキュリティを改善する方法
JP2000183951A (ja) 1998-12-18 2000-06-30 Pfu Ltd 暗号化システムおよび記録媒体
US7966372B1 (en) * 1999-07-28 2011-06-21 Rpost International Limited System and method for verifying delivery and integrity of electronic messages
WO2001010090A1 (en) * 1999-07-28 2001-02-08 Tomkow Terrance A System and method for verifying delivery and integrity of electronic messages
US6775771B1 (en) 1999-12-14 2004-08-10 International Business Machines Corporation Method and system for presentation and manipulation of PKCS authenticated-data objects
IL138408A0 (en) 2000-04-07 2001-10-31 Digitalsecu Co Ltd Apparatus for and method of storing log data in communication network
JP2002082880A (ja) 2000-06-28 2002-03-22 Oregadare Inc メッセージの送受信管理方法及びメッセージの送受信管理システム
US20020059525A1 (en) * 2000-11-10 2002-05-16 Estes Timothy A. Authenticating the contents of e-documents
US20090144382A1 (en) * 2001-01-09 2009-06-04 Benninghoff Iii Charles F Method for certifying and unifying delivery of electronic packages
US8179555B2 (en) 2002-03-08 2012-05-15 Hewlett-Packard Development Company, L.P. Printing and finishing capability for customized document production system and method
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
JP4001047B2 (ja) * 2003-04-23 2007-10-31 村田機械株式会社 中継装置
JP2005108063A (ja) 2003-10-01 2005-04-21 Hitachi Ltd 暗号化データ変換装置を利用した電子自治体共用サーバ及び暗号化データ復号化装置を利用した電子自治体用端末
KR100579147B1 (ko) * 2004-01-29 2006-05-12 (주)드림투리얼리티 전자문서파일의 위변조 검증 전자문서관리시스템 및 그를이용한 방법
WO2005098566A1 (en) * 2004-04-08 2005-10-20 International Business Machines Corporation Method and system for linking certificates to signed files
DE602004002777T2 (de) 2004-08-31 2007-10-04 Opportunity Solutions A/S Vorrichtung zur Behandlung von E-Mails in einer Mehrbenutzer-Umgebung
KR100653512B1 (ko) 2005-09-03 2006-12-05 삼성에스디에스 주식회사 전자문서 관리 및 보관 시스템, 이 시스템에서 수행되는전자문서의 등록방법 및 이용방법
JP2007179145A (ja) 2005-12-27 2007-07-12 Brother Ind Ltd アドレス情報検索システム、およびアドレス情報検索プログラム
KR100816184B1 (ko) * 2006-08-10 2008-03-21 한국전자거래진흥원 전자문서의 불변경성과 사실증명을 수행하는전자문서보관소 시스템 및 그 시스템에서 수행되는전자문서 등록방법, 열람방법, 발급방법, 이관방법, 증명서발급방법
JP5029616B2 (ja) * 2006-12-22 2012-09-19 富士通株式会社 検証装置、検証方法および検証プログラム
US20080168536A1 (en) * 2007-01-10 2008-07-10 Rueckwald Mark C System and methods for reduction of unwanted electronic correspondence
CN101017544B (zh) * 2007-02-15 2010-12-01 江苏国盾科技实业有限责任公司 含电子印章数字证书的合体印章签署认证方法
WO2008120334A1 (ja) * 2007-03-28 2008-10-09 Fujitsu Limited 証明書検証方法及び証明書検証装置
KR100969313B1 (ko) * 2007-09-12 2010-07-09 정보통신산업진흥원 전자문서 증명서 발급 방법 및 이를 위한 전자문서 보관시스템, 상기 방법을 구현하는 프로그램이 저장된 기록매체
KR100978906B1 (ko) * 2007-09-12 2010-08-31 정보통신산업진흥원 전자문서 관리 시스템 및 그 운용 방법, 상기 방법을구현하는 프로그램이 저장된 기록매체
KR100932266B1 (ko) * 2007-10-12 2009-12-16 주식회사 하나은행 전자문서중계 서비스 제공 방법
US8739292B2 (en) * 2008-03-04 2014-05-27 Apple Inc. Trust exception management
US8732452B2 (en) 2008-06-23 2014-05-20 Microsoft Corporation Secure message delivery using a trust broker
JP2010093354A (ja) * 2008-10-03 2010-04-22 Sanyo Electric Co Ltd 通信装置
US8255685B2 (en) * 2009-03-17 2012-08-28 Research In Motion Limited System and method for validating certificate issuance notification messages
JP5105291B2 (ja) * 2009-11-13 2012-12-26 セイコーインスツル株式会社 長期署名用サーバ、長期署名用端末、長期署名用端末プログラム
KR20120005363A (ko) * 2010-07-08 2012-01-16 정보통신산업진흥원 전자문서 유통 시스템 및 전자문서 유통 방법

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"XML-Signature Syntax and Processing", TELECOMMUNICATIONS TECHNOLOGY ASSOCIATION, 2004

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110419040A (zh) * 2017-04-27 2019-11-05 惠普发展公司，有限责任合伙企业 用于履行服务操作的控制器
US12137174B2 (en) 2021-07-27 2024-11-05 Fujitsu Limited Computer-readable recording medium storing information processing program, information processing apparatus, and system

Also Published As

Publication number Publication date
EP2592594A2 (en) 2013-05-15
JP2013535858A (ja) 2013-09-12
US20130117400A1 (en) 2013-05-09
US20130110919A1 (en) 2013-05-02
SG187005A1 (en) 2013-02-28
JP2013535859A (ja) 2013-09-12
KR20120005393A (ko) 2012-01-16
KR20120005392A (ko) 2012-01-16
EP2602758A4 (en) 2014-01-22
CN103080958A (zh) 2013-05-01
SG187006A1 (en) 2013-02-28
CN103124981A (zh) 2013-05-29
EP2602758B1 (en) 2016-08-24
CN103124981B (zh) 2016-12-07
KR20120005363A (ko) 2012-01-16
KR20120005364A (ko) 2012-01-16
KR101364612B1 (ko) 2014-02-20
EP2592594A4 (en) 2014-05-14
WO2012005555A3 (ko) 2012-05-31
CN103080958B (zh) 2016-12-07
EP2602758A2 (en) 2013-06-12
EP2592594B1 (en) 2016-08-17
WO2012005546A3 (ko) 2012-05-31
KR101266086B1 (ko) 2013-05-27
JP2016195440A (ja) 2016-11-17
WO2012005555A2 (ko) 2012-01-12
US9143358B2 (en) 2015-09-22
SG10201505317XA (en) 2015-08-28

Similar Documents

Publication Publication Date Title
WO2012005546A2 (ko) 전자문서 유통 시스템 및 전자문서 유통 방법
Atkinson et al. Web services security (WS-Security)
US7698549B2 (en) Program product for unified certificate requests from certificate authorities
US20070276768A1 (en) Trusted third party services system and method
JP2013535858A5 (https=)
US20040213283A1 (en) Information transmitting apparatus, information saving apparatus, information receiving apparatus, method for using the same, and recording medium thereof
US20100111300A1 (en) Server certificate issuing system
Adams et al. Internet X. 509 Public Key Infrastructure data validation and certification server protocols
US8578150B2 (en) Contact information retrieval system and communication system using the contract information retrieval system
Foudil et al. A file format to aid in security vulnerability disclosure
US7246241B2 (en) Apparatus and method for securely realizing cooperative processing
JP2012181662A (ja) アカウント情報連携システム
Abley et al. Dnssec trust anchor publication for the root zone
Foudil et al. Rfc 9116: A file format to aid in security vulnerability disclosure
Blakley et al. WS-Security Profile of the OASIS Security Assertion Markup Language (SAML)
Adams et al. RFC3029: Internet X. 509 Public Key Infrastructure Data Validation and Certification Server Protocols
Hallam-Baker et al. WS-Security Profile of the OASIS Security Assertion Markup Language (SAML)
Hada et al. Web Services Security (WS-Security)
Bob Blakley et al. Document identifier: draft-sstc-ws-sec-profile-01 5 Location: http://www. oasis-open. org/committees/security/docs 6
Zolotarev et al. Network Working Group C. Adams Request for Comments: 3029 Entrust Technologies Category: Experimental P. Sylvester EdelWeb SA-Groupe ON-X Consulting
OUT Web Service Transfer (WS-Transfer)

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180043451.8

Country of ref document: CN

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

Ref document number: 11803832

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 13808576

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2013518281

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2011803832

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2011803832

Country of ref document: EP