JP4999751B2 - Data sharing techniques - Google Patents

Description

  The present invention relates to data sharing, and more particularly, to an anonymous and simple technique for sharing data among a plurality of users.

  It may be convenient for two people to arrange future, secure (and possibly anonymous) data exchanges. Some of the usual techniques (some of which include storing data on portable memory media (eg, CD, memory stick), memory media for one or more individuals using mail) , Sending encrypted data files to e-mails, communicating e-mails to target recipients, uploading secure data to ftp sites) can be used for data exchange. However, each existing approach has its drawbacks anyway. Either non-anonymous or detailed exchange of detailed information is required, or some setup effort is required prior to the exchange.

  In light of the above, there is a desire for a simplified approach that allows users to exchange data while maintaining user anonymity.

  Embodiments of the present invention provide a technique for sharing data between users in a manner that maintains user anonymity. In order to share data, a token is generated and provided to the user. The token includes information obtained by encoding an identifier and an encryption key. Users can upload data to be shared using tokens. The data to be shared is encrypted using the encryption key associated with the token, and the encrypted data is stored so that it can be accessed using the identifier associated with the token. The user can then use the token to access the shared data. Data is accessed using an identifier associated with a token used to access shared data, and data is decrypted using an encryption key associated with the token. Data is shared anonymously using tokens without revealing the user's identity.

  According to an embodiment of the present invention, a technique for sharing data is provided. In one embodiment, an identifier is generated that can be used to access data to be shared. An encryption key that can be used to encrypt the data to be shared is generated. A set of one or more tokens including an identifier and a cryptographic key is generated. The tokens included in the token set allow data to be stored in a form that is accessible to any token from the token set. In one embodiment, as part of generating the identifier, a storage location that stores the data to be shared can be determined, and the identifier can be generated based on the storage location. In one embodiment, a machine readable code encoded with an identifier and a cryptographic key can be generated, and the machine readable code is associated with each token in the set of tokens.

  The tokens from the generated set can then be used to upload the information to be shared. In one embodiment, the identifier and encryption key from the first token in the token set. Information identifying the first data to be shared can also be received. The first data is encrypted by using the encryption key obtained from the first token to generate the encrypted first data, and the first encrypted data is the encrypted first data. Is stored as accessible using the identifier.

  Shared data can also be accessed using tokens from a set of tokens. In one embodiment, the identifier and encryption key are obtained from a token in a set of tokens that are presented to access the shared data. The encrypted first data is accessed using an identifier obtained from the token. The encrypted first data is then decrypted using the encryption key obtained from the token to generate the decrypted first data. Access to the decoded first data is enabled. In this way, the token holder can access the shared data using the token.

  The token generated and used can be a digital (electronic) token or a physical token. A physical token can be generated by printing the token on a physical medium. In one embodiment, the token set can be generated by printing the token set on a physical medium. The physical medium allows for physical separation of other tokens printed on the physical medium and tokens printed on the physical medium.

  In accordance with another embodiment of the present invention, a technique for sharing data is provided. In one embodiment, information identifying first data to be shared is received. An identifier and an encryption key are generated. The first data is encrypted using the encryption key, and the encrypted first data is generated. The encrypted first data is encrypted so that the encrypted first data can be accessed using the identifier. One or more sets of tokens are generated, each of which includes an identifier and a cryptographic key. The generated token can then be used to access the shared data. In one embodiment, a first token can be presented to access shared data. Information can be obtained from the first token. The identifier and the encryption key can be determined from information obtained from the first token. The encrypted first data is accessed using the identifier obtained from the first token, decrypted using the encryption key obtained from the first token, and the decrypted first data is Can be generated. Access to the decrypted first data can be enabled.

  According to embodiments of the present invention, different versions of shared data can be stored and accessed. In one embodiment, a first record having associated first metadata may be stored. A first identifier can be generated. The first record is accessible using the first identifier. An encryption key can be generated. The encryption key can be used to encrypt data to be shared. One or more sets of tokens can be generated. Each token in the set comprises a first identifier and an encryption key, and the token from the token set stores data such that the stored data is accessible using any token from the token set Enable.

  The token can then be used to store the version of the data to be shared. In one embodiment, a cryptographic key is obtained from a token from a set of tokens. Information identifying the first data to be shared is received. The first data is encrypted using the encryption key, and the encrypted first data is generated. The encrypted first data is stored in the second record, and the second metadata is associated with the second record. A second identifier is generated. The second record is accessible using the second identifier. The second identifier is stored in the first metadata associated with the first record. The second metadata can be encrypted using an encryption key obtained from the token.

  The shared data can then be accessed using the token. In one embodiment, a first identifier and a cryptographic key are obtained from a token from a set of tokens. The first record is accessed using the first identifier. The second identifier is determined from the first metadata associated with the first record. The second record is accessed using the second identifier. The encrypted first data of the second record is decrypted using the encryption key to generate the decrypted first data. Access to the decoded first data is enabled.

  Tokens can also be used to store different versions of data to be shared. In one embodiment, the first identifier and the encryption key are obtained from a token used to upload data to be shared. Information identifying second data is received. The second data is encrypted using the encryption key to generate the encrypted second data. The encrypted second data is stored in the third record, and the third metadata is associated with the third record. A third identifier is generated. The third record is accessible using the third identifier. The third identifier is stored in second metadata associated with the second record.

  The token can be used to access the last updated shared data. In one embodiment, a first identifier and a cryptographic key are obtained from a token from a set of tokens. The first record is accessed using the first identifier. The second identifier is determined from the first metadata associated with the first record. The second record is accessed using the second identifier. The third identifier is stored in second metadata associated with the second record. The third record is accessed using the third identifier. The encrypted second data of the third record is decrypted using the encryption key to generate the decrypted second data. Access to the decoded second data is enabled.

  The foregoing description of the invention, as well as other features, examples, and advantages, will become more apparent with reference to the specification, claims, and drawings.

  In the following description, for purposes of explanation, specific details are set forth in order to provide a thorough understanding of the present invention. However, the present invention may be practiced without the specific details described above.

  Embodiments of the present invention provide a technique for sharing data among multiple users in a manner that maintains user anonymity. According to an embodiment of the present invention, one or more tokens that facilitate data sharing are generated. FIG. 1 is a simplified block diagram of a system 100 for generating and using tokens according to an embodiment of the present invention. The token 100 depicted in FIG. 1 is merely illustrative of an embodiment of the invention and does not limit the scope of the invention as recited in the claims. Those skilled in the art will recognize other variations, modifications, and alternatives.

  As depicted in FIG. 1, system 100 includes a token processor 102 that facilitates the generation and use of tokens according to an embodiment of the present invention. The token processor 102 can be implemented in software (code or instructions executed by the processor), hardware, or a combination thereof. For example, as depicted in FIG. 1, the token processor 102 may be an application that executes on the computer system 104. The software code or instructions for module 102 may be executed by the processor of system 104.

  Token processor 102 is configured to generate tokens in accordance with the teachings of the present invention. The token may be generated in response to the token processor 102 receiving a request from the user to generate one or more tokens. In one embodiment, the user can request the generation of a new token and at the same time identify the data to be shared using the token. In response, the token processor 102 is configured to perform processing to generate a token. FIG. 2 is a simplified high-level flowchart 200 representing a method for generating tokens according to an embodiment of the present invention. The method depicted in FIG. 2 may be performed by software modules (code modules or instructions) executed by a processor, hardware modules, or combinations thereof. For example, the method can be performed by the token processor 102 depicted in FIG. Flowchart 200 depicted in FIG. 2 is merely illustrative of an embodiment of the present invention and is not intended to limit the scope of the present invention. Other variations, modifications, and alternatives are within the scope of the present invention. The method depicted in FIG. 2 can be adapted to work with various implementation constraints.

  When a signal to generate a new token is received, the process can be activated (step 202). Along with the request to generate a new token, information identifying the data to be shared using the new token to be generated is also received (step 204). The token processor 102 can include a user interface that allows a user to request the generation of a new token and also identify the data to be shared.

  A storage location for storing the data to be shared is then determined (step 206). The storage location can be created as part of 206 if it does not already exist. For example, as shown in FIG. 1, a storage location 106 for storing data to be shared can be determined. The storage location for storing the data to be shared can be local to the computer system 104 or remote to the computer system 104.

  An identifier for generating a token is then generated (step 208). The generated identifier is such that it can be used to access shared data from the storage location identified at 206. The identifier may encapsulate information that can be used to determine the storage location where the shared data is stored (ie, the storage location determined at 206) and also determine the data stored at that storage location. it can. Examples of identifiers include a pointer or reference to a storage location that stores data to be shared, an index to the storage location, a URL, and the like. In one embodiment, a globally unique identifier is generated. The unique identifier can be generated using various methods (such as calculation of a cryptographic hash of data). For example, in one embodiment, the shared data can be encrypted and stored as a document in a storage location that stores the data to be shared, and the generated identifier is globally identifying the document that contains the storage location. It is a unique identifier.

  A unique encryption key for the token to be generated is then generated / identified (step 210). In one embodiment, the encryption key is a symmetric encryption key that can be used to encrypt data and further decrypt the encrypted data. The data identified at 204 is encrypted using the encryption key determined at 210 to generate encrypted data (step 212). Various encryption techniques can be used to encrypt the data. The encrypted data generated at 212 is then stored in the storage location identified at 206 (step 214).

  One or more tokens are generated (step 216). Each of the generated tokens includes information including an identifier generated in 208 and an encryption key generated in 210 used for encryption of shared data. Various techniques can be used to associate the identifier and encryption key with the generated token. In one embodiment, the identifier and encryption key can be printed on the token. In another embodiment, the identifier and encryption key can be encoded into a machine readable code that is printed on the generated token. Examples of machine readable codes that can be used to encode information include barcodes such as QR codes, glyphs, and the like. In one example, the identifier and encryption key may be encoded into two separate machine readable codes (eg, two separate barcodes). The token can then comprise two separate barcodes.

  The token generated at 216 can be a digital (electronic) token or a physical token. For example, as depicted in FIG. 1, the token processor 102 can generate a digital token 108 that can be stored in the memory of the computer system 104. The digital token 108 may be an image comprising information encoded with an identifier and an encryption key. The digital token 108 can be electronically communicated (eg, email) and can be displayed on an output device (such as on a screen, monitor, visual display, etc.). The physical token can be generated using a physical medium (paper, card, plastic, etc.). For example, in the system 100 shown in FIG. 1, the physical token 110 can be generated using the printer 112. The token processor 102 can be configured to send token related information to the printer 112. The printer 112 can then generate the physical token 110 by printing the information on a physical medium (paper, card, plastic, etc.). One or more tokens can be generated.

  In the process shown in FIG. 2 and described above, the data to be shared is identified by a request to generate a token. In another embodiment, tokens can be generated without knowledge of the data to share. For example, a token can be generated without identifying the data to be shared. The target data to be shared may not have been created or available at the time of generating the target token used for data sharing. The previously generated (pre-generated) token can then be used later to share the data to be shared.

  FIG. 3 is a simplified high-level flowchart 300 illustrating a method for generating a token without identifying the data to be shared using the token, according to an embodiment of the present invention. The method depicted in FIG. 3 may be performed by software modules (code modules or instructions) executed by a processor, hardware modules, or combinations thereof. For example, the method can be performed by the token processor 102 depicted in FIG. Flowchart 300 depicted in FIG. 3 is merely illustrative of an embodiment of the present invention and is not intended to limit the scope of the present invention. Other variations, modifications, and alternatives are within the scope of the present invention. The method depicted in FIG. 3 can be adapted to work with various implementation constraints.

  Upon receipt of a signal to generate a new token, the process can be activated (step 302). A storage location for storing data to be shared is then determined (step 304). The storage location determined at 304 represents the location where the data to be shared using the generated token will be stored. If a storage location that stores data to be shared does not yet exist, the storage location can be created as part of 304. In this way, memory locations are identified for data storage. The storage location for storing the data to be shared may be local to computer system 104 or at a specific remote location.

  An identifier for generating a token is then generated (step 306). The generation identifier can be used to locate shared data from the storage location determined at 304. Examples of identifiers include pointers or references to storage locations, indexes to storage locations, URLs, and the like. In one embodiment, a unique identifier is generated. The unique identifier can be generated using various methods (such as cryptographic hash calculation).

  A unique encryption key for the token to be generated is then generated (step 308). In one embodiment, the encryption key is a symmetric encryption key that can be used to encrypt data and further decrypt the encrypted data.

  One or more tokens are then generated (step 310). Each of the generated tokens includes an identifier generated in 306 and information including an encryption key generated in 308 used for encryption of shared data. Using various techniques (such as printing the identifier and encryption key on the token, encoding the identifier and encryption key into machine-readable code printed on the generated token, etc.) Can be associated with a token. The token generated at 310 can be a digital (electronic) token or a physical token.

  As described above, a token can be generated before data to be shared is identified. The previously generated token (digital or physical) can then later encrypt and store the data to be shared. FIG. 4 is a simplified high-level flowchart 400 representing a method for sharing data using previously generated tokens according to an embodiment of the present invention. The method depicted in FIG. 4 may be performed by software modules (code modules or instructions) executed by a processor, hardware modules, or combinations thereof. For example, the method can be performed by the token processor 102 depicted in FIG. Flowchart 400 depicted in FIG. 4 is merely illustrative of an embodiment of the present invention and is not intended to limit the scope of the present invention. Other variations, modifications, and alternatives are within the scope of the present invention. The method depicted in FIG. 4 can be adapted to work with various implementation constraints.

  As shown in FIG. 4, it can be activated upon receiving a request to share data using a previously generated token (step 402). For example, the token processor 102 depicted in FIG. 1 can receive a signal from the user to share data using a previously generated token. Information identifying the data to be shared can be received (step 404). As described above, the token processor 102 can include an interface that allows the user to define the data to be shared.

  Information is then obtained from previously generated tokens to be used for data sharing (step 406). Various techniques for obtaining information from a previously generated token can be used. In one embodiment, as depicted in FIG. 1, a token reader 114 configured to obtain information from a previously generated token 116 presented to the token reader 114 may be provided. Information obtained from the token 116 includes an identifier and an encryption key associated with the token.

  The token reader 114 may be able to obtain information from a physical token or a digital token. In the case of a digital token, the token reader 114 can be configured to capture information from the digital token displayed on the display (on screen, monitor, visual display, etc.). In one embodiment, information can be obtained from a digital token using image processing or optical character recognition techniques. In the case of a physical token, the reader 114 can be configured to read information from the physical token. As described above, in one embodiment, the identifier and encryption key can be encoded with a machine readable code associated with a digital or physical token. In this example, token reader 114 may be a bar code reader configured to scan and read machine-readable code printed on a physical token.

  The identifier and encryption key are then determined from the information obtained from the token at 406 (step 408). The encryption key can be a symmetric encryption key.

  The data identified at 404 is then encrypted using the encryption key determined at 408 to generate encrypted data (step 410). The encrypted data generated at 410 is then stored in the storage location corresponding to the identifier determined at 408 so that the stored data can be retrieved using the identifier (step 412). In this way, a pre-generated token can be used to encrypt information and load it into a storage location that can be accessed by one or more users. The data stored in the storage location is then available for access by other users sharing the data using a token having the same identifier and the same encryption key as the token used to upload the shared data.

  The shared information can also be accessed using the token generated as described above. FIG. 5 is a simplified high-level flowchart 500 representing a method for accessing shared data using a generated token, according to an embodiment of the present invention. The method depicted in FIG. 5 may be performed by software modules (code modules or instructions) executed by a processor, hardware modules, or combinations thereof. For example, the method can be performed by the token processor 102 depicted in FIG. Flowchart 500 depicted in FIG. 5 is merely illustrative of an embodiment of the present invention and is not intended to limit the scope of the present invention. Other variations, modifications, and alternatives are within the scope of the present invention. The method depicted in FIG. 5 can be adapted to work with various implementation constraints.

  As shown in FIG. 5, upon receiving a request to access shared information corresponding to a token, the process can be started (step 502). At 502, a user attempting to access information using a token can present a token (digital or physical) to a token reader, such as token reader 114 depicted in FIG. Information is then obtained from the presented token (step 504). The information obtained from the token includes information identifying an identifier and an encryption key associated with the token. The identifier and encryption key associated with the token are then determined from the information obtained from the token at 504 (step 506). The data identified by the identifier determined at 506 is then accessed (step 508). As described above, the identifier can be used to determine the storage location that stores the data to be shared and the data at the storage location. The data to be accessed is usually encrypted data. The encrypted data accessed from the storage location at 508 is then decrypted using the encryption key determined at 506 from the token (step 510). The decrypted data is then made accessible to the token holder (step 512). In this way, the token can be used to gain access to data that is encrypted and stored for sharing.

  As described above, according to embodiments of the present invention, token processor 102 facilitates the generation and use of tokens. The token processor 102 may include a number of modules for performing various tasks related to token generation and use. FIG. 6 depicts a simplified block diagram of various modules of token processor 102, according to an embodiment of the present invention. As depicted in FIG. 6, the token processor 102 may comprise a user interface module 602, an identifier processor module 604, an encryption / decryption module 606, a token information capture module 608, and a token generator module 610. A module may be implemented in software (code or instructions executed by a processor), hardware, or a combination thereof.

  User interface module 602 allows a user to interact with token processor 102. For example, the user interface module 602 may request that a user generate a new token, define / identify information to be shared, request upload of the information to be shared using the token, It is possible to provide an interface that can be used to request access to shared information.

  The token information capture module 608 can be configured to perform tasks related to capturing information from the token and determining identifier and encryption key information from the captured information. The token information capture module 608 can interface with the token reader and receive information captured by the token reader.

  The identifier processor module 604 may be configured to perform tasks related to data storage and access to and from storage locations that store data to be shared. The above tasks are based on determining or creating a storage location for storing data, generating an identifier for the storage location, determining a storage location corresponding to a particular identifier, storing data in the storage location corresponding to the identifier, and Data access from a storage location, and the like.

  The encryption / decryption module 606 can be configured to perform encryption and decryption related tasks. Such tasks may include determining / generating the encryption key to be associated with the token, encrypting the data to be shared using the encryption key, and decrypting the encrypted data using the encryption key.

  The token generator module 610 can be configured to perform tasks related to digital tokens or physical tokens. Such tasks may include encoding identifiers and cryptographic keys in machine-readable code, associating codes with tokens, generating digital tokens, generating physical tokens using services of devices such as printers, etc. .

  As described above, the token can be used to share data between user groups. For example, a set of tokens can be generated to allow data sharing with each token in the set having the same identifier and the same encryption key. The data to be shared may or may not be identified at the time the token is generated. The generated token can then be distributed to a group of users who want to share data. Users from the group can later share data with others in the group using their tokens. As mentioned above, by using tokens, data shared by users is encrypted using the encryption key associated with their token and stored in a storage location corresponding to the identifier associated with their token. Remembered. The tokens distributed to the other members of the group also contain the same identifiers used to store the data, so the users of the group use their tokens to access the shared data from the storage location as described above. be able to. Furthermore, since the encryption key associated with the distributed token is the same and is a symmetric encryption key, the shared data can be decrypted using the encryption key. In this way, data can be shared among the members of the group.

  For example, a set of conference tokens can be generated. Each token has the same identifier associated with it and a symmetric encryption key. The set of tokens can then be distributed to meeting attendees to allow sharing of data between attendees. Any attendee can use his token to encrypt the data and upload the data to the storage location corresponding to the identifier associated with the distributed token. Attendees can also access data from storage using their tokens.

  The data to be shared can also be identified when the token is generated. The data is encrypted using an encryption key associated with the token (usually a symmetric encryption key) and stored in a storage location corresponding to the identifier associated with the token. The generated token can then be distributed to users. Users can then access the shared data using the token. Any user in the group can also load the data into the storage location using the user's token, and the data can then be accessed by other users with the same identifier and encryption key token. In this way, the token allows data sharing between users. Using the conference as an example, the presenter at the conference identifies the target data to be shared with the attendees at the conference prior to the conference and stores a set of tokens (each of which is stored in the target data shared by the presenter. With the same encryption key and identifier used). The token set can then be distributed to meeting attendees. The attendee can then use his token to access the data stored in the storage location. Attendees can also use the attendee's token to encrypt the data and upload the data to a storage location. In this way, data is shared between attendees and presenters.

  The creation of a token creates a storage location where data can be stored and subsequently accessed. A storage location is like a “drop box” where encrypted data can be stored or deposited and the encrypted data can be accessed. The identifier associated with the token can be used to identify the location of the “drop box”. The encryption key associated with the token is like a “key” to the drop box, which allows the data to be “locked” (encrypted) in the drop box, and the drop box It is also possible to unlock (decrypt) the data from.

  Such tokens do not contain information about users sharing data. The identifier and encryption key associated with the token do not reveal anything about the identity of the token user. Thus, the token allows data to be shared securely while maintaining the anonymity of the token user. A group of users with tokens with the same identifier and encryption key may not know each other in order to share data. Users accessing shared data may not know who uploaded the shared data. Tokens thus allow anonymous data sharing between third parties that are not trusted third parties.

  By supplying the same set of tokens to a group of users, all users have access to the same identifier and the same encryption key. The identifier provides a pointer to the encrypted shared data, and can be used for specifying and identifying the shared data. The shared data can be encrypted and decrypted using the encryption key. The combination of identifier and encryption key allows a group of users to deposit and retrieve encrypted information anonymously with minimal advance preparation.

  Preferably, the identifier is globally unique and not guessable. Further, preferably the identifier and encryption key associated with the token set are stored in the token itself, not elsewhere. Thus, only those who have access to the token can upload the data to be shared to the storage location corresponding to the identifier associated with the token. Furthermore, only those who have access to a token with the same identifier and encryption key can access the data from the stored location and decrypt the data. In this way, data is securely shared.

  As described above, a plurality of tokens having the same identifier and encryption key can be generated and distributed to users. The group of users can then use their token to load or access the data to be shared. However, it is not essential to generate multiple tokens. In one embodiment, a single token can be generated. A single token can be used by multiple users (or a single user) who want to load data to be shared or access shared data.

  7A and 7B represent examples of tokens that can be generated by embodiments of the present invention. As shown in FIG. 7A, a card 700 (or paper, plastic, or other physical medium) can be generated. Card 700 has two identical tokens 702-A and 702-B. Each token includes a unique identifier and a barcode (QR code) 704 encoded with a symmetric encryption key. The card 700 may be pierced along line 706 to allow the card to be folded or split into two physically separate tokens, each with a QR code. When the card is folded, the token 702-A can be given to the first user and the token 702-B can be given to the second user who wants to share data with the first user. For example, a first user can use token 702-A to encrypt data and upload it to a storage location that can be accessed by a second user using token 702-B. Any user can deposit the data to be shared and access the shared data using his / her token. This is because the token 702-A and the token 702-B have the same identifier and symmetric encryption key. By supplying the same token pair to two individuals, both have access to the same unique identifier and the same encryption key. The combination of identifier and encryption key allows a group of users to deposit and retrieve encrypted information anonymously with minimal advance preparation. In another embodiment, it can be created by several tokens that can be folded into separate physical tokens.

  FIG. 7B represents another card 750 with the same two tokens 752-A and 752-B. Each token includes information 754 that encodes a unique identifier 756 and a symmetric encryption key 758. Card 750 can be split along line 760 to create two physically separate independent tokens. These tokens can then be provided to separate users. Each token also includes a space 762 provided for marking by the token user. For example, a user can write a description of data that is shared using a token. Each token also includes a keyhole that allows the token to be attached to a key chain for convenient carrying.

  As described above, a symmetric key can be associated with a token so that the same key is used for encryption and decryption of information using the token. In another embodiment, a key pair such as a public / private key pair can be used. In the foregoing embodiment, the data can be encrypted using the public key and can be decrypted using only the private key of the pair that is kept secret. A card, such as card 700 depicted in FIG. A, can be created using non-identical tokens 702-A and 702-B. The machine readable code associated with token 702-A encodes the unique identifier and the public key of the public / private key pair, and the machine readable code associated with token 702-B is token 702— The same unique identifier as A and the private key of the public / private key pair can be encoded. The token 702-A can then be provided to a user who can encrypt the shared data using the public key and upload the information to be shared to the storage location corresponding to the identifier. The token 702-B can access the shared information from the storage location and decrypt it using the secret key. In another embodiment, the keys in pairs can be printed on the token. For example, two machine readable codes can be printed on the token. One encodes the identifier and the public key of the public / private key pair, and the other encodes the identifier and the private key of the public / private key pair. One of the machine readable codes can be printed on one side of the token and the other can be printed on the other side.

  Public / private key encryption generally works symmetrically. That is, when data is encrypted with a so-called public key, it can only be decrypted using a secret key. Alternatively, when data is encrypted using a private key, it can only be decrypted using a public key. That is, when a public / private key pair is used in an embodiment of the present invention, it is possible to provide data that is encrypted so that it can only be used by the other user, not by himself.

  In another embodiment, instead of a token with a key from a key pair, each token in the token set comprises information indicating an identifier, a symmetric encryption key, and an encrypted public / private key. The token holders in the set can access the same key pair using the token. The encryption key pair can be decrypted using the symmetric key associated with the token. The holder of each token uses the public key of the key pair to encrypt the data and the private key of the key pair and retrieves it. In this embodiment, the symmetric key associated with the token is only used to decrypt the public / private key. In this embodiment, it is possible to encrypt a document stored in a storage location using a secret key. The public key and document identifier can be read and decrypted for all documents, but can be distributed to other users who cannot add new documents. Only those with a symmetric key have access to the private key and can upload new encrypted documents.

  In another embodiment, the token holder can choose a secret password and the shared data can still be encrypted using that password so that individuals can access the shared data. , Tokens with identifiers and encryption keys, and passwords must be accessed.

  According to the embodiment of the present invention, in addition to storing encrypted shared data, metadata associated with the shared data can also be stored. The metadata can be stored in an encrypted format. The metadata may comprise information about shared data (such as mime types of shared objects, tags about shared data, and pointers to subsequent and selected versions of the data). Metadata can be accessed using document identifiers in the same storage location by requesting metadata instead of requesting a document.

  For example, in one embodiment, the shared data can be stored in a document that is encrypted using an encryption key and then stored in a location where it can be shared. A cryptographic hash (eg, a 128-bit cryptographic hash) can be calculated from the encrypted document bits, and the hash can serve as a unique identifier. The encrypted document is then stored using the hash as an identifier. Metadata associated with the document is also encrypted and stored with the document. One or more tokens with a hash identifier and an encryption key used to encrypt the document can be generated.

  When a new version of shared information is uploaded using a token with a hash identifier and an encryption key, a new version with shared data is created and a new document is encrypted using the encryption key. A new hash identifier is then calculated for the new encrypted document and the new information is stored using the new identifier. This newly calculated identifier is added to the document metadata previously stored as the “next” version of the document. The person with the original token can follow the "next" pointer using the stored document version metadata until the person finds the most recent known version of the document or the version he is looking for Thus, it is convenient to encrypt all versions of a document using the same encryption key. The most recently encrypted document version can be decrypted using the encryption key.

  In one embodiment, the first version of the encrypted document may contain no information or may function as a placeholder that contains information such as specific information about the creator of the document. Regardless of the data content in the first version of the document, the document identifier is uniquely calculated. For example, the identifier can be calculated as a cryptographic hash of the selected cryptographic key concatenated with the date and time and a further random sequence. One or more identical tokens with the calculated identifier and the encryption key can then be generated.

  An individual who wants to upload data to be shared can use a token that encrypts shared data using an encryption key from the token. The new identifier is calculated based on the encrypted data to be shared, the encrypted data corresponding to the new identifier is stored, and a new pointer is stored. Added as a “next” pointer (or one of the next pointers) to the metadata associated with the token and associated with the original identifier indicating the original placeholder document. An individual who wants to access shared data uses a token with the same identifier (ie, the original identifier) and encryption key so that an application (such as the token processor 102 depicted in FIG. 1) is read from the token. The original identifier can be used to access the placeholder document and its metadata, and follow the “next” pointer in the metadata to access the desired encrypted version of the shared document. The desired encrypted version can then be accessed using the encryption key read from the token and the desired encrypted version can be decrypted.

  FIG. 8 is a simplified high-level flowchart 800 representing a method for generating tokens and sharing data in an embodiment in which various versions of shared data can be stored. The method depicted in FIG. 8 may be performed by software modules (code modules or instructions) executed by a processor, hardware modules, or combinations thereof. For example, the method can be performed by the token processor 102 depicted in FIG. Flowchart 800 depicted in FIG. 8 is merely illustrative of an embodiment of the present invention and is not intended to limit the scope of the present invention. Other variations, modifications, and alternatives are within the scope of the present invention. The method depicted in FIG. 8 can be adapted to work with various implementation constraints.

  As shown in FIG. 8, upon receiving a request to generate a new token, the process can be activated (step 802). A unique identifier for the object associated with the token to be generated may be generated (step 804). The identifier generated at 804 is such that it can be used to identify and access shared data. In one embodiment, the identifier can be calculated as a hash of a random stream of data generated by a random number generator. At 804, a unique identifier may be generated using other techniques. A unique symmetric encryption key for the object associated with the token to be generated is also created (step 806).

  An empty record is then created that can be accessed using the unique identifier generated at 804 (step 808). The created empty record can be a document. The metadata of the empty record created in 808 is also stored (step 810). The metadata may include information indicating the next version of the shared data. For example, the metadata may include “next” information that can be used to indicate the next version of the shared data. Initially, there is no shared data stored, so the metadata “next” pointer of the empty record is set to null. In one embodiment, the metadata is encrypted using the encryption key generated at 806 and the encrypted metadata is stored.

  One or more tokens (digital tokens or physical tokens) are then generated, each token comprising a unique identifier generated at 804 and an encryption key created at 806 (step 812). As described above, various techniques can be used to associate an identifier and cryptographic key information with a token. For example, a QR code can be created by encoding a unique identifier and a cryptographic key, and the QR code can be associated (eg, printed) with each token (digital token or physical token). The physical token can be created in various forms, including the examples depicted in FIGS. 7A and 7B. The token generated at 812 can then be distributed to a group of users who want to share data. Users from the group can use tokens to load data to be shared or to access shared data.

  The created empty record functions as a placeholder that can be used to store and access various versions of shared data. When shared data is uploaded for the first time using a token (ie, the first version of the shared data), the first version is encrypted using the encryption key from the token. The first encrypted version of the shared data is stored in the newly created record. Using the generated identifier, a new identifier for the new record is generated so that the new record is accessible. The metadata information of the newly generated record is stored. The metadata information can be encrypted using an encryption key associated with the token. The “next” pointer in the metadata associated with the empty record is changed to point to the new record. This can be done in one embodiment by setting the “next” information in the metadata of the empty record to the newly generated identifier for the new record. The new identifier thus comprises a link or pointer to the new record. The “next” pointer in the metadata associated with the new record is set to null. In this way, a kind of linked list is created. The empty record is the first node in the list, and the uploaded version (which is the “latest” version) is stored in the record indicated by the metadata of the empty record. When a newer version of shared data is uploaded, a new record is created for each newly added version, and a new identifier is calculated for the newly created record and uploaded in advance The "next" information in the metadata associated with the record storing the version is set to the newly calculated identifier, so that the pointer from the record storing the previous version in the record storing the latest version Is created. The last record in the linked list stores the latest version of the shared data.

  The token can then be used to access the latest version of the stored data. The token allows access to the first record in the linked list (ie, an empty record) and then uses the metadata pointer to store the linked record list with the latest version of the shared data. You can traverse to the last record. The encryption key from the token can then be used to access and decrypt the latest version of the data.

  In one embodiment, the data collection can be stored in the identifier by storing a list of document identifiers in the metadata of the original identifier in the token, rather than a linked list. For example, each time a user wants to share a new document, the document is encrypted using the encryption key on the token, and then a new document identifier is calculated or generated. The encrypted document is uploaded to the location defined by the new identifier. The new identifier is added to the list of document identifiers stored in the identifier metadata in the token. The identifier in the collection can still be encrypted using the encryption key in the token.

  FIG. 9 is a simplified high-level flowchart 900 representing a method for uploading data to be shared using tokens in an embodiment in which various versions of shared data can be stored. The method depicted in FIG. 9 may be performed by software modules (code modules or instructions) executed by a processor, hardware modules, or a combination thereof. For example, the method can be performed by the token processor 102 depicted in FIG. The flowchart 900 depicted in FIG. 9 is merely illustrative of an embodiment of the present invention and is not intended to limit the scope of the present invention. Other variations, modifications, and alternatives are within the scope of the present invention. The method depicted in FIG. 9 can be adapted to work with various implementation constraints.

  As shown in FIG. 9, information identifying the data to be uploaded and made available as shared data can be received (step 902). Information used to upload the data is obtained from the token (step 904). For example, a machine readable code associated with a token can be read at 904 by a token reader. The identifier and encryption key are then determined from the information obtained from the token at 904 (step 906).

  The data identified at 902 is then encrypted using the encryption key determined at 906 to generate encrypted shared data (step 908). A new record is then created and the encrypted data is stored in the newly created record (step 910). The new record can be a document that stores encrypted shared data. A new unique identifier is then calculated for the new record created at 910 (step 912). In one embodiment, the unique identifier can be generated by calculating a cryptographic hash of the encrypted content of the new record. The new record created at 910 is stored so that it can be accessed using the identifier calculated at 912 (step 914). Metadata is stored for the new record (step 916).

  A process for uploading a new record storing new encrypted shared data is performed. The record corresponding to the unique identifier determined at 906 (ie, the identifier obtained from the token) is then accessed (step 918). The record format may be the document format indicated by the unique identifier. Metadata associated with the accessed record is read (step 920). In one embodiment, the metadata can be encrypted and the metadata can be decrypted using the encryption key determined from the token at 906.

  A check is then made to see if the “next” information contained in the accessed metadata is null or indicates another stored record. If the “next” pointer is null, it indicates that the last record in the linked record list has been reached. This last record stores the most recently uploaded version of shared data. If the “next” pointer is not null, it indicates that the last record in the linked list has not been reached and traverses the linked record list until the last record is reached.

  Thus, if the “next” information in the metadata is not null, the record indicated by the “next” pointer is accessed (step 924). In one embodiment, the “next” information identifies a record and identifies an identifier used to access the record. Processing then returns to 920. At 920, metadata associated with the newly accessed record is read. According to 922, a check is made to see if the null pointer associated with the accessed metadata is set to null. In this way, steps 920, 922, and 924 are repeated until the last record (a record with metadata with the “next” information set to null) is reached.

  When the last record is reached, the “next” information in the metadata associated with the last record is updated to indicate the new record created at 910 (step 926). This can be accomplished by setting the “next” information in the metadata of the last accessed record to the new identifier calculated at 912. In this way, the “next” information indicates a new record. Set the "next" information in the metadata associated with the newly created record to null (step 928), thereby indicating that it is the last record in the linked record list; Remember the latest version of the data. The metadata associated with the record can be encrypted using an encryption key obtained from the token. Information identifying the version can also be stored in metadata associated with the newly created record.

  As described above, a new record is created and added each time a new version of shared data is uploaded using a token with a specific identifier and encryption key. Uploading can be performed by various users. The upload can be done using the same token or another token (all with the same identifier and encryption key). Those familiar with database processing and version control systems will recognize that it is important that two different users not attempt to update the next pointer in the metadata of the same record at the same time. That is, any user may upload a new version of a document at the same time, find the same null pointer, and any may attempt to change the null pointer to a different identifier at the same time. If this happens, the last user's changes are successfully written and the first user's changes are lost. There are several ways to avoid collisions including atomic processing and write locking. For example, when the process of obtaining and checking a null pointer and updating it to a new identifier value is an atomic process performed in one process, it is not possible for two users to inspect and update at the same time. In one embodiment, the next plurality of pointers may be enabled in the linked list. This will allow the document version to branch, but may be more acceptable than losing all the documents.

  FIGS. 10A, 10B, and 10C illustrate the transition of the linked record list as a newer version of shared data is uploaded using tokens, according to an embodiment of the present invention. As shown in FIG. 10A, when a token is first created, an empty record 1002 corresponding to the identifier (ID0) associated with the token can be created. In certain embodiments, the record 1002 may not be empty, but may retain information such as when the record was created, the record creator, and the like. Also stored is metadata 1004 for the empty record 1002, including "next" information and "previous" information. “Next” information is used to indicate the next record in the record list, and “previous” information is used to indicate the preceding record in the list. The “next” information and the “previous” information are set to null.

  FIG. 10B represents the record list at the time when the first version of the shared data was uploaded using the token containing the same identifier and encryption key used to create the record at 10A. The first version is encrypted using the encryption key read from the token. A new record 1006 is created for storing the encrypted data. A new identifier (ID1) for the new record 1006 is created. Metadata 1008 for the new record 1006 is also stored. The “next” information in the metadata 1004 associated with the record 1002 is set to ID1, thereby indicating a new record 1006. The “next” information in the metadata 1008 associated with the new record 1006 is set to null. The “previous” information in the metadata 1008 is set to ID0, thereby indicating the preceding record 1002 in the record list. Record 1006 then stores the latest version of the shared data uploaded using the token in encrypted form.

  FIG. 10C represents a list of records at the time when the second version of the shared data is uploaded using the token. The second version is encrypted using the encryption key read from the token. A new record 1010 for storing the encrypted data is created. A new identifier (ID2) for the new record 1010 is created. The “next” information in the metadata 1008 associated with the record 1006 is set to ID2, thereby indicating a new record 1010. The “next” information in the metadata 1012 associated with the new record 1010 is set to null. The “previous” information in the metadata 1012 is set to ID1, thereby indicating the preceding record 1006 in the record list. Record 1010 then stores the latest version of the shared data uploaded using the token in encrypted form.

  In this way, multiple versions of shared data can be uploaded using tokens having the same identifier and encryption key. In one embodiment, information identifying a particular version of shared data stored by a record can also be stored in metadata associated with the record.

  You can also use tokens to access the latest version of shared data. FIG. 11 is a simplified high-level flowchart 1100 representing a method for accessing the latest version of shared data using tokens, according to an embodiment of the present invention. The method depicted in FIG. 11 may be performed by software modules (code modules or instructions) executed by a processor, hardware modules, or combinations thereof. For example, the method can be performed by the token processor 102 depicted in FIG. Flowchart 1100 depicted in FIG. 11 is merely illustrative of an embodiment of the present invention and is not intended to limit the scope of the present invention. Other variations, modifications, and alternatives are within the scope of the present invention. The method depicted in FIG. 11 can be adapted to work with various implementation constraints.

  As shown in FIG. 11, information can be obtained from a token used to access shared data (step 1102). The identifier and encryption key are determined from the information obtained at 1102 (step 1104). A record corresponding to the unique identifier determined in 1102 is accessed (step 1106). Metadata associated with the accessed record is read (step 1108). In one embodiment, the metadata can be encrypted and the metadata can be decrypted using the encryption key determined at 1102 from the token.

  A check is then made to see if the “next” information contained in the accessed metadata is null or indicates another stored record (step 1110). If the “next” pointer is null, it indicates that the last record has been reached. This last record stores the most recently uploaded version of shared data. If the “next” pointer is not null, it indicates that the last record in the linked list has not been reached and traverses the linked record list until the last record is reached. Therefore, if it is determined in 1110 that the “next” information in the metadata is not null, the record indicated by the “next” pointer is accessed (step 1112). In one embodiment, the “next” information identifies an identifier that indicates the next record to be accessed. Processing then returns to 1108. In 1108, metadata associated with the accessed record is read. According to 1110, a check is made to see if the null pointer associated with the accessed metadata is set to null. In this way, steps 1108, 1110 and 1112 are repeated until the last record (the “next” information in the metadata associated with the record is set to null) is reached.

  The last record stores the most recent version of shared data in encrypted form. The encrypted data from the last record is decrypted using the encryption key determined in 1104 (step 1114). The decrypted information is then made accessible to the token holder seeking access to the information (step 1116).

  In the above embodiment, the identifier information stored in the metadata associated with the record can be encrypted using the encryption key associated with the token. During processing, this information can be decrypted using the encryption key read from the token. In one embodiment, all encryption can be performed using a symmetric key associated with the token. The symmetric key can then be used to perform all decryption.

  Optionally, the two token holders can agree on a password, which can be used as an additional layer of security. In this embodiment, in addition to the identifier and encryption key, a password is also required to access the shared data.

  FIG. 12 is a simplified block diagram of a data processing system 1200 that can be used to perform processing according to an embodiment of the present invention. For example, as shown in FIG. 1, the data processing system 1200 can serve as the computer system 104 depicted in FIG. As shown in FIG. 12, the data processing system 1200 includes a processor 1202 that communicates with several subsystems via a bus subsystem 1204. The aforementioned subsystems include a storage subsystem 1206 (including a memory subsystem 1208 and a file storage subsystem 1210), a user interface input device 1212, a user interface output device 1214, and a network interface subsystem 1216. Can be included.

  Bus subsystem 1204 provides a mechanism for causing the various components and subsystems of computer system 1200 to communicate with each other as intended. Although bus subsystem 1204 is shown schematically as a single bus, alternate embodiments of the bus subsystem may utilize multiple buses.

  Network interface subsystem 1216 provides an interface to other computer systems, networks and devices. The network interface subsystem 1216 serves as an interface for transmitting and receiving data to and from other systems from the data processing system 1200. For example, digital tokens can communicate with data processing system 1200 using network interface subsystem 1216. Examples of network interface subsystem 1216 are typically Ethernet cards, modems (telephone, satellite, cable, ISDN), (asynchronous) digital subscriber line (DSL) devices, firewire interfaces, USB interfaces Etc. For example, the interface 1216 can be coupled to a computer network, a firewire bus, or the like. In other embodiments, the interface 1216 may be physically integrated on the motherboard of the data processing system 1200, or may be a software program such as soft DSL.

  The user interface input device 1212 includes a keyboard, a pointing device (such as a mouse, a trackball, a touch pad and a graphic tablet), a scanner, a barcode scanner, a touch screen incorporated in a display, an audio input device (a voice recognition system, Microphone or other type of input device). In general, use of the term “input device” is intended to include all possible types of devices and mechanisms for entering information into data processing system 1200. A user can perform a task (identification of shared data, generation of a request, etc.) using the input device 1212.

  User interface output device 1214 may include a display subsystem, a printer, a fax machine, or a non-visual display (such as an audio output device). The display subsystem can be a cathode ray tube (CRT), a flat panel device (such as a liquid crystal display (LCD)), or a projection device. In general, use of the term “output device” is intended to include all possible types of devices and mechanisms that output information from data processing system 1200. Digital tokens can be displayed via output device 1214.

  The storage subsystem 1206 can be configured to store basic programming and data structures that provide the functionality of the present invention. Software (eg, code modules or instructions) that, when executed by a processor, provides the functionality of the present invention can be stored in the storage subsystem 1206. Such software modules or instructions may be executed by processor 1202. The storage subsystem 1206 can also provide a repository for storing data used by the present invention. For example, a digital token can be stored by the storage subsystem 1206. The storage subsystem 1206 can comprise a memory subsystem 1208 and a file / disk storage subsystem 1210.

  The memory subsystem 1208 stores a main random access memory (RAM) 1218 for storing instructions and data during program execution, and a read-only memory (ROM) 1220 for storing fixed instructions. May include several memories. File storage subsystem 1210 provides permanent (non-volatile) storage of programs and data files, and includes hardware disk drives, floppy disk drives and associated removable media, It may include a compact disk read only memory (CD-ROM) drive, an optical drive, a removable media cartridge, and other similar storage media.

  Data processing system 1200 may be a variety of data processing systems including personal computers, portable computers, workstations, network computers, general purpose computers, kiosks and any other data processing system. Due to the ever-changing nature of computers and networks, the description of the data processing system 1200 depicted in FIG. 12 is intended only as a specific example for purposes of illustrating the preferred embodiment of the computer system. A configuration with more components than the system shown in FIG. 12 or a configuration with fewer components than the system shown in FIG.

  While specific embodiments of the invention have been described, various modifications, alterations, alternative configurations, and equivalents are also encompassed within the scope of the invention. The above-described invention is not limited to operation within a specific data processing environment, and can operate freely within a plurality of data processing environments. Further, although the present invention has been described using a specific series of transactions and processes, it should be apparent to those skilled in the art that the scope of the present invention is not limited to the series of transactions and processes described above.

  Furthermore, although the invention has been described using specific combinations of hardware and software, other combinations of hardware and software are within the scope of the invention. The present invention can be realized using hardware, software, or a combination thereof.

  The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense. However, additions, subtractions, deletions and other modifications and changes can be made thereto without departing from the broader spirit and scope of the invention as defined in the claims.

