Patent Publication Number: US-11645406-B2

Title: System for verifying data access and method thereof

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application claims priority from Korean Patent Application No. 10-2020-0087954 filed on Jul. 16, 2020 in the Korean Intellectual Property Office, and all the benefits accruing therefrom under 35 U.S.C. 119, the contents of which in its entirety are herein incorporated by reference. This application also relates to U.S. application Ser. No. 17/068,565 entitled “SYSTEM FOR EMBEDDING DIGITAL VERIFICATION FINGERPRINT AND METHOD THEREOF” which is concurrently filed with this application and incorporated herein by reference in its entirety. 
     BACKGROUND 
     1. Field 
     The present inventive concept relates to a system for verifying data access and a method thereof. Specifically, the present inventive concept relates to a system and a method for issuing data by inserting a verification fingerprint for data access, thereby performing verification. 
     2. Description of the Related Technology 
     Due to the effects of the recent rapid development of technology, it has become easy to access data online from anywhere in the world. Instead, restricting and managing access to data that require security is emerging as an important issue. Particularly for information that require limited access, such as personal information of a specific individual, or the medical information of a patient, verification of data after access may be necessary. 
     To achieve this, a watermarking technology has been proposed in which a watermark, which is a type of digital signature, is inserted into the original data. Digital watermarking is a type of copyright protection technology that solves copyright issues by inserting specific data called a watermark into digital data and re-extracting the data content. 
     Verification of data may include verification of the authenticity of the data. In other words, any falsification or distortion of data accessed by someone must be identified through verification. Through this verification step, it can be authorized that the opened data contains the same information as the actual original data. 
     In addition, verification of data may include the verification of a copyright. i.e., where the data originates. In other words, any abnormal acquisition of data to which access is denied must be restricted. 
     To this end, if accessed information on data can be verified through the data, the person who holds the data may trust the data, and the provider of the data may secure the basis for limiting unauthorized data holders. 
     SUMMARY 
     An object of the present inventive concept is to provide a system for verifying data access that verifies data using an independent verification fingerprint for data access. 
     Another object of the present inventive concept is to provide a data access verification method for verifying data using an independent verification fingerprint for data access. 
     The objects of the present inventive concept are not limited to the above, and other objects and advantages not mentioned can be understood from the following description, and more clearly understood from the embodiments of the described technology. In addition, it will be apparent that the objects and advantages of the present inventive concept can be carried out by the means in the scope of the claims and a combination thereof. 
     According to an aspect of the present inventive concept, there is provided a system for verifying data access, comprising a service module for receiving a data access request for an original data from a client, and sending a first verification data to the client, a verification module for receiving a first data eigenvalue corresponding to the original data from the service module, and generating a first verification fingerprint corresponding to the first data eigenvalue, a data module for generating the first verification data by receiving the first verification fingerprint to embed into the original data, and generating a first integrity value by hashing the first verification data and a verification database for storing data access information comprising the first data eigenvalue, the first verification fingerprint and the first integrity value in one record identified as the original data. 
     In some embodiments of the present inventive concept, wherein the verification database comprises a plurality of nodes, and wherein the data access information is each stored in the plurality nodes in a plurality of block chains forms. 
     In some embodiments of the present inventive concept, wherein the service module receives a second verification data and a data verification request from the client, and sends a verification acknowledgement thereto, wherein the data module generates a second integrity value by hashing the second verification data, and wherein the verification database generates the verification acknowledgement in response to the second integrity value. 
     In some embodiments of the present inventive concept, wherein the verification acknowledgement comprises a first verification acknowledgement and a second verification acknowledgement, wherein the first verification acknowledgement is an acknowledgement of the presence of a record corresponding to the second integrity value, wherein, when there is a record corresponding to the second integrity value, the verification database checks the original data corresponding to the second integrity value, wherein the data module generates a second verification fingerprint by contrasting the original data and the second verification data, and wherein the second verification acknowledgement is an acknowledgement of the second integrity value and the second verification data being in the same record. 
     In some embodiments of the present inventive concept, wherein the data access information comprises an inquirer information of the client and a request time corresponding to the data access request. 
     In some embodiments of the present inventive concept, wherein the verification database performs a primary storage of the data eigenvalue and the first verification fingerprint in one record identified as the original data, and thereafter, renewing by additionally performing a secondary storage of the first integrity value in the record. 
     In some embodiments of the present inventive concept, wherein the data access request comprises a second data eigenvalue comprising a key value corresponding to the original data, and wherein the service module generates a first data eigenvalue corresponding to the second data eigenvalue. 
     In some embodiments of the present inventive concept, wherein the first and second data eigenvalues are identical values. 
     According to another aspect of the present inventive concept, there is provided a data access verification method, comprising receiving a data access request corresponding to original data from a client, randomly generating a first verification fingerprint corresponding to the original data, recording an eigenvalue of the original data, the first verification fingerprint, and inquirer information for the client in a first record, generating a first verification data by inserting the first verification fingerprint into the original data, generating a first integrity value by hashing the first verification data, and renewing the first record by additionally storing the first integrity value in the first record. 
     In some embodiments of the present inventive concept, the method may further comprise receiving a second verification data and a verification request of the second verification data from the client, generating a second integrity value by hashing the second verification data, and verifying the second verification data through the second integrity value to send to the client. 
     In some embodiments of the present inventive concept, wherein verifying the second verification data through the second integrity value, comprises checking the presence of a second record recording the second integrity value and original data corresponding to the second record, extracting a second verification fingerprint by contrasting the original data and the second verification data, and determining whether the second verification fingerprint and the second integrity value are stored together in the second record. 
     In some embodiments of the present inventive concept, wherein generating the first verification data, comprises inserting the first verification fingerprint in a predetermined input-enabled location of the original data. 
     In some embodiments of the present inventive concept, wherein the input-enabled location is predetermined according to a data type of the original data. 
     In some embodiments of the present inventive concept, wherein the input-enabled location is located in an unused area of the original data. 
     In some embodiments of the present inventive concept, wherein recording the first record, comprises storing a request time corresponding to the data access request to the first record. 
     In some embodiments of the present inventive concept, comprising an appearance of the first verification data that is completely identical to an appearance of the original data. 
     In some embodiments of the present inventive concept, comprising an appearance of the first verification data that is different from an appearance of the original data. 
     The system for verifying data access and a method for the same of the present inventive concept allows independent verification of each data access, thereby allowing detailed tracking of the state of data. 
     In addition, the requester&#39;s information and request time, etc. of each browsing are recorded so that the detailed matters of data access request can be checked, enabling the detailed management of data. 
     In addition to the above-described information, the specific effects of the present inventive concept are disclosed along with the following description of the specific details for carrying out the described technology. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The above and other features and advantages of the present inventive concept will become more apparent by describing in detail embodiments thereof with reference to the attached drawings. 
         FIG.  1    is a conceptual diagram illustrating a system for verifying data access according to some embodiments. 
         FIG.  2    is a block diagram illustrating in detail, the system for verifying data access of  FIG.  1    inserting a verification fingerprint into an original data. 
         FIG.  3    is a flow chart displaying the operation of each module of the system for verifying data access according to some embodiments of the present inventive concept. 
         FIG.  4    is a conceptual diagram illustrating a verification database. 
         FIG.  5    is an exemplary view illustrating a table stored on the verification database. 
         FIG.  6    is a block diagram illustrating a data module and a watermarking module. 
         FIG.  7    is a flow chart displaying an operation of the data module and the watermarking module. 
         FIG.  8    is an exemplary view illustrating the system for verifying data access according to some embodiments of the present inventive concept converting original data into verification data. 
         FIG.  9    is a diagram illustrating an embedding location preset list and an input-enabled location of the system for verifying data access according to some embodiments of the present inventive concept. 
         FIG.  10    is a block diagram illustrating in detail, the system for verifying data access of  FIG.  1    verifying verification data. 
         FIG.  11    is a flow chart displaying an operation of each module related to the system for verifying data access according to some embodiments of the present inventive concept verifying verification data. 
         FIG.  12    is a flow chart illustrating a data access verification method according to some embodiments of the present inventive concept. 
         FIG.  13    is a flow chart illustrating in detail, the steps of extracting an embedding location of  FIG.  12    and generating a first verification data. 
         FIG.  14    is a flow chart illustrating in detail, the step of extracting an input-enabled location of  FIG.  13   . 
         FIG.  15    is a flow chart illustrating in detail, the step of extracting at least a portion of a usable area list of  FIG.  14    as an input-enabled location. 
         FIG.  16    is a flow chart illustrating the verification of verification data in the data access verification method according to some embodiments of the present inventive concept. 
         FIG.  17    is a block diagram of an electronic system implementing the system for verifying data access according to the embodiments of the present inventive concept. 
     
    
    
     DETAILED DESCRIPTION 
     The present inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, in which embodiments of the described technology are shown. This described technology may, however, be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the described technology to those skilled in the art. The same reference numbers indicate the same components throughout the specification. In the attached figures, the thickness of layers and regions is exaggerated for clarity. 
     It will be understood that when an element or layer is referred to as being “connected to,” or “coupled to” another element or layer, it can be directly connected to or coupled to another element or layer or intervening elements or layers may be present. In contrast, when an element is referred to as being “directly connected to” or “directly coupled to” another element or layer, there are no intervening elements or layers present. Like numbers refer to like elements throughout. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items. 
     It will also be understood that when a layer is referred to as being “on” another layer or substrate, it can be directly on the other layer or substrate, or intervening layers may also be present. In contrast, when an element is referred to as being “directly on” another element, there are no intervening elements present. 
     The use of the terms “a” and “an” and “the” and similar referents in the context of describing the described technology (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms “comprising,” “having,” “including,” and “containing” are to be construed as open-ended terms (i.e., meaning “including, but not limited to,”) unless otherwise noted. 
     Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this described technology belongs. It is noted that the use of any and all examples, or exemplary terms provided herein is intended merely to better illuminate the described technology and is not a limitation on the scope of the described technology unless otherwise specified. Further, unless defined otherwise, all terms defined in generally used dictionaries may not be overly interpreted. 
     Below is a description of the system for verifying data access according to some embodiments of the present inventive concept with reference to  FIG.  1    to  FIG.  11   . 
       FIG.  1    is a conceptual diagram illustrating the system for verifying data access according to some embodiments of the present inventive concept. 
     With reference to  FIG.  1   , the system for verifying data access  100  according to some embodiments of the present inventive concept can receive a data access request from a client  10 . The client  10  can transmit a first data eigenvalue I 1 , while transmitting the data access request. The system for verifying data access  100  can provide the client  10  with a first verification data Dv 1 . 
     Specifically, the client  10  can be an inquirer requesting a browse and inquiry of data from the system for verifying data access  100 . The client  10  can be someone with a legitimate title to browse the original data of the system for verifying data access  100 . 
     The client  10  can transmit data to the system for verifying data access  100  via a network. The network can include a network by a wired internet technology, a wireless internet technology and a local area communication technology. Wired internet technologies can include one or more from a group consisting of, for example, LAN (local area network) and WAN (wide area network). 
     Wireless internet technologies can include one or more from a group consisting of, for example, WLAN (Wireless LAN), DLNA (Digital Living Network Alliance), Wibro (Wireless Broadband). Wimax (World Interoperability for Microwave Access), HSDPA (High Speed Downlink Packet Access), HSUPA (High Speed Uplink Packet Access), IEEE 802.16, LTE (Long Term Evolution), LTE-A (Long Term Evolution-Advanced), WMBS (Wireless Mobile Broadband Service) and 5G NR (New Radio). However, this embodiment is not limited to the above. 
     Local area communication technologies can include one or more from a group consisting of, for example, Bluetooth, RFID (Radio Frequency Identification), IrDA (Infrared Data Association), UWB (Ultra-Wideband), ZigBee, NFC (Near Field Communication), USC (Ultra Sound Communication), VLC (Visible Light Communication), Wi-Fi, Wi-Fi Direct and 5G NR (New Radio). However, this embodiment is not limited to the above. 
     The client  10  and the system for verifying data access  100  communicating through a network can adhere to technical standards and standard communication methods for mobile communication. For example, standard communication methods can include one or more from the group consisting of: GSM (Global System for Mobile communication), CDMA (Code Division Multi Access), CDMA2000 (Code Division Multi Access 2000), EV-DO (Enhanced Voice-Data Optimized or Enhanced Voice-Data Only), WCDMA (Wideband CDMA), HSDPA (High Speed Downlink Packet Access), HSUPA (High Speed Uplink Packet Access), LTE (Long Term Evolution), LTEA (Long Term Evolution-Advanced) and 5G NR (New Radio). However, this embodiment is not limited to the above. 
     The client  10  can communicate with the system for verifying data access  100  via a user terminal. A user terminal can refer to a data processing terminal owned by the client  10 . The user terminal can be implemented as, for example, a PC (personal computer), a workstation, a data center, an internet data center (IDC), a DAS (direct attached storage) system, a SAN (storage area network) system, a NAS (network attached storage) system a RAID (redundant array of inexpensive disks, or redundant array of independent disks) system, or a mobile device, however, is not limited to the above. 
     In addition, the mobile device can be implemented as a laptop computer, a portable phone, a smart phone, a tablet PC, a PDA (personal digital assistant), an EDA (enterprise digital assistant), a digital still camera, a digital video camera, a PMP (portable multimedia player), a PND (personal navigation device or a portable navigation device), a handheld game console, a mobile internet device (MID), a wearable computer, an internet of things (IoT) device, an internet of everything (IoE) device, a drone, or an e-book, however, is not limited to the above. 
     The first data eigenvalue I 1  can be a value, which enables the client  10  to identify the original data making a browse requesting. For example, the first data eigenvalue I 1  can be a key value of the original data. However, this embodiment is not limited to the above. 
     The system for verifying data access  100  can receive a first data eigenvalue I 1  and a data access request from the client  10 , and transmit a first verification data Dv 1  to the client  10  in response. 
     In this regard, the transmission of the first verification data Dv 1  by the system for verifying data access  100  to the client  10  can go through the network. However, this embodiment is not limited to the above. 
     The first verification data Dv 1  is a data requested by the client  10 , which can be a data that includes a verification fingerprint for verification in the original data. The first verification data Dv 1  can be an identical data to the original data Do, with the exception of the verification fingerprint. 
       FIG.  2    is a block diagram illustrating in detail, the system for verifying data access of  FIG.  1    inserting a verification fingerprint into the original data. 
     With reference to  FIG.  1    and  FIG.  2   , the system for verifying data access  100  can include a service module  110 , a data module  120 , a data warehouse  130 , a verification module  140 , a verification database  150  and a watermarking module  160 . One or more of the modules  110 ,  120 ,  140  and  160  can be implemented with one or more processors. 
     The service module  110  can be a module in direct communication with the client  10 . The service module  110  can receive a first data eigenvalue I 1  from the client  10 . The service module  110  can receive a data access request along with the first data eigenvalue I 1 . The service module  110  can transmit a first verification data Dv 1  to the client  10  in response to the data access request. 
     The data module  120  can derive an input-enabled location Li from the original data Do together with the watermarking module  160 , and generate a first verification data Dv 1  by inserting a first verification fingerprint Fp 1  into the original data Do. In addition, the data module  120  can generate a first integrity value H 1  of the first verification data Dv 1 . In addition, the data module  120  can be a module in direct communication with the data warehouse  130 . 
     Specifically, the data module  120  can receive a first data eigenvalue I 1  and a first verification fingerprint Fp 1  from the service module  110 . The data module can transmit the original data Do, the first verification data Dv 1  and the first integrity value H 1  to the service module  110 . 
     In this regard, the original data Do can be a data responding to the data access request of the client  10  or a data identified by the first data eigenvalue I 1 . The original data Do can be one or more from a group of data in various forms, for example, an image, a video or a document. However, this embodiment is not limited to the above. 
     A first verification fingerprint Fp 1  can be generated by the verification module  140 . The first verification fingerprint Fp 1  can generate a first verification data Dv 1  by being inserted into the original data Do by the data module  120 . The first verification fingerprint Fp 1  can generate a first verification data Dv 1  without damaging the content of the original data Do by being inserted into an unused area of the original data Do. 
     In this regard, the first verification data Dv 1  may change a portion of the appearance of the original data Do, or may not. In other words, depending on the data type of the original data Do, there may or may not be a portion that does not change the appearance of the original data Do at all. Therefore, the first verification data Dv 1  can be completely identical to the original data Do in appearance. Or the first verification data Dv 1  may be different from the original data Do in appearance. 
     However, in either of the cases, the first verification data Dv 1  can possibly not damage the content of the original data Do. In other words, a significant portion of the original data Do may be preserved completely in the first verification data Dv 1 , and an insignificant portion may be changed. 
     A first integrity value H 1  can be a value generated by hashing a first verification data Dv 1  by the data module  120 . The first integrity value H 1  can be generated using a unidirectional hash function. For example, the first integrity value H 1  can be generated using one or more of MD5, SHA-1 and SHA-2 (i.e., SHA-224, SHA-256, SHA-384 and SHA-512). However, this embodiment is not limited to the above. 
     The data module  120  can transmit a first data eigenvalue I 1  to the data warehouse  130 . The data module  120  can receive the original data Do from the data warehouse  130 . The data module  120  can transmit the original data Do to the watermarking module  160 . The data module  120  can receive data type information It, an embedding location preset list Lp and an input-enabled location Li from the watermarking module  160 . 
     In this regard, a data type can refer to the type of file of the original data Do. For example, a data type can refer to a type of file, such as PDF or JPG. However, this embodiment is not limited to the above. 
     The embedding location preset list Lp can refer to a list of locations to insert a predetermined first verification fingerprint Fp 1  for each data type. In other words, the embedding location preset list Lp may be different for each data type. The embedding location preset list Lp can be located in an unused area of the original data Do for each data type. In this regard, an unused area can refer to an area in which the content of the original data Do does not change due to the insertion of a first verification fingerprint Fp 1 , or at least is difficult for the client  10  to verify such change. 
     The embedding location preset list Lp can display a plurality of areas using an offset and regular expression in the original data Do. In this regard, “offset” can refer to a method of expressing a location in a data, such as “n bytes from the front” or “n bytes from the back.” 
     In addition, “regular expression” includes all methods of expressing a location and an area in a data in a hex code, such as “front of a specific expression or a character string” or “back of a specific expression or a character string” in the original data Do. 
     The input-enabled location Li can refer to an area in which a final input of the first verification fingerprint Fp 1  from the embedding location preset list Lp is made. In other words, it can refer to an unused area in which the first verification fingerprint Fp 1  is input after being finally filtered from the embedding location preset list Lp. 
     The data warehouse  130  can store original data Do within it. The data warehouse  130  can receive a first data eigenvalue I 1  from the data module  120 . The data warehouse  130  can send the original data Do corresponding to the first data eigenvalue I 1  to the data module  120 . 
     The verification module  140  can be a module generating a first verification fingerprint Fp 1 , and in direct communication with the verification database  150 . However, this embodiment is not limited to the above. 
     Specifically, the verification module  140  can receive a second data eigenvalue I 2 , an inquirer information Ireq and a first integrity value H 1 . The verification module  140  can transmit a first verification fingerprint Fp 1  and a second acknowledgement Ack 2  to the service module  110 . 
     The service module  110  can generate a second data eigenvalue I 2  in response to the first data eigenvalue I 1 . In this regard, the second data eigenvalue I 2  can be a distinct value that can specify or identify the original data Do. For example, the second data eigenvalue I 2  can be a key value that can identify the original data Do. In this regard, the second data eigenvalue I 2  can be an identical value as the first data eigenvalue I 1 . However, this embodiment is not limited to the above. 
     Or the second data eigenvalue I 2  can be a value of hashing the original data Do. In this regard, the second data eigenvalue I 2  can be generated using a unidirectional hash function. For example, the second data eigenvalue I 2  can be generated using one or more of MD5, SHA-1 and SHA-2 (i.e., SHA-224, SHA-256, SHA-384 and SHA-512). However, this embodiment is not limited to the above. 
     The second data eigenvalue I 2  can be a value of a different form that can identify the original data Do in addition to the above-described values. 
     An inquirer information Ireq can refer to the information of identity of the client  10 . The inquirer information can include one or more from a group consisting of, for example, personal information of the client  10 , ID of the client  10  and the browsing history of the client  10 . However, this embodiment is not limited to the above 
     When the verification module  140  makes a verification fingerprint renewal request while transmitting a first integrity value H 1  to the verification database  150 , the second acknowledgement Ack 2  can be a response thereto. In other words, the verification database  150  can first store the second data eigenvalue I 2 , the first verification fingerprint Fp 1 , the request time T and inquirer information Ireq in the same record, and thereafter, receive the first integrity value H 1  along with the verification fingerprint renewal request. 
     In this regard, “same record” can refer to storing as a plurality of label values linked to one original data Do. For example, the second data eigenvalue I 2 , the first verification fingerprint Fp 1 , the request time T, the inquirer information Ireq and the first integrity value H 1  of the original data Do can be stored in the form of one row in each table. However, this embodiment is not limited to the above. 
     In this regard, the verification database  150  can store a first integrity value H 1  in the same record in which a second data eigenvalue I 2 , a first verification fingerprint Fp 1 , a request time T and inquirer information Ireq are stored. In addition, the verification database  150  can transmit a second acknowledgement Ack 2  to the verification module  140  to indicate that the first integrity value H 1  has been stored in the same record as the second data eigenvalue I 2 , the first verification fingerprint Fp 1 , the request time T and the inquirer information Ireq. The verification module  140  can transmit a second acknowledgment Ack 2  to the service module  110 . 
     In addition, the verification module  140  can deliver a second data eigenvalue I 2 , a first verification fingerprint Fp 1 , a request time T, inquirer information Ireq and a first integrity value H 1  to the verification database  150 . The verification module  140  can receive a first acknowledgement Ack 1  and a second acknowledgement Ack 2  from the verification database  150 . 
     A request time T can be a time at which the verification module  140  requests the verification database  150  to store the second data eigenvalue I 2 , the first verification fingerprint Fp 1  and the inquirer information Ireq. Or the request time T can be a time at which the client  10  delivers a data access request to the system for verifying data access  100 . 
     The request time T can be stored as one distinct value for one data access request. In other words, when the request time T is a time at which the data access request is identified, all of the above is possible. 
     A first acknowledgement Ack 1  can be an acknowledgement to the request made by the verification module  140  to the verification database  150  to store the second data eigenvalue I 2 , the first verification fingerprint Fp 1 , the request time T and the inquirer information Ireq. In other words, the verification database  150  can transmit a first acknowledgement Ack 1  to the verification module  140  after storing the second data eigenvalue I 2 , the first verification fingerprint Fp 1 , the request time T and the inquirer information Ireq. The first acknowledgement Ack 1  can refer to the success of storing the second data eigenvalue I 2 , the first verification fingerprint Fp 1 , the request time T and the inquirer information Ireq. However, this embodiment is not limited to the above. 
     The verification database  150  can store a second data eigenvalue I 2 , a first verification fingerprint Fp 1 , a request time T, inquirer information Ireq and a first integrity value H 1  of the original data Do in the same record. 
     The verification database  150  can be a standard storage location that can store data. Or the verification database  150  can be implemented in the form of a standard storage server or a block chain system. However, this embodiment is not limited to the above. 
     The watermarking module  160  can generate a first verification data Dv 1  by inserting a first verification fingerprint Fp 1  into the original data Do together with the data module  120 . A more detailed description of the watermarking module  160  will be provided subsequently. 
       FIG.  3    is a flow chart displaying the operation of each module of the system for verifying data access according to some embodiments of the present inventive concept. 
     With reference to  FIG.  2    and  FIG.  3   , first, the client  10  transmits a first data eigenvalue I 1  to the service module  110 . In this regard, the client  10  can transmit a data access request together. 
     Then, the service module  110  transmits the first data eigenvalue I 1  to the data module  120  in S 11 . 
     Then, the data module  120  transmits the first data eigenvalue I 1  to the data warehouse  130  in S 12 . 
     Then, the data warehouse  130  transmits the original data Do corresponding to the first data eigenvalue I 1  to the data module  120  in S 13 . 
     Then, the data module  120  transmits the original data Do to the service module  110  in S 14 . 
     Then, the service module  110  transmits a second data eigenvalue I 2  and inquirer information Ireq to the verification module  140  in S 15 . In this regard, the second data eigenvalue I 2  can be a value corresponding to the first data eigenvalue I 1 . For example, the second data eigenvalue I 2  can be a value that is identical to the first data eigenvalue I 1 , or a key value or a hashed value of the original data Do. However, this embodiment is not limited to the above. The service module  110  can generate a second data eigenvalue I 2  based on the first data eigenvalue I 1 . In addition, the service module  110  can generate inquirer information Ireq based on the information of the client  10 . In this regard, the inquirer information Ireq can be received from the client  10 , or in the case of a client  10  that has already been registered, the service module  110  may have the inquirer information Ireq. 
     Then, the verification module  140  generates a first verification fingerprint Fp 1 . The first verification fingerprint Fp 1  can be randomly generated. The size of the first verification fingerprint Fp 1  can be predetermined. However, this embodiment is not limited to the above. 
     Then, the verification module  140  transmits the second data eigenvalue I 2 , the first verification fingerprint Fp 1 , the request time T and the inquirer information Ireq to the verification database  150  in S 17 . In this regard, the request time T can be a time at which the service module  110  receives data access from the client  10 . In such case, the request time T can be generated by the service module  110  and transmitted to the verification module  140 . 
     Or the request time T can be a time at which the verification module  140  transmits the second data eigenvalue I 2 , the first verification fingerprint Fp 1  and the inquirer information Ireq to the verification database  150 . In such case, the request time T can be generated by the verification module  140 . 
     Then, the verification database  150  stores data access request information in a first record in S 18 . In this regard, the data access request information can include a second data eigenvalue I 2 , a first verification fingerprint Fp 1 , a request time T and inquirer information Ireq. All of the data access information stored in the first record can be stored in correspondence with the original data Do so that it can identify the original data Do. In this regard, “first record” simply refers to a specific record of a plurality of records, and is not limited to the foremost record. 
     Then, the verification database  150  transmits a first acknowledgement Ack 1  to the verification module  140  in S 19 . The first acknowledgement Ack 1  can be an acknowledgement to the data access request information being stored in the first record. 
     Then, the verification module  140  transmits the first verification fingerprint Fp 1  to the service module  110  in S 20 . The verification module  140  can transmit the first verification fingerprint Fp 1  to the service module  110  after receiving the first acknowledgement Ack 1  from the verification database  150 . If the first verification fingerprint Fp 1  is transmitted to the service module  110  before the data access request information is stored in the verification database  150 , any forthcoming verifications may not be successfully completed. Therefore, the period at which the verification module  140  transmits the first verification fingerprint Fp 1  to the service module  110  must be after the verification database  150  transmits the first acknowledgement Ack 1  to the verification module  140 . 
     Then, the service module  110  transmits the first verification fingerprint Fp 1  to the data module  120  in S 21 . 
     Then, the data module  120  generates a first verification data Dv 1  by embedding the first verification fingerprint Fp 1  to the original data Do in S 22 . The first verification data Dv 1  can be completely identical to the original data Do with the exception of the portion in which the first verification fingerprint Fp 1  is inserted. 
     Then, the data module  120  transmits the first verification data Dv 1  to the service module  110  in S 23 . 
     Then, the data module  120  generates a first integrity value H 1  by hashing the first verification data Dv 1  in S 24 . 
     Steps S 23  and S 24  above were described as consecutive steps, however, this embodiment is not limited to the above. Steps S 23  and S 24  may be performed in parallel. 
     Then, the data module  120  transmits the first integrity value H 1  to the service module  110  in S 25 . 
     Then, the service module  110  transmits the first integrity value H 1  to the verification module  140  in S 26 . 
     Then, the verification module  140  transmits the first integrity value H 1  to the verification database  150  in S 27 . 
     Then, the verification database  150  stores the first integrity value H 1  in the first record in S 28 . The first record can be renewed by adding the first integrity value H 1 . Therefore, the second data eigenvalue I 2 , the first verification fingerprint Fp 1 , the request time T, the inquirer information Ireq and the first integrity value H 1  can be stored in the first record. 
     Then, the verification database  150  transmits a second acknowledgement Ack 2  to the verification module  140 . The second acknowledgement Ack 2  can be an acknowledgement of the first record being renewed by adding the first integrity value H 1  to the first record. 
     Then, the verification module  140  transmits the second acknowledgement Ack 2  to the service module  110  in S 30 . 
     Then, the service module  110  provides the first verification data Dv 1  to the client  10  after receiving the second acknowledgement Ack 2  in S 31 . 
       FIG.  3    above is merely one exemplary sequence of operation of modules, and this embodiment is not limited to the above. Therefore, the system for verifying data access according to some embodiments of the present inventive concept may operate in a different sequence and method to  FIG.  3   . 
       FIG.  4    is a conceptual diagram illustrating the verification database of  FIG.  2   . 
     With reference to  FIG.  4   , the verification database  150  can be implemented in a block chain form, rather than as a simple storage server. 
     Specifically, the verification database  150  can include a plurality of nodes ( 151 ). The verification database  150  can store a record comprising the second data eigenvalue I 2 , the first verification fingerprint Fp 1 , the request time T, the inquirer information Ireq and the first integrity value H 1  of the above-described original data Do in the form of a block. The block can include a block header and a transaction, and the record can be included in the transaction. The integrity of the block header can be checked by storing the hash value of the transaction. 
     The verification database  150  can generate a block chain code by combining the block generated as above to an existing completed block chain code. This block chain code can each be stored in a plurality of nodes ( 151 ). Accordingly, even if a block chain code stored in any one of the plurality of nodes ( 151 ) is changed, a block chain code stored in the remaining nodes ( 151 ) exists, and thus, the verification database  150  can safely store the stored record so that it is not changed. 
     Particularly in the event of an attack to change data by hacking the verification database  150 , the change of the stored record can be prevented unless all of the plurality of nodes ( 151 ) of the verification database  150  are attacked. Accordingly, the verification database  150  can achieve improved security and reliability, and the system for verifying data access according to some embodiments of the present inventive concept can also have improved reliability. 
       FIG.  5    is an exemplary view illustrating a table stored in the verification database of  FIG.  2   . 
     With reference to  FIG.  2    and  FIG.  5   , the verification database  150  can include a table within it. The table of the verification database  150  can include data eigenvalues, verification fingerprints, inquirer information, request times and integrity values corresponding to the original data Do. In other words, for example, the above-described second data eigenvalue I 2 , the first verification fingerprint Fp 1 , the inquirer information Ireq, the request time T and the first integrity value H 1  can each correspond to the same. 
     The table of the verification database  150  can include data eigenvalues, verification fingerprints, inquirer information, request times and integrity values in one row. Through which, linked information can be included in the form of a label in one original data Do. Through which, verification data can be verified by verifying whether any forthcoming verification fingerprint and integrity value extracted from one verification data are located in the same record. i.e., the same row. 
     In the description above, the same record was explained as information located in the same row of the table. However, this embodiment is not limited to the above. The same record can comprise same columns in the table, or composed in another form. In other words, if information is arranged for the data eigenvalue, the verification fingerprint, the inquirer information, the request time and the integrity value to identify one original data, the arrangement of the information does not matter. 
       FIG.  6    is a block diagram illustrating the data module and the watermarking module of  FIG.  2   . 
     With reference to  FIG.  6   , the watermarking module  160  can include an interpretation module  161 , a preset module  162  and a preset database  163 . 
     The interpretation module  161  can determine the data type of the original data Do, and interpret the input-enabled location Li. Specifically, the interpretation module  161  can receive original data Do and an embedding location preset list Lp from the data module  120 . The interpretation module  161  can transmit the data type information It and the input-enabled location Li to the data module  120 . 
     The preset module  162  can directly communicate with the preset database  163  to send a predetermined embedding location preset list Lp for each data type. The preset module  162  can receive data type information It from the data module  120 . The preset module  162  can transmit the embedding location preset list Lp to the data module  120 . 
     The preset database  163  can store the embedding location preset list Lp within it. The preset database  163  can receive data type information It from the preset module  162 , and transmit an embedding location preset list Lp corresponding to the data type information It to the preset module  162 . 
       FIG.  7    is a flow chart displaying the operation of the data module and the watermarking module of  FIG.  6   . 
     With reference to  FIG.  6    and  FIG.  7   , the service module  110  transmits a first verification fingerprint Fp 1  to the data module  120  in S 21 . This step can be the same as Step S 21  of  FIG.  3   . 
     Then, the data module  120  transmits an original data Do to the interpretation module  161  in S 22   a.    
     Then, the interpretation module  161  analyzes the data type of the original data Do to transmit the data type information It to the data module  120  in S 22   b.    
     Then, the data module  120  transmits the data type information It to the preset module  162  in S 22   c.    
     Then, the preset module  162  transmits the data type information It to the preset database  163  in S 22   d.    
     Then, the preset database  163  sends an embedding location preset list Lp corresponding to the received data type information It to the preset module  162  in S 22   e . An embedding location preset list Lp corresponding to various types of data type information It may already be stored in the preset database  163 . 
     Then, the preset module  162  transmits the embedding location preset list Lp to the data module  120  in S 22   f.    
     Then, the data module  120  transmits the embedding location preset list Lp to the interpretation module  161  in S 22   g.    
     Then, the interpretation module  161  filters the embedding location preset list Lp to derive an input-enabled location Li (S 22   h ). 
     Then, the interpretation module  161  delivers the input-enabled location Li to the data module  120  in S 22   i.    
     Then, the data module  120  embeds a first verification fingerprint Fp 1  to the input-enabled location Li of the original data Do in S 22   j . Through which, a first verification data  9 Dv 1 ) can be generated. 
     Then, the data module  120  transmits the first verification data Dv 1  embedded with the first verification fingerprint Fp 1  to the service module  110  in S 23 . This step can be the same as S 23  of  FIG.  3   . 
       FIG.  7    above is merely one exemplary sequence of operation of modules, and this embodiment is not limited to the above. Therefore, the system for verifying data access according to some embodiments of the present inventive concept may operate in a different sequence and method to  FIG.  7   . 
       FIG.  8    is an exemplary view illustrating the system for verifying data access according to some embodiments of the present inventive concept converting original data into verification data. 
     With reference to  FIG.  6    to  FIG.  8   , the original data Do can be indicated as a hex code, i.e., a hexadecimal. The original data Do can include an input-enabled location Li derived by the interpretation module  161 . The data module  120  can embed a first verification fingerprint Fp 1  into the input-enabled location Li. The first verification fingerprint Fp 1  can also be indicated as a hex code. However, this embodiment is not limited to the above. 
     When a first verification fingerprint Fp 1  is embedded, the original data Do can be converted into a first verification data Dv 1 . The first verification data Dv 1  can be identical to the original data Do in its entirety, with the exception of the first verification fingerprint Fp 1 . 
       FIG.  9    is an illustration illustrating the embedding location preset list and the input-enabled location of the system for verifying data access according to some embodiments of the present inventive concept. 
     With reference to  FIG.  6    to  FIG.  9   , the interpretation module  161  can select the input-enabled location Li based on the received embedding location preset list Lp. 
     The embedding location preset list Lp can include a plurality of areas. The content of the original data Do may not be damaged for at least a portion of the plurality of areas included in the embedding location preset list Lp even if the first verification fingerprint Fp 1  is embedded. However, there may be areas where significant values exist within the embedding location preset list Lp. Therefore, the interpretation module  161  can filter this portion to select the final input-enabled location Li. 
     An input-unenabled area Lp 0  of the embedding location preset list Lp of  FIG.  9    is an area where a significant value exists because it is written with the code “7667 778e.” Thus, although it is included in the embedding location preset list Lp, it cannot be selected as the final input-enabled location Li. 
     The input-enabled location Li can include a substitutable area Li 1 , an insertable area Li 2  and a combined area Li 3 . A substitutable area Li 1  is an area in which insignificant values, such as “0000 0000” exist, and the first verification fingerprint Fp 1  can be substituted and inserted. 
     An insertable area Li 2  can be an area where no values exist in its original state. In the insertable area Li 2 , the first verification fingerprint Fp 1  may be directly inserted without the need of being substituted. In such case, the size of the first verification data Dv 1  may become larger than the original data Do according to the insertion of the first verification fingerprint Fp 1  into the insertable area Li 2 . 
     A combined area Li 3  can be an area in which the substitutable area Li 1  and the insertable area Li 2  are combined. The size of the first verification fingerprint Fp 1  may be predetermined. However, the size of the plurality of areas included in the embedding location preset list Lp may not be predetermined. In other words, the size of the plurality of areas included in the embedding location preset list Lp can be sufficiently large for the first verification fingerprint Fp 1  to be inserted, however, it can also be too small for the first verification fingerprint Fp 1  to be inserted. 
     If a portion of the plurality of areas included in the embedding location preset list Lp is too small for the first verification fingerprint Fp 1  to be inserted, the interpretation module  161  can generate a larger area by being merged together. In this regard, the merged area generated by this merging can be sufficiently large for the first verification fingerprint Fp 1  to be inserted. 
     The merged area generated by the merging can be classified into an area merging substitutable areas Li 1 , an area merging insertable areas Li 2  and an area merging a substitutable area Li 1  with an insertable area Li 2 . Among which, the area merging a substitutable area Li 1  with an insertable area Li 2  can be defined as a combined area Li 3 . 
     Therefore, the combined area Li 3  can comprise two or more areas, and at least one of each sub-area can be a substitutable area Li 1 , and at least one of each sub-area can be an insertable area Li 2 . 
     The data module  120  can insert the first verification fingerprint Fp 1  into one or more original data. In other words, the first verification fingerprint Fp 1  can be repeatedly inserted into original data Do by the data module  120 . 
       FIG.  10    is a block diagram illustrating in detail, the system for verifying data access of  FIG.  1    verifying verification data. 
     With reference to  FIG.  10   , the service module  110  can receive a second verification data Dv 2  from the client  10  of  FIG.  1   , and send a fourth acknowledgement (Ack 4 ). In this regard, the second verification data Dv 2  can be a verification data owned by the client  10  of  FIG.  1   . A fourth acknowledgement (Ack 4 ) is an acknowledgement of the second verification fingerprint Fp 2  and the second integrity value H 2  being located in the same record in the verification database  150 , and can be an acknowledgement of the second verification data Dv 2  being verified. 
     The service module  110  can transmit the second verification data Dv 2  and the first data eigenvalue I 1  to the data module  120 . The data module  120  can extract the second integrity value H 2  and the second verification fingerprint Fp 2  to transmit to the service module  110 . 
     The first data eigenvalue I 1  can be the same value as the first data eigenvalue I 1  of  FIG.  2   . The first data eigenvalue I 1  can be a key value corresponding to the original data Do. The service module  110  can receive the second data eigenvalue I 2  from the verification module  140  to transmit the first data eigenvalue I 1  corresponding to the second data eigenvalue I 2  to the data module  120 . 
     The second integrity value H 2  can be a value that is generated by the data module  120  by hashing the second verification data Dv 2 . The second integrity value H 2  can use the same hash function as the hash function for generating the first integrity value H 1  of  FIG.  2   . 
     A second verification fingerprint Fp 2  can be extracted by the data module  120  by contrasting the second verification data Dv 2  and the original data Do. The second verification fingerprint Fp 2  can be the portion that is different between the second verification data Dv 2  and the original data Do. 
     The data module  120  can transmit the first data eigenvalue I 1  to the data warehouse  130 , and receive the original data Do corresponding to the first data eigenvalue I 1 . 
     The service module  110  can transmit the second integrity value H 2  and the second verification fingerprint Fp 2  to the verification module  140 , and receive the second data eigenvalue I 2  and the fourth acknowledgement (Ack 4 ). The second eigenvalue I 2  can be the same value as the second data eigenvalue I 2  of  FIG.  2   . The second data eigenvalue I 2  can be the value of sending the second data eigenvalue I 2  in the same record to the verification module  140  after the verification database  150  receives the second integrity value H 2 . The service module  110  can transmit the first data eigenvalue I 1  corresponding to the received second data eigenvalue I 2  to the data module  120 . 
     The verification module  140  can transmit the second integrity value H 2  and the second verification fingerprint Fp 2  to the verification database  150 , and receive a third acknowledgement Ack 3  and a fourth acknowledgement Ack 4 . In this regard, the third acknowledgement Ack 3  can be an acknowledgement of the presence of a record corresponding to the second integrity value H 2 . The fourth acknowledgement Ack 4  can be an acknowledgement of the second integrity value H 2  and the second verification fingerprint Fp 2  being in the same record. 
     The verification database  150  can receive the second integrity value H 2  and the second verification fingerprint Fp 2  from the verification module  140 . The verification database  150  can transmit the third acknowledgement Ack 3  and the fourth acknowledgement Ack 4  to the verification module  140 . 
       FIG.  11    is a flow chart displaying the operation of each module related to the system for verifying data access according to some embodiments of the present inventive concept verifying the verification data. 
     With reference to  FIG.  11   , first, the client  10  transmits the second verification data Dv 2  to the service module  110  in S 40 . 
     Then, the service module  110  transmits the second verification data Dv 2  to the data module  120  in S 41 . 
     Then, the data module  120  hashes the second verification data Dv 2  to generate the second integrity value H 2  in S 42 . If the second verification data Dv 2  is identical to the above-described first verification data Dv 1 , the second integrity value H 2  can be identical to the first integrity value H 1 . 
     Then, the data module  120  transmits the second integrity value H 2  to the service module  110  in S 43 . 
     Then, the service module  110  transmits the second integrity value H 2  to the verification module  140  in S 44 . 
     Then, the verification module  140  transmits the second integrity value H 2  to the verification database  150  in S 45 . 
     Then, the verification database  150  checks whether there is a record corresponding to the second integrity value H 2 , and checks the original data corresponding to the second integrity value H 2  in S 46 . If the second integrity value H 2  is identical to the above-described first integrity value H 1 , the above-described first record and the original data Do corresponding to the first record can be identified. In addition, the second data eigenvalue I 2  corresponding to the first record can be identified. 
     Then, the verification database  150  transmits the third acknowledgement Ack 3  to the verification module  140  in S 47 . If the first record and the original data Do corresponding to the first record are identified by the verification database  150 , the third acknowledgement Ack 3  can be an acknowledgement of the identification of the first record and the original data Do corresponding to the first record. In addition, it can also be an acknowledgement of the identification of the second data eigenvalue I 2  corresponding to the first record. 
     Then, the verification module  140  transmits the identified second data eigenvalue I 2  to the service module  110  in S 48 . 
     Then, the service module  110  transmits the first data eigenvalue I 1  to the data module  120  in S 49 . In this regard, the first data eigenvalue I 1  can be identical to the second data eigenvalue I 2 , or a value corresponding to the second data eigenvalue I 2 . The first data eigenvalue I 1  can be a key value corresponding to the original data Do. The service module  110  can receive the second data eigenvalue I 2 , and generate a first data eigenvalue I 1  corresponding to the second data eigenvalue I 2 . 
     Then, the data module  120  transmits the first data eigenvalue I 1  to the data warehouse  130  in S 50 . 
     Then, the data warehouse  130  transmits the original data Do to the data module  120  in S 51 . The original data Do can correspond to the first data eigenvalue I 1 . 
     Then, the data module  120  contrasts the original data Do with the second verification data Dv 2  to extract a second verification fingerprint Fp 2  in S 52 . In this regard, the second verification fingerprint Fp 2  can be extracted by the difference between the original data Do and the second verification data Dv 2 . If the second verification data Dv 2  is identical to the above-described first verification data Dv 1 , the second verification fingerprint Fp 2  can be identical to the first verification fingerprint Fp 1 . 
     Then, the data module  120  transmits the extracted second verification fingerprint Fp 2  to the service module  110  in S 53 . 
     Then, the service module  110  transmits the second verification fingerprint Fp 2  to the verification module  140  in S 54 . 
     Then, the verification module  140  transmits the second verification fingerprint Fp 2  to the verification database  150  in S 55 . 
     Then, the verification database  150  checks the presence of the second verification fingerprint Fp 2  and the second integrity value H 2  in the same record in S 56 . In this regard, if the second verification fingerprint Fp 2  and the second integrity value H 2  are each identical to the first verification fingerprint Fp 1  and the first integrity value H 1 , they can exist in the same record, which is the first record. 
     Then, the verification database  150  transmits a fourth acknowledgement Ack 4  to the verification module  140  in S 57 . In this regard, the fourth acknowledgement Ack 4  can be an acknowledgement of the presence of the second verification fingerprint Fp 2  and the second integrity value H 2  in the same record. Through which, it can be verified that there is no falsification or modification to the second verification data Dv 2  from the original data Do, and it is a lawfully browsed data. 
     Then, the verification module  140  transmits the fourth acknowledgement Ack 4  to the service module  110  in S 58 . 
     Then, the service module  110  transmits the fourth acknowledgement Ack 4  to the client  10  in S 59 . 
       FIG.  11    above is merely one exemplary sequence of operation of modules, and this embodiment is not limited to the above. Therefore, the system for verifying data access according to some embodiments of the present inventive concept may operate in a different sequence and method to  FIG.  11   . 
     In this embodiment, if the presence of the second integrity value H 2  in the record is identified in Step S 46 , it can be primarily verified that there is no falsification or modification to the second verification data Dv 2 , and it is a lawfully browsed data. 
     However, since the second integrity value H 2  is a hash value having a short length, Step S 56  can be additionally performed to exclude the probability of having the same hash value in different verification data. 
     Through which, this embodiment can perform a more accurate and precise verification of data. 
     In addition, in this embodiment, it can be clearly ascertained when and who browsed the requested verification data based on information stored in the verification database  150 . Accordingly, browsing that is restricted by data security can be easily and rapidly managed. 
     In addition, the access of data using an abnormal route by those without browsing rights of the data can also be clearly ascertained and controlled. 
     Below is a description of the data access verification method according to some embodiments of the present inventive concept with reference to  FIG.  1    to  FIG.  3   ,  FIG.  6    to  FIG.  9    and  FIG.  12    to  FIG.  16   . The above-described embodiments and overlapping descriptions are omitted, or briefly outline. 
       FIG.  12    is a flow chart illustrating the data access verification method according to some embodiments of the present inventive concept, and  FIG.  13    is a flow chart illustrating in detail, the steps of extracting the embedding location, and generating the first verification data of  FIG.  12   .  FIG.  14    is a flow chart illustrating in detail, the step of extracting the input-enabled location of  FIG.  13   , and  FIG.  15    is a flow chart illustrating in detail, the step of extracting at least a portion of the usable area list in  FIG.  14    as an input-enabled location.  FIG.  16    is a flow chart illustrating the verification of verification data in the data access verification method according to some embodiments of the present inventive concept. 
     With reference to  FIG.  12   , data access request is received from the client in S 110 . 
     Specifically, with reference to  FIG.  1    to  FIG.  3   , the client  10  can transmit a data access request, while transmitting the first data eigenvalue I 1  to the system for verifying data access  100 . The first data eigenvalue I 1  can be a value that can identify the original data requested by the client  10 . 
     Again, with reference to  FIG.  12   , the presence of original data corresponding to the data access request is determined in S 120 . 
     Specifically, with reference to  FIG.  1    to  FIG.  3   , the data warehouse  130  can determine the presence of an original data Do corresponding to the first data eigenvalue I 1 . If there is no corresponding original data Do, a request fail message is transmitted to the client in S 220 . 
     Again, with reference to  FIG.  12   , if there is original data corresponding to the first data eigenvalue, the original data is loaded in S 130 . 
     Specifically, with reference to  FIG.  1    to  FIG.  3   , the data warehouse  130  can send the original data Do corresponding to the first data eigenvalue I 1  to the data module  120 . 
     Again, with reference to  FIG.  12   , a first verification fingerprint Fp 1  corresponding to the original data is generated in S 140 . 
     Specifically, with reference to  FIG.  1    to  FIG.  3   , the first verification fingerprint Fp 1  can be generated by the verification module  140 . The first verification fingerprint Fp 1  can be randomly generated. However, this embodiment is not limited to the above. 
     Again, with reference to  FIG.  12   , data access request information is stored in the first record in S 150 . 
     Specifically, with reference to  FIG.  1    to  FIG.  3   , the verification database  150  stores data access request information in the first record. In this regard, the data access request information can include a second data eigenvalue I 2 , a first verification fingerprint Fp 1 , a request time T and inquirer information Ireq. 
     Again, with reference to  FIG.  12   , the success of storing the data access request information is determined in S 160 . 
     If the storage of the data access request information has failed, a request fail message is transmitted to the client in S 220 . 
     If the storage of the data access request information has succeeded, an input-enabled location according to the original data type is extracted in S 170 . 
     Specifically, with reference to  FIG.  1    to  FIG.  3   , the data module  120  and the watermarking module  160  extracts an input-enabled location Li according to the original data type. 
     Again, with reference to  FIG.  12   , a first verification fingerprint is embedded into the original data to generate the first verification data in S 180 . 
     Specifically, with reference to  FIG.  1    to  FIG.  3   , the data module  120  embeds a first verification data Dv 1  into the original data Do to generate the first verification data Dv 1 . 
     Again, with reference to  FIG.  12   , the first integrity value for the first verification data is generated in S 190 . 
     Specifically, with reference to  FIG.  1    to  FIG.  3   , the first integrity value H 1  can be a value generated by the data module  120  by hashing the first verification data Dv 1 . The first integrity value H 1  can be generated using a unidirectional hash function. For example, the first integrity value H 1  can be generated using one or more of MD5, SHA-1 and SHA-2 (i.e., SHA-224, SHA-256, SHA-384 and SHA-512). However, this embodiment is not limited to the above. 
     Again, with reference to  FIG.  12   , the first integrity value is stored in the first record in S 200 . 
     Specifically, with reference to  FIG.  1    to  FIG.  3   , the verification database  150  stores the first integrity value H 1  in the first record in S 28 . The first record can be renewed by adding the first integrity value H 1 . 
     Again, with reference to  FIG.  12   , the first verification data is transmitted to the client in S 210 . 
     Specifically, with reference to  FIG.  1    and  FIG.  3   , the service module  110  can transmit the first verification data Dv 1  to the client  10  in response to the data access request. 
     Below is a detailed explanation of Steps S 170  and S 180  of  FIG.  12    above, with reference to  FIG.  2   ,  FIG.  3   ,  FIG.  6   ,  FIG.  7    and  FIG.  13   . 
     With detailed reference to  FIG.  13   , an original data and a first verification fingerprint are received in S 310 . 
     Specifically, with reference to  FIG.  2   ,  FIG.  3   ,  FIG.  6    and  FIG.  7   , the data module  120  can receive an original data Do and a first verification fingerprint Fp 1 . 
     Again, with reference to  FIG.  13   , the data type of the original data is identified in S 320 . 
     Specifically, with reference to  FIG.  6    and  FIG.  7   , the interpretation module  161  receives the original data Do from the data module  120 , and checks the data type of the original data Do. The interpretation module  161  sends the data type information It related to the data type of the original data Do to the data module  120 . 
     Again, with reference to  FIG.  13   , an embedding location preset list according to the data type is received in S 330 . 
     Specifically, with reference to  FIG.  6    and  FIG.  7   , the data module  120  transmits the data type information It to the preset module  162 . The preset module  162  again transmits the data type information It to the preset database  163 . The preset database  163  sends the embedding location preset list Lp corresponding to the data type information It stored in the database to the preset module  162 . The preset module  162  transmits the embedding location preset list Lp to the data module  120 . 
     Again, with reference to  FIG.  13   , an input-enabled location is extracted from the embedding location preset list in S 340 . 
     Specifically, with reference to  FIG.  6    and  FIG.  7   , the data module  120  transmits the embedding location preset list Lp to the interpretation module  161 . The interpretation module  161  extracts an input-enabled location Li from the areas of the embedding location preset list. 
     Again, with reference to  FIG.  13   , a first verification fingerprint is inserted into the input-enabled location in S 350 . 
     Specifically, with reference to  FIG.  2    and  FIG.  3   , a first verification fingerprint Fp 1  can be inserted into the original data Do by the data module  120  to generate a first verification data Dv 1 . The first verification fingerprint Fp 1  can be inserted into an unused area of the original data Do to generate the first verification data Dv 1  without damaging the content of the original data Do. 
     Below is a detailed explanation of Step S 340  of  FIG.  13    above, with reference to  FIG.  6    to  FIG.  9    and  FIG.  14   . 
     With detailed reference to  FIG.  14   , a review area is appointed in the embedding location preset list in S 341 . 
     Specifically, with reference to  FIG.  6    and  FIG.  9   , the embedding location preset list Lp can include a plurality of separated areas. The interpretation module  161  can consecutively determine the entirety of the plurality of areas in the embedding location preset list Lp. In other words, the interpretation module  161  can appoint and determine certain areas of the embedding location preset list Lp as review areas, and then, consecutively appoint and determine the remaining areas also as review areas. 
     Again, with reference to  FIG.  14   , the use of a review area is determined in S 342   a . If the review area has been used, it cannot be used as a review area. Thus, a review area is appointed again in S 341 . If the review area has not been used, review of the review area can be continued. 
     Specifically, with reference to  FIG.  6    and  FIG.  9   , an input-unenabled area Lp 0  of the embedding location preset list Lp is an area in which a significant value exists because it is written with the code “7667 778e,” and thus, had been included in the embedding location preset list Lp. However, it cannot be selected as a final input-enabled location Li. Therefore, in such case, it can be excluded from input-enabled locations Li. 
     Furthermore, the review of substitutable areas Li 1 , in which insignificant values, such as “0000 0000” exist, or insertable areas Li 2 , in which no values exist, can be continued. 
     Again, with reference to  FIG.  14   , it is determined whether the length of the review area is smaller than the length of the verification fingerprint in S 342   b.    
     Specifically, with reference to  FIG.  6    and  FIG.  9   , the size of the first verification fingerprint Fp 1  can be predetermined. However, the size of the plurality of areas included in the embedding location preset list Lp may not be predetermined. In other words, the size of the plurality of areas included in the embedding location preset list Lp can be sufficiently large for the first verification fingerprint Fp 1  to be inserted, however, it can also be too small for the first verification fingerprint Fp 1  to be inserted. 
     Again, with reference to  FIG.  14   , if the length of the review area is greater or equal to the length of the verification fingerprint, the review area is added to the usable area list in S 343 . In contrast, if the length of the review area is smaller than the length of the verification fingerprint, the review area is added to the reserve usable area list in S 344 . 
     Then, it is determined whether all areas of the embedding location preset list have been checked in S 345 . If not, the review area is appointed again in S 341 , and if all areas have been checked, the next step is performed. 
     Then, it is determined whether there are two or more review areas added to the reserve usable area list in S 346   a . If there are less than two review areas added to the reserve usable area list, at least a portion of the usable area list is immediately extracted as an input-enabled location in S 348 . 
     If there are two or more review areas added to the reserve usable area list, it is determined whether the length of a merged area combining the review areas added to the reserve usable area list is smaller than the length of the verification fingerprint in S 346   b.    
     If the length of the merged area combining the review areas added to the reserve usable area list is greater or equal to the length of the verification fingerprint, the merged area is added to the usable area list in S 347 . 
     If the length of the merged area combining the review areas added to the reserve usable area list is smaller than the length of the verification fingerprint, the merged area is not added to the usable area list. 
     Then, at least a portion of the usable area list is extracted as an input-enabled location in S 348 . 
     Specifically, with reference to  FIG.  6    and  FIG.  9   , the interpretation module  161  can extract an input-enabled location Li using this process. 
     In this regard, an input-enabled location Li can use the entirety of the given usable area list. In such case, the original data Do can be converted to a first verification data Dv 1 , thereby corresponding to the case having the greatest number of changed portions. Through which, this embodiment can enable easy extraction of any forthcoming verification data, and even if an error occurs during the conversion procedure, verification can be performed. 
     Or an input-enabled location Li can be extracted by randomly selecting only a portion of the given usable area list. In such case, any unexpected damage of the content of the original data Do can be minimized by minimizing changes to the original data Do. 
     Or the input-enabled location Li can consecutively extract an input-enabled location according to the characteristics of the areas of the given usable area list. Below is detailed explanation of Step S 348  of  FIG.  14    above, when extraction is performed according to the characteristics of the areas, with reference to  FIG.  6    to  FIG.  9    and  FIG.  15   . 
     With reference to  FIG.  15   , the presence of substitutable areas, insertable areas and combined areas in the usable area list is checked in S 348   a.    
     Specifically, with reference to  FIG.  6    and  FIG.  9   , a combined area Li 3  can be a merged area of a substitutable area Li 1  and an insertable area Li 2 . A merged area can be classified into an area merging substitutable areas Li 1 , an area merging insertable areas Li 2  and an area merging a substitutable area Li 1  with an insertable area Li 2 . Among which, the area merging a substitutable area Li 1  with an insertable area Li 2  can be defined as a combined area Li 3 . 
     Therefore, the combined area Li 3  comprises two or more areas, and at least one of each sub-area can be a substitutable area Li 1 , and at least one of each sub-area can be an insertable area Li 2 . 
     The interpretation module  161  can identify substitutable areas Li 1 , insertable areas Li 2  and combined areas Li 3 . 
     Again, with reference to  FIG.  16   , substitutable areas are extracted as input-enabled locations in S 348   b.    
     Specifically, with reference to  FIG.  8    and  FIG.  9   , the size of the original data Do of a substitutable area Li 1  may not increase due to the insertion of the first verification fingerprint Fp 1  compared to an insertable area Li 2  and a combined area Li 3 . Therefore, substitutable areas Li 1  can be extracted as input-enabled locations as first priority. 
     Again, with reference to  FIG.  15   , it is determined whether further extraction of input-enabled locations is required in S 348   c.    
     Specifically, with reference to  FIG.  8    and  FIG.  9   , the number of input-enabled locations Li can be predetermined. Therefore, if the required number of input-enabled locations Li is satisfied only with substitutable areas Li 1 , there is no further need to extract input-enabled locations Li. 
     If the required number of input-enabled locations is not satisfied only with substitutable areas Li 1 , the extraction of input-enabled location Li must be continued. 
     Again, with reference to  FIG.  15   , combined areas are extracted as input-enabled locations in S 348   d.    
     Specifically, with reference to  FIG.  8    and  FIG.  9   , combined areas Li 3  may have a relatively smaller expansion of the original data Do compared to insertable areas Li 2 . Therefore, combined areas Li 3  can be extracted as input-enabled locations Li as second priority after substitutable areas Li 1 , and before insertable areas Li 2 . 
     Again, with reference to  FIG.  15   , it is determined whether further extraction of input-enabled locations is required in S 348   e.    
     Specifically, with reference to  FIG.  8    and  FIG.  9   , if the required number of input-enabled locations Li is satisfied only with substitutable areas Li 1  and combined areas Li 3 , there is no further need to extract input-enabled locations Li. 
     If the required number of input-enabled locations is not satisfied only with substitutable areas Li 1  and combined areas Li 3 , the extraction of input-enabled location Li must be continued. 
     Again, with reference to  FIG.  16   , insertable areas are extracted as input-enabled locations in S 348   f.    
     Specifically, with reference to  FIG.  8    and  FIG.  9   , insertable areas Li 2  have the relatively largest expansion of the original data Do compared to substitutable areas Li 1  or combined areas Li 3 . Therefore, insertable areas Li 2  can be extracted lastly as input-enabled locations Li. 
     Below is an explanation of the verification method of the data access verification method according to some embodiments of the present inventive concept, with reference to  FIG.  1   ,  FIG.  10   ,  FIG.  11    and  FIG.  16   . 
     With reference to  FIG.  16   , a second verification data and a data verification request are received from the client in S 410 . 
     Specifically, with reference to  FIG.  1   ,  FIG.  10    and  FIG.  11   , the service module  110  can receive a second verification data Dv 2  from the client  10  of  FIG.  1   . In this regard, the second verification data Dv 2  can be a verification data owned by the client  10  of  FIG.  1   . The client  10  can transmit a data verification request to the service module  110  along with the second verification data Dv 2 . 
     Again, with reference to  FIG.  16   , a second integrity value of a second verification data is generated in S 420 . 
     Specifically, with reference to  FIG.  1   ,  FIG.  10    and  FIG.  11   , the data module  120  can receive a second verification data Dv 2  and hash the data to generate a second integrity value H 2 . 
     Again, with reference to  FIG.  16   , the presence of a second record corresponding to the second integrity value is determined in S 430 . 
     Specifically, with reference to  FIG.  1   ,  FIG.  10    and  FIG.  11   , if the second verification data Dv 2  is identical to the above-described first verification data Dv 1 , the second integrity value H 2  may be identical to the first integrity value H 1 . In addition, the second record may be identical to the first record. 
     If there is no second record corresponding to the second integrity value H 2 , a request fail message is transmitted to the client in S 490 . 
     If there is a second record corresponding to the second integrity value H 2 , the verification procedure can be continued. 
     Again, with reference to  FIG.  16   , the original data corresponding to the second record is loaded in S 440 . 
     Specifically, with reference to  FIG.  1   ,  FIG.  10    and  FIG.  11   , the data module  120  can transmit a first data eigenvalue I 1  corresponding to the original data Do to the data warehouse  130 , and receive the original data Do. 
     Again, with reference to  FIG.  16   , a second verification fingerprint is extracted by contrasting the original data to the second verification data in S 450 . 
     Specifically, with reference to  FIG.  1   ,  FIG.  10    and  FIG.  11   , the data module  120  can extract a second verification fingerprint Fp 2  by contrasting the original data Do with the second verification data Dv 2 . In this regard, if the second verification data Dv 2  is identical to the above-described first verification data Dv 1 , the second verification fingerprint Fp 2  can be identical to the first verification fingerprint Fp 1 . 
     Again, with reference to  FIG.  16   , the success of extraction is determined in S 460 . 
     If the extraction of the second verification fingerprint has failed, a request fail message is transmitted to the client in S 490 . 
     If the extraction of the second verification fingerprint has succeeded, the verification procedure can continue. 
     Then, a verification is made using the second verification fingerprint and the second integrity value in S 470 . 
     Specifically, with reference to  FIG.  1   ,  FIG.  10    and  FIG.  11   , the verification database  150  can receive a second integrity value H 2  and a second verification fingerprint Fp 2  from the verification module  140 . The verification database  150  can transmit a fourth acknowledgement Ack 4  to the verification module  140 . The fourth acknowledgement Ack 4  can be an acknowledgement of the second integrity value H 2  and the second verification fingerprint Fp 2  being in the same record. If the second verification fingerprint Fp 2  and the second integrity value H 2  exist in the same record, i.e., the second record, verification of the second verification data Dv 2  can be completed. 
     Then, the verification result is transmitted to the client in S 480 . 
     Specifically, with reference to  FIG.  1   ,  FIG.  10    and  FIG.  11   , the service module  110  can receive a fourth acknowledgement Ack 4  from the verification module  140 . The service module  110  can send the fourth acknowledgement Ack 4  to the client  10 . 
       FIG.  17    is a block diagram of an electronic system implementing the system for verifying data access according to the embodiments of the present inventive concept. 
     With reference to  FIG.  17   , the electronic system  100  according to the embodiments of the present inventive concept can comprise a controller  1110 , an input/output device ( 1120 , I/O), a memory device  1130 , an interface  1140  and a bus  1150 . The controller  1110 , the input/output device  1120 , the memory device  1130  and/or the interface  1140  can be coupled together via the bus  1150 . The bus corresponds to a path on which data is transferred. 
     The controller  1110  can comprise one or more of a CPU (Central Processing Unit), an MPU (Micro Processor Unit), an MCU (Micro Controller Unit), a GPU (Graphic Processing Unit), a microprocessor, a digital signal process, a microcontroller, an AP (Application Processor) and logic elements that can perform similar functions as the devices above. The input/output device  1120  can comprise a keypad, a keyboard, a touchscreen and a display device. The memory device  1130  can store data and/or commands, etc. 
     The interface  1140  can perform the function of transmitting data to a communication network or receiving data from a communication network. The interface  1140  can be in wired or wireless form. For example, the interface  1140  can comprise an antenna or a wired/wireless transceiver, etc. Although not depicted, the electronic system  1100  is a driving memory for improving the operation of the controller  1110 , which can further comprise a high-speed DRAM and/or SRAM. 
     The electronic system  1100  can be applied to a PDA (personal digital assistant), a portable computer, a web tablet, a wireless phone, a mobile phone, a digital music player, a memory card or all electronic products that can transmit and/or receive information in a wireless environment. 
     Or the system for verifying data access according to the embodiments of the present inventive concept can be a system formed by connecting a plurality of electronic systems  1100  via a network. In such case, each module or a combination of modules can be implemented as an electronic system  1100 . 
     While the present inventive concept has been particularly shown and described with reference to exemplary embodiments thereof, it will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present inventive concept as defined by the following claims. It is therefore desired that the present embodiments be considered in all respects as illustrative and not restrictive, reference being made to the appended claims rather than the foregoing description to indicate the scope of the described technology.