WO2014207551A2

WO2014207551A2 - Social router

Info

Publication number: WO2014207551A2
Application number: PCT/IB2014/001443
Authority: WO
Inventors: Bertrand WEBER; Ian KU; Sergio Catanzariti
Original assignee: Orange
Priority date: 2013-06-28
Filing date: 2014-06-25
Publication date: 2014-12-31
Also published as: WO2014207551A3

Abstract

A method is provided for requesting specific content by a user in a Content Centric Network comprising a plurality of CCN nodes, each node comprising a Forwarding Information Base populated using a prefix based routing protocol, each prefix comprising one or more names used for the routing in the CCN, the method comprising a user device CCN node: issuing an interest request command destined to the designated router, using a content request prefix formed with the name designated router, the username of the user and the content name, the request command being inserted in the content request prefix between the router name and the username; and receiving from the designated router a data content prefix to be used by the user device, the data content prefix comprising the designated router and the content name.

Description

SOCIAL ROUTER

BACKGROUND

[0001] The Internet and related search engines have made it possible for individuals to acquire information and establish relationships that were impossible only a decade or two ago. This has also been a boon for marketing, since there are now unprecedented ways of hooking consumers up with potential products that may be of interest to them.

[0002] However, existing search engines and recommendation engines have certain limitations. For example, in Google's® web utilities, everything starts with a search— a user searches for news or for a product/service. If the user wants to learn about something or decide which product/service to purchase, they use a search utility like Google to do so. But existing search engines are not optimal, and can be revised to enhance their results in order to better anticipate the user's intentions. Users want information to be more relevant and would like it quickly. Existing search engines are not yet like personal assistants that are able to provide relevant content or information regarding the user. Search engines are currently limited in the amount of information regarding their users that they can utilize, and are not

localized/personalized to the extent possible.

SOCIAL NETWORKING

[0003] YouTube currently has a great deal of content, and users can search for content, but YouTube can lack in helping users to find the content they want to watch, despite recent redesigns to highlight content that is relevant to its users. One redesign permits users to select channels that interest them, and then they will be shown new videos relevant to that interest. However, it is still difficult for people to find more relevant content of interest. YouTube lacks, to some extent, more robust tools for content discovery and recommendation, i.e., once users have selected channels that they would like to subscribe to, it is difficult to find new content that might be relevant to their interests.

[0004] Facebook^® takes a different approach. Using Facebook, rather than searching for a news article, the user waits for friends to tell the user what to read. Friends tell other friends what movies they enjoyed, what brands they like, where to eat, etc.

[0005] But keeping track of the rapidly provided deluge of news, stories, photos, and other information shared on social networks and other sources is a very complex task. One study showed the average social network user now receives eight hundred links per day. This makes it difficult for users to keep up, and therefore, it is desirable to provide a better solution for users to find relevant content and information they are really interested in.

[0006] Other social networking applications, such as Show You,^® address content socialization aspects by offering certain social features. In response to a user signing in to Show You with their Facebook or Twitter account, this application will fetch all of the videos posted by friends and gather them in a single place. Once the user has logged in, he/she sees a large grid of videos taken from their social networks and other sources. Show You is designed for the user to follow "content curators" belonging to their social circle.

CONTENT-CENTRIC NETWORKING (CCN)

[0007] The Palo Alto Research Center (PARC) developed a technology called Content Centric Networking (CCN), which is a new type of distributed network architecture. CCN differs from traditional IP-based routing in that a routing decision is made based on the data being transmitted rather than any routing information attached to it.

[0008] With CCN, one can get any content by using its name. There is no need to know the location of the content (e.g., the URL, the server where it is located) and then establish a connection to a specific server. Also, each CCN node has a local cache and can store data that passes through it. An Internet Protocol (IP)-based router cannot do that on its own. In CCN, content can then be cached on any CCN node and delivered to the end user from the most appropriate node depending on the location of the requesting user.

[0009] In CCN, there are 2 types of packets: 1) an Interest packet— this contains the name prefix of the requested data; and 2) a Data packet— this contains the name prefix of the data and the actual requested data. To request the desired data, the user sends an interest packet. When the interest reaches a node that has the desired data, a data packet is sent back to the user. Both the interest and data packets contain the name prefix of the data, but not its location. There is no identification of the user or device that requested the data. To send the data back to the user, the data packet uses the reverse path of the interest packets. The interest packets leaves what is called, in CCN parlance, "breadcrumbs" on the CCN nodes (each time it is forwarded) so it is possible to trace back where the interest originated from.

[0010] A CCN node contains several components that will allow the previous operation to happen: 1) a Content Store (CS)— this caches data packets that have passed through a node; 2) a Pending Interest Table (PIT)— each entry of this table contains the name prefix of the interest and a set of interfaces on the node from which the matching interests have been received; and 3) a Forwarding Information Base (FIB)— this is populated by a name-based routing protocol, and enables interest packets to be routed to the right interface(s). The FIB is primarily a local routing table on a specific CCN node. It matches name prefixes with a list of outgoing face(s) in order to be able to route an incoming interest to the right face(s).