FIG. 2 is a simplified block diagram of a system for generating and using tokens according to an embodiment of the present invention. 6 is a simplified high-level flowchart illustrating a method for generating a token, according to an embodiment of the present invention. 6 is a simplified high-level flowchart representing a method for generating a token without identifying the data to be shared using the token, according to an embodiment of the present invention. 6 is a simplified schematic level flowchart representing a method of sharing data using previously generated tokens, according to an embodiment of the present invention. 6 is a simplified high-level flowchart illustrating a method for accessing shared data using a generated token, according to an embodiment of the present invention. FIG. 3 is a simplified block diagram representing various modules of a token processor, according to an embodiment of the present invention. FIG. 4 is a diagram illustrating an example of a token that can be generated according to an embodiment of the present invention. FIG. 4 is a diagram illustrating an example of a token that can be generated according to an embodiment of the present invention. FIG. 6 is a simplified high-level flowchart illustrating a method for generating tokens and sharing data in an embodiment in which various versions of shared data can be stored. FIG. 6 is a simplified schematic level flowchart representing a method for uploading data to be shared using tokens in an embodiment in which various versions of shared data can be stored. FIG. 6 is a diagram illustrating the transition of a linked record list as a new version of shared data is uploaded using tokens, according to an embodiment of the present invention. FIG. 6 is a diagram illustrating the transition of a linked record list as a new version of shared data is uploaded using tokens, according to an embodiment of the present invention. FIG. 6 is a diagram illustrating the transition of a linked record list as a new version of shared data is uploaded using tokens, according to an embodiment of the present invention. 6 is a simplified high-level flowchart representing a method for accessing the latest version of shared data using tokens, according to an embodiment of the invention. 1 is a simplified block diagram of a data processing system that can be used to perform processing according to an embodiment of the present invention. FIG.

