Information deletion guarantee system using a distributed ledger

Abstract

The technology disclosed herein helps provide assurance regarding the deletion of information from client systems utilizing a distributed ledger network. One or more implementations disclosed herein enable a user to upload and delete information using a user interface (UI) client, and provide a Rest API (Application Programming Interface) communicated to the distributed ledger network to record the upload and / or deletion of information.

Description

Technology Field

[0001] The present invention is a regular application based on the priority of U.S. Patent Application No. 63 / 035,077, filed June 5, 2020, “Information Deletion System Using Distributed Ledger,” and U.S. Patent Application No. 62 / 948,008, filed December 13, 2019, “Information Deletion System Using Distributed Ledger,” the entirety of which is incorporated herein by reference. Background Technology

[0002] With the proliferation of user data and its sharing among various vendors, ensuring that user data is properly controlled has become paramount. To guarantee user control over their data, various regulations have been introduced by competent authorities. For example, the General Data Protection Regulation (GDPR) introduced by the European Union requires various vendors collecting data to definitively guarantee that user data will be deleted within a specified period upon the user's request. These and other regulations impose an excessive burden on small vendors who may lack the infrastructure or tools to provide such guarantees. Furthermore, if a third-party curator is present, the transaction adds an element of “warranty” to the data curation and deletion process, which adds a useful warranty regardless of the size of the company / merchant using the Information Deletion Guarantee System (IDAS) disclosed herein. Prior Art 1: Nakamoto, Satoshi, Bitcoin: A Peer-to-Peer Electronic Cash System (Aug. 21, 2008) Prior Art 2: Benet, J. et al, Filecoin: A Cryptocurrency Operated File Storage Network (July 15, 2014) Prior Art 3: PCT Published Patent Application WO 2019 / 106177 A1 (June 6, 2019) The problem to be solved

[0003] The technology disclosed herein helps provide assurance regarding the deletion of information from a client system using a distributed ledger. One or more implementations disclosed herein allow a user to upload and delete information using a user interface (UI) client, and an application programming interface (Rest API) communicately connected to a distributed ledger network records the upload and / or deletion of information. means of solving the problem

[0004] The information erasure guarantee system disclosed herein provides an infrastructure that can be utilized by various parties to provide information erasure guarantees to one another. Specifically, the information erasure guarantee system disclosed herein uses a distributed ledger network, such as a blockchain, to provide information erasure guarantees between various parties. Brief explanation of the drawing

[0005] The nature and advantages of the present invention are further explained with reference to the drawings, which are described in part of the specification. In the drawings, similar elements have similar numbers. Figure 1 illustrates an example block diagram of an implementation of an information deletion guarantee system using an example distributed ledger. FIG. 2 illustrates an example operation of a system using a distributed ledger, such as a blockchain, to establish a system for securing the uploading of the above data. FIG. 3 illustrates an example operation of the system using a distributed ledger, such as a blockchain, to provide for the deletion of the data. Figure 4 illustrates a block diagram of a transaction that creates a node using the distributed ledger to store a transaction related to the deletion of information. FIG. 5 illustrates an example computing system that can be used to implement the technology disclosed in this specification. FIGS. 6a-6d illustrate exemplary operations of the information deletion and public assurance system (IDDAS) disclosed herein. Specific details for implementing the invention

[0006] FIG. 1 illustrates an example block diagram (100) of an implementation of the information erasure guarantee system using an example distributed ledger (DL). Specifically, user data (110) represents the storage of both the original unfiltered user data uploaded by the authorized user and the anonymized data to be left for analysis after the erasure protocol has been processed by the IDAS (Information Erasure Guarantee System). As discussed herein, “user data” refers to any media type other than text that relates to the identity of the authorized user, provided that such data is defined as “personal” by the Terms of Service (TOS) agreed upon by the interested parties. The DL (102) may be any variant of the DL system that provides the ability to execute state-of-the-art cryptographic hashing functions, smart contracts, and specialized chain code within the IDAS as a whole. An example of the DL (102) is a blockchain database. Another example of the DL (102) is Hyperledger.

[0007] Alternatively, the DL (102) may be configured in other forms, such as a directed acyclic graph, a chain of transactions, etc. In the illustrated implementation, the DL (102) includes a number of blocks containing the number of approved transactions associated with the IDAS (100). Block N (104) contains transactions 1 through N, and block N+1 (106) contains transactions 1 through N. The blocks (e.g., block N (104) and block N+1 (106)) may contain other data and metadata, such as a previous hash, nonce, Merkle root, date, time node software version, etc.

