Information deletion guarantee system using distributed ledger

Abstract

The technology disclosed herein facilitates ensuring the deletion of information from client systems using a distributed ledger network. One or more implementations disclosed herein provide for logging the upload and / or deletion of information using a user interface (UI) client that allows users to upload and delete information and a remaining application programming interface (API) communicatively connected to the distributed ledger network.

Description

[Technical field]

[0001] The present invention relates to an information deletion guarantee system using a distributed ledger. [Background technology]

[0002] The technology disclosed herein facilitates providing assurance against the deletion of information from client systems using a distributed ledger network. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] U.S. Pat. No. 10,333,694 Summary of the Invention [Problem to be solved by the invention]

[0004] There is room to improve the information deletion guarantee system using a distributed ledger. [Means for solving the problem]

[0005] One or more implementations disclosed herein provide for logging the upload and / or deletion of information using a user interface (UI) client that allows a user to upload and delete information, and a rest application programming interface (API) communicatively connected to the distributed ledger network.

[0006] A further understanding of the nature and advantages of the present technology may be realized by reference to the figures described in remaining portions of the specification, in which like reference numerals are used throughout the several views to refer to like elements. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 is a block diagram of an embodiment of a system for ensuring information deletion using an example distributed ledger. [Diagram 2] A diagram showing an example of system operation when building a system for securely uploading data using a distributed ledger such as blockchain. [Diagram 3] Diagram showing an example of the operation of a system using a distributed ledger such as blockchain to provide secure deletion of data. [Figure 4] Block diagram of a transaction generating node that uses a distributed ledger to store transactions related to the deletion of information. [Diagram 5] FIG. 1 illustrates an example computing system that can be used to implement the techniques disclosed herein. [Figure 6A] FIG. 2 illustrates an example operation for the Information Deletion and Disclosure Assurance System (IDDAS) disclosed herein. [Figure 6B] FIG. 1 illustrates an example operation for an Information Deletion and Disclosure Assurance System (IDDAS) disclosed herein. [Figure 6C] FIG. 1 illustrates an example operation for an Information Deletion and Disclosure Assurance System (IDDAS) disclosed herein. [Figure 6D] FIG. 1 illustrates an example operation for an Information Deletion and Disclosure Assurance System (IDDAS) disclosed herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] With the proliferation of user data and data sharing among various vendors, proper control of user data has become paramount. Various regulations have been introduced by governing bodies to ensure users' control over their data. For example, the General Data Protection Regulation (GDPR) adopted by the European Union requires various vendors that collect data to give assurances to users that they will delete the data within a given time period upon the user's request. These and other regulations place an undue burden on smaller vendors that do not have the tools or infrastructure to provide such assurances. Furthermore, having a third party curate the transactions adds an element of "assurance" to the data curation and deletion process regardless of the size of the company / vendor using the Information Deletion Assurance System (IDAS) disclosed herein.

[0009] The information deletion guarantee system disclosed herein provides an infrastructure that can be used by various parties to provide information deletion guarantees to each other. Specifically, the information deletion guarantee system disclosed herein uses a distributed ledger network such as a blockchain to provide information deletion guarantees between various parties.

[0010] FIG. 1 illustrates a block diagram_100 of an implementation of an information deletion assurance system using an exemplary distributed ledger (DL). Specifically, user data 110 describes the storage of both raw, unfiltered user data uploaded by authorized users and a parallel user data set consisting of pseudonymized data that remains for analysis after the deletion protocol is processed by the IDAS. As discussed herein, "user data" is understood to be any media type, not just text, that is related to the identity of an authorized user, if that data is defined as "personal" by the terms of service (TOS) agreed upon by the stakeholders. The distributed ledger DL 102 may be any variation of the distributed ledger DL system that provides state-of-the-art cryptographic hash functions, smart contracts, and the overall ability to execute specialized chaincode within the information deletion assurance system IDAS. One example of a distributed ledger DL 102 is a blockchain database. Another example of a distributed ledger DL102 is Hyperledger.

[0011] Alternatively, the distributed ledger DL102 may be organized in a different form, such as a directed acyclic graph (DAG) or a chain of transactions. In the illustrated implementation, the distributed ledger DL102 comprises a number of blocks comprising a number of validated transactions associated with the information deletion assurance system IDAS100. Block N 104 comprises transactions 1 through N, and block N+1 106 comprises transactions 1 through N. The blocks (e.g., block N 104 and block N+1 106) may comprise other data and metadata, such as previous hashes, nonce, Merkle root, date, time node software version, etc.