[0011] Content requests are sent using Interest packets, which specify the prefix of the name of the desired content. Interests are forwarded hop-by-hop based on their name prefixes towards content sources using the FIB at each node. Along their paths towards content sources, interests leave a trail of pending interest entries stored in the PIT on each node. These "breadcrumbs" prevent interest loops and define the return path for the replies. Timeouts and error conditions may be handled by native CCN mechanisms.

[0012] When the interest reaches a source of content (original producer or cached copy), the network forwards the data packets back along the path taken by the Interests that requested them. Corresponding pending interests are deleted in the PIT as data is transmitted to the user. Content reaches the requesting user and is not sent where it was not requested.

CONTENT NAMING

[0013] Names are hierarchically structured with any number of components. Each component is an arbitrary number of octets (as long as the name is not too long). CCN names are hierarchical, consisting of a series of delimited components (length-annotated bit-strings for instance). There has to be agreements on the structure of the names for a particular service like the social router. Names are independent of the location of the node where the content could be found.

[0014] Names are constructible, meaning that it is possible to construct the name of content without having been given the name up front. Algorithms can provide the names so that the source and user can arrive at the same name based on parameters available to both.

[0015] Technical documentation for CCN can be found in the documentation downloaded from http://w xcnx.org/release^ and associated linked pages, the documents from this address and those links on this page downloaded on June 27, 2013, being herein incorporated by reference as "CCNx Technical Documentation". SUMMARY

[0016] The following acronyms are used throughout this disclosure.

ACRONYM TABLE

API application program interface

CCN content centric networking

FIB forwarding information base

IGP interior gateway protocol

IS-IS intermediate system - intermediate system

LSA link-state advertisement

PARC Palo Alto Research Center

PIT pending interest table

[0017] Disclosed herein is a system and method that permits the management of usernames and user-focused transactions in a CCN, despite the fact that CCN possesses no inherent mechanisms for doing so. In various embodiments of the invention, each node in a CCN has a routing table, i.e., a Forwarding Information Base (FIB), populated using a name- or prefix- based routing protocol. The FIB enables interest and data packets to be routed to the right interface(s).

[0018] When a device connects to the network, a social router client application registers the user name prefix. A userjd or username has to match exactly the real id of the user in a particular social network's graph, otherwise the SR cannot use the social networks graph and find relevant information about the user.

[0019] CCN prefixes are typically configured manually and registered by applications locally in the FIB. The protocol that local apps use to register prefixes with their own ccnd is documented in: http://www.ccnx.org/releases/latest/doc/technical/Registration.txt. In a CCN self-registration protocol, clients can register the prefixes for interests they wish to receive using a specific "face" on the CCN node (discussed in more detail below). Each prefix can then be disseminated using the least common denominator (of a hierarchical structure). [0020] The user device, aware of this registration, will then issue an interest command. The command will be inserted between the social router name and the username (e.g.,

/socialrouter/get/username/contentA). The social router is configured to extract the command, and, based on the command, issue a prefix to be used by the user device when requesting content (e.g., /socialrouter/get/username/contentA).

[0021] In sum, disclosed herein is a system that recommends and forwards to users more focused and personalized content of interest. The system takes into account different types of criteria to provide relevant and recommended content. It can recommend live or on-demand content and in various formats (text, photo, video, etc.). It can further interact with users through a website or an application. In general terms, it integrates more of a social context into networking communications.

[0022] A method is provided for requesting specific content by a user in a Content Centric Network, the CCN comprising a plurality of CCN nodes, each node comprising a Forwarding Information Base populated using a prefix based routing protocol, each prefix comprising one or more names used for the routing in the CCN, the user being defined by a user name associated with a specific social network, the method comprising a user device CCN node: registering in the FIB of a user CCN node a user CCN prefix comprising the name of a designated router and the username of the user, for subsequent dissemination by said user CCN node of the user CCN prefix, the dissemination including the designated router; disseminating the user CCN prefix via preexisting CCN protocols to the designated router; issuing an interest request command destined to the designated router, using a content request prefix formed with the name designated router, the username of the user and the content name, the request command being inserted in the content request prefix between the router name and the username; and receiving from the designated router a data content prefix to be used by the user device, the data content prefix comprising the designated router and the content name.

[0023] A method is also provided for recommending content to a user in a Content Centric Network, the CCN comprising a plurality of nodes, each node comprising a Forwarding Information Base populated using a prefix based routing protocol, each prefix comprising one or more names used for the routing in the CCN, the user being defined by a user name, the method comprising, for a designated router: receiving from a user CCN node a user prefix comprising the name of the designated router, and the username of the user; storing the user prefix in the in the FIB of the designated router; receiving a content request prefix addressed to the designated router, the prefix comprising the name of the designated router, the username of the user in a social network and a content name, a request command being inserted in the prefix between the router name and the username; identifying that the received content prefix is a request for content from the user by comparing the received content prefix and the stored user prefixes in the social router FIB of the designated router, and extracting the request command; and returning to the user the prefix to be used by the user device to request content, the prefix comprising the designated router and the content name.

[0024] A non-transitory computer program product is also provided, comprising a computer usable medium having a computer readable program code embodied therein, said computer readable program code adapted to be executed to implement the methods disclosed herein.

DESCRIPTION OF THE DRAWINGS

[0025] The following drawings illustrate various embodiments of the invention.

Figure 1 is a high level block diagram illustrating a plurality of users associated with (having an interest in) a data collection comprising various content;