[0008] Hyperledger is a variant of the immutable ledger and will record all Creation, Update, Access, Read, and Delete operations to implement the described rules and chaincode (smart contracts), and will track these actions for a final deletion consensus in which all copied instances of data flagged for deletion are overwritten and deleted. Data flagged for deletion by the IDAS is not considered deleted until all instances of that data have passed through the chaincode algorithm and reached a final consensus for deletion confirmation. The DL (102) may include a large number of blocks or nodes, such as blocks (104, 106) in which each block stores a large number of transactions. For example, the block (104) stores transactions 104a, 104b,… and the block (106) stores transactions (106a, 106b, etc.).

[0009] A communication network (140) can facilitate communication between various components of the IDAS (100). In one implementation, the communication network (140) may be a public IP to private IP secure socket layer connection for transactions between application code and their service application interfaces. This is not limited to HTTP(s), WebSockets, TCP / UDP, or user-defined P2P protocols.

[0010] In some example implementations, nodes may be implemented in various types. For example, a pool ledger node is a node that stores the actual completed version of the DL (102). An approval node is a node that can approve and authorize transactions and / or blocks to be included in the DL (102). A contributor node is a node that contributes to transactions for approval of the DL (102). A consumer node is a node that can consume and verify transactions for the DL (102). It can be seen that other types of nodes may also be considered.

[0011] The above DL (102) may be implemented as a private (authorized) ledger, a hybrid private / public ledger, or a fully public ledger. A private ledger is a ledger in which each node supporting the ledger is authorized or authorized to use the ledger. Furthermore, a private ledger may not be publicly visible or accessible to some nodes or external parties. In a public DL, the above fully DL (102) is publicly distributed to many nodes and is accessible to all nodes within the network. Each node supporting the ledger includes a cryptographic identity, which may include a public / private key pair.

[0012] The IDAS (100) also includes a distributed file storage cluster (130) (the distributed file storage cluster may be any variant of a distributed cluster storage that is scalable and definable in a number of variations). The implementation of the distributed file storage cluster (130) may include devices and servers from all stakeholders and authorized parties regarding the IDAS (100). It may also be noted that the distributed file storage cluster (130) may be cloud-based and non-cloud-based. Users A, B, B', etc., referred to by 111, may be configured as nodes, and master nodes, which may be used to function as both nodes and data storage units of accounts for the DL, may be determined by the specific needs of the A ←---→ B transaction relationship and may evolve as defined by applicable Terms of Service (TOS) at any point in the transaction life of the TOS between A ←---→ B and ALSO third-party curator C.

[0013] In one implementation, the UI (120) is used during the initialization of a view / share / unshare transaction, which is further described below in FIG. 6a-6d. These include authorization capabilities that define the super manager or sub-manager status, both in initializing chaincode commands and transactions and in initializing passive view / share / unshare actions. Specifically, the view function may be both a chaincode event and a non-chaincode event. Once the initial view of a file is written to the DL, the responsibility for deleting that file has already been transferred, and thereafter, all additional view actions no longer need to be pushed to the DL because they are useless and inefficient, and 100% of the responsibility has already occurred from the view of that file and has been written to the chaincode. In one implementation, subsequent views of the same file may be pushed to a user database for the recording of the data / metadata.

[0014] In another implementation, the user data (110) may be internal system data such as customer relationship management (CRM) system data or content management system data. Data from a private third-party system such as a CRM provides a plugin mechanism that enables the implementation of the user data content and pseudo-data anonymization algorithm.

[0015] The UI client (120) may be configured to provide all necessary user interface tools to initialize, execute, and verify the TOS between all authorized users of the IDAS. The UI client is an infrastructure provided by Company C for the sharing and communication of information between A, B, B', B'', etc. In one implementation, the UI client (120) is also used for the initialization of deletion requests and the execution of manual deletion protocols. It also provides each user with deletion requests, deletion confirmations, and organized presentations of transactions, as well as any private message communication between stakeholders. Alternatively, the UI client (120) also provides the necessary encryption functions required to provide data hashing and secure uploading for delivery to the DL (102), the user data (110), and the distributed file storage cluster (130).