[0012] Hyperledger is a variation of an immutable ledger that records all creations, updates, accesses, reads, and deletions and programmatically implements the rules and chaincodes (smart contracts) described and tracks the actions for a final deletion consensus where all copied instances of the data flagged for deletion are overwritten and deleted. Data flagged for deletion by the IDAS is not considered deleted until all instances of the data have passed through the chaincode algorithm and a final deletion confirmation consensus has been reached. The distributed ledger DL102 may comprise multiple nodes or blocks, such as blocks 104, 106, where each block stores multiple transactions. For example, block 104 stores transactions 104a, 104b, ... and block 106 stores transactions 106a, 106b, etc.

[0013] The communications network 140 may facilitate communication between various components of the information deletion assurance system IDAS 100. In one implementation, the communications network 140 may be a public IP to private IP secure socket layer connection for transactions between application code and its service application interfaces, including but not limited to HTTP(s), web sockets, TCP / UDP, custom peer-to-peer protocols, etc.

[0014] In some example implementations, nodes may be implemented in various types. For example, a full ledger node is a node that stores a substantially complete copy of the distributed ledger DL102. A validation node is a node that may validate and approve (approve) transactions and / or blocks for inclusion in the distributed ledger DL102. A contributor node is a node that contributes transactions for validation in the distributed ledger DL102. A consumer node is a node that may consume and verify transactions on the distributed ledger DL102. It should be understood that other types of nodes are contemplated.

[0015] The distributed ledger DL102 may be implemented as a private (permissioned) ledger, a hybrid private / public ledger, or a fully public ledger. A private ledger is one where each node supporting the ledger is authenticated or authorized to use the ledger. Additionally, a private ledger may not be publicly viewable / accessible to some nodes or external parties. In a public distributed ledger DL, the complete distributed ledger DL102 is publicly distributed to many nodes and is accessible to all nodes in the network. Each node supporting the ledger has a cryptographic identity (encrypted identity) that may consist of a public / private key pair.

[0016] The information deletion assurance system IDAS 100 also includes a distributed file store cluster 130, which may be any variation of a scalable and definable distributed cluster storage in multiple variations. The implementation of the distributed file store cluster 130 may include servers and devices from all stakeholders and authorized parties to the information deletion assurance system IDAS 100. It is also understood that the distributed file store cluster 130 is both cloud-based and non-cloud-based. Users A, B, B′, etc., referenced in 111, may be configured as nodes and master nodes that may be deployed to function as nodes of accounts in the distributed ledger DL and as data storage units. Users A, B, B′ may also evolve at any point during the transactional life of the terms of service (TOS) between A←···→B and (ALSO) the third-party curator C, as determined by the specific needs of the A←···→B transactional relationship and as defined by the applicable terms of service (TOS).

[0017] In one embodiment, the user interface UI client 120 is used in initiating view / share / unshare transactions, which are further described in FIG. 6A-6D below. These include permission functions that define superadmin or subadmin status for both chaincode command and transaction initiation and manual view / share / unshare actions. Specifically, view functions may be both chaincode and non-chaincode events. Once the first view of a file is logged in the distributed ledger DL, all further view operations may no longer need to be pushed to the distributed ledger DL as redundant and inefficient since the liability for deleting that file has already been transferred and 100% of the responsibility from the view of that file has already occurred and been logged in the chaincode. In one embodiment, subsequent views of the same file may be pushed to the user database for data / metadata logging.

[0018] In yet another embodiment, the user data 110 may be internal system data, such as customer relationship management (CRM) system data or a content management system. Private third party system data, such as a customer relationship management CRM, provides a plug-in mechanism through which user data content and pseudo data anonymization algorithms can be implemented.

[0019] The user interface UI client 120 may be configured to provide all the necessary user interface tools to initialize, execute, and verify the terms of use TOS between all authorized users of the information deletion assurance system IDAS. The user interface UI client 120 is the infrastructure provided by company C for communication and sharing of information between A, B, B′, B″, etc. In one embodiment, the user interface UI client 120 is also used to initiate deletion requests and execute manual deletion protocols. The user interface UI client 120 also provides each user with an organized presentation of transactions, deletion requests, deletion confirmations, and any private message communication between interested parties. Alternatively, the user interface UI client 120 also provides the necessary cryptographic functions to provide secure upload and data hashing for the distributed ledger DL 102, the user data 110, and delivery to the distributed file store cluster 130.

