`
`CROSS-REFERENCE TO RELATED APPLICATIONS
`
`[0001]
`
`This application is a continuation of US. Application No. 15/640,211, filed on June
`
`30, 2017, which is a continuation of US. Application No. 15/136,347, filed on April 22, 2016,
`
`issued as US. Patent No. 9,729,390, which claims the benefit of US. Provisional Application
`
`No. 62/151,188, filed April 22, 2015, US. Provisional Application No. 62/193,927, filed July 17,
`
`2015, US. Provisional Application No. 62/193,930, filed July 17, 2015, and US. Provisional
`
`Application No. 62/214, 124, filed September 3, 2015, all of which are incorporated by reference
`
`herein.
`
`1.
`
`FIELD OF ART
`
`BACKGROUND
`
`[0002]
`
`The present invention generally relates to the field of computer networking and data
`
`storage and in particular to a network architecture for facilitating secure data exchange over a
`
`decentralized computer network and data storage architecture.
`
`2.
`
`BACKGROUND OF THE INVENTION
`
`[0003]
`
`The Internet (including the Web) enables users of computers to quickly and easily
`
`exchange data. There is a wide range of applications that leverage this ability to exchange data to
`
`achieve powerful results for individuals and enterprises alike. Examples include email, file
`
`sharing, home automation, entertainment, data management, and more.
`
`[0004]
`
`However, the way that data is exchanged over the Internet makes the data, and those
`
`who send the data, vulnerable to malicious actors. For instance, data moving between parties or
`
`
`
`stored on a remote server typically include information associated with the sender and the
`
`recipient. Accordingly, an interceptor of the data may associate the data with the parties. If the
`
`data contain sensitive information, it may leave the parties open to identity theft or other
`
`malicious acts. As a result, many users are discouraged from sharing important information via
`
`the Internet, thereby missing out on many of the advantages that are afforded to computer users.
`
`SUMMARY OF THE INVENTION
`
`[0005]
`
`According to embodiments of the invention, a method for performing an action
`
`responsive to detecting an event in a dead drop (DD) domain is described. The method includes
`
`monitoring, by a node in the DD domain, for an occurrence of a specified event within the DD
`
`domain. The method further includes detecting the occurrence of the specified event within the
`
`DD domain. The method further includes performing a specified action in response to detecting
`
`the occurrence of the specified event within the DD domain.
`
`[0006]
`
`According to embodiments of the invention, a system for exchanging data between a
`
`sender and a recipient is described. The system includes a processor for executing computer
`
`program instructions. The system also includes a non-transitory computer-readable storage
`
`medium storing computer program instructions executable by the processor to perform steps.
`
`The steps include monitoring, by a node in the DD domain, for an occurrence of a specified
`
`event within the DD domain. The steps further include detecting the occurrence of the specified
`
`event within the DD domain. The steps further include performing a specified action in response
`
`to detecting the occurrence of the specified event within the DD domain.
`
`[0007]
`
`According to embodiments of the invention, a non-transitory computer-readable
`
`storage medium storing computer program instructions for exchanging data between a sender
`
`and a recipient. The computer program instructions are executable to perform steps. The steps
`
`
`
`include monitoring, by a node in the DD domain, for an occurrence of a specified event within
`
`the DD domain. The steps further include detecting the occurrence of the specified event within
`
`the DD domain. The steps further include performing a specified action in response to detecting
`
`the occurrence of the specified event within the DD domain.
`
`BRIEF DESCRIPTION OF DRAWINGS
`
`[0008]
`
`FIG. 1 is a high-level block diagram illustrating an example of passing data using a
`
`dead drop network architecture according to one embodiment.
`
`[0009]
`
`FIG. 2 is a high-level block diagram illustrating a detailed view of the dead drop
`
`domain of FIG. 1 according to one embodiment.
`
`[0010]
`
`FIG. 3 is a high-level block diagram illustrating an example of a dead drop storage
`
`node according to one embodiment.
`
`[0011]
`
`FIG. 4 is a flowchart illustrating steps for using a dead drop to pass data from a
`
`sender to a recipient according to one embodiment.
`
`[0012]
`
`FIG. 5 is a flowchart illustrating steps for using a DD to monitor events and perform
`
`actions if an event is detected according to one embodiment.
`
`[0013]
`
`FIG. 6 is a high-level block diagram illustrating an example of two nodes establishing
`
`a direct connection according to one embodiment.
`
`[0014]
`
`FIG. 7 is a high-level block diagram illustrating physical components of a computer
`
`used as part or all of one or more of the entities described herein in one embodiment.
`
`DETAILED DESCRIPTION
`
`[0015]
`
`The Figures (FIGS.) and the following description describe certain embodiments by
`
`way of illustration only. One skilled in the art will readily recognize from the following
`
`
`
`description that alternative embodiments of the structures and methods illustrated herein may be
`
`employed without departing from the principles described herein. Reference will now be made
`
`to several embodiments, examples of which are illustrated in the accompanying figures.
`
`[0016]
`
`It is noted that wherever practicable similar or like reference numbers may be used in
`
`the figures and may indicate similar or like functionality. This description occasionally uses
`
`reference numbers in combination with letters to designate items illustrated in the figures.
`
`Herein, a reference number used without an accompanying letter (e.g., “150”) references any or
`
`all instances of the designated item, while a reference number used with an accompanying letter
`
`(e.g., “150A”) refers to the specific item designated with that label in the figure.
`
`[0017]
`
`FIG. 1 is a high-level block diagram illustrating an example of passing data using a
`
`dead drop network architecture according to one embodiment. FIG. 1 illustrates a recipient 110
`
`in communication with a sender 120 via a dead drop (DD) domain 130. FIG. 1 describes a
`
`unidirectional data pass between a single sender 120 and a single recipient llO. Embodiments
`
`can have multiple senders 120 and recipients llO engaged in bidirectional one-to-one and one-
`
`to-many communications.
`
`[0018]
`
`Briefly, the recipient 110 uses the DD domain 130 to establish a communication
`
`channel that can be used to pass data to the recipient. The recipient 110 provides the sender 120
`
`with a dead drop identifier (DDID) referencing a storage location within the DD domain. The
`
`sender 120, in turn, uses the DDID to pass data (e.g., send a message) to the recipient 110 via the
`
`DD domain 130. The data transmission from the sender 120 to the recipient 110 is secure in the
`
`sense that it is extremely difficult for a malicious actor or other third party to locate, intercept, or
`
`decipher the data. Thus, the DD network architecture is suited to communications where
`
`security and privacy concerns are paramount. In addition, the DD network architecture may be
`
`
`
`used to provide enhanced security for general purpose communications.
`
`[0019]
`
`In one embodiment, the recipient 110 includes software executing on a computer used
`
`by a user (e.g., a person) to perform tasks such as communicating with other users via the DD
`
`domain 130 or via other communication networks. For example, the recipient 110 may include
`
`software executing on a desktop, notebook, or tablet computer, or another electronic device with
`
`computer functionality, such as a mobile telephone, music player, television set-top-box, home
`
`automation component, industrial equipment or connected appliance. The recipient 110 may
`
`include an input device such as a keyboard or touch-sensitive display that allows for the input of
`
`data and an output device such as a display or speaker that allows for the output of data.
`
`Functionality enabling the recipient 110 to communicate via the DD domain 130 may be
`
`embedded into the hardware of the recipient 110 and/or included in software executed by the
`
`recipient l 10.
`
`[0020]
`
`Similarly, the sender 120 includes a computer used by a user to perform tasks
`
`including communicating with other users via the DD domain 130 or via other communication
`
`networks. The sender 120 may include the same components as the recipient 110. In fact, the
`
`sender 120 may act as a recipient 110 and vice versa, depending upon the direction of data flow
`
`in a given communication transaction. The users who respectively use the recipient 110 and
`
`sender 120 to communicate can be different people or the same person.
`
`[0021]
`
`The recipient 110 and sender 120 are connected to the DD domain 130 via respective
`
`communications links 150A, 150B. The communication links 150 may include network
`
`communication links using conventional computer networking technologies. For example, the
`
`communications links 150 may use wired or wireless network communications technologies
`
`such as the wired and wireless forms of Ethernet. Likewise, the communication links 150 may
`
`
`
`use other communications technologies designed to support communication with local
`
`peripherals, such as Universal Serial Bus (USB), Thunderbolt, Bluetooth, Personal Area
`
`Network (PAN), Serial ATA, infrared, heat signatures, and/or sound. The communications links
`
`150 may be encrypted using any encryption technologies such as secure sockets layer (S SL),
`
`transport layer security (TLS), HTTP Secure (HTTPS), virtual private networks (VPNs), Internet
`
`Protocol security (IPsec), etc. In another embodiment, communication uses custom and/or
`
`dedicated data communications technologies instead of, or in addition to, the ones described
`
`above.
`
`[0022]
`
`The DD domain 130 is a collection of one or more DD nodes 140 (labeled as nodes
`
`l4OA-L in FIG. 1). A DD node 140 includes functionality for acting in the DD domain 130 and
`
`a memory for storing data within the domain. A typical DD domain 130 includes many DD
`
`nodes 140. Each node 140 is connected to one or more other nodes via DD communication links
`
`160. The DD communication links 160 may use the same communication technologies as the
`
`communication links 150 used by the recipient 110 and sender 120 to connect to the DD domain
`
`130. In one embodiment, the DD nodes 140 and DD communication links 160 are arranged
`
`within the DD domain 130 such that every node is reachable by every other node. In another
`
`embodiment, the DD nodes 140 are logically or physically partitioned so that some nodes cannot
`
`reach other nodes. The path connecting two DD nodes 140 may pass through one or more
`
`intermediate nodes. In addition, the recipient 150A and sender 150B communication links
`
`respectively connect the recipient 110 and the sender 120 to at least one DD node 140 within the
`
`DD domain 130. The recipient 110 and sender 120 may also communicate with each other using
`
`other communication links that do not pass through the DD domain 130, such as a
`
`communications link 170.
`
`
`
`[0023]
`
`To receive data using the DD domain 130, the recipient llO sends a request to the DD
`
`domain 130 to create a DD on behalf of the recipient. A DD node 140 within the domain 130
`
`receives the create request and either services the request or selects another node to service the
`
`request. For example, the DD node 140 that receives the request may randomly select another
`
`node within the DD domain 130 and pass the request to the selected node. The random selection
`
`may occur in a manner such that the node that receives the request does not know which node
`
`ultimately services the request.
`
`[0024]
`
`The node 140 that services the request to create the DD establishes a DDID that
`
`uniquely identifies the created DD. In addition, the node 140 establishes a set of tokens
`
`associated with the DDID. A token describes the access rights a possessor of the token has with
`
`respect to the created DD. For example, an embodiment includes a read token giving a possessor
`
`of the token the right to read from the DD identified by the associated DDID and a write token
`
`giving the right to write to the DD identified by the associated DDID. The node 140 that
`
`services the request provides the DDID and the associated tokens to the recipient 110.
`
`[0025]
`
`The recipient llO typically stores the DDID and associated tokens in a secure
`
`manner. For example, the recipient 110 may store the DDID and tokens in an encrypted data
`
`store at the recipient. The recipient 110 provides the DDID and the write token to the sender 120
`
`via a communications link 170. This communications link 170 may be a secure or unsecure link,
`
`and may include communication over the Internet and/or dedicated communications links. For
`
`example, the recipient 110 may use encrypted or unencrypted email to send the DDID and write
`
`token to the sender 120. Alternatively, the recipient may use a different electronic
`
`communications technique, such as short-range wireless communications, or even use non-
`
`electronic techniques to exchange the information (e.g., a pen and paper). In one embodiment,
`
`
`
`the DDID and one or more tokens are combined and may be encrypted or encoded (e.g., by a
`
`hashing function) to form a single code. In this embodiment, the recipient 110 may share the
`
`code with the sender 120 instead of sharing the DDID and write token separately. The code may
`
`be decoded, for example by the sender 120 or at a DD node 140, to determine the DDID and
`
`token.
`
`[0026]
`
`In addition, the recipient 110 and sender 120 may choose to encrypt the data sent by
`
`the sender using one or more symmetric or asymmetric encryption techniques. The recipient 110
`
`and sender 120 may choose to exchange encryption keys, if necessary, at the same time the
`
`recipient 110 provides the DDID and write token to the sender 120. Alternatively, the recipient
`
`110 and sender 120 may exchange encryption keys at different times, may use encryption
`
`techniques that do not require a key exchange, or may choose not to encrypt the data. In one
`
`embodiment, the DD domain 130 itself is used to perform the key exchange needed to facilitate
`
`an encrypted communications link.
`
`[0027]
`
`The sender 120 uses the DDID and associated write token to send data to the recipient
`
`110. In one embodiment, the sender 120 sends a write request to the DD domain 130 that
`
`includes the DDID and the write token. In another embodiment, the write request includes the
`
`DDID and data representing the write token. The data representing the write token may be
`
`encrypted (e.g., by hashing, obfuscation, etc.). This request is received by an initial DD node 140
`
`in the DD domain 130. The receiving node 140 determines whether it has the DD identified by
`
`the DDID. If not, the receiving node 140 sends a message containing the DDID and the write
`
`token to the other nodes within DD domain 130. The node 140 storing the DD associated with
`
`the DDID receives the message and verifies the write token. If the token verifies, the node
`
`storing the DD creates a connection with the receiving node, which in turn has a connection with
`
`
`
`the sender 120. The sender 120 then writes the data to the node storing the DD associated with
`
`the DDID.
`
`[0028]
`
`Similarly, the recipient 110 uses the DDID and associated read token to read data
`
`from the DD. In one embodiment, the recipient llO sends a read request to the DD domain 130
`
`that includes the DDID and the read token. In another embodiment, the read request includes the
`
`DDID and data representing the read token. The data representing the read token may be
`
`encrypted (e.g., by hashing, obfuscation, etc.). This request is received by an initial DD node 140
`
`in the DD domain 130. The receiving node 140 determines whether it has the DD identified by
`
`the DDID. If not, the receiving node 140 broadcasts a message containing the DDID and the
`
`read token the other nodes within the DD domain 130. The node 140 storing the DD associated
`
`with the DDID receives the message and verifies the read token. If the token verifies, the node
`
`140 storing the DD creates a connection with the receiving node, which in turn has a connection
`
`with the recipient. The recipient 110 then reads the data from the node storing the DD associated
`
`with the DDID.
`
`[0029]
`
`Thus, the DD network architecture described above permits secure and private
`
`communications between the recipient 110 and the sender 120. The sender 120, and/or other
`
`parties possessing the DDID and write token can send data to the recipient. However, such
`
`parties cannot read the data from the DD. Moreover, a malicious actor who obtains access to one
`
`or more nodes 140 in the DD domain 130 may be able to obtain or read data stored in individual
`
`DDs. But the malicious actor cannot determine the intended recipients of the data because there
`
`is no mapping of DDIDs to recipients. For the same reason, the malicious actor cannot
`
`determine the path between a sender and a recipient. In addition, the data stored in the DDs may
`
`be encrypted.
`
`
`
`[0030]
`
`FIG. 2 is a high-level block diagram illustrating a detailed view of the DD domain
`
`130 of FIG. 1 according to one embodiment. As described above, the domain 130 typically
`
`includes multiple DD nodes 140 connected by DD communication links 160. The individual
`
`nodes 140 within the DD domain 130 may be formed of physically separate computers, such as a
`
`collection of geographically disparate computers. In addition, some or all of the nodes may be
`
`formed of virtual computers. For example, the nodes 140 of a domain 130 may be instances of
`
`virtual computers hosted in a cloud environment.
`
`[0031]
`
`Each DD node 140 has an associated set of characteristics that describe attributes of
`
`the node. The characteristics may describe the location of the node 140. The location may be
`
`specified as a geographic location. In addition, the location may be specified as a logical
`
`location (e.g., a “zone”). For example, the logical location may indicate that the node is
`
`associated with a particular enterprise (e.g., a business) or other group. The characteristics may
`
`also describe physical properties of the node, such as a node’s processing power, storage
`
`capacity, uptime, and the like.
`
`[0032]
`
`In one embodiment, the set of DD nodes 140 in a DD domain 130 may be divided
`
`into multiple subdomains, with each subdomain including a proper subset of nodes from the set
`
`of DD nodes in the DD domain. The subdomains to which a node 140 is member may be
`
`determined based on the characteristics of the node. For example, the DD domain 130 may
`
`include nodes 140 distributed over a wide geographic area (e.g., a country), and a subdomain
`
`may include nodes physically located within a smaller area (e.g., a state within the country).
`
`Similarly, the DD domain 130 may include nodes 140 associated with multiple enterprises, and a
`
`subdomain may include only nodes associated with one of the enterprises or a part of an
`
`enterprise.
`
`lO
`
`
`
`[0033]
`
`In one embodiment, the DD nodes 140 are arranged as a mesh network. Each node
`
`140 is connected to at least one other node via a DD communication link 160. Moreover, each
`
`node 140 maintains a routing table identifying the nodes to which it is connected. A node 140
`
`can send a message to another node by forwarding the message to the nodes to which it is
`
`connected. The nodes 140 that receive the message in turn forward the message to other nodes,
`
`until the message reaches the node to which it is directed. The path followed by the message is
`
`formed of hops from node 140 to node along the DD communication links 160.
`
`[0034]
`
`Consider the communications between the sender 120 and the recipient llO described
`
`in FIG. 1 in the context of FIG. 2. As shown in FIG. 2, the recipient 110 is connected to a node
`
`140A of the domain 130 via a communication link 150A. This node 140A serves as the point of
`
`ingress to the domain 130 for the recipient. The recipient llO sends a request to the ingress node
`
`140A of the domain 130 to create a DD on behalf of the recipient. This request may include
`
`domain information specifying a particular subdomain in which the DD should be created. For
`
`example, the domain information may specify that the DD should be created in a node 140
`
`located in a particular geographic area or managed by a particular enterprise.
`
`[0035]
`
`The node 140A serving as the point of ingress for the recipient 110 receives the create
`
`request and analyzes the domain information to identify the subdomain in which the DD should
`
`be created. In one embodiment, the node 140A services the request by randomly selecting a
`
`node within the specified subdomain that will host the DD. In one embodiment, random
`
`selection is performed using a load balancing technique, which may be performed by the node
`
`140A or by a separate computing device. In one embodiment, the node 140 services the request
`
`by randomly selecting a number of node hops for which the request will be forwarded, and
`
`randomly selecting another node within the specified subdomain to which the node 140A is
`
`ll
`
`
`
`connected. The ingress node 140A then forwards the request to the randomly selected node
`
`(e.g., node 140D) and also forwards the selected value for the number of node hops. The node
`
`140D to which the request was forwarded randomly selects another node (e.g., node 140E) in the
`
`subdomain from its routing table, decrements the value for the number of node hops, and
`
`forwards the request to the selected node. This selection, decrement, and forward process
`
`repeats until the value for the number of node hops reaches zero, at which point the final node
`
`establishes and hosts the DD associated with the request from the recipient 110. In one
`
`embodiment, each node that forwards the create request includes the path from the ingress node
`
`150A to the forwarding node with the request. The final node that creates the DD uses the path
`
`to identify and contact the ingress node 140A for the recipient 110. For example, the node 140
`
`may use the path to send the DDID and associated tokens to the ingress node 140A, so that the
`
`latter node can provide this information to the recipient.
`
`[0036]
`
`For example, assume the ingress node 140A receives a create request from the
`
`recipient 110, and also assume that the request specifies a subdomain encompassing nodes 140A,
`
`140D and 140E, as well as other nodes within the domain 130. Also assume the ingress node
`
`140A randomly selects “2” as the number of hops. The ingress node randomly selects a node
`
`(e.g., node 140D) from the specified subdomain in its routing table, decrements the hop value,
`
`and forwards the request and decremented hop value (e.g., “1”) to the selected node. That node
`
`140D, in turn, randomly selects another node (e.g., node 140E), decrements the hop value, and
`
`forwards the request and decremented hop value (e.g., “0”) to the selected node. The final node
`
`140E evaluates the hop value and determines that it is “0” and, therefore, creates the DD and
`
`associated tokens. The final node 140E then returns the DDID and tokens to the ingress node
`
`140A via the reverse of the path used to reach the final node.
`
`12
`
`
`
`[0037]
`
`Variations on the techniques described above may be used in some embodiments. In
`
`one embodiment, a node forwarding a request decrements the hop value only if the node is
`
`within the specified subdomain. This variation may be used, for example, in situations in which
`
`a node receiving a create request is not within the specified subdomain and/or connected to any
`
`other nodes in the subdomain. In this situation, the nodes may randomly forward the request to
`
`other nodes until a node within the specified subdomain receives the request, at which point the
`
`node in the subdomain decrements the hop value and forwards the request anew if the hop value
`
`is greater than zero or creates the DD and associated tokens if the hop value is zero.
`
`[0038]
`
`The sender 120, in turn, is connected to a different node l4OL that serves as the point
`
`of ingress for the sender to the domain 130 via a different communication link 150B. When the
`
`sender 120 makes a write request, the sender provides the DDID and write token to the sender’s
`
`ingress node l4OL. This node l4OL forwards the request including the DDID and write token to
`
`the other nodes in its routing table, and the other nodes continue to forward the request until it
`
`reaches the node having the DD associated with the DDID (e.g., node 140E). This node 140E
`
`verifies the token and establishes a connection with the sender’s ingress node l4OL using a
`
`return path created by the forwarding nodes. Alternatively, the node 140E may establish a direct
`
`connection with the sender 120. The sender 120 provides the data to be written to the ingress
`
`node l4OL, and that node forwards the data to the node 140E having the DD via the connection.
`
`A read request made by the recipient 110 is handled in a similar fashion in one embodiment,
`
`except that the recipient reads data from, rather than writes data to, the node 140E having the
`
`DD.
`
`[0039]
`
`FIG. 3 is a high-level block diagram illustrating an example of a DD node 140
`
`according to one embodiment. The node 140 includes a routing module 305, creation module
`
`13
`
`
`
`310, write module 3 15, read module 320, time-to-live (TTL) module 325, data control module
`
`330, delete module 335, notification module 340, geo-fence module 345, and data storage 390.
`
`Other embodiments may include different or other modules in other embodiments. In addition,
`
`the behaviors of the modules may differ in other embodiments.
`
`[0040]
`
`The data storage 390 stores data used by the node 140. The data may include data
`
`being maintained in DDs managed by the node 140, DDIDs and tokens associated with the DDs,
`
`and information used by the modules within the node 140 to perform the tasks described herein.
`
`Depending upon the embodiment, the data storage 390 may include one or more types of non-
`
`transitory computer-readable persistent storage media. For example, the data storage 390 may
`
`include a hard drive, solid-state memory device, and/or other form of persistent memory.
`
`[0041]
`
`Turning now to the individual modules within the node 140, the routing module 305
`
`routes messages received by node 140. As part of this task, an embodiment of the routing
`
`module 305 maintains the routing table for the node 140. The routing module 305 periodically
`
`communicates with other nodes 140 to which it is connected to ascertain information about those
`
`nodes. This information may include, for example, network addresses of the nodes, information
`
`about the subdomains with which the nodes 140 are associated, and the like. The routing module
`
`305 stores this information about the connected nodes in the routing table. In addition, the
`
`routing module 305 responds to routing table-related communications from routing modules 305
`
`of other nodes 140.
`
`[0042]
`
`The messages handled by the routing module 305 include messages related to create
`
`requests, write requests, read requests, and other types of messages and requests described
`
`herein. For a given message, the routing module 305 analyzes the message to determine whether
`
`to process the message locally on the node 140 or to route the message to another node in the
`
`14
`
`
`
`routing table. For example, upon receiving a create request from another node, the routing
`
`module 305 examines the hop value to determine whether it is greater than zero. If the hop value
`
`is greater than zero, the routing module 305 decrements the hop value, randomly selects a
`
`connected node in the routing table (subject to any specified subdomain constraints, if
`
`applicable), and forwards the request and decremented hop value to the selected node. If the hop
`
`value is zero, the routing module 305 provides the request to the creation module 310.
`
`[0043]
`
`Similarly, upon receiving a write request, the routing module 305 determines whether
`
`the DDID is associated with a DD maintained by the node 140. If the DDID is not associated
`
`with a DD maintained by the node 140, the routing module 305 forwards the request to other
`
`nodes in its routing table.
`
`If, on the other hand, the DDID is associated with a DD maintained by
`
`the node, the routing module 305 provides the request to the write module 315. The routing
`
`module 305 handles read requests, as well as other requests described herein, in the same
`
`fashion.
`
`[0044]
`
`The creation module 310 creates DDs in response to requests received by the node
`
`140. Upon receiving a create request from the routing module 305, the creation module 310
`
`generates a DDID to represent the DD for the request. In addition, the creation module 310
`
`generates a set of tokens associated with the DDID. The creation module 310 provides the
`
`DDID and tokens to the recipient l 10 that requested the DD using the path to the recipient’s
`
`ingress node 140A as described with respect to FIGS. 1 and 2.
`
`[0045]
`
`In one embodiment, the creation module 310 generates the DDID as a globally unique
`
`identifier (GUID). The DDID is a value represented using a large number of bits (e.g., a 128-bit
`
`value). A small portion of the bits may be fixed to identify the value as a DDID or encode other
`
`information, while the other bits are randomly generated by the creation module 310. The large
`
`15
`
`
`
`number of bits makes it extremely unlikely that the same DDID would be generated for multiple
`
`DDs. Therefore, each DDID is unique for practical purposes. The DDID may be represented as
`
`sequence of hexadecimal digits.
`
`[0046]
`
`In one embodiment, the tokens generated by the creation module 310 may include a
`
`write token, a read token, and an owner token. The write and read tokens respectively provide
`
`the bearer of the token the rights to write data to, and read data from, the DD associated with the
`
`DDID as described above. The owner token provides the bearer with administrative rights to the
`
`DD, such as the right to delete data within the DD or delete the entire DD.
`
`[0047]
`
`In one embodiment, a token, like the DDID, is a value represented using a large
`
`number of bits, some of which may be fixed and others of which are randomly generated by the
`
`creation module 310. The number of bits in each token may be fewer than the number of bits in
`
`the DDID. Each token associated with a particular DDID is unique with respect to other tokens
`
`associated with that DDID.
`
`[0048]
`
`The creation module 310 allocates space in the data storage 390 for the created DD
`
`and associates this space with the DDID. The amount of space, and the time when the space is
`
`allocated may vary in different embodiments. In one embodiment the creation module 310
`
`allocates a fixed amount of storage space for the DD when creating the DD. In another
`
`embodiment, the creation module 310 allocates the storage space later, when receiving data to
`
`store in the DD. Likewise, the amount of space allocated for the DD can vary in different
`
`embodiments.
`
`[0049]
`
`The write module 3 15 writes data to DDs in response to write requests received by
`
`the node 140. Upon receiving a write request from the routing module 305, the write module
`
`3 15 initially verifies the write token included in the request. The write module 3 l5 identifies the
`
`16
`
`
`
`DDID and write token included in the request, and compares the write token to the stored write
`
`token created by the creation module 310 for the DDID. If the compared write tokens do not
`
`match, the write module 315 denies the write request. Depending upon the embodiment, the
`
`write module 315 can deny the request by acting as if the request was not received (i.e., by not
`
`sending any messages in response to the write request) or by sending a message to the sender
`
`120 indicating that the write token is invalid.
`
`[0050]
`
`If the compared write tokens match, the write module 315 uses the return path in the
`
`write request to open a network connection with the ingress node 14OL for the sender 120. The
`
`write module 315 receives data from the sender of the write request, and writes the data to the
`
`storage allocated for the DD identified by the DDID. In one embodiment, the write module 315
`
`stores the data in a DD as a series of discrete messages, such that the data for each write request
`
`to a DD is saved as a logically separate message. The stored messages for the DD are organized
`
`in a queue or another data structure.
`
`[0051]
`
`The read module 320 reads data from DDs in response to read requests received by
`
`the node 140. Upon

Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ ChargeStill Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.

This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.

One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site