[0016] FIG. 2 illustrates an operation (200) of the system using a distributed ledger, such as a blockchain, to establish a system for securing the uploading of the data. Operation (202) initializes an operation to generate a transaction. Operation (204) causes users to join the IDAS (100). For example, users (111) can join the IDAS (100) in operation (204). These users (111) can participate as senders and receivers of data, data requests, etc. within the IDAS. Subsequently, operation (206) determines the identity status of the receiver and sender within the IDAS (100). Such identity status of the sender and receiver may include a username, user email, user computing device information, etc. The terms of service (ToS) and contract between various senders and receivers can be determined in operation (208). The above ToS may specify various data deletion and verification policies and service level agreements. The confirmation of said agreements and ToS may include one or more senders and receivers who execute said electronic or other forms of documents and exchange said executed documents. Operation (210) creates a ToS transaction and uploads it to said DL. Uploading such a ToS transaction may additionally include generating a hash based on said ToS transaction that includes said transaction documents and one or more metadata related to said ToS. Operation (212) determines whether a data upload request has been received. Specifically, said operation (212) may be related to said data upload request regarding said related ToS.

[0017] In that case, the operation (214) uploads the data and the hash of the data indexed for future deletion to various nodes, such as nodes (104, 106) of the DL. Additionally, the operation (216) generates a hash of the designated space referenced by the index for future overwriting and / or deletion, and such hash may also be stored in the various nodes of the DL. In one implementation, the deletion operation may further include the step of deleting the overwritten data after overwriting the data. The step of overwriting prior to deletion adds an additional layer of security for the deletion guarantee. Subsequently, the deletion operation is approved, and a transaction containing the hash of the approval is created.

[0018] FIG. 3 illustrates an operation of the system using a distributed ledger, such as a blockchain, to provide for the securing of the deletion of the data. An operation (302) receives a deletion request. For example, the deletion request may be received from one of the users (111). In response, an operation (304) broadcasts the deletion request to various nodes of the DL. An operation (306) verifies the validity of the deletion request by all nodes by verifying whether consensus can be achieved. Such verification of the deletion request may include the implementation of peer nodes specifically designed to process the block of transactions directed and broadcast from the operation (304). These peer nodes check the accuracy of the directed result, including promotion policy checks defined by the chaincode, possible “double spending,” and syntax errors, and the overall accuracy of the consensus block presented to these nodes by the directed node, which is given the task of consolidating the consensus. These peer nodes, given the task of consensus approval, then update the distributed network database to the most recent state of the ledger. The transaction generated by the deletion request may also include metadata generated by the deletion transaction to specify and distinguish the deletion request from other transactions. This metadata is also approved by the DL as described and helps with the audit trail in a “human-readable” form. Once the deletion request is verified, the operation (308) notifies the flagged user, such as the user (111) B, B', B”, etc. of the deletion request. Nodes are not “notified” via the UI client unless they are the direct flagged recipients of the deletion request. Thus, for example, the operation (308) is a description of an activity that primarily occurs at the UI client level, such as the UI client (120).The operation (310) determines compliance of the deletion request with respect to the deletion TOS. For example, determining compliance of the deletion request with respect to the deletion TOS may include ensuring that the party initiating the deletion request has the authority and that the deletion request matches one or more conditions of the TOS.

[0019] In operation (314), the chaincode begins executing deletions per TOS. The chaincode may be stored in as many different locations and on various nodes as needed and is defined by the implementation of the chaincode business logic. The “chaincode” is defined within the distributed network and the transaction instructions for modifying the object or “asset” with code and business logic. These transaction instructions may assume many different forms. For example, such execution includes one or more deletion requests entering a ‘grace period’ (whereby if the grace period is defined within the TOS, the manual deletion protocol is compressed, manual or automatic forced deletion is executed, random data is written to a designated space, and the index reference is deleted from the designated space and the designated space that was overwritten). In one implementation, the grace period is seventy-two (72) hours. In an alternative implementation, the grace period reflects the party’s data retention policy.

[0020] Operation (316) receives a deletion confirmation. Specifically, in one implementation, the operation (316) receives the deletion confirmation from all parties from the operation (304), which includes the UI client (120). The operation (318) determines the validity of the deletion confirmation by the consensus of the peer nodes. Subsequently, the operation (320) generates and uploads a hash having the deletion confirmation to the (DL).