[0020] FIG. 2 illustrates operations 200 of a system that uses a distributed ledger DL, such as a blockchain, to establish a system for secure uploading of data. Operation 202 initializes an operation for generating a transaction. Operation 204 allows users to participate in the information deletion assurance system IDAS 100. For example, users 111 can participate in the information deletion assurance system IDAS 100 in operation 204. These users 111 can participate in the information deletion assurance system IDAS as senders and receivers of data, data requests, etc. Operation 206 then determines the identity status of senders and receivers in the information deletion assurance system IDAS 100. Such sender and receiver identity status may include usernames, user emails, user computing device information, etc. Contracts and terms of service (TOS) between various senders and receivers may be finalized in operation 208. The terms of service TOS may specify various data deletion and validation policies, as well as usage level agreements. The determination of the contract and terms of use TOS may include one or more of the sender and the recipient executing documents in electronic or other formats and exchanging the executed documents. Operation 210 generates and uploads a terms of use TOS transaction to the distributed ledger DL. Such uploading of the terms of use TOS transaction may further include generating a hash based on the terms of use TOS transaction comprising a transaction document and one or more metadata related to the terms of use TOS. Operation 212 determines whether a data upload request has been received. In particular, operation 212 may associate the data upload request with the associated terms of use TOS.

[0021] In that case, operation 214 uploads the indexed data and data hash to various nodes of the distributed ledger DL, such as nodes 104, 106, for future deletion. Operation 216 also generates a hash of the specified space referenced by the index for future overwriting and / or deletion, so that such hash may also be stored in various nodes of the distributed ledger DL. In one implementation, the delete operation may comprise first overwriting the data and then deleting the overwritten data. Providing an overwrite before the delete adds an additional layer of security to the delete guarantee. The delete operation is then verified in operation 216, so that a transcript is generated that comprises a hash of the verification.

[0022] FIG. 3 illustrates operations 300 of a system using a distributed ledger DL, such as a blockchain, to provide secure deletion of data. Operation 302 receives a deletion request. For example, the deletion request may be received from one of the users 111. In response, operation 304 broadcasts the deletion request to various nodes of the distributed ledger DL. Operation 306 determines the validity of the deletion request by verifying that it is consensusable by all nodes. Such validation of the deletion request may comprise the implementation of peer nodes specially designed to process the blocks of transactions ordered and broadcast from operation 304. These peer nodes verify the correctness of the order result, which comprises checking the endorsement policy defined by the chaincode, possible "double spends", syntax errors, and the overall correctness of the consensus block submitted by the order node tasked with orchestrating the consensus. These peer nodes responsible for consensus validation then update the distributed network database with the latest state of the ledger. The transaction generated by the delete request may also have accompanying metadata generated by the transaction generated by the delete request to identify and distinguish the delete request from other transactions. This metadata is also verified by the distributed ledger DL as described, and facilitates an auditable trail to a "human readable" format. Once the delete request is verified, operation 308 notifies flagged users, such as B, B', and B'' of the user 111, of the delete request. A node is not "notified" via the user interface UI client 120 unless it is the direct flagged recipient of the delete request. Thus, for example, operation 308 is a description of activity occurring primarily at the user interface UI client level, such as the user interface UI client 120. Operation 310 determines the compliance of the delete request with the delete terms of use TOS.For example, determining compliance of a removal request with a removal terms of use TOS may include ensuring that the party initiating the removal request has the authority to do so and that the removal request conforms to one or more terms (conditions) of the terms of use TOS.

[0023] In operation 314, the chaincode begins executing the deletion per the terms of service TOS. The chaincode may be stored in various locations and on various nodes as required, as defined by the chaincode business logic implementation. "Chaincode" refers to the code and business logic that defines objects or "assets" in a distributed network and defines transactional instructions for modifying them. These transactional instructions can take many different forms. For example, such execution includes one or more of: the deletion request entering a "grace period" if a grace period was defined in the terms of service TOS that encapsulates a manual deletion protocol; performing a manual or automatic forced deletion; writing the designated space with random data; and deleting the overwritten designated space and deleting index references to the designated space. In one embodiment, the grace period is 72 hours. In an alternative embodiment, the grace period reflects the parties' data retention policies.

[0024] Operation 316 receives a deletion confirmation. Specifically, in one implementation, operation 316 receives a deletion confirmation from all parties from operation 304 that comprise the user interface UI client 120. Operation 318 determines the validity of the deletion confirmation by consensus of the peer nodes. Operation 320 then generates and uploads a hash that comprises the deletion confirmation to the distributed ledger DL.