Figure 2 is a block diagram illustrating social router system components;

Figure 3 is a data flow sequence diagram illustrating a user registering with the social router server;

Figure 4 is a data flow sequence diagram illustrating the basic flow of an interest and its responding data result; and

Figure 5 is a data flow sequence diagram illustrating the flow of information triggered by a user's request for content within or associated with the social router.

DETAILED DESCRIPTION

[0026] Exemplary embodiments of the social router system are described in more detail below. However, the following assumptions are made:

1) the social router is an application running on CCN nodes;

2) the system contains both a social router client-side application and a server-side application; 3) a social router client runs on end user machines;

4) a social router server runs on CCN nodes on the network;

5) a specific naming convention is used for the social router (names have a specific format);

6) users know the prefix of the social router (e.g., /socialrouter or /sr in the figures);

7) contents are grouped by collections (content names include the name of the

collection followed by the content name (e.g., /colll/contA in the figures)— the content name can contain a version identifier;

8) when published using known techniques in CCN, the content prefix is advertised (e.g., /socialrouter/collection_name/content_name, or /sr/colll/contA in the figures);

9) users subscribe to collections of contents that they are interested in. The social router keeps track in real time of which collections users have subscribed to in a database (e.g., /userl/colll; /user2/colll; user3/colll);

10) the social router can prevent the looping of the recommendation (e.g., when userl recommends a content to user2, then user2 will not recommend the same content to userl). The recommending is automatic— the social router server recommends a particular content watched, e.g., by userl to user 2. The recommending is done when, e.g., the rpc_get command (discussed below) is used; and

11) the social router can access the user's social graph information (using APIs) by either the social client or server.

SOCIAL-BASED INFORMATION TO BE USED

[0027] The system described herein utilizes social network application program interfaces (APIs) to allow access to information about social network members and various connections among them. These APIs provide a real-time view of the social graph and give some information about different types of objects (e.g. people, photos, events, etc.) and connections between them (e.g. relationships, tags, etc.). The system can learn a lot of things about users by using these APIs: for instance, how people and objects interact with each other in real-time, or actions (such as watch, listen, and read). Members/users of the social network express their passions and hobbies on social networks, and they can create a lot of social information when they "like" a product or update their status.

[0028] This system determines whether a user is a member of the social network and then obtains information about the member and the member's connections within the social network. It then uses this information from the social network to enhance the user's experience and recommend more relevant and personalized content. The system recommending content may also take into account the status and location information of the user. It utilizes CCN to determine what kind of content the user has looked at recently or is interested in real-time. This is done by looking at the interests for specific content generated by the user on the network in a specific time interval (e.g., the last twenty-four hours). This is done at a network level and not at an application level.

[0029] The system relates to an architecture arranged to support social and network-based recommendation over a network infrastructure. A group of users sharing the same interest can be identified based on social profiles and interests generated by the users. Content collections can be built around sports, food, fashion, etc.

[0030] Legacy search engines, such as Google, can be useful when the intent of a search is to return a broad array of data related to a given definable topic. Such search systems look for content that already exists on the web prior to the time of search. However, advantageously, the system described herein can recommend content as it is generated. When a content owner or user publishes a new piece of content matching particular interests, the system recommends and forwards the content to the members of the community in a real-time fashion.

[0031] This system can take into account how many times contents are shared (popularity) and the importance of the friend / news source that shared the link. This social and network- aware system can look at the information about a user's environment, activities, connections, and preferences to improve the content recommendation with that end user or object. It can anticipate the user's needs, and proactively serves up the most appropriate and customized content.

[0032] Figure 1 illustrates the relationships of users Ul, U2, U3 to a collection COL1 of information for content A CONA, content B CONB and content C CONC. The contents CONx are grouped into various collections COLx, and users Ux subscribe to collections of content that they are interested in. The system, described in more detail below, maintains a database that correlates the users and the collections of contents. Figure 1 illustrates a situation in which three users Ul, U2, and U3 are have subscribed to the content of collection 1 COL1 which comprises content A CONA, content B CONB and content C CONC.

[0033] Figure 2 is a block diagram of the social router logical structure and node design. In this Figure, a user CCN node 35' device of both users and applications 10, as part of a CCN node 35' can interact with a social network 20, such as Facebook,^® Linkedln,^® etc. (herein, a social network router, i.e., a specific node, is also identified with ref. char. 20), as well as a content centric network (CCN) infrastructure 80 that includes access to a social router server 40 as part of another CCN node 35. The CCN nodes 35, 35' contain the Pending Interest Table (PIT) 37 and Forwarding Information Base (FIB) 39 (i.e., the routing table) as well as a content store CS 38. Both the social router client 95 and social router server 40 have a PIT 37, a FIB 39, and a content store CS 38, because they are both CCN nodes (as is the content server 75). At the heart of the social router server 40 is the social router engine 60 that runs algorithm(s) associated with the social router server 40. The interfaces to the social router engine 60 are through a variety of application program interfaces (APIs) 30, 50, 90 that middleware of the social router 60 exports. These APIs 30, 50, 90 implicitly define the content structure for applications and allows them to publish and get content.