[0021] FIG. 4 illustrates a block diagram (400) of a transaction generation device (410) that can be utilized by various nodes on a DL network to generate a transaction for storage on the DL network. The device (410) may be implemented using a computer system that executes instructions executable by a processor to support the DL (102). The device (410) may include a clock (418) that provides a timestamp for data deletion requests and execution. A deletion ToS database (420) stores various ToS and contracts between the users of the IDAS. A deletion confirmation database (422) stores various deletion completion data. A deletion data identification store (424) stores the location of data associated with the data deletion request. A storage medium (414) stores other data and programs used to implement the transaction generation, and such programs may be executed by a processor (426). The hash generator (416) uses the digital signature (412), the clock data, the deletion ToS, the deletion confirmation, etc., to generate a hash that is communicated to the DL (402) through the transmitter (426).

[0022] In one implementation, the system also provides baseline scaling of third party C. The system disclosed herein is configured to handle the addition of more nodes and also to handle their removal. As far as third party C is likely to scale at least N+1 on a DL such as the DL (402), this ensures that an unbiased third party like third party C always has at least an extra node of the DL, thereby preventing users sharing and consuming data on the system from accumulating and leveraging a majority share of the nodes against other parties with a smaller node base within the DL (402) and the DL system for the purpose of attack and / or hacking, thereby preventing them from gaining a statistical advantage over one another. Thus, blocks (408) can be utilized by such third party C. Furthermore, a counter (415) may be provided to count the node ratio.

[0023] FIG. 5 illustrates an exemplary computing system that may be useful for implementing the information deletion guarantee system disclosed herein. The operating environment and the exemplary hardware of FIG. 5 for implementing the described technology include a computing device such as a gaming console or computer (20), a mobile phone, a PDA, a set-top box, or a general-purpose computing device in the form of other types of computing devices. In the implementation of FIG. 5, for example, the computer (20) includes a processing unit (21), a system memory (22), and a system bus (23) (the system bus operably connects various system components, including connecting the system memory to the processing unit (21)). There may be only one or more processing units (21), and thus 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. The computer (20) may be a conventional computer, a distributed computer, or any other type of computer; its implementation is not so limited. The information deletion assurance system (IDAS) (502) may be implemented on the computer (20) to store code and perform one or more operations of the technology disclosed in this specification.

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

[0025] The hard disk drive (27), magnetic disk drive (28), and optical disk drive (30) are each connected to the system bus (23) by a hard disk drive interface (32), a magnetic disk drive interface (33), and an optical disk drive interface (34). The drives and their associated physical computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer (20). A person skilled in the art will know that any type of physical computer-readable media capable of storing data accessible by a computer, such as magnetic cassettes, flash memory cards, digital video discs, random access memory (RAMs), read-only memory (ROMs), etc., may be used in the example operating environment.

[0026] A number of program modules may be stored on the hard disk, magnetic disk (29), optical disk (31), ROM (24), or ROM (25), including an operating system (35), one or more application programs (36), other program modules (37), and program data (38). A user may input commands and information into the personal computer (20) through input devices such as a keyboard (40) and a positioning 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 broadcast receiving antenna, a scanner, etc. These and other input devices are commonly connected to the processing unit (21) via a serial port interface (46) connected to the system bus, but may also be connected via 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) via an interface such as a video adapter (48). In addition to the monitor, the computer typically includes other peripheral output devices (not shown), such as speakers and a printer.

[0027] The computer (20) may be operated in a networked environment using logical connections to one or more remote computers, such as a remote computer (49). These logical connections are made by a communication device connected to or part of the computer (20); the implementation is not limited to a specific type of communication device. The remote computer (49) may be another computer, server, router, network PC, client, peer device, or other network node, and may typically include many or all of the parts described above relating to the computer (20), although only the memory storage device (50) is shown in FIG. 2. The logical connections shown in FIG. 2 include a local area network (LAN) (51) and a wide area network (WAN) (52). Such network environments are common in all types of networks, such as local area networks, enterprise networks, internal computer networks, and the Internet.

[0028] When used in a LAN network environment, the computer (20) is connected to the local network (51) through a network interface or adapter (53), which is a type of communication device. When used in a WAN network environment, the computer (20) typically includes a modem (54), a network adapter, a type of communication device, or another type of communication device for establishing communication in a wide area network (52). The modem (54) may be internal or external and is connected to the system bus (23) through the serial port interface (46). In a networked environment, the program engine described for the personal computer (20) or a part thereof may be stored in the remote memory storage device. The illustrated network connection is an example, and it can be seen that other means and communication devices may be used to establish a communication connection between the computers.