[0025] FIG. 4 shows a block diagram_400 of a transaction generating device 410 that may be used by various nodes on the distributed ledger DL network to generate transactions for storage on the distributed ledger DL network. The transaction generating device 410 may be implemented using a computer system that executes processor-executable instructions to support the distributed ledger DL102. The transaction generating device 410 may include a clock 418 that provides a timestamp for data deletion requests and execution. The deletion terms of use TOS database 420 stores various contracts and terms of use TOS between users of the information deletion assurance system IDAS. The deletion confirmation database 422 stores various deletion completion data. The deletion data ID store 424 stores the location of data related to the data deletion request. The storage medium 414 stores other data and programs for realizing transaction generation, so that the programs can be executed by the processor (processing device) 428. The hash generator 416 uses the digital signature 412, clock data, deletion terms of use TOS, deletion confirmation, etc. to generate a hash that is transmitted to the distributed ledger DL402 via the sender 426.

[0026] In one embodiment, the system also provides a baseline scaling for the third party C. The system disclosed herein is configured to handle the addition of more nodes as well as the removal of nodes. Since the third party C is likely to scale at a minimum of N+1 on the distributed ledger DL, such as the distributed ledger DL402, this allows an unbiased third party, such as the third party C, to always have a minimum of excess nodes on the distributed ledger DL. Thus, users sharing and consuming data on the system cannot gain a statistical advantage over one another by accumulating and leveraging a majority stake in the nodes against another party with a smaller node base within the distributed ledger DL402 and the distributed ledger DL system for the purpose of attack and / or hacking. Thus, the block 408 may be used by such a third party C. Additionally, a counter 415 may be provided to keep a count of the node ratio.

[0027] FIG. 5 illustrates an exemplary system 500 that may be useful in implementing the information deletion assurance system disclosed herein. The exemplary hardware and operating environment of FIG. 5 for implementing the described technology includes a computing device, such as a general-purpose computing device in the form of a gaming console or computer 20, a mobile phone, a personal data assistant (PDA), a set-top box, or other type of computing device. In the embodiment of FIG. 5, for example, the computer 20 includes a processing unit 21, a system memory 22, and a system bus 23 that operatively couples various system components including the system memory 22 to the processing unit 21. The processing unit 21 may be single or multiple, so that, for example, the processor of the computer 20 may include a single central processing unit (CPU) or multiple processing units, commonly referred to as a parallel processing environment. It is noted that the computer 20 may be a conventional computer, a distributed computer, or other type of computer, and the embodiment is not so limited. The computer 20 may be implemented with an information deletion assurance system (IDAS) 502 for storing code and performing one or more operations of the technology disclosed herein.

[0028] The system bus 23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, a switched fabric, a point-to-point connection, and a local bus using any of a variety of bus architectures. The system memory, sometimes simply referred to as memory, includes a ROM (read only memory) 24 and a RAM (random access memory) 25. A basic input / output system (BIOS) 26, which contains the basic routines that help to transfer information between elements within the computer 20, such as during start-up, is stored in the ROM 24. The computer 20 further includes a hard disk drive 27 for reading from and writing to a hard disk (not shown), a magnetic disk drive 28 for reading from and writing to a removable magnetic disk 29, and an optical disk drive 30 for reading from and writing to a removable optical disk 31, such as a CD-ROM, DVD, or other optical media.

[0029] Hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to system bus 23 by hard disk drive interface 32, magnetic disk drive interface 33, and optical disk drive interface 34, respectively. The drives and their associated tangible computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for computer 20. Those skilled in the art should appreciate that any type of tangible computer-readable medium capable of storing data accessible by a computer may be used in the exemplary operating environment, such as magnetic cassettes, flash memory cards, digital video disks, random access memory (RAM), read-only memory (ROM), etc.

[0030] A number of program modules may be stored on the hard disk, removable magnetic disk 29, removable optical disk 31, ROM 24, or RAM 25, including an operating system 35, one or more application programs 36, other program modules 37, and program data 38. A user may enter commands and information into the computer (personal computer) 20 through input devices such as a keyboard 40 and a pointing device 42. Other input devices (not shown) may include a microphone (e.g., for voice input), a camera (e.g., for a natural user interface (NUI)), a joystick, a game pad, a satellite dish, a scanner, and the like. These and other input devices are often connected to the processing unit 21 through a serial port interface 46 coupled to the system bus, but may also be connected by other interfaces, such as a parallel port, a game port, or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 through an interface, such as a video adapter 48. In addition to a monitor, a computer typically includes other peripheral output devices (not shown), such as speakers and printers.

[0031] Computer 20 may operate in a networked environment with logical connections to one or more remote computers, such as remote computer 49. These logical connections are realized by communication devices coupled to or part of computer 20, and the implementation is not limited to a particular type of communication device. Remote computer 49 may be another computer, a server, a router, a network PC, a client, a peer device, or other common network node, and typically includes many or all of the elements described above relative to computer 20, although only memory storage device 50 is illustrated in FIG. 4. The logical connections depicted in FIG. 4 include a local area network (LAN) 51 and a wide area network (WAN) 52. Such networking environments are commonplace in any type of network, such as an office network, an enterprise-wide computer network, an intranet, the Internet, etc.