[0034] In more detail, the social router system architecture is composed of at least the following set of modules: 1) the social network API 30— for a real-time view of the social graph and to know who each user's friends are; 2) the CCN API 90— to interface with the CCN; 3) a user, content and collection (subscription) database 70— this provides real-time updates to match users Ux and content CON x collections that the users have subscribed to; 4) the social router engine 60 that runs the social router logic algorithms; 5) the social router API 50 that permits the user/application and the social router to interact; and the content collection database/server 75.

[0035] The social router may be implemented in a client-server architecture. As explained in more detail below, the social router server comprise the hardware of the social router server 40 combined with its software -implemented engine 60. The social router client component 95 can be provided on a device (35') of the user 10, on the respective social network platform 20, and on the CCN infrastructure elements 80.

SOCIAL ROUTER USER REGISTRATION [0036] In an embodiment, the name of the user (username) is made of 2 parts: /socialnet/userid, where socialnet identifies the social network that the user is a part of (e.g., Facebook, Twitter, etc.), and userid identifies the user in this specific social network. Examples of the username might be: facebook/zuck (for Mark Zuckerberg's Facebook account id), and twitter/jack (for Jack Dorsey's Twitter account id). As used below, such names have been compressed with shorthand to "userl", etc. The userid has to match exactly the real id of the user in a particular social network's graph, otherwise the social router cannot use the social network's graph and find relevant information about the user. Additionally, since a user might be using different social networks, the social router client might have to register different user names. The social router client 95 knows the name(s) of the user who owns the machines where the social router client application 95 is installed. The social router client knows the social identities used by the person using the machine.

[0037] It is important to ensure that no user can register someone else's user name, or a name without proper authorization. Two possibilities for dealing with this situation are: "user provided", and "client detection" scenarios. In the user provided scenario, the user directly provides the username to the application. The social router client asks for the social network account password and verifies with the appropriate social network that this is the right user. In the client detection scenario, the social router client application detects the username and password/authorization automatically when user uses the social networks. The social router could know that a user name is being used, and not a content name, because it starts with a known social networking identifier (e.g. Facebook, Twitter, etc.). These social networking identifiers could be, e.g., predefined in a table on the social router server.

[0038] In a preferred option for user name prefix registration, CCN prefixes are typically configured manually and registered by applications locally in the FIB. The protocol that local apps use to register prefixes with their own ccnd (the name of the main Linux process for the CCNx implementation developed by PARC). A CCN node registers locally a prefix to be able to serve a prefix and receive interests matching this prefix. A ccnd process runs on each node. The protocol is documented in:

http://www.ccnx.Org/releases/latest/doc/technical/Registration.t xt (copy from June 20, 2013 reproduced at the end of this

Specification under the heading CCNx Face Management and Registration Protocol). [0039] The CCN self-registration protocol allows clients to register the prefixes for interests (/colli) that they wish to receive. This is done using a specific "face" on the CCN node, which is generally the identifier of a hardware interface or an application process identifier. Dynamic routing for CCN is developing for making the prefix dynamically reachable and route the interests towards the right content source. For a CCN system in which name-based dynamic routing protocols are available for CCN, the CCN can announce locally published prefixes and FIBs can be populated by name-based dynamic routing protocols. Existing routing protocols, such as OSPF, could be extended to support CCN and its capabilities: name prefixes, interest multipara forwarding, etc..

[0040] When the device connects to the network, the social router client locally registers the user name prefix /socialrouter/username (/sr/userl), and announces that it can serve Interests matching this specific prefix. It creates an FIB entry for the user name prefix pointing at a specific face, which, for example, could be, Prefix: /sr/usrl Arrival Face: 0. It also sends the user name prefix into an interior gateway protocol (IGP) link-state advertisement (LSA) which is flooded to other nodes via known CCN mechanisms. FIBs in other CCN nodes are updated using name-based routing protocols. The resulting FIB allows interests to be routed to the user's 10 current location— the CCN node of the user 35'.

[0041] Figure 3 illustrates a basic example of a user registration in the social router system. When a device, such as a user's smartphone, etc., connects to the network, a social router client application 95 registers the user name prefix via an interest S100 having a specific (e.g., user_reg) command (e.g., /sr/user_reg/username). Here, the social router server 40 receives the registration request from the social router client 95 on the user's device 35'.

[0042] The user device 35' has a social router client 95 to register the user's username (usrl), but using existing CCN dissemination or routing protocols. As the dissemination covers the entire CCN grid, the designated router (i.e., the CCN server) (sr) 40 or social network router 20 will see its FIB 39 also populated with the /socialrouter/username (/sr/usrl). The social router server (40) stores the username (usrl) in a registration phase with the social network router 20.

[0043] Put differently, the social router server (40) does not receive a specific message from the user 10 (social router client 95) when the user (usrl) registers its prefix in the FIB 39 of the user's social router client 95. The user (usrl) locally registers and creates an FIB 39 entry for the "/socialrouter/username" (/sr/usrl) prefix on the user CCN node 35' using a specific CCN function. This prefix (/sr/usrl) information is then disseminated (including the recommendation (also defined herein as the "designated") router's, i.e., the CCN server's 40, FIB) through classic routing protocols, and not though specific social router messages.