[0029] FIGS. 6a-6d illustrate exemplary operations (600) of the Information Deletion and Disclosure Assurance System (IDDAS) disclosed herein. Specifically, the operations (600) create and store transactions on the DL in response to a party's view / download, sharing, or unsharing of one or more files. For example, Party A may share a file with Party B to disclose some content, and Party B may subsequently share the shared data with Party D. Party C is an unbiased curator of ledger transactions between Parties A, B, and D. Data disclosure transactions performed through the operations (600) are stored on the DL.

[0030] Specifically, the operation (600) enables the implementation of an Information Disclosure and Deletion Guarantee System (IDDAS), so that when Party A shares a document with another party to disclose content, the sharing is transacted as a sharing function on the DL. When the other party (recipient) views / downloads the shared content, a corresponding DL transaction is created. Subsequent views / downloads are pushed to the database for reference. At this time, if the data is never viewed, the content is not the responsibility of a future alternative recipient. The purpose of the IDAS is to reduce the legal liability of an entity / individual with responsibility for data deletion and the duty of explanation to the lowest possible level. Because the existence of a stored file to which the authorized recipient has access and the upload function are linked by the sharing function, the sharing function itself adds a level of nuance to the definition of legal liability meaning that the information is “deleted.”

[0031] The share / unshare functions of the management tool provided at this time generate a subset of a “soft” deletion protocol (non-store level overwrite) by simply removing the ability of a specific node to access previously shared and viewed information. Furthermore, from the perspective of a specific lower-level user node (an administrator’s employee), the unshare action constitutes a “deletion” for that node (the authorized node had access to the data and no longer does), and thus the share and unshare functions can be considered as defining the parameters of the “soft” deletion protocol. Accordingly, the share and unshare functions define a combination of tools that combine with the view function to complete the “soft” deletion, all of which are transactional on the DL. This is important because the IDAS is designed to ensure that all nodes receiving the authorized information ultimately no longer have access to the shared information.

[0032] These functions may be much more useful or advantageous than “hard” deletion in situations where a project enters a dormant phase and becomes active again among peer groups; and in B2B interactions (where the ability to “soft” delete the data multiple times satisfies the legal definition of deletion for a specific user / node, but avoids “hard” deletion, where distributed data is deleted from the repository and, in that case, the data can no longer be viewed by any user or node within the ledger relationship and network). For the business previously described as a project with an unpredictable timetable, this avoids the need to re-upload previous data or re-sign the ToS, etc., which would have been required due to data being completely removed from the repository if hard deletion had been used. Once the project is completely finished, hard deletion may occur as necessary upon the termination of the entire business relationship of the participating entities.

[0033] As used in FIGS. 6a-6d, a sub-managed user node is a description within a group of user nodes defined by its relationship to a “super manager” (not disclosed herein). For example, the super manager may be defined merely as a manager. For example, the super manager may have the ability to share shared data, while the sub-manager may not. Alternatively, the sub-manager may have the ability to view / consume shared data but may not have the ability to share shared data. This distinction is shown in FIGS. 6a-6d as necessary in the actual implementation of the said release function, particularly as its application is specifically defined in said release function.

[0034] In the context of Figures 6a-6d, when an individual shares data with an enterprise / company, the enterprise's data protection officer / super manager must share the shared data with lower-level employee sub-manager nodes within the enterprise and within the reasonable scope of B2B interactions to provide services requested and provided by the individual consumer user node. Therefore, from a user experience perspective, since it is tedious and illogical to force an individual user node, which can be multiple users of a single file, to unshare, the chaincode must clean this up. Furthermore, when the super manager unshares, all other nodes that shared the data with those designated as sub-managers are also automatically unshared.

[0035] At this time, with reference to FIGS. 6a-6d, operation (602) initializes one or more operations for the transaction. Such initialization may include initialization through a web / browser-based implementation or a non-browser-based application. One or more users, such as the user (111), may join the system in operation (604). These users (111) may participate in the IDAS as senders and receivers of data, data requests, etc. Operation (606) determines the identity status of these senders and receivers. Operation (608) determines the contract and service conditions (ToS) between various senders and receivers. Operation (610) creates a ToS transaction and uploads it to the DL. Operation (612) determines whether a data upload request has been received. Specifically, operation (612) may be regarding the data upload request having a related ToS. In that case, the operation (614) uploads the data and the hash of the data indexed for subsequent distribution to various nodes, such as the nodes (104, 106) of the DL. Additionally, in the operation (616), the sender or provider of the uploaded data shares the data with other designated recipients. For example, the designated recipient may be designated and assigned to registered users within the membership service application of the network by an identity management device using a username, email, user's computing device information, etc., or any other specified registration identifier.

[0036] Subsequently, operation (618) determines whether the recipient of the data is an administrator user who has permission to share and unshare data with other user nodes according to the ToS. If so, in operation (618b), the shared function transaction is hashed and added to the DL as an administrator designation. However, if not, in operation (618a), the shared function transaction is hashed and added to the DL as a non-administrator designation. Subsequently, operation (620) determines whether the shared data has been viewed by one or more recipients to whom the data was shared in operation (616). If so, operation (622) hashes and adds the transaction of the view of the designated data to the DL, and records all subsequent views of the data by the recipients in the user database. Specifically, such a user database continues to record views of the data of various users.

[0037] If the operation (620) determines whether the shared data has been viewed by a recipient from the operation (616), the operation (624) determines from the operation (618b) whether the administrator has shared the data with the sub-admin user node. If the answer is “yes,” the operation (626) hashes the shared function transaction with the sub-admin user designation and adds it to the DL. The operation (628) determines whether the shared data has been viewed by the sub-admin recipient. If the answer is “yes,” the operation (630) hashes the transaction of the view of the designated data with the DL and adds it, and records the subsequent view of the data by the sub-admin recipient in the user database.

[0038] However, if the determination by the above operation (624) is “No” and the determination by the above operation (628) is also “No,” the operation (632) determines whether the data sharing release operation was initialized by the recipient of the data from the above operation (614). If the answer is “Yes,” in the operation (633b), the recipient of the designated data releases the data, and the release function is transacted into the above DL. If the answer is “No,” in the operation (633a), the sender / provider of the data uploaded from the operation (614) releases the data from the designated user(s), and the release function may enter a grace period according to the above ToS.

[0039] Subsequently, operation (634) determines whether the sender / provider is an administrator from operation (618b). If the answer is “yes,” in operation (638c), the unshare function is transacted to a sub-administrator user node, hashed, and added to the DL. If the answer is “no,” operation (636) determines whether the designated user is an administrator from operation (618b). If the answer is “yes,” in operation (638a), the unshare function is transacted to a administrator user node, transacted to one or more sub-administrator nodes from operation (626), hashed, and added to the DL. If the answer is “no,” in operation (638b), the unshare function is transacted to a non-administrator (private) user node, hashed, and added to the DL.

[0040] In an example implementation, data and software or firmware for providing a search management system, various applications, a search context pipeline, a search service, a service, a local file index, a local or remote application content index, a provider API, a contextual application launcher, and other instructions and data may be stored in memory (22) and / or a storage device (29 or 31) and processed by the processing device (21).

[0041] Some embodiments may include a product. The product may include a physical storage medium for storing logic. Examples of the storage medium are one or more types of computer-readable storage media capable of storing electronic data, which include volatile or non-volatile memory, removable or non-removable, eraseable or non-erasable memory, writable or rewritable memory, etc. Examples of the logic may include various software components 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, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. In one embodiment, for example, the product may store executable computer program instructions that, when executed by a computer, enable the computer to perform methods and / or operations according to the embodiments described above. Any of the above executable computer program instructions may include code of a suitable type, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, etc. Any of the above executable computer program instructions may be implemented according to a predefined computer language, method, or grammar to instruct a computer to perform a specific function. Any of the above instructions may be implemented using a suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0042] The implementation described herein is implemented as a logical step in one or more computer systems. The logical operation may be implemented as (1) a sequence of steps implemented as a processor executing within one or more computer systems and (2) machine or circuit modules connected to each other within one or more computer systems. The implementation is optional and depends on the performance requirements of the computer systems used. Accordingly, the logical operation constituting the implementation described herein is referred to in various ways as an operation, a step, an object, or a module. Furthermore, the logical operation may be performed in any order unless explicitly otherwise claimed or a specific order is implicitly required by the claim language.