[0032] When used in a LAN-networking environment, the computer 20 is connected to the local area network 51 via a network interface or adapter 53, which is one type of communication device. When used in a WAN-networking environment, the computer 20 typically includes a modem 54, a network adapter, a type of communication device, or any other type of communication device for establishing communications over the wide area network 52. The modem 54, which may be internal or external, is connected to the system bus 23 via a serial port interface 46. In a network environment, the program engine depicted in association with the computer (personal computer) 20, or portions thereof, may be stored in a remote memory storage device. It is understood that the network connections shown are exemplary and other means and communication devices for establishing a communications link between the computers may be used.

[0033] 6A-6D are diagrams illustrating exemplary operations 600 for an information deletion and disclosure assurance system (IDDAS) disclosed herein. Specifically, the operations 600 allow for generating and storing transactions on the distributed ledger DL in response to a party viewing / downloading, sharing, or unsharing one or more files. For example, party A discloses some content by sharing a file with party B. Party B can then share the shared data with party D. Party C is an unbiased curator of ledger transactions between parties A, B, and D. The data disclosure transaction made via the operations 600 is saved on the distributed ledger DL.

[0034] Specifically, when party A shares a document with another party to disclose content by operation 600, an information disclosure / deletion assurance system (IDDAS) can be implemented such that the share is transacted on the distributed ledger DL as a sharing function. If the other party (receiver) views / downloads the shared content, a corresponding distributed ledger DL transaction is generated. Any subsequent views / downloads are pushed to the database for reference. Here, if the data is never viewed, the content does not become a liability of future alternative receiving parties. The purpose of the information deletion assurance system IDAS is to make the legal liability of the entity / individual responsible and accountable for the deletion of data as low as possible. The sharing function itself adds a level of nuance to the definition of legal liability of what it means to "delete" information, since the upload function and the existence of the file in storage by the recipient who is authorized to access it are linked by the sharing function.

[0035] The share / unshare functionality of the management tools provided herein creates a subset of the "soft" delete protocol (non-storage level overwrite) by simply removing the ability of a particular node to access information that was previously shared and viewed. Furthermore, from the perspective of a particular low-level user node (an employee of the management), the action of unsharing constitutes a "deletion" for that node (an authorized node had access to the data, but now does not). Thus, the share and unshare functionality can be thought of as defining the parameters of the "soft" delete protocol. Thus, the share and unshare functionality, together with the view functionality processed on the distributed ledger DL, define a set of tools to complete the "soft" delete. This is important because the information deletion assurance system IDAS is designed to ensure that all nodes that receive authorized information do not ultimately have access to the shared information.

[0036] These features can be used more usefully or advantageously than "hard" deletion in situations where a project goes dormant and is resurrected among peer groups or B2B interactions. In peer groups or B2B interactions, the "soft" deletion feature avoids hard deletion while meeting many times the legal definition of deletion for a particular user node. In hard deletion, distributed data is deleted from storage and is no longer visible to any user or node in the ledger relationship or network. In the case of business projects with unpredictable timelines as mentioned above, soft deletion can avoid situations where data is completely deleted by hard deletion on storage, which would require re-uploading of previous data, changes to terms of use (TOS), etc. When a project is completely terminated, hard deletion can be performed as needed at the end of the entire business relationship of the participating entities.

[0037] As used in Figures 6A-6D, a sub-administrator user node is a description within a user node group defined by its relationship to a "super-administrator" (not disclosed herein). For example, a super-administrator may be defined as merely an administrator. For example, a super-administrator may have the ability to share shared data while a sub-administrator may not. Or, a sub-administrator may have the ability to view / consume shared data while not having the ability to share shared data. This distinction is noted in Figures 6A-6D because its application in non-shared functions is specifically defined as required in a practical implementation of the non-shared functions.

[0038] In the context of Figures 6A-6D, if an individual shares data with a business / company, it can be understood (and legally defined within the Terms of Use TOS) that the data protection officer / super administrator of that business must share the shared data with lower level employee sub-administrator nodes to provide the services offered and requested by the individual consumer user node, both within the business and within the reasonable scope of B2B interactions. Therefore, from a user experience perspective, it is cumbersome and illogical for individual user nodes to be forced to unshare what could be many users of a single file, so a chaincode needs to sort this out. Furthermore, if the super administrator unshares, then all other nodes that shared the data designated as sub-administrators will also automatically unshare.