[0044] If the social router server 40 accepts the user registration, it notifies the client by responding back with a positive acknowledgement (ACK) S105; otherwise, the server responds back with a negative acknowledgement (NAK). When a device, such as a user's smartphone, etc., connects to the network, a social router client application 95 registers the user name prefix via an interest SlOO (e.g., /sr/user_reg/userl). If the username can be registered, the social router server 60 responds back with a positive acknowledgement (ACK) SI 05; otherwise, the server responds back with a negative acknowledgement (NAK) (e.g., in the case of a non-existing user name). A similar mechanism could be utilized for an unregistration process.

[0045] Figure 4 illustrates a very basic scheme by which a social router client 95 and social router server 60, applications (or potentially other CCN-based applications) can send messages or commands to the user using the /socialrouter/username prefix. This is very advantageous, since it is, by default, not possible to identify users using the native CCN, since there is no field in the CCN packets that can be used to identify a user. In Figure 4, the social router client 95 sends an interest packet to the social router server 60, e.g., in the form of

/socialrouter/username/cmdname/parameters SI 10, and receives back an associated data packet (the "result") SI 15.

[0046] Thus, using the social router, users can be found on the network, and messages and commands can be sent to them, even though the underlying CCN does not accommodate packets that natively identify a user. The only need to is to know the user name and to use a command known by the social router.

[0047] An interest can be sent by a user and to a user by the social router. The name of the interest contains: 1) the username (i.e., the name of the user); 2) the command name (i.e., the name of a known command); and 3) parameters (optional) (i.e., parameters needed for the command, such as the collection/content name).

[0048] The following exemplary commands could be utilized:

The username is made up of /socialnet/userid where socialnet identifies the social network that the user is a part of (e.g., Facebook, Twitter, etc.), and userid identifies the user in this specific social network.

user usr_unreg /sr/user_unreg/username Unregisters a user unregistration with a social router server.

get data get /sr/get/username/coll/cont The username

identifies the user requesting a specific content part of a specific collection. data interest rpc_get /sr/username/rpc_get/coll/cont This is a command inquiry sent by the social router server.

Username identifies the user who is asked, if interested, to request a specific content part of a specific collection. If the user agrees, the user immediately sends a get command.

Table 1

Exemplary Social Router Commands

[0049] There is no need for a put command, since the existing CCN command can be used. As to updating the data itself, the social router knows in real-time what are the changes in the social networks because it uses the social network APIs before step S220 when it needs to know the list of userl 's friends and before sending the rpc_get commands. The client will receive the interest it registered with the name of the user, and will return the data packet with the corresponding command result (if any). In an embodiment, a timestamp (combining data and time) may be added at the end of the interest name to ensure it reaches the right client and does not use a cached source of data, which may be outdated.

EXEMPLARY USE CASE [0050] Figure 5 presents an exemplary use case for the social router system. In this use case, it is presumed that the users userl, user2, and user3 have already properly registered with the social router server 60, and have subscribed to collection 1. The social router server 40 contains mappings of all user interests registered in the user and collection database 70, although the user and collection database 70 could be located on a computer other than the social router server 40.