Explanation of symbols

102 token processor 104 computer system 106 storage location 108 digital token 110 physical token 112 printer 114 token reader 116 token

Claims (10)

Memory configured to store data to be shared;
Generating an identifier that can be used to access the data to be shared from the memory;
Generating an encryption key that can be used to encrypt data to be shared from the memory;
A processor configured to generate one or more token sets including the identifier and the encryption key, wherein each token included in the token set uses any token of the token set A data sharing system that enables the data to be stored in a form accessible to the data. The system of claim 1, wherein the processor is
Obtaining the identifier and the encryption key from a first token in the set of tokens;
Receiving information identifying the first data to be shared;
Encrypting the first data using the encryption key obtained from the first token to generate encrypted first data;
A system configured to store the encrypted first data in the memory such that the encrypted first data is accessible using the identifier. The system of claim 1, wherein the processor is
Obtaining the identifier and the encryption key from a token in the set of tokens;
Accessing the encrypted first data using the identifier obtained from the token;
Decrypting the encrypted first data using the encryption key obtained from the token to generate the decrypted first data;
A system configured to allow access to the decrypted first data.   The system of claim 1, wherein at least one token in the set of tokens is a physical token comprising a machine readable code encoding the identifier and the encryption key.   The system of claim 1, further comprising a printer configured to print the set of tokens on a physical medium, the physical medium having a token printed on the physical medium on the physical medium. A system that allows you to physically separate it from other tokens printed on it. A data sharing method,
Storing data to be shared by a memory;
Generating, by a processor, an identifier that can be used to access data to be shared from the memory;
Generating an encryption key by the processor that can be used to encrypt data to be shared from the memory;
Generating one or more token sets including the identifier and the encryption key by the processor, wherein each token included in the token set uses any token of the token set. A data sharing method for storing the data in a form accessible to the data. The data sharing method according to claim 6, wherein
Obtaining the identifier and the encryption key from the first token in the set of tokens by the processor;
Receiving, by the processor, information identifying first data to be shared;
Encrypting the first data using the encryption key obtained from the first token and generating the encrypted first data by the processor;
Storing the encrypted first data in the memory by the processor such that the encrypted first data is accessible using the identifier. The data sharing method according to claim 6, wherein
Obtaining the identifier and the encryption key from a token in the set of tokens by the processor;
Accessing the encrypted first data by the processor using the identifier obtained from the token;
By the processor,
Decrypting the encrypted first data using the encryption key obtained from the token to generate the decrypted first data;
Enabling the access to the decrypted first data by the processor.   7. The data sharing method according to claim 6, wherein at least one token in the set of tokens is a physical token including a machine-readable code encoding the identifier and the encryption key.   7. The data sharing method according to claim 6, further comprising a step of printing the set of tokens on a physical medium by a printer, the physical medium including a token printed on the physical medium on the physical medium. A data sharing method that allows it to be physically separated from other tokens printed on it.

Images