[0039] 6A-6D, operation 602 initializes one or more operations for a transaction. Such initialization may comprise initialization via a web / browser-based implementation or a non-browser-based application. One or more users, such as user 111, may join the system in operation 604. These users 111 may join the information deletion assurance system IDAS as senders and receivers of data or data requests, etc. Operation 606 determines the identity status of these senders and receivers. Operation 608 finalizes contracts and terms of service (TOS) between various senders and receivers. Operation 610 generates and uploads a terms of service TOS transaction to the distributed ledger DL. Operation 612 determines whether a data upload request has been received. Specifically, operation 612 may associate the data upload request with an associated terms of service TOS. If so, operation 614 uploads the indexed data and data hashes for future distribution to various nodes, such as nodes 104, 106, of the distributed ledger DL. Also, in operation 616, the sender or provider of the uploaded data shares the data with other designated recipients. For example, the designated recipients may be specified by username, email, user's computer information, or any other specific registered ID (identification) designated and assigned to registered users by an ID management device in a membership service application of the network.

[0040] Then, operation 618 determines whether the recipient of the data is an administrator user who has permission to share and unshare (unshare) data with other user nodes according to the terms of use TOS. If so, in operation 618B, the share function transaction is hashed and added to the distributed ledger DL with the administrator's designation. However, if not, in operation 618A, the share function transaction is hashed and added to the distributed ledger DL without the administrator's designation. Then, operation 620 determines whether one or more of the recipients with whom the shared data was shared in operation 616 above have viewed the shared data. If so, operation 622 hashes and adds the transaction of viewing the designated data to the distributed ledger DL and logs the subsequent viewing of the data by the recipient in a user database. In particular, such a user database keeps a log of the viewing of data by various users.

[0041] If operation 620 determines that the shared data from operation 616 has or has not been viewed by the recipient, operation 624 determines whether the administrator from operation 618B shared data with the sub-administrator user node. If yes, operation 626 hashes the share function transaction and adds it to the distributed ledger DL with the sub-administrator user specification. Operation 628 determines whether the shared data has been viewed by the sub-administrator receiver. If yes, operation 630 hashes the transaction of viewing the specified data and adds it to the distributed ledger DL, as well as logging the subsequent viewing of the data by the sub-administrator receiver in the user database.

[0042] However, if the determination from operation 624 is "no" and if the determination from operation 628 is "no", operation 632 determines whether a data unshare operation has been initiated by the data receiver from operation 614. If "yes", then in operation 633b, the specified data receiver unshares itself and the unshare operation is transacted to the distributed ledger DL. If "no", then in operation 633a, the sender / provider of the uploaded data unshares the data from the specified user(s) (user / s) from operation 614 and the unshare function may enter a grace period in accordance with the terms of use TOS.

[0043] Next, operation 634 determines whether the sender / provider is the administrator from operation 618B. If yes, then in operation 638C the non-shared function is transacted to a sub-administrator user node and hashed and added to the distributed ledger DL. If no, operation 636 determines whether the specified user is the administrator from operation 618B. If yes, then in operation 638A the non-shared function is transacted to an administrator user node and hashed and added to the distributed ledger DL, similar to the non-administrator node or nodes from operation 626. If no, then in operation 638B the non-shared function is transacted to a non-administrator (individual) user node from operation 618A and hashed and added to the distributed ledger DL.

[0044] In an exemplary implementation, software or firmware instructions and data for providing the search management system, various applications, search context pipeline, search services, services, local file indexes, local or remote application content indexes, provider APIs, contextual application launchers, and other instructions and data may be stored in system memory 22 and / or storage devices (29 or 31) and processed by processing unit 21.

[0045] Some embodiments may comprise an article of manufacture. The article of manufacture may comprise a tangible storage medium for storing logic. Examples of storage media may comprise one or more types of computer readable storage media capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and the like. Examples of logic may comprise various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (APIs), instruction sets, opcodes, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. In one embodiment, for example, the article of manufacture may store executable computer program instructions that, when executed by a computer, cause the computer to perform methods and / or operations according to the described embodiments. The executable computer program instructions may comprise any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. The executable computer program instructions may be implemented according to a predefined computer language, manner or syntax for instructing a computer to perform a particular function. The instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0046] The implementations described herein are implemented as logical steps in one or more computer systems. Logical operations may be implemented (1) as a sequence of processor-implemented steps executed in one or more computer systems, and (2) as interconnected machine or circuit modules within one or more computer systems. The implementation depends on the performance requirements of the computer system employed and is a matter of choice. Accordingly, the logical operations making up the implementations described herein are variously referred to as operations, steps, objects, or modules. Furthermore, it should be understood that logical operations may be performed in any order unless expressly claimed otherwise or a particular order is inherently required by the claim language.