[0051] At S200, userl (a social router client 35') sends a get request to the social router server 40 for contentA of collection 1. The social router server 40 responds at S205with the prefix to be used by userl to get contentA from the contentA repository 75. Figure 2 shows the collection/content repository 75 located outside of the social router server 40— it could be at any location on the network, including the social router server 40. Now knowing the supplied prefix to use to get contentA data, the user asks, at S210, the contentA repository 75 to provide the data associated with contentA. The contentA repository 75 responds with the data at S215.

[0052] Not shown in Figure 5, the social router server 40 then obtains from the social network(s) 20, using the social network(s) API(s) 30 a list of userl 's friends. In this use case, it determines that of all userl 's friends, only user2 and user3 have subscribed to collectionl.

[0053] Based on this determination, the social router server 40 sends, at S220, an rpc_get command to user2, which notifies user2 that userl requested the contentA data. User2 can respond, at S225, as to whether they want to retrieve contentA (via a data packet ACK) or not (NAK). This could be based on an actual response by user2, or some form of automated response configured ahead of time by the user or social router configuration parameters set in a table or configuration file.

[0054] This is repeated for user3 at S230 and S235. For both user2 and user3, at S240 and S245, if an ACK was sent, then an interest is sent to the social router server 40 to retrieve the data by user2 and user 3 in a manner similar to what was done by userl at S200. Additionally, due to a cascading effect, friends of user2 and user3 are notified in a manner similar to the mechanisms at S220 and S230. As noted previously, loops are avoided via a loop prevention mechanism in that user2 and user3 will not trigger the interest back to userl who originated in the data interest— in other words, when userl recommends a particular content to user2, then user2 will not recommend the same content to userl.

BENEFITS [0055] There are many advantages of the social router described herein. Compared to similar content recommendation and distribution systems based on IP, this system offers new features, is simpler, is more scalable, offers better mobility support, and is more secure.

[0056] It offers new features because an IP router cannot route content based on a social profile, but only based on IP addresses. It provides automatic content distribution, since there is nothing to provision or configure. The social router looks at what is going on directly on the network. Also, the social router system leverages CCN's multipath routing: it can route interests to and get data from multiple interfaces. IP-based systems can only route packets to a single interface.

[0057] The social router system is simper because the social router runs on top of CCN and easily adds social context into the networking architecture. It is content-centric with content name addressing and provides applications with content collection-based distribution. Many of the popular applications on the Internet could use the social router. Text, photos, messages or media files can be published as content by the users. The social router offers a consistent naming convention for multiple applications to deliver contents to end-users. The users can request content without knowing which node can provide it. Also, the most appropriate sources can be used depending on the location of the user and the load on the network.

[0058] The social router system is more scalable because it leverages CCN's multisource content delivery: an interest can be routed to all potential content sources and get content from those simultaneously. It can improve performance and reliability. Furthermore, it leverages CCN's content caching— reduces the time to deliver contents to the end users and reduces the load on the network. More content can be exchanged.

[0059] The social router provides better mobility support. It supports moving receivers: the CCN removes the requirement that endpoints register their IP address every time they move. The CCN can be used to provide mobility support for. A user sends interests and data flows back following the trail set up by the interests. It also supports moving senders: it will inform (using prefix registration) the receiving user to send the Interest towards the mobile source to retrieve the data.

[0060] Finally, the social router is more secure. The CCN can tell if the content was produced and signed by the right content producer. There may be a cryptographic binding between the content and its name, which may consist of a hash of the content provider's private key in the name of the content object. Data packets can be digitally signed, using per-user key pairs.

[0061] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated as incorporated by reference and were set forth in its entirety herein.

[0062] For the purposes of promoting an understanding of the principles of the invention, reference has been made to the preferred embodiments illustrated in the drawings, and specific language has been used to describe these embodiments. However, no limitation of the scope of the invention is intended by this specific language, and the invention should be construed to encompass all embodiments that would normally occur to one of ordinary skill in the art.

[0063] Embodiments of the invention may be described in terms of functional block components and various processing steps. Such functional blocks may be realized by any number of hardware and/or software components that perform the specified functions. For example, the embodiments may employ various integrated circuit components, e.g., memory elements, processing elements, logic elements, look-up tables, and the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices. Similarly, where the elements are implemented using software programming or software elements, embodiments of the invention may be implemented with any programming or scripting language such as C, C++, Java, assembler, or the like, with the various algorithms being implemented with any combination of data structures, objects, processes, routines or other programming elements. Functional aspects may be implemented in algorithms that execute on one or more processors. Furthermore, embodiments of the present invention could employ any number of conventional techniques for electronics configuration, signal processing and/or control, data processing and the like. The words "mechanism" and "element" are used broadly and are not limited to mechanical or physical embodiments, but can include software routines in conjunction with processors, etc.

[0064] The particular implementations shown and described herein are illustrative examples of the invention and are not intended to otherwise limit the scope of the invention in any way. For the sake of brevity, conventional electronics, control systems, software development and other functional aspects of the systems (and components of the individual operating components of the systems) may not be described in detail. Furthermore, the connecting lines, or connectors shown in the various figures presented are intended to represent exemplary functional relationships and/or physical or logical couplings between the various elements. It should be noted that many alternative or additional functional relationships, physical connections or logical connections may be present in a practical device. Moreover, no item or component is essential to the practice of the invention unless the element is specifically described as "essential" or "critical".

[0065] The use of "including," "comprising," or "having" and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. Unless specified or limited otherwise, the terms "mounted," "connected," "supported," and "coupled" and variations thereof are used broadly and encompass both direct and indirect mountings, connections, supports, and couplings. Further, "connected" and "coupled" are not restricted to physical or mechanical connections or couplings.

[0066] The use of the terms "a" and "an" and "the" and similar referents in the context of describing the invention (especially in the context of the following claims) should be construed to cover both the singular and the plural. Furthermore, recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. Finally, the steps of all methods described herein are performable in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., "such as") provided herein, is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention unless otherwise claimed.

TABLE OF REFERENCE CHARACTERS

10 user/application

20 social network

30 social network API

35 content centric network (CCN) node (server)

35' user content centric network (CCN) node (client)

37 pending interest table (PIT) 38 content store (CS)

39 forwarding information base (FIB)

40 social router server

50 social router API

60 social router engine

70 user and collection database

75 content server

80 content centric network (CCN) infrastructure

90 CCN API

95 social router client

CCNx FACE MANAGEMENT AND REGISTRATION PROTOCOL

== Face Management Protocol

The Face Management Protocol provides a method for an entity such as ccndc to control

the faces maintained by ccnd, which are subsequently used in the Registration Protocol .

The FMP supports "newface", "destroyface" , and "queryface" operations.

A request operation is represented as a CCNx Interest with

a CCNx ContentObject encoding the majority of the request parameters embedded as a component of the Interest name.

A response is represented as a ContentObj ect for which the name matches the Interest,

and the content encodes any necessary response data.

For the Face Management Protocol, the CCNx ContentObject encoding the request and reply

is the Facelnstance .

To create a new face ccndc signs a content object NFBLOB whose Content is a ccnb-encoded Facelnstance containing

- Action "newface"

- other fields necessary to set up a socket (at least IPProto, Host, and Port) . ccndc then expresses an interest in /ccnx/CCNDID/newface/NFBLOB

- CCNDID is the pubid of the local ccnd

- NFBLOB is the signed content object

The verb, "newface" occurs redundantly in both the interest prefix and in the NFBLOB .

Its presence in the prefix is for dispatching the request.

It is also in the NFBLOB, so that it is signed. ccnd creates the new face and answers with a Facelnstance containing at least the PublisherPublicKeyDigest and FacelD.

== Facelnstance

See ccnx . xsd/ccnx . dtd

Facelnstance := Action?

PublisherPublicKeyDigest ?

FacelD?

IPProto?

Host?

Port?

MulticastInterface?

MulticastTTL?

Freshnes sSeconds ?

Action ::= ("newface" "destroyface" "queryface")

PublisherPublicKeyDigest ::= SHA-256 digest

FacelD = nonNegativelnteger

IPProto = nonNegativelnteger [ IANA protocol number; 6=TCP, 17=UDP] Host = textual representation of numeric IPv4 or IPv6 address Port = nonNegativelnteger [1..65535]

MulticastInterface = textual representation of numeric IPv4 or IPv6 address MulticastTTL = nonNegativelnteger [1..255]

FreshnessSeconds = nonNegativelnteger

=== Action

When Facelnstance is used as a request, the Action must be specified.

It will not be present in a response.

. ^' newface^' - If a face matching the parameters does not already exist, an attempt is made to create it.

Then if the face exists (whether new or old)

the full description is returned as a Facelnstance.

. ^' destroyface^' - at least the FacelD must be present.

If permitted, the face is destroyed.

. 'queryface' - specification TBD

=== PublisherPublicKeyDigest

Identifies the ccnd that the information is relevant for.

PublisherPublicKeyDigest is not necessary for self-registration, but indicates the ccnd to which the request is directed, if present.

PublisherPublicKeyDigest is always present in a response.

=== FacelD

FacelD is not present in a ^'newface^' request, but must be specified in a ^' destroyface^' or ^'queryface^' request.

FacelD is always present in a response.

=== Host

Identifies the IPv4 or IPv6 numeric address of the remote ccnd for this Facelnstance .

=== Port

Port identifies the port on the remote ccnd, or the port for the multicast === Multicastlnterface

If the Host is a multicast address, and there are multiple

interfaces present, Multicastlnterface will identify the unicast

numeric address of the interface to which the multicast address will be attached .

=== MulticastTTL Specifies the TTL to be used for multicast operations. The default value is 1.

=== FreshnessSeconds

FreshnessSeconds is optional in a request, but is treated as a hint by ccnd. In a response, FreshnessSeconds specifies the remaining lifetime of the face .

== Prefix Registration Protocol

The prefix registration protocol uses the ForwardingEntry element type to represent both requests and responses.

ForwardingEntry ::= Action?

Name?

PublisherPublicKeyDigest ?

FacelD?

ForwardingFlags ?

Freshnes sSeconds ?

Action ::= ("prefixreg" "selfreg" "unreg")

Name : := the name prefix to be registered

PublisherPublicKeyDigest ::= SHA-256 digest of the ccnd's public key (CCNDID) FacelD ::= nonNegativelnteger

ForwardingFlags ::= nonNegativelnteger

FreshnessSeconds ::= nonNegativelnteger

=== Action

When ForwardingEntry is used as a request, the Action must be specified.

It will not be present in a response.

- 'prefixreg' - Register (or re-register) the prefix on the specified face.

- ^' selfreg - Register (or re-register) the prefix on the current face; the FacelD need not be present in the request, but if present it must match the current face.

- ^'unreg^' - Remove the prefix registration for the specified face.

=== PublisherPublicKeyDigest

Identifies the ccnd that the information is relevant for.

It is optional in a request (the name in the requesting interest has already addressed the appropriate node) .

PublisherPublicKeyDigest is always present in a response.

=== FacelD

FacelD is required in ^'prefixreg^' and ^'unreg^' requests.

FacelD is always present in a response.

=== Name

This is the name prefix to be acted on.

=== ForwardingFlags

This integer holds the inclusive OR of the following bit fields:

CCN_FORW_ACTIVE 1

CCN_FORW_CHILD_INHERIT 2

CCN_FORW_ADVERTISE 4

CCN_FORW_LAST 8

CCN_FORW_CAPTURE 16

CCN_F0RW_L0CAL 32

CCN_FORW_TAP 64

CCN_FORW_CAPTURE_OK 128

The ^' CCN_FORW_ACTIVE^' bit indicates that the entry is active;

interests will not be sent for inactive entries (but see note below) .

' CCN_FORW_CHILD_INHERIT' says that this entry may be used even if there is a longer match available. In the absence of this bit, the presence of a longer matching prefix that has an active entry will prevent this entry from being used.

^* CCN_FORW_ADVERTISE~ says that the prefix may be advertised to other nodes.

^% CCN_FORW_LAST^% indicates that this entry should be used last, if nothing else worked .

This is intended to be used by ccndc and similar programs to monitor

unanswered interests.

The presence of this flag on any entry causes the associated face to be considered non-local, as far as interest forwarding is concerned.

Thus it will not receive interests with Scope=l, nor will it receive interests in namespaces that are marked local.

However, the ability of the face to change prefix registrations is not affected.

^% CCN_FORW_CAPTURE^% says that no shorter prefix may be used, overriding

child-inherit bits that would otherwise make the shorter entries usable.

For a child-inherit bit to be overridden, the CCN_FORW_CAPTURE_OK must be set in the same forwarding entry that has CCN_FORW_CHILD_INHERIT set.

Note that this means that using CCN_FORW_CAPTURE will have no effect if the

CCN_FORW_CAPTURE_OK flag is not used.

^% CCN_FORW_LOCAL ^% restricts the namespace to use by applications on the local machine .

^% CCN_FORW_TAP^% causes the entry to be used right away. This is intended for debugging and monitoring purposes. It is likely that there will be no response as a result, so no intentional delay is added before any further forwarding of this interest .

~ CCN_FORW_CAPTURE_OK' used in conjunction with CCN_FORW_CHILD_INHERIT allows a CCN_FORW_CAPTURE flag on a longer prefix to override the effect of the child- inherit bit .

The flags ~ CCN_FORW_ADVERTISE~ , ~ CCN_FORW_CAPTURE~ and ~ CCN_FORW_LOCAL~ affect the prefix as a whole, rather than the individual registrations.

Their effects take place whether or not the ~ CCN_FORW_ACTIVE ~ bit is set.

=== FreshnessSeconds

FreshnessSeconds is optional in a request, but is treated as a hint by ccnd. In a response, FreshnessSeconds specifies the remaining lifetime of the regi stration .

Claims

WHAT IS CLAIMED IS:

1. A method for requesting specific content by a user in a Content Centric Network (CCN), the CCN comprising a plurality of CCN nodes, each node comprising a Forwarding

Information Base (FIB) populated using a prefix based routing protocol, each prefix comprising one or more names used for the routing in the CCN, the user being defined by a user name associated with a specific social network, the method comprising a user device CCN node:

registering in the FIB of a user CCN node a user CCN prefix comprising the name of a designated router and the username of the user, for subsequent dissemination by said user CCN node of the user CCN prefix, the dissemination including the designated router;

disseminating the user CCN prefix via preexisting CCN protocols to the designated router;

issuing an interest request command destined to the designated router, using a content request prefix formed with the name designated router, the username of the user and the content name, the request command being inserted in the content request prefix between the router name and the username; and receiving from the designated router a data content prefix to be used by the user device, the data content prefix comprising the designated router and the content name.

2. The method of claim 1, further comprising:

issuing a data interest request utilizing the data content prefix; and

receiving data associated with the data interest request by the user device.

3. The method of claim 1, further comprising:

receiving a data interest inquiry using a data interest inquiry command from the

designated router for further content; responding by the user device with a positive acknowledgment if receipt of data for the further content is desired, and a negative acknowledgment if receipt of the data for the further content is not desired;

if the user device responded with a positive acknowledgment, then issuing a further interest request command destined to the designated router, using a further content request prefix formed with the name designated router, the username of the user and the content name, the request command being inserted in the content request prefix between the router name and the username; and receiving from the designated router a further data content prefix to be used by the user device, the further data content prefix comprising the designated router and the further content name.

4. The method of claim 3, further comprising:

issuing a data interest request utilizing the data content prefix; and

receiving data associated with the data interest request by the user device.

5. The method of claim 1, further comprising:

unregistering in the FIB of the user CCN node the user CCN prefix.

6. A method for recommending content to a user in a Content Centric Network (CCN), the CCN comprising a plurality of nodes, each node comprising a Forwarding Information Base (FIB) populated using a prefix based routing protocol, each prefix comprising one or more names used for the routing in the CCN, the user being defined by a user name, the method comprising, for a designated router:

receiving from a user CCN node a user prefix comprising the name of the designated router, and the username of the user;

storing the user prefix in the in the FIB of the designated router;

receiving a content request prefix addressed to the designated router, the prefix comprising the name of the designated router, the username of the user in a social network and a content name, a request command being inserted in the prefix between the router name and the username;

identifying that the received content prefix is a request for content from the user by comparing the received content prefix and the stored user prefixes in the social router FIB of the designated router, and extracting the request command; and returning to the user the prefix to be used by the user device to request content, the prefix comprising the designated router and the content name.

7. The method of claim 6, further comprising:

determining a further user device having registered an interest in the content; and sending, to the further user device, a data interest inquiry using a data interest inquiry command from the designated router for the content.

8. The method of claim 7, further comprising:

receiving either a positive acknowledgement or a negative acknowledgement from the further user device.

9. The method of claim 7, further comprising:

determining, prior to the sending to the further user device, whether the further user device not has received the content in order to prevent looping; and performing the sending to the further user device in response to a positive

determining.

10. The method of claim 6, further comprising:

receiving, from the further user device an interest request command comprising a content request prefix formed with the name of the designated router, the username of the user and the content name; and returning to the user the prefix to be used by the user device to request content, the prefix comprising the designated router and the content name.

11. A non-transitory computer program product, comprising a computer usable medium having a computer readable program code embodied therein, said computer readable program code adapted to be executed to implement a method for requesting specific content by a user in a Content Centric Network (CCN), the CCN comprising a plurality of CCN nodes, each node comprising a Forwarding Information Base (FIB) populated using a prefix based routing protocol, each prefix comprising one or more names used for the routing in the CCN, the user being defined by a user name associated with a specific social network, the method comprising a user device CCN node: