Reconstructable content objects

One embodiment of the present invention provides a system for delivering a content piece over a network using a set of reconstructable objects. During operation, the system obtains a metadata file that includes a set of rules; generates the set of reconstructable objects for the content piece based on the set of rules included in the metadata file; cryptographically signs the set of reconstructable objects to obtain a set of signed reconstructable objects; and delivers, over the network, the set of signed reconstructable objects along with the metadata file to a recipient, thereby enabling the recipient to extract and store a copy of the content piece and then to reconstruct the set of signed reconstructable objects from the stored copy of the content piece and the metadata file.

BACKGROUND

Field

The present disclosure relates generally to a content-centric network (CCN). More specifically, the present disclosure relates to a system and method for implementing reconstructable Content Objects in content-centric networks (CCNs).

Related Art

The proliferation of the Internet and e-commerce continues to fuel revolutionary changes in the network industry. Today, a significant number of information exchanges, from online movie viewing to daily news delivery, retail sales, and instant messaging, are conducted online. An increasing number of Internet applications are also becoming mobile. However, the current Internet operates on a largely location-based addressing scheme. The two most ubiquitous protocols, Internet Protocol (IP) and Ethernet protocol, are both based on end-host addresses. That is, a consumer of content can only receive the content by explicitly requesting the content from an address (e.g., IP address or Ethernet media access control (MAC) address) that is typically associated with a physical object or location. This restrictive addressing scheme is becoming progressively more inadequate for meeting the ever-changing network demands.

Recently, information-centric network (ICN) architectures have been proposed in the industry where content is directly named and addressed. Content-centric networking (CCN), an exemplary ICN architecture, brings a new approach to content transport. Instead of viewing network traffic at the application level as end-to-end conversations over which content travels, content is requested or returned based on its unique name, and the network is responsible for routing content from the provider to the consumer. Note that content includes data that can be transported in the communication system, including any form of data such as text, images, video, and/or audio. A consumer and a provider can be a person at a computer or an automated process inside or outside the CCN. A piece of content can refer to the entire content or a respective portion of the content. For example, a newspaper article might be represented by multiple pieces of content embodied as data packets. A piece of content can also be associated with metadata describing or augmenting the piece of content with information such as authentication data, creation date, content owner, etc.

In CCN, it is desirable that the intermediate node of the recipient of a content piece caches the received popular content to respond to future requests. However, the self-authentication nature of CCN requires that the content be stored in both the ready-to-use form and the Content Object form, resulting in storage of large sets of duplicated data.

SUMMARY

One embodiment of the present invention provides a system for delivering a content piece over a network using a set of reconstructable objects. During operation, the system obtains a metadata file that includes a set of rules; generates the set of reconstructable objects for the content piece based on the set of rules included in the metadata file; cryptographically signs the set of reconstructable objects to obtain a set of signed reconstructable objects; and delivers, over the network, the set of signed reconstructable objects along with the metadata file to a recipient, thereby enabling the recipient to extract and store a copy of the content piece and then to reconstruct the set of signed reconstructable objects from the stored copy of the content piece and the metadata file.

In a variation on this embodiment, the set of rules includes one or more of: a rule that specifies how to chunk the content piece, with a respective chunk of the content piece forming a payload of a corresponding reconstructable object; a rule that defines a naming convention; a rule that specifies a signing key; a rule that specifies whether to include a secure catalog; and a rule that specifies how to generate the secure catalog based on the set of reconstructable objects.

In a further variation, cryptographically signing the set of reconstructable objects involves using the specified signing key to sign each reconstructable object.

In a further variation, cryptographically signing the set of reconstructable objects involves using the specified signing key to sign the secure catalog.

In a variation on this embodiment, the network is a content-centric network (CCN), and the set of reconstructable objects conforms to a CCN standard.

One embodiment of the present invention provides a system for reconstructing a set of reconstructable objects representing a content piece. During operation, the system receives a set of signed reconstructable objects and an associated metadata file, extracts payloads and one or more signatures from the set of received signed reconstructable objects, assembles a copy of the content piece using the extracted payloads, stores the copy of the content piece, the metadata file, and the extracted one or more signatures. The system then discards the set of received signed reconstructable objects. In response to receiving a request for the content piece, the system reconstructs the set of signed reconstructable objects based on the copy of the content piece, the metadata file, and the extracted one or more signatures.