[0047] The above specification, examples, and data provide a complete description of the structure and use of the exemplary implementations. Since many embodiments can be made without departing from the spirit and scope of the claimed invention, the following appended claims define the invention. Moreover, structural features of different embodiments may be combined in yet other embodiments without departing from the scope of the recited claims.

[0048] An embodiment of the present technology is disclosed herein in the context of an electronic marketplace system. In the above description, for purposes of explanation, numerous specific details are set forth in order to fully understand the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without some of these specific details. For example, although various features are attributed to specific embodiments, it should be understood that features described with respect to one embodiment may be incorporated in other embodiments as well. However, in the same sense, no single feature or features of any described embodiment should be deemed essential to the present invention, since other embodiments of the present invention may omit such features.

[0049] For clarity, not all of the routine functions of the embodiments described herein are shown and described. Of course, in the development of any such actual implementation, numerous implementation-specific decisions must be made to achieve the developer's particular goals, such as compliance with application- and business-related constraints. It will be understood that those particular goals will vary from implementation to implementation and developer to developer.

[0050] According to an embodiment of the present invention, the components, process steps, and / or data structures disclosed herein may be implemented using various types of operating systems (OS), computing platforms, firmware, computer programs, computer languages, and / or general purpose machines. The methods may be performed as programmed processes running on processing circuitry. The processing circuitry may take the form of many combinations of processors and operating systems, connections and networks, data stores, or stand-alone devices. The processes may be implemented as instructions executed by such hardware, by hardware alone, or any combination thereof. The software may be stored on a machine-readable program storage device.

[0051] In accordance with one embodiment of the present invention, the components, processes, and / or data structures may be implemented using machine language, assembler, C or C++, Java, and / or other high level language programs executing on a data processing computer, such as a personal computer, workstation computer, mainframe computer, or high performance server running an OS such as Solaris available from Sun Microsystems, Inc., Santa Clara, Calif., Windows Vista, Windows NT, Windows XP_PRO, and Windows 2000 available from Microsoft Corporation, Redmond, Wash., Apple OS X-based systems available from Apple Inc., Cupertino, Calif., or various versions of Unix operating systems, such as Linux, available from a number of vendors. The method may also be practiced in a multiprocessor system or computing environment having a variety of peripherals, such as input devices, output devices, displays, pointing devices, memory, storage devices, media interfaces for transferring data to and from the processor(s). Additionally, such computer systems or computing environments may be networked, locally or over the Internet or other networks. Different implementations may be used and may include other types of operating systems, computing platforms, computer programs, firmware, computer languages, and / or general purpose machines. Additionally, those skilled in the art will recognize that less general purpose devices, such as hardwired devices, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and the like, may also be used without departing from the scope and spirit of the inventive concepts disclosed herein.

[0052] In the context of the present invention, the term "processor" describes a physical computer (either standalone or distributed) or a virtual machine (either standalone or distributed) that processes or transforms data. A processor may be implemented in hardware, software, firmware, or a combination thereof.

[0053] In the context of the present technology, the term "data store" describes a local or distributed hardware and / or software means or device for storing digital or analog information or data. The term "data store" describes any device, such as, by way of example, random access memory (RAM), read-only memory (ROM), dynamic random access memory (DRAM), static dynamic random access memory (SDRAM), flash memory, hard drives, disk drives, floppy drives, tape drives, CD drives, DVD drives, magnetic tape devices (audio, visual, analog, digital, or combinations thereof), optical storage devices, electrically erasable programmable read-only memories (EEPROMs), solid-state memory devices, and universal serial bus (USBD) storage devices. The term "data store" also describes, by way of example, databases, file systems, systems of record, object-oriented databases, relational databases, SQL databases, audit trails and logs, program memories, caches and buffers, and the like.

[0054] The above specification, examples, and data provide a complete description of the structure and use of the exemplary embodiments of the invention. Although various embodiments of the invention have been described above with a certain degree of particularity or with reference to one or more individual embodiments, those skilled in the art could make numerous modifications to the disclosed embodiments without departing from the spirit or scope of the invention. In particular, it is to be understood that the described techniques may be employed independent of a personal computer. Accordingly, other embodiments are contemplated. All matters contained in the above description and shown in the accompanying drawings are intended to be interpreted only as illustrative of particular embodiments and not limiting. Changes in detail or structure may be made without departing from the basic elements of the invention as defined in the following claims.