[0043] The foregoing specification, examples, and data provide a complete description of the use of the structure and exemplary implementation. Since many implementations may be made without departing from the spirit and scope of the claimed invention, the following enclosed claims define the invention. Furthermore, structural features of other examples may be combined in other implementations without departing from the claims described.

[0044] Embodiments of the present technology are disclosed herein in the context of an electronic market system. In the foregoing description, numerous specific details are presented for the purpose of explanation to provide a complete understanding of the invention. However, it will be apparent to those skilled in the art that the invention may be practiced without some of these specific details. For example, it should be understood that while various features are attributed to specific embodiments, features described in relation to one embodiment may also be incorporated into other embodiments. However, no single feature or characteristic of the described embodiment is considered essential to the invention, as other embodiments of the invention may omit such features by the same token.

[0045] For clarity, not all routine functions of the implementation described here are illustrated and explained. Of course, when developing such an actual implementation, numerous implementation-specific decisions must be made to achieve specific developer goals, such as compliance with application and business-related constraints, and it should be noted that specific goals vary from implementation to implementation and from developer to developer.

[0046] According to one 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 method may be executed as a programmed process executed on a processing circuit. The processing circuit may take the form of a number of combinations of processors and operating systems, connections and networks, data storage, or standalone devices. The process may be implemented as an instruction executed on such hardware, hardware alone, or any combination thereof. The software may be stored on a machine-readable program storage device.

[0047] According to 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 running on a data processing computer (the data processing computer is a personal computer, workstation computer, mainframe computer, or high-performance server running an operating system, and the operating system is Solaris® of Sun Microsystems, Inc., Santa Clara, California; Windows Vista™, Windows NT®, Windows XP PRO, and Windows® 2000 of Microsoft, Inc., Redmond, Washington; Apple OS X-based systems of Apple, Inc., Cupertino, California; or various versions of Unix operating systems such as Linux available from numerous vendors). The method may also be implemented in a computing environment comprising a multiprocessor system or various peripheral devices (the peripheral devices are input devices, output devices, displays, pointing devices, memory, storage devices, media interfaces for data transfer to and from processors, etc.). Additionally, such a computer system or computing environment may be networked locally, via the Internet, or through other networks. Various implementations may be used and may include different types of operating systems, computing platforms, computer programs, firmware, computer languages, and / or general-purpose machines. Additionally, a person skilled in the art will recognize that devices of a less general-purpose nature, such as devices embedded in hardware, field programmable gate arrays (FPGAs), and application-specific integrated circuits (ASICs), may also be used without departing from the scope and spirit of the inventive concept disclosed herein.

[0048] In the context of the present invention, the term “processor” refers to a physical computer (standalone or distributed) or a virtual machine (standalone or distributed) that processes or converts data. The processor may be implemented in hardware, software, firmware, or a combination thereof.

[0049] In the context of the present technology, the term “data storage” refers to hardware and / or software means or devices for storing digital or analog information or data locally or distributedly. The term “data storage” refers to devices such as, for example, Random Access Memory (RAM), Read-Only Memory (ROM), Dynamic Random Access Memory (DRAM), Static Dynamic Random Access Memory (SDRAM), Flash Memory, Hard Drive, Floppy Drive, Tape Drive, CD Drive, DVD Drive, Magnetic Tape Device (audio, visual, analog, digital, or a combination thereof), Optical Storage Device, Electrically Erasable Programmable Read-Only Memory (EEPROM), Solid State Memory Device, and Universal Serial Bus (USB) Storage Device. The term “data storage” also refers, for example, to databases, file systems, record systems, object-oriented databases, relational databases, SQL databases, audit trails and logs, program memory, caches and buffers, etc.

[0050] The foregoing specification, examples, and data provide a complete description of the use of the structure and exemplary implementation. Although various embodiments of the invention have been described in detail to a certain degree or by reference to one or more individual embodiments, a person skilled in the art can make many variations of the disclosed embodiments without departing from the scope or spirit of the invention. In particular, the described technology can be used independently of a personal computer. Other embodiments are therefore expected. All details shown in the drawings included in and accompanying the foregoing description are intended only to illustrate specific embodiments and are not limiting. Variations of details or structures may be made without departing from the basic elements of the invention as defined in the following claims.

Claims

Claim 1 A computer-implemented method for providing a guarantee regarding data deletion, wherein - the method is implemented by a plurality of computer-readable instructions stored in a non-transient computer-readable medium and executed by a computer processor - the method comprises: creating a distributed ledger (DL) transaction based on a deletion service condition (TOS) between a deletion guarantee provider and a plurality of clients; acknowledging the deletion TOS by a plurality of DL nodes; receiving a deletion request from one of the plurality of clients; acknowledging compliance of the deletion request with respect to the deletion TOS by the plurality of DL nodes; acknowledging the deletion request by the plurality of DL nodes; initializing a deletion operation; acknowledging the deletion operation by the plurality of DL nodes; and creating a transaction including the acknowledgment of the deletion operation. Claim 2 A method according to claim 1, wherein the step of approving the deletion request by the plurality of DL nodes further includes the step of broadcasting the deletion request to the plurality of DL nodes. Claim 3 In paragraph 2, the step of approving the deletion operation further includes the step of approving the deletion confirmation. Claim 4 A method according to claim 1, further comprising the step of storing the location of the data related to the deletion request. Claim 5 In claim 4, the step of creating a transaction including approval of the deletion operation further includes the step of creating the transaction including deletion TOS, clock data, and deletion confirmation. Claim 6 A method according to claim 1, further comprising the step of generating a sharing / unsharing DL transaction in response to the sharing or unsharing of data conditioned on the deletion TOS. Claim 7 In claim 6, the step of creating the sharing / unsharing DL transaction further includes the step of creating the sharing DL transaction, which includes the management designation of the party sharing or unsharing data conditioned on the deletion TOS. Claim 8 In claim 7, the step of creating the shared DL transaction further comprises the step of creating the shared DL transaction including the identity of the recipient of the data conditioned on the deletion TOS. Claim 9 A method according to claim 1, further comprising the step of generating a view DL transaction in response to a view of data conditioned on the deletion TOS. Claim 10 In claim 9, the step of creating the view DL transaction further includes the step of creating the view DL transaction, which includes the management designation of the party viewing the data subject to the deletion TOS. Claim 11 A method according to claim 1, wherein the deletion operation further includes the step of deleting the overwritten data after overwriting the data, and the step of approving the deletion operation further includes the step of approving the deletion of the overwritten data after overwriting the data. Claim 12 A method according to claim 1, wherein the step of generating a transaction including approval of the deletion operation further includes the step of generating a hash of metadata generated by said transaction to specify and distinguish multiple deletion requests from other transactions. Claim 13 A method implemented using a computing device, the method comprising: receiving a deletion service condition (TOS) between a deletion guarantee provider and a plurality of clients at a deletion guarantee user interface (UI) client implemented on a server; creating a distributed ledger (DL) transaction based on the deletion service condition (TOS) between the deletion guarantee provider and the plurality of clients; acknowledging the deletion TOS by a plurality of DL nodes; receiving a deletion request from one of the plurality of clients for deletion of data at the deletion guarantee UI client; acknowledging compliance of the deletion request for the deletion TOS; acknowledging the deletion request by the plurality of DL nodes; initializing a deletion operation—the deletion operation includes the step of overwriting the data before deleting the data—; acknowledging the deletion operation by the plurality of DL nodes; and creating a transaction including the acknowledgment of the deletion operation. Claim 14 In claim 13, the step of approving the deletion request by the plurality of DL nodes further comprises the step of broadcasting the deletion request to the plurality of DL nodes. Claim 15 In paragraph 14, the step of approving the deletion operation further includes the step of approving the deletion confirmation. Claim 16 In claim 13, the step of generating a transaction including approval of the deletion operation further comprises the step of generating a hash of metadata generated by said transaction to specify and distinguish multiple deletion requests from other transactions. Claim 17 A method according to claim 13, further comprising the step of generating a share / unshare DL transaction in response to the sharing or unshare of data conditioned on the deletion TOS. Claim 18 In claim 17, the step of creating the above-mentioned share / unshare DL transaction further comprises the step of creating the above-mentioned share DL transaction including the management designation of the party sharing or unshareing data conditioned on the above-mentioned deletion TOS. Claim 19 In claim 18, the step of creating the shared DL transaction further comprises the step of creating the shared DL transaction including the identity of the recipient of the data conditioned on the deletion TOS. Claim 20 A method according to claim 13, further comprising the step of generating a view DL transaction in response to a view of data conditioned on the deletion TOS.

Images