In a variation on this embodiment, the set of rules includes one or more of: a rule that specifies how to chunk the content piece, with a respective chunk of the content piece forming a payload of a corresponding reconstructable object; a rule that defines a naming convention; a rule that specifies a signing key; a rule that specifies whether to include a secure catalog; and a rule that specifies how to generate the secure catalog based on the set of reconstructable objects.

In a further variation, extracting the one or more signatures from the set of received signed reconstructable objects involves extracting a signature from each signed reconstructable object. The system further verifies the signature based on the specified signing key.

In a further variation, reconstructing the set of signed reconstructable objects involves inserting an extracted signature into each reconstructable object.

In a further variation, extracting the one or more signatures from the set of received signed reconstructable objects involves extracting a signature from the secure catalog. The system verifies the signature based on the specified signing key.

In a further variation, the system discards the secure catalog along with the set of received signed reconstructable objects. In response to receiving a request for the content piece, the system regenerates the secure catalog based on the rule that specifies how to generate the secure catalog.

In a further variation, reconstructing the set of signed reconstructable objects involves inserting an extracted signature into the regenerated secure catalog.

In a variation on this embodiment, the network is a content-centric network (CCN), wherein the set of reconstructable objects conforms to a CCN standard.

DETAILED DESCRIPTION

Overview

Embodiments of the present invention provide a system and method for implementing reconstructable Content Objects. More specifically, the system uses a set of metadata to describe how to publish the user data as Content Objects over the CCN networks. The metadata specifies the number of bytes included in each Content Object, the timestamps used, the convention for naming the Content Objects, and other parameters that may be included in the Content Objects. When a node publishes a piece of content over the network, it constructs a set of Content Objects based on a set of rules included in a metadata file, and creates a set of signatures, one for each Content Object. A first requester requesting the content piece receives the metadata file along with the Content Objects that contain the user data and the original publisher's signatures. Instead of storing all the Content Objects, the first requester extracts user data from the received Content Objects, and stores the extracted user data in a form that is ready to be used by an associated application. The requester also stores the received metadata and cryptographic signatures. When a different requester requests the content piece from the first requester, the first requester can reconstruct the original set of Content Objects based on the user data and information contained in the metadata, and pair the cryptographic signatures to corresponding Content Objects. The reconstructed Content Objects and the metadata file can be transmitted to the different requester, which can then use, store, and retransmit the user data when needed. In this way, embodiments of the present invention allow a node to store received content in its original form (without CCN headers) using minimum additional storage beyond the original file size while still being able to reproduce exactly the set of original Content Objects as published by the content publisher. Note that the phrase “reproduce exactly” means that the Content Objects are identical, down to their hash-based self-certified names.

In general, CCN uses two types of messages: Interests and Content Objects. An Interest carries the hierarchically structured variable-length identifier (HSVLI), also called the “name” or the “CCN name” of a Content Object and serves as a request for that object. If a network element (e.g., router) receives multiple Interests for the same name, it may aggregate those Interests. A network element along the path of the Interest with a matching Content Object may cache and return that object, satisfying the Interest. The Content Object follows the reverse path of the Interest to the origin(s) of the Interest. A Content Object contains, among other information, the same HSVLI, the object's payload, and cryptographic information used to bind the HSVLI to the payload.