Claims

1. 1. A computer-implemented method for providing assurances associated with data deletion, the method being implemented by a plurality of computer-readable instructions stored on a non-transitory computer-readable medium and executable by a computer processor, the method comprising: generating distributed ledger (DL) transactions based on a deletion terms of service (TOS) between a deletion guarantee provider and a plurality of clients, the generating DL transactions including verifying the DL transactions based on the deletion terms of service TOS by a plurality of DL nodes; receiving a delete request from one of said plurality of clients; verifying whether the deletion request complies with the deletion terms of use (TOS); validating the delete request by a plurality of the distributed ledger DL nodes; initiating a delete operation; verifying the delete operation by a plurality of the distributed ledger DL nodes; generating a transaction comprising a verification of the delete operation; The method comprises:

2. Validating the delete request by a plurality of the distributed ledger DL nodes further comprises broadcasting the delete request to a plurality of the distributed ledger DL nodes. The method of claim 1.

3. The step of verifying the delete operation further comprises verifying a delete confirmation. The method of claim 2.

4. The method further comprises storing a location of data associated with the delete request. The method of claim 1.

5. The step of generating the transaction comprising the verification of the delete operation further comprises the step of generating a transaction comprising the delete terms of use TOS, clock data, and a delete confirmation. The method according to claim 4.

6. The method further includes generating a shared / unshared distributed ledger DL transaction in response to sharing or unsharing data subject to the deletion terms of use TOS. The method of claim 1.

7. The step of generating the shared / non-shared DL transaction further includes a step of generating a shared DL transaction including an administrator designation of a party who will share or not share the target data of the deletion terms of use TOS. The method according to claim 6.

8. The step of generating the shared distributed ledger DL transaction further includes generating the shared distributed ledger DL transaction with an ID of a recipient of the target data of the deletion terms of use TOS. The method of claim 7.

9. The method further includes generating a view distributed ledger DL transaction in response to viewing the data subject to the deletion terms of use TOS. The method of claim 1.

10. The step of generating the view distributed ledger DL transaction further includes a step of generating the view distributed ledger DL transaction including an administrator designation of a party viewing the target data of the deletion terms of use TOS.

10. The method of claim 9.

11. the delete operation further comprises overwriting data and then deleting the overwritten data; The step of verifying the delete operation further comprises verifying the step of overwriting the data and then deleting the overwritten data. The method of claim 1.

12. The step of generating the transaction comprising verification of the delete operation further comprises generating a hash of metadata generated by the delete transaction to identify and distinguish the delete request from other transactions. The method of claim 1.

13. 1. A method implemented using a computing device, the method comprising: receiving a deletion terms of service (TOS) between a deletion guarantee provider and a plurality of clients in a deletion guarantee user interface (UI) client implemented on a server; generating a distributed ledger (DL) transaction based on a deletion terms of use (TOS) between the deletion guarantee provider and a plurality of the clients, the generating DL transaction comprising verifying the DL transaction based on the deletion terms of use (TOS) by a plurality of DL nodes; receiving a deletion request from one of the plurality of clients in a deletion guarantee user interface UI client, the deletion request requesting deletion of data; verifying whether the deletion request complies with the deletion terms of use (TOS); validating the delete request by a plurality of the distributed ledger DL nodes; initiating a delete operation, the delete operation comprising overwriting the data before deleting the data; verifying the delete operation by a plurality of the distributed ledger DL nodes; generating a transaction comprising a verification of the delete operation; The method comprises:

14. Validating the delete request by a plurality of the distributed ledger DL nodes further comprises broadcasting the delete request to a plurality of the distributed ledger DL nodes. The method of claim 13.

15. The step of verifying the delete operation further comprises verifying a delete confirmation. The method of claim 14.

16. The step of generating the transaction comprising verification of the delete operation further comprises generating a hash of metadata generated by the delete transaction to identify and distinguish the delete request from other transactions. The method of claim 13.

17. The method further includes generating a shared / unshared distributed ledger DL transaction in response to sharing or unsharing data subject to the deletion terms of use TOS. The method of claim 13.

18. The step of generating the shared / non-shared DL transaction further includes a step of generating a shared DL transaction including an administrator designation of a party who will share or not share the target data of the deletion terms of use TOS.

20. The method of claim 17.

19. The step of generating the shared distributed ledger DL transaction further includes generating the shared distributed ledger DL transaction with an ID of a recipient of the target data of the deletion terms of use TOS.

20. The method of claim 18.

20. The method further includes generating a view distributed ledger DL transaction in response to viewing the data subject to the deletion terms of use TOS. The method of claim 13.

Images