The terms used in the present disclosure are generally defined as follows (but their interpretation is not limited to such):“HSVLI:” Hierarchically structured variable-length identifier, also called a Name. It is an ordered list of Name Components, which may be variable length octet strings. In human-readable form, it can be represented in a format such as ccnx:/path/part. Also the HSVLI may not be human-readable. As mentioned above, HSVLIs refer to content, and it is desirable that they be able to represent organizational structures for content and be at least partially meaningful to humans. An individual component of an HSVLI may have an arbitrary length. Furthermore, HSVLIs can have explicitly delimited components, can include any sequence of bytes, and are not limited to human-readable characters. A longest-prefix-match lookup is important in forwarding packets with HSVLIs. For example, an HSVLI indicating an Interest in “/parc/home/bob” will match both “/parc/home/bob/test.txt” and “/parc/home/bob/bar.txt.” The longest match, in terms of the number of name components, is considered the best because it is the most specific. Detailed descriptions of the HSVLIs can be found in U.S. Pat. No. 8,160,069, entitled “SYSTEM FOR FORWARDING A PACKET WITH A HIERARCHICHALLY STRUCTURED VARIABLE-LENGTH IDENTIFIER,” by inventors Van L. Jacobson and James D. Thornton, filed 23 Sep. 2009, the disclosure of which is incorporated herein by reference in its entirety.“Interest:” A request for a Content Object. The Interest specifies an HSVLI name prefix and other optional selectors that can be used to choose among multiple objects with the same name prefix. Any Content Object whose name matches the Interest name prefix (and optionally other requested parameters such as publisher key-ID match) satisfies the Interest.“Content Object:” A data object sent in response to an Interest. It has an HSVLI name and a Content payload that are bound together via a cryptographic signature. Optionally, all Content Objects have an implicit terminal name component made up of the SHA-256 digest of the Content Object. In one embodiment, the implicit digest is not transferred on the wire, but is computed at each hop, if needed. Note that the Content Object is not the same as a content component. A Content Object has a specifically defined structure under CCN protocol and its size is normally the size of a network packet (around 1500 bytes for wide area networks and 8000 bytes for local area networks and with fragmentation), whereas a content component is a general term used to refer to a file, which can be an embedded object of a web page. For example, a web page may include a number of embedded objects, such as image or video files. Each embedded object is a content component and may span multiple Content Objects.

As mentioned before, an HSVLI indicates a piece of content, is hierarchically structured, and includes contiguous components ordered from a most general level to a most specific level. The length of a respective HSVLI is not fixed. In content-centric networks, unlike a conventional IP network, a packet may be identified by an HSVLI. For example, “abcd/bob/papers/ccn/news” could be the name of the content and identifies the corresponding packet(s), i.e., the “news” article from the “ccn” collection of papers for a user named “Bob” at the organization named “ABCD.” To request a piece of content, a node expresses (e.g., broadcasts) an Interest in that content by the content's name. An Interest in a piece of content can be a query for the content according to the content's name or identifier. The content, if available in the network, is sent back from any node that stores the content to the requesting node. The routing infrastructure intelligently propagates the Interest to the prospective nodes that are likely to have the information and then carries available content back along the reverse path traversed by the Interest message. Essentially the Content Object follows the breadcrumbs left by the Interest message and thus reaches the requesting node.

FIG. 1illustrates an exemplary network architecture, in accordance with an embodiment of the present invention. In this example, a network180comprises nodes100-145. Each node in the network is coupled to one or more other nodes. Network connection185is an example of such a connection. The network connection is shown as a solid line, but each line could also represent sub-networks or super-networks, which can couple one node to another node. Network180can be content-centric, a local network, a super-network, or a sub-network. Each of these networks can be interconnected so that a node in one network can reach a node in other networks. The network connection can be broadband, wireless, telephonic, satellite, or any type of network connection. A node can be a computer system, an endpoint representing users, and/or a device that can generate Interest or originate content.

In accordance with an embodiment of the present invention, a consumer can generate an Interest for a piece of content and forward that Interest to a node in network180. The piece of content can be stored at a node in network180by a publisher or content provider, who can be located inside or outside the network. For example, inFIG. 1, the Interest in a piece of content originates at node105. If the content is not available at the node, the Interest flows to one or more nodes coupled to the first node. For example, inFIG. 1, the Interest flows (Interest flow150) to node115, which does not have the content available. Next, the Interest flows (Interest flow155) from node115to node125, which again does not have the content. The Interest then flows (Interest flow160) to node130, which does have the content available. The flow of the Content Object then retraces its path in reverse (content flows165,170, and175) until it reaches node105, where the content is delivered. Other processes such as authentication can be involved in the flow of content.

In network180, any number of intermediate nodes (nodes100-145) in the path between a content holder (node130) and the Interest generation node (node105) can participate in caching local copies of the content as it travels across the network. Caching reduces the network load for a second subscriber located in proximity to other subscribers by implicitly sharing access to the locally cached content.

Reconstructable Content Objects

In CCN, content flows through the network in the form of Content Objects, with each Content Object being a data packet having a well-defined format and size.FIG. 2presents a diagram illustrating an exemplary Content Object in content-centric networks (CCNs). InFIG. 2, Content Object200includes a name component202, a key-ID component204, an optional key component206, a payload component208, other components, and a signature component212. Name component202is a non-cryptographic user-assigned string, which can be an HSVLI in a human-readable form or a flat name. Key-ID component204identifies a public key used to sign Content Object200. The public key can be optionally included in Content Object200as key component206. Payload component208includes the user data. Content Object200may also include other components (not shown inFIG. 2), such as a timestamp field indicating the time of the last modification. Signature component212is a cryptographic signature that binds all other components in Content Object200. The signature can be generated using an RSA scheme. For example, the publisher of the content can generate the signature using its private key, which is verifiable using public key206. Note that, instead of signing all the bytes, the signature is usually generated by signing a hash of Content Object200(minus signature component212), shown as a signature hash210.

When a requester requests a content piece, such as a document, an image file, a video or audio file, or an application-specific data file, over the CCN, it often receives multiple Content Objects transmitted from the content provider, which can be the original content publisher or a node that stores a copy of the content piece. The payload of the received Content Objects contains the content data, with each Content Object containing a chunk of the data file. Upon receiving the multiple Content Objects, the requester, now the content receiver, needs to extract the content data from the Content Objects, assemble, and store the content data as a normal file in its original format on the local machine, such that the corresponding application can use the data file. For example, if the data file is a JPEG image file, the requester of the JPEG image file may receive multiple Content Objects with each Content Object carrying a portion of the JPEG image file in its payload. The receiver can then extract the portions of the JPEG image file from the received Content Objects, assemble the extracted portions into a complete JPEG image file, and store the assembled JPEG image file such that an image-reading application can open the JPEG image file to show the image.

On the other hand, in CCN, it is desirable that the content receiver also caches the Content Objects such that the content receiver may respond to future Interests for the content piece by returning the cached Content Objects. Note that, because the Content Objects are cryptographically signed by the original publisher, they need to be saved in their original forms so that future receivers of the content can verify the authenticity of the content by verifying those signatures. If the current receiver only keeps the payload of the Content Objects and throws away the wrappers (which can include the name, the key-ID/key, the signature, etc.), the current receiver cannot reconstitute those signatures. Even if the current receiver stores the signatures, they cannot be paired with the original Content Objects to enable the authentication process.

However, storing the Content Objects along with the user data means that the current content receiver, after it receives the content piece, needs to store the same content data in two different forms: one in the form of a normal data file that is application-ready and the other in the form of Content Objects. This creates undesired redundancy where a potentially large set of duplicated data is stored on the local system. To avoid this redundancy, in some embodiments of the present invention, the system delivers content as reconstructable Content Objects that allow a receiver to store the content in the application-ready format and reconstruct original Content Objects when re-transmitting the content to other nodes. In order to generate the reconstructable Content Objects, in some embodiments, a metadata file that includes a set of rules is implemented.

FIG. 3Apresents a diagram illustrating how a content publisher creates a set of reconstructable Content Objects for a content piece, in accordance with an embodiment of the present invention. InFIG. 3A, a publisher is publishing a data file302over the CCN network. To do so, the publisher needs to generate a plurality of Content Objects that conform to the CCN protocol and/or certain criteria defined by the publisher. In some embodiments, generating the plurality of Content Objects involves applying a set of rules included in a metadata file306. The rule set may specify how to chunk the original data file (such as how many bytes per chunk) and what to fill in all the fields of a Content Object. For example, the rule set may specify how to fill the creation-time field in a Content Object and when to use an end-of-segment field. Moreover, the rule set may specify the format of the names of the Content Objects. In some embodiments, all Content Objects may have a same CCN base name, and the CCN name for a particular Content Object can be the base name plus the corresponding chunk number. Additionally, the rule set may specify the signing key, and may specify whether to include the public key of the signing key in one or more Content Objects. In some embodiments, the rule set may specify that the first Content Object include a copy of the public key. Based on the set of rules included in metadata file306, the publisher generates an initial set of Content Objects for data file302, each Content Object including a chunk of data file302. For example, a Content Object310includes chunk 0 of data file302. Note that metadata file306may be a system default file, or a file generated by the content publisher in order to include a set of user-definable rules.

Subsequent to the generation of the initial set of Content Objects, the publisher cryptographically signs, using a signing key304, each Content Object, generating a set of signatures, such as a signature308. In some embodiments, signing key304may be a private signing key of a public/private key pair. In further embodiments, signing a Content Object may involve signing a hash value of the Content Object. Note that, once generated, a signature is included in the corresponding Content Object, being an actual part of the Content Object. To avoid ambiguity, a Content Object that includes the signature is also called a signed Content Object.

FIG. 3Bpresents a diagram illustrating an exemplary response to a content request, transferred over the network, in accordance with an embodiment of the present invention. More specifically, when the publisher of data file302responds to a set of Interests for Content Objects that represent data file302, the publisher transfers over the network these Content Objects along with metadata file306. In some embodiments, the signature for each Content Object is transferred together with the corresponding Content Object. For example, the Content Object that carries chunk 0 of data file302is combined with signature S0to form a signed Content Object312. Note that metadata306is transferred over the network in the form of CCN Content Objects as well, and may have been digitally signed by the content publisher.

Upon receiving metadata file306and the signed Content Objects, the receiver can authenticate the signed Content Objects by verifying the signatures. Subsequently, the receiver stores metadata306, and extracts and stores the payload and signature of each signed Content Object. Payloads from the plurality of Content Objects that represents data file302are assembled to form a copy of data file302in the form that is ready to be used by an appropriate application. For example, if data file302is a JPEG image file, the assembled file will be a copy of the JPEG image file. The signatures are stored separately from metadata file306and the copy of data file302. The receiver can then discard the received Content Objects. In other words, the recipient deconstructs each received Content Object by extracting and saving useful information (such as the payload and the catalog signature) while discarding redundant information (information that is included in the metadata file, such as the CCN name, the key-ID, and the secure catalog). This way, instead of storing content in both the user data form and the Content Object form, the content recipient only needs to store the content in its user data form along with the metadata file and the original signatures, thus significantly reducing the amount of storage space required for large content pieces. When the content receiver receives a request for the content, it can reassemble the original signed Content Objects, using information included in the metadata file and the signatures, and transfer the reassembled signed Content Objects over the network to the new content requester.

FIG. 3Cpresents a diagram illustrating how to reassemble the reconstructable Content Objects, in accordance with an embodiment of the present invention. InFIG. 3C, a device or a node stores a data file320, metadata file306, and a set of signatures associated with data file320. Note that data file320is a copy of original data file302, and is formed by extracting and assembling the payloads of a plurality of Content Objects representing data file302. Metadata file306is received along with the plurality of Content Objects representing data file302. The set of signatures is extracted from the plurality of signed Content Objects representing data file302, each signature corresponding to a Content Object.

Upon receiving a request for the content, the device reassembles a plurality of signed Content Objects. Note that, in order for future recipients of the Content Object to be able to verify the authenticity of those Content Objects, the reassembled signed Content Objects need to be exact copies of the original signed Content Objects received by the device. In some embodiments, to accomplish this, the device applies the set of rules included in metadata file306to data file320, generating an initial set of Content Objects with each Content Object corresponding to a chunk of data file320. Subsequently, the device inserts the signatures into their corresponding Content Objects to form the final set of signed Content Objects that is ready for transmission over the network. For example, the Content Object that contains chunk 0 of data file312is combined with S0to form a reassembled signed Content Object322, which is a copy of signed Content Object312. This final set of signed Content Objects can then be transmitted to the content requester along with metadata file306. Note that transmitting the metadata file along with the signed Content Objects allows any future recipient of the Content Objects to store only the application data along with the signatures and the metadata file, but still have the ability to reconstruct the original signed Content Objects. Note that the metadata file and the signatures only add a small amount of data to the original data file, and require significantly less storage compared with the need to store the entire set of Content Objects.

In some embodiments, instead of creating a cryptographic signature for each Content Object, the content publisher may use a secure catalog, also known as an Aggregated Signing Object, to authenticate the Content Objects. More specifically, the content publisher can create the secure catalog by aggregating the hash values (such as SHA-256 hashes) of the Content Objects, and then signing, using a private key, the secure catalog to create a catalog signature. In some embodiments, the secure catalog can be the concatenation of the cryptographic hash for each Content Object. Note that a rule that defines how to generate the secure catalog can be included in the metadata file.

FIG. 4Apresents a diagram illustrating how a content publisher creates a set of reconstructable Content Objects, in accordance with an embodiment of the present invention. InFIG. 4A, a publisher is publishing a data file402over the CCN network. Similar to what is shown inFIG. 3A, the publisher generates an initial set of Content Objects406based on a set of rules included in a metadata file404. Each Content Object includes a chunk of data file402. For example, a Content Object408includes chunk 0 of data file402. Subsequently, the publisher can generate, based on a secure-catalog rule included in metadata file404, a secure catalog410for initial set of Content Objects406. Note that secure catalog410can span multiple Content Objects. In the example shown inFIG. 4A, secure catalog410spans two Content Objects. The publisher then creates a catalog signature414by signing, using a signing key412, over secure catalog410. In some embodiments, signing key412is the private key of a public/private key pair, and an identifier that identifies the corresponding public key can be included in metadata file404. Note that, if secure catalog410spans multiple Content Objects, catalog signature414may include multiple signatures, one for each Content Object in secure catalog410. In general, given data file402, a metadata file404, and a signing key412, the content publisher generates a set of Content Objects representing data file402, a secure catalog410, and a catalog signature414.

FIG. 4Bpresents a diagram illustrating an exemplary response to a content request, transferred over the network, in accordance with an embodiment of the present invention. More specifically, when the publisher of data file402responds to a set of Interests for Content Objects that represent data file402, the publisher transfers over the network metadata file404, set of Content Objects406, secure catalog410, and catalog signature414. Note that if catalog signature414includes multiple signatures, each for an individual Content Object in secure catalog410, the publisher may insert each signature into its corresponding Content Object, creating a signed secure-catalog Content Object. By verifying catalog signature414, a recipient can first authenticate secure catalog410, and then use secure catalog410to authenticate the plurality of Content Objects within set of Content Objects406.

Once the authentication is completed, the recipient can store metadata file404, extract and store the payload of each Content Object within set of Content Objects406, and store catalog signature414. Payloads from the plurality of Content Objects within set of Content Objects406are assembled to form data file420, which is a copy of original data file402. The recipient can then discard the received set of Content Objects406and secure catalog410. In other words, the recipient deconstructs each received Content Object by extracting and saving useful information (such as the payload and the catalog signature), while discarding redundant information (information that is included in the metadata file, such as the CCN name, the key-ID, and the secure catalog). This way, instead of storing content in both the user data form and the Content Object form, the content recipient only needs to store the content in its user data form along with the metadata file and the signature for the secure catalog. Note that compared with the set of signatures for all Content Objects, the signature for the secure catalog occupies less storage space. Note that because the rule to generate the secure catalog is included in the metadata file, the recipient does not need to store the secure catalog itself. When this content recipient receives a request for the content, it can reassemble the original set of Content Objects and the signed secure-catalog Content Objects, using information included in the metadata file and the catalog signature, and forward the reassembled Content Object set and the signed secure-catalog Content Objects over the network to the new content requester.

FIG. 4Cpresents a diagram illustrating how to reassemble the reconstructable Content Objects along with the secure catalog, in accordance with an embodiment of the present invention. InFIG. 4C, a device or a node stores a data file420, metadata file404, and a catalog signature414associated with data file420. Note that data file420is a copy of original data file402, and is formed by extracting and assembling the payloads of Content Objects within set of Content Objects406. Metadata file404is received along with the set of Content Objects406. Catalog signature414can be extracted from the signed secure-catalog Content Objects.

Upon receiving a request for the content, the device reassembles a plurality of Content Objects using data file420and metadata404. In some embodiments, to accomplish this, the device applies a set of rules included in metadata file404to data file420, generating a set of Content Objects with each Content Object corresponding to a chunk of data file420. The device also generates a secure catalog based on the generated set of Content Objects and one or more rules included in metadata file404. Subsequently, the device combines catalog signature414with the generated secure catalog to form the signed secure-catalog Content Objects, that are ready to be transmitted along with the set of Content Objects and the metadata. Similar to the example shown inFIG. 3C, the reconstructed Content Objects and signed secure-catalog Content Objects are exact copies of the received Content Objects representing the data file and the received signed secure-catalog Content Objects. No authentication information is lost during the reconstruction process.

FIG. 5presents a flowchart illustrating a process of creating a set of reconstructable Content Objects, in accordance with an embodiment of the present invention. During operation, a content publisher obtains a to-be-published content piece (operation502). The publisher then creates or obtains a metadata file that includes a set of rules for constructing Content Objects (operation504). In some embodiments, the set of rules may specify how to chunk the original data file (such as how many bytes per chunk), what to fill in all the fields of a Content Object, and the key(s) used to sign the Content Objects. Based on the rules, the publisher creates a set of initial Content Objects (operation506). The publisher can then optionally create a secure catalog based on the initial Content Objects (operation508). The publisher then generates one or more signatures by signing the Content Objects or, if possible, the secure catalog (operation510). In response to a request for the content, the publisher transfers the metadata file, the signed Content Objects and, if possible, the signed secure-catalog Content Objects over the network (operation512).

FIG. 6presents a flowchart illustrating a process of storing a content piece and reconstruction information associated with the content piece, in accordance with an embodiment of the present invention. During operation, a device or a node receives, over the network, a metadata file, a plurality of Content Objects, and possibly one or more signed secure-catalog Content Objects (operation602). The device extracts payload and signature (if any) fields from each Content Object (operation604), and reassembles a data file using the extracted payloads (operation606). Note that the reassembled data file can be ready to be used by an appropriate application. Note that, if there are signed secure-catalog Content Objects, the system extracts the catalog signature from the secure-catalog Content Objects. Subsequently, the device stores the metadata file, the data file, and the extracted signature(s) (operation608), and discards the received Content Objects and, if any, the signed secure-catalog Content Objects (operation610).

FIG. 7presents a flowchart illustrating a process of reconstructing a set of Content Objects associated with a content piece, in accordance with an embodiment of the present invention. During operation, a device or a node that stores a content piece receives a request for the content piece (operation702). Note that this device is not the publisher of the original content piece, and the content piece is stored in a form that is ready to be used by an application as a data file. In response to the request, the device accesses a metadata file that stores a set of rules (operation704), and constructs a set of initial Content Objects by applying the rules to the data file (operation706). Note that the metadata file is received by the device along with the content piece, and specifies how to chunk the data file and how to fill in the various fields within each Content Object. Each data file chunk can be the payload of each Content Object. The device may optionally compute a secure catalog based on the initial set of Content Objects (operation708). In some embodiments, the rules that govern the computation of the secure catalog are also stored in the metadata file. Subsequently, the device inserts the original publisher's signatures into appropriate Content Objects to form signed Content Objects (operation710). Note that when the secure catalog is used, the device inserts a catalog signature into the secure-catalog Content Object to form a signed secure-catalog Content Object.

Note that optionally the original publisher may not send out meta data, and the receiving node may only receive regular Content Objects (non-reconstructable Content Objects). In such a situation, the receiving node that implements reconstructable Content Objects may infer the metadata from the received Content Objects, and create its own metadata on-the-fly. Similar to the process shown inFIG. 6, the receiving node stores the newly created metadata along with the data file containing the extracted payload of the Content Objects. When retransmitting the data file, this node may or may not include the newly created metadata. If the node chooses not to include the newly created metadata, subsequent receiving nodes would need to create their own metadata. If the node chooses to include the newly created metadata, it should include it in such a way that does not change the original signatures (stored separately from the payload) or the self-certified names of the reconstructed Content Objects. In some embodiments, this node can include a header in the unsigned part of the Content Objects to indicate that the metadata is available via a given link or that the metadata is embedded in the header (if enough space is provided).

Computer and Communication System

FIG. 8illustrates an exemplary system that implements reconstructable Content Objects, in accordance with an embodiment of the present invention. A system800that implements reconstructable Content Objects comprises a processor810, a memory820, and a storage830. Storage830typically stores instructions that can be loaded into memory820and executed by processor810to perform the methods mentioned above. In one embodiment, the instructions in storage830can implement a metadata transmitting/receiving module832, a Content Object construction/deconstruction module834, a Content Object transmitting/receiving module836, and a signature insertion/extraction module838, all of which can communication with each other through various means.

In some embodiments, modules832,834,836, and838can be partially or entirely implemented in hardware and can be part of processor810. Further, in some embodiments, the system may not include a separate processor and memory. Instead, in addition to performing their specific tasks, modules832,834,836, and838, either separately or in concert, may be part of general- or special-purpose computation engines.

Storage830stores programs to be executed by processor810. Specifically, storage830stores a program that implements a system (application) for enabling all-in-one content download. During operation, the application program can be loaded from storage830into memory820and executed by processor810. As a result, system800can perform the functions described above. System800can be coupled to an optional display880(which can be a touch screen display), keyboard860, and pointing device870, and can also be coupled via one or more network interfaces to network882.