WO2016168116A1 - Method and apparatus for matching information supply and demand in icn based on imperfect matching - Google Patents

Abstract

The invention pertains to methods and apparatus for matching information supply and demand in an Information Centric Network in which the matching is performed using imprecise information. The matching may be performed using a fuzzy extractor based on imprecise information and/or imperfect matching criteria in a secure manner that preserves privacy and requires minimal signalling.

Description

METHOD AND APPARATUS FOR MATCHING INFORMATION SUPPLY AND DEMAND IN ICN BASED ON IMPERFECT MATCHING

CROSS REFERENCE

[0001] This application claims the benefit of U.S. Provisional Application No.

62/149,260, filed April 17, 2015, the contents of which are incorporated by reference herein.

FIELD OF THE INVENTION

[0002] This application relates to information centric networks and networking (ICN). More particularly, this application relates to the process of matching the publishers and subscribers of information into a communication relationship.

BACKGROUND

[0003] The Internet may be used to facilitate content distribution and retrieval. In existing Internet protocol (IP)-based networks, computing nodes are interconnected by establishing communications using IP addresses of these nodes. In ICNs, routing functions are based on the content itself, rather than where the content is stored. Content distribution and retrieval may be performed by ICNs based on names (i.e., Content Identifiers (CIDs)), of content, rather than IP addresses.

[0004] Presently, the content-based publisher and subscriber matching in ICNs is substantially indiscriminate in the sense that, if a subscriber requests a piece of content that is available from multiple sources (publishers), then the matching protocol chooses one of those publishers essentially randomly.

SUMMARY

[0005] The invention pertains to methods, apparatus, systems, and techniques for matching information supply and demand in an Information Centric Network in which the matching is performed using contextual information, imprecise information, and/or imprecise matching. In one embodiment, for instance, contextual information about a piece of content, such as its format, bitrate, or geolocation, may be used to enhance matching. In accordance with one exemplary embodiment, the matching of a subscriber of content to a particular publisher of the requested content when there are several publishers that have the requested content may be based at least partially on selecting one of the publishers based on the closeness of contextual factors, such as desired data format, bitrate, and/or geolocation. In other embodiments, the subscriber to the information may request the content using only a partial identification of the requested content.

[0006] In certain embodiments, the technique may use an imperfect matching function, such as a fuzzy extractor, to match a content subscription with a content publication based on such imprecise information and/or imperfect matching criteria in a secure manner that preserves privacy and requires minimal signaling.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0008] FIG. 1 A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented;

[0009] FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1 A; and,

[0010] FIGS. 1C-1E are system diagrams of an example radio access networks and example core networks that may be used within the communications system illustrated in FIG. 1A;

[0011] FIG. 2 is a block diagram of an exemplary fuzzy extractor;

[0012] FIG. 3A is a block diagram of an exemplary network topology in accordance with one embodiment;

[0013] FIG. 3B is a signal flow diagram in accordance with a first exemplary embodiment;

[0014] FIG. 4 is a signal flow diagram in accordance with a second exemplary embodiment; and

[0015] FIG. 5 is a diagram illustrating a namespace for ICN in accordance with an exemplary embodiment. DETAILED DESCRIPTION

1 Networks for Implementation

[0016] The present invention is applicable to any type of network, wired or wireless. The following is a description of a few exemplary wireless networks in which one or more of the disclosed embodiments may be implemented. FIG. 1A is a diagram of an example wireless communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.

[0017] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0018] The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, the Intemet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNodeB, a Home Node B, a Home eNodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0019] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0020] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0021] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0022] In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E- UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE- A).

[0023] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0024] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNodeB, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE- A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106.

[0025] The RAN 104 may be in communication with the core network 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing an E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology. [0026] The core network 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0027] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0028] FIG. IB is a system diagram of an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 106, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0029] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0030] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0031] In addition, although the transmit/receive element 122 is depicted in FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0032] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0033] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 106 and/or the removable memory 132. The non-removable memory 106 may include random- access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0034] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0035] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0036] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0037] FIG. 1C is a system diagram of the RAN 104 and the core network 106 according to an embodiment. As noted above, the RAN 104 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106. As shown in FIG. 1C, the RAN 104 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 104. The RAN 104 may also include RNCs 142a, 142b. It will be appreciated that the RAN 104 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0038] As shown in FIG. 1C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an lub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodi versify, security functions, data encryption, and the like.

[0039] The core network 106 shown in FIG. 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0040] The RNC 142a in the RAN 104 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0041] The RNC 142a in the RAN 104 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices. [0042] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0043] FIG. ID is a system diagram of the RAN 104 and the core network 106 according to another embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106.

[0044] The RAN 104 may include eNodeBs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, the eNodeB 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0045] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. ID, the eNodeBs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0046] The core network 106 shown in FIG. ID may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0047] The MME 162 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S I interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA. [0048] The serving gateway 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring data planes during inter-eNodeB handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0049] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP- enabled devices.

[0050] The core network 106 may facilitate communications with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0051] FIG. IE is a system diagram of the RAN 104 and the core network 106 according to another embodiment. The RAN 104 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 104, and the core network 106 may be defined as reference points.

[0052] As shown in FIG. IE, the RAN 104 may include base stations 170a, 170b, 170c, and an ASN gateway 172, though it will be appreciated that the RAN 104 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 170a, 170b, 170c may each be associated with a particular cell (not shown) in the RAN 104 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the base stations 170a, 170b, 170c may implement MIMO technology. Thus, the base station 170a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 170a, 170b, 170c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 172 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 106, and the like.

[0053] The air interface 116 between the WTRUs 102a, 102b, 102c and the RAN 104 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 106. The logical interface between the WTRUs 102a, 102b, 102c and the core network 106 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

[0054] The communication link between each of the base stations 170a, 170b, 170c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 170a, 170b, 170c and the ASN gateway 172 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 100c.

[0055] As shown in FIG. IE, the RAN 104 may be connected to the core network 106. The communication link between the RAN 104 and the core network 106 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 106 may include a mobile IP home agent (MIP- HA) 174, an authentication, authorization, accounting (AAA) server 176, and a gateway 178. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0056] The MIP-HA 174 may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 174 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 176 may be responsible for user authentication and for supporting user services. The gateway 178 may facilitate interworking with other networks. For example, the gateway 178 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. In addition, the gateway 178 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0057] Although not shown in FIG. IE, it will be appreciated that the RAN 104 may be connected to other ASNs and the core network 106 may be connected to other core networks. The communication link between the RAN 104 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 104 and the other ASNs. The communication link between the core network 106 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

2 Information Centric Networks

[0058] Recent research efforts, such as in the area of information-centric networking (ICN), have studied novel approaches to routing information as opposed to sending bit packets from endpoint A to endpoint B. A crucial step in routing information within ICNs is that of rendezvous, which matches the publishers of information and the subscribers to information into a temporally limited communication relationship, which is created on-the-fly for forwarding said information from the chosen publisher(s) to the subscriber(s).

[0059] In approaches such as [1], [2] (all references are listed at the end of this specification), such rendezvous procedure generally performs a non-discriminative match, i.e., a single publisher is selected from a set of matching publishers offering the information while all subscribers (who have currently subscribed to the information) are chosen. In the case of several possible publishers, one publisher is randomly chosen. In [1], such procedure is performed offline and leads to the population of Forwarding Information Bases (FIB) routing tables in the intermediary forwarding elements, while [2] uses a centralized rendezvous function, which performs the matching procedure with every received publication and subscription.

[0060] Alternatives such as [4] eliminate the need for real-time FIBs or determination of forwarding paths to subscribers by relying on a notion of "scope trees." However, much like [2], [4] contains a per-scope centralized entity called a "scope root" which must match each content request with the ultimate location of each content item - among several potential locations.

[0061] The non-discriminative nature of the matching in [1], [2] and [4] is motivated through the basic operation of an ICN, which is the bringing together of publishers and subscribers solely based on the offered information. It is desirable to introduce

discriminative steps into this procedure, leading to a matching of publishers and subscribers based on one or more discriminative factors. Such factors may depend on publisher and/or subscriber information as well as factors relating to the information itself.

[0062] A match that is somewhat akin to a natural language search, i.e., the

information/content has some additional contextual information associated with its publication and the search operation provides close matches (possibly in a ranking manner), rather than exact matches. This context information can take many forms - e.g., metadata. Likewise, the subscriber may provide some contextual information associated with its subscription request (or equivalent interest/delivery request for systems like [1] and [4]). The ICN's Rendezvous function may match the contextual information in the

subscription/delivery request to the "closest" available publication context and map the subscription/delivery request to the corresponding publisher. Alternatively, the request may be mapped to multiple publishers that are sufficiently close based on the matching criteria and allow the subscriber or another network node to make the final choice from the list. Alternatively, a ranking result may be provided, where the "closest" matches are provided in a list, ranked according to a proximity metric.

[0063] Achieving this goal of matching publishers and subscribers based partially on context as well as content presents several significant challenges that stem from the complex nature of the idea of "closeness." While an exact match, even with wildcards, is a well- defined notion, a "close match" is context dependent. For example, "building" and

"architect" might be a close match if the context of an inquiry is architecture, but is a complete mismatch if the context is string processing.

[0064] In one embodiment, the matching is done by a network function called the Rendezvous Point (RP) - which may or may not be centralized. To perform a "closeness" evaluation, the RP should be aware of context, which may be supplied by both publishers and subscribers/requestors. This introduces several issues. For instance, signalling and control overhead could be an issue. Specifically, context may (and often is) highly application dependent. Providing a full description for each publication and subscription may involve significant overhead.

[0065] Another potential issue is processing load at the RP. A frequent goal in the design of ICN systems is to minimize the processing requirements on the RP. Where the RP is centralized, this is made explicit (see, e.g. [2]). When the RP operation is distributed and/or implicit (as in systems like [1]) a complex per-request RP operation is not feasible.

Requiring the RP to support a potentially unlimited number of various application or context- dependent algorithms for "closeness" evaluation could lead to an overly complex RP design and one that is not easily distributed or performed off-line.

[0066] Yet further, security and privacy concerns may exist. Specifically, context information may be sensitive. Disclosing certain context information to a third party - which an RP is in most cases - may pose significant security and privacy concerns.

[0067] Accordingly, a content routing approach that addresses at least some of these issues is desirable. Fuzzy extractors can be used in the content routing process to address at least some of these issues. Some desirable characteristics for such a system include: (1) minimal signalling and control overhead over and above what already exists in an ICN system; (2) a low-complexity RP function implementation; and (3) security and privacy.

3 Fuzzy Extractors

[0068] Fuzzy extractors can be implemented in ICNs using well-known techniques once the system requirements are well understood. [0069] This specification follows the conventions of cryptography literature and assumes binary (i.e., bit) strings for all quantities. It should be recognized that this leads to no loss of generality, as any countable (and indeed uncountable, but congruent to Reals) input distribution can be represented using binary strings. The use of binary strings is convenient both notationally (the notation is simpler) and practically. In particular, note that the output of the extractors can be readily used as binary cryptographic key matter.

[0070] As noted in [6], a Fuzzy Extractor is constructed from two components, namely, and Extractor and a Secure Sketch. Each is briefly described below, including practical means for constructing them.

3.1. Extractors

[0071] An extractor (or more precisely a randomness extractor) is a well-known tool in theoretical cryptography for "extracting randomness" from an input that contains inherent, but "imperfect", randomness. More precisely, given an input drawn from a distribution X on {0,1 }', a randomness extractor produces a shorter output (hereinafter termed the

"randomness-extracted credential") drawn from {0, l }^k, k < 1, (we use the notation {0, 1 }' for a binary string of length n bits and {0, 1 } * for a binary string of arbitrary length) such that:

The output is statistically indistinguishable from that produced by uniform

distribution on {0, 1 }^k up to a small factor ε> 0;

Moreover, the output of the extractor is statistically independent of the input up to a small factor δ >0.

[0072] This can be achieved provided that k is chosen to be less than the min-Entropy of X, where (1) the min-Entropy of X is a measure of the randomness present in X and (2) is defined as the minimum integer m such that for all x e {0, 1 }' , Prx(x) <2^"m. It was shown (see [7] and also the books [8] and [9]) that randomness extraction can be achieved in theory, in particular using the well-known notion of universal hashing developed by Carter and Wegman [10], [11]. Moreover, [12] shows that commonly used hash functions such as SHA- 1, SHA-2, MD5, etc. can be utilized for the purposes of randomness extraction.

3.2 Secure Sketches [0073] Following the exemplary presentation in [6], the notion of a Secure Sketch is discussed herein as a pair of randomized procedures, Sketch (SS) and Recover (REC), which operate as follows:

On input w, the Sketch (SS) returns a string s e {0,1 }*.

The Recovery procedure (REC) takes as inputs s and w', where w' is the other input to which we are attempting to determine a match with w. The correctness property of a Secure Sketch guarantees that if d(w, w') <t then REC(w', s) = w. Here, d is an appropriate measure of "distance" on the input distribution, as will be discussed in more detail further below;

The security property of a Secure Sketch guarantees that, given s, the probability of guessing w is no better than 2^"m, where m is the min-entropy of the distribution from which w is drawn. In particular, if w is "perfectly random" - e.g., if w is an 1-bit string drawn uniformly from {0,1 }', then s leaks no information about w.

[0074] As with extractors, practical implementations of Secure Sketches are well known. However, these depend strongly on the notion of "distance" between two inputs which is, itself, strongly context dependent. Some common examples are as follows:

Hamming Distance: this is the number of bits by which two strings differ. In this case, [6] proposes using the ideas in [13] and utilizes hashing combined with linear error-correcting codes (in particular the well-known BCH codes) to construct a Secure Sketch.

Set Difference: this is the number of elements that are different between two sets. Here both [6] and [14] provide somewhat distinct examples of what can be practically done.

[0075] See [6] for other notions and concepts.

3.3 Fuzzy Extractors

[0076] Building on the description above of Extractors and Secure Sketches, fuzzy extractors are constructed as follows. [0077] A Fuzzy Extractor is a pair of randomized procedures, Generate (GEN) and Reproduce (REP).

[0078] The Generate procedure (GEN) takes an input string w and produces two outputs, namely, the extracted string R and a helper string P.

[0079] The Reproduce procedure (REP) takes as inputs a string w' and the helper string P. The correctness property of a Fuzzy Extractor guarantees that if d(w, w') <t then REP(w', P) = R.

[0080] The security property of a Fuzzy Extractor guarantees that both P and R as well as the pair (P, R) taken together leak information about w, which is upper bounded by 2^"m, where m is the min-entropy of the distribution from which w is drawn. As with Secure Sketches, this means that if w is drawn from a perfectly random input, (P, R) leaks very little information about w.

[0081] FIG. 2, taken from [6], shows an exemplary construction of a Fuzzy Extractor. Particularly, it includes a GEN procedure 201 and a REP procedure 203. In the GEN procedure 201, Ext 205 is a standard extractor (as described above) and SS 207 is a Secure Sketch as described above.

[0082] The REP procedure 203 includes a Rec procedure 209, which is a Recovery procedure for SS, as discussed above, and another extractor 211.

[0083] The value r is a random value used only on the GEN side to randomize the SS procedure. See [6] for details on how r is used.

[0084] The value x is a random quantity which gets included in P (and is therefore available to REP). The value x may be included in any of a number of ways (e.g., added, multiplied, etc.) and may be used much like the variable r mentioned immediately above.

[0085] A fuzzy extractor is one example of an imperfect matching function that can be used to match subscribers and publishers in ICN (or, more generally, information requests with information responses in networks). Other imperfect matching functions may be used also. Examples of other imprecise matching functionality that can be used in other embodiments include linear correlation, information-theoretic functions such as conditional entropy, etc. 4 Use cases/Scenarios

[0086] This section considers several exemplary use cases enabled by the techniques discussed herein.

[0087] Note the following terms/actors/entities that are used in the following example descriptions.

Information Originator: The entity which created or initiated distribution of the information/ content.

Publisher: A network entity that makes the information/content available to subscribers (consumers), typically by either caching (for static content) or having the capability to produce the required information on demand. Note that, in many cases, the information originator also may be the publisher of the information/content.

Subscriber: The consumer of content information.

Rendezvous Function (RP): A function within an ICN network responsible for matching subscribers and publishers. The function is a logical entity and need not be centralized or explicitly defined. The precise definition and functionality of RP will vary with each ICN implementation, such as [1], [2], [4].

Context: Additional information (e.g., metadata) associated with a particular piece of content. Thus, the information originator may set some context associated with a piece of content. A publisher may have some additional relevant context that may be added to the context from the originator in connection with the copy of the content that is resident at that publisher, e.g., geolocation or format (if the publisher changed the format of the content). Likewise, subscribers will have contextual information that may be set and incorporated into requests for content (e.g., geolocation, a particularly preferred format, etc.). Examples of the context (or contextual information) may include information related to: locations (geolocation, logical location, etc.) of the publishers and/or subscribers; identity information of the publisher and/or information originator; privacy requirements; price/cost of the information item(s); and quality of experience for the item (which may be data rate, resolution, etc.) Content Identifier (CID): This is a value that uniquely identifies content/information. This value may be a plaintext name (as in, e.g., [1]) or a well-structured binary value designed to be easily machine processable (e.g. [2]). As with other details, the CID may take many forms, and what is important is that it can be used to uniquely name/identify content.

Context Signature: A publically shared value that provides a cryptographically secure (i.e., it does not reveal the context) signature for a particular context. This value corresponds to the helper string P of a fuzzy extractor in embodiments that employ a fuzzy extractor for the imperfect matching functionality.

Context Validator: A value shared with the network by the context signature generating entity. The value corresponds to the extracted string R of a fuzzy extractor.

[0088] Note that the terms "publisher" and "subscriber" do not constrain the techniques defined herein to a pure pub/sub solution as in [2]. All of these techniques can be used in systems that are based on an interest/response paradigm (e.g. [1]) as well as mixed systems with both subscription and request aspects (e.g. [4]). Additionally, each particular ICN implementation also contains several other key functions, such as routing setup, policy management, etc. While important, to the extent that these do not impact the specific problem addressed herein, they are not specifically addressed.

[0089] With all that in mind, it is useful to consider several use cases to highlight potential applications of these concepts.

4.1 Selecting a Publisher from Among Several Candidates

[0090] In one example, an originator creates content with label CID that is made available to subscribers by a number of publishers. Each publisher has a network context associated with it, denoted as CXT(PUBi) for publisher i. The publisher's context may incorporate key information of importance to subscribers, for example, storage format, transcoding rate, network state, geolocation, logical location, etc. Each publisher publishes CID to the RP function in the usual fashion, e.g., it makes the RP function (or, more generally, the network) aware that it is able to deliver the content named CID. [0091] In a first example, a "basic" procedure is considered in which a single subscriber chooses from among a number of publisher. This concept will later be extended to handle any number of subscribers - and how, in fact, this leads to potentially improved network operation.

[0092] FIG. 3A shows an exemplary network topology for this embodiment and FIG. 3B shows an exemplary signal flow diagram for these embodiments. With reference first to FIG. 3A, in this first example, a subscriber 303, hereinafter "SUB", wishes to subscribe to a piece of content CID 311, and generates a publisher preference description (i.e., context)

CXT(SUB). The content 311 may be anything, e.g., a movie. The context may be any one or more of a format (mpeg), a resolution (1080p), a geolocation of the subscriber node, a price that the subscriber is willing to pay for the movie, or any other information that might be used to select one copy of the content 311 bearing the particular CID for delivery to the subscriber as opposed to any other copy of content having the same CID. It then uses a Fuzzy Extractor GEN function 309 to generate a pair (P,R)^GEN(CXT(SUB)). Here, P is the Context Signature and R is the Context Validator. The subscriber 303, SUB, forwards a Subscription Request 331 to RP 305 that includes the triplet (CID, P, R) through the network 301.

[0093] Next, RP 305 sends subscription forwarding messages 333 that include the value P from the subscription request 331 to all publishers of CID 311, e.g., publishers 307i and 3073. Note that, in accordance with typical ICN features, the publishers have previously informed the RP 305 of the CIDs of the content that is available from these publishers. Each such publisher 307i and 3073 uses the REP function 313 to produce a validation mask value Ri that is a function of P and that publishers contextual information, i.e.,

Ri -REP(CXT(PUBi),P) and include the resulting Ri in the communication 335 associated with the delivery of CID 311, e.g., it can be part of all associated packet headers. At the same time, RP 305 configures the network 301 to reject any delivery of content with Content Identifier CID 311 whose "validation mask" Ri does not match R.

[0094] The full procedure is illustrated in the signal flow diagram of FIG. 3B. FIG. 3B represents an exemplary embodiment in which the RP function 305 may be centralized (e.g., it may reside at a separate node on the network). This, of course, is merely exemplary (and, in fact, FIG. 3B is not necessarily preclusive of a distributed embodiment). In other embodiments, the RP function need not be centralized and may be distributed among the publishers and/or subscribers and other network elements. , Alternatively, no explicit RP functionality may exist. Instead, this functionality may be integrated into other network functionality, while the outcome of RP (i.e. matching publishers and subscribers) is nonetheless achieved. In order to simplify the discussion and not obfuscate the basic principles of the invention, FIG. 3B illustrates a single standalone, centralized RP 305. The procedure starts with several steps that are standard in ICN implementations (and will differ implementation by implementation). These are shown using gray arrows.

[0095] These steps include sharing of the CIDs (or CID exchange) 350. Specifically, the subscriber 303 needs to know the content identifier CID to which it wishes to subscribe. This CID is often learned by a subscriber as a result of information or protocols external to ICN (e.g., it is known by the application).

[0096] Also, the content, if not generated at the publishers 307, will need to be delivered from the content originator(s) 315 to the publishing nodes 307, as shown at 352.

[0097] Further, the publishers 307 publish the CIDs of the content available from the publishers to the RP 305, as shown at 354. This also happens using standard means, which may differ from ICN implementation to ICN implementation. For example, in [1] (where RP function is implicit in FIB configuration), this is accomplished by properly configuring FIBs in the network nodes; and, in [2] and [4], this involves having each publisher send an explicit publication announcement to an actual RP node in [2] and scope root in [4].

[0098] The next three steps are the ones outlined above, namely, (1) subscriptions sent from the subscriber node 303 to the RP 305, including the 3-tuple (CID, P, R) as previously described, as shown at 356 (2), the RP 305 sending delivery requests to publishers 307, including (CID, P), as shown at 358, and (3) the configuration of network nodes with (CID, R), as generally represented at 360.

[0099] Finally, at shown generally at 362, the publishers 307 (potentially more than one) that have the requested content forward the content toward the subscriber 303 through the network 301. As noted above, the forwarding is done using whatever the appropriate ICN implementation means are, with the additional caveat that it only happens if Ri=R. More particularly, each publisher 307 forwards the content it has that bears the CID matching the CID in the subscription request 356 to the network 301, and the nodes in the network, which were configured in step 360 with (CID, R), determine if the Ri value in the forwarding messages 362 are equal to the R value in the subscription request 356 to which they are responsive. If so, the network 301 forwards the content to the subscribed 03. In essence, the forwarding system may simply treat the pair <CID, R> as the content label/name/ID, but otherwise remain the same. Thus, if Ri≠R, then the system (e.g., the appropriate forwarding node within network 301) "drops" the content simply because it does not know what to do with content <CID, Ri>.

[00100] Note that the fact that the forwarding operation in the network 301 simply treats <CID, R> as the new "CID" leads directly to efficient extensions for simultaneously supporting any number of subscriber requests with any number of associated contexts.

Specifically, for any single CID, but multiple Context Validator values Ri, each forwarding node can be configured with specific routing rules. This allows, for instance, the following options: i) forwarding the same CID to different destinations (different Ri values lead to different forwarding rules in a forwarding node); ii) forwarding to the same destination based on multiple potential context matches (same CID and different Ri values correspond to same forwarding rule).

[00101] Privacy of CXT(SUB) is guaranteed by the inherent privacy of the Fuzzy

Extractor's GEN function, which creates outputs (P,R) that do not reveal the context or requested CID of the subscriber (except for an arbitrarily small leakage) to either the RP node 305 or the publisher node 307. In fact, if Ri≠R, then the value P received from the subscriber 303 provides the publisher 307 even less information (up to an even smaller leakage value) about the subscriber's context, thus providing the subscriber additional privacy and protection against context leakage. Moreover, only the RP knows the full (P, R) pair. The publishers 307 know only P, while the routing nodes in the network 301 know only R.

[00102] Privacy of the Publisher's context, CXT(PUBi), also is guaranteed by the inherent privacy of the Fuzzy Extractor's REP function, which outputs only the context validator (Ri) given the context signature P from the subscriber and the context w' of the content CID at the publisher.

4.2 Searching for Content by Name [00103] Another application of the invention allows a subscriber to execute a search for content by name when it does not know the name precisely. In this example, multiple CIDs are published into the ICN. The subscriber knows an approximate content 10, <CID*>. It uses the GEN function to generate a context signature, P, and validator, R, from the partial context ID, i.e., <P, R> -GEN(CID*) and sends the pair <P, R> as a subscription to RP.

[00104] The RP forwards P to the publisher (or publishers) and configures the forwarding nodes to forward content marked with R to the subscriber.

[00105] The publisher(s) identifies candidate content, CIDi, i.e., content having a CID that matches CID*, and runs the fuzzy extractor REP function on it (using P as an input) to produce Ri - REP (CIDi, P). Then it forwards the content to the network, including Ri. The forwarding nodes in the network drop the content unless Ri=R.

[00106] Note that this procedure is very similar to the procedure in FIG. 3B, but with the following two differences. First, the Context Validator values (i.e., R for the content requested by the subscriber and Ri for the content sent by each responding publisher) have now fully assumed the function of CID in the forwarding operation. The CID is not used at all. Second, the publication step is omitted. Specifically, since CIDs are not used, there is nothing for publishers to publish.

[00107] Due to the non-use of CIDs in this particular exemplary embodiment, the RP does not receive any publications, and thus needs to consider all available publishing nodes (i.e., all potential storage location) as potential sources for the requested CID and, therefore, in at least some embodiments, must forward the requests to all publishers in its domain.

Moreover, each publisher may produce and output a large amount of content, as the publishers do not have a CID from the subscriber. This may create a large load at the publishers and forwarding nodes (especially before all the mismatched data (i.e., the content for which Ri≠ R) is dropped by the network). Thus, this embodiment may not be practical in some networks, particularly larger networks.

[00108] One way to reduce the load in this type of embodiment is to include a "partial" CID with the signature P when the RP sends the delivery request message to the publisher. In this case, then the publisher would send publications only of content that matches the partial CID. With this modification, the procedure becomes almost exactly as in the embodiment of FIG. 3B, except that the CID is not necessarily a unique content name.

Exemplary options for CIDs in accordance with this concept include: a container descriptor (e.g., the "scope" in [4] or [2]) (in which case many different pieces of content share the same CID); an actual CID, with the unknown portion representing the originator context (this procedure then allows searching for the originator context); and a general category (e.g. video) within which the subscribers can search.

4.3 Keeping Things Private from Publishers

[00109] One aspect of the procedures above is that the publishers are fully aware of the context information associated with the content it is storing. If the context is that of a publisher, this is not a problem, and is in fact unavoidable. However, in many cases, the context may be associated with an Information Originator that is a separate entity from the publisher. For instance, the publisher may be just an in-network cache and may not be sufficiently trusted by the Information Originator with the contextual information. In such cases, it would be desirable to keep the context private from the publisher.

[00110] Accordingly, a modified procedure with even greater privacy of Context/CID against publishers as well as other network entities (the RP and the forwarding nodes) is presented below. The procedure is illustrated in the signal flow diagram of FIG. 4 for an exemplary case wherein the information to be hidden from the network is a private portion of a CID and there is only one publisher. These assumptions are made for illustration purposes and/or to simplify the description. It should be understood that neither using information origin context instead of a private CID (or in combination with it) nor having multiple publishers would change the basic operation. Also, for illustrative purposes, FIG. 4 is more representative of a distributed embodiment than FIG. 3B, wherein the RP functions can reside at the publishers, or be split between the publishers and the subscribers and/or other nodes. Note that, in this embodiment, the modifications tend to occur in the first, preparatory steps, rather than the later steps.

[00111] The Information Origin (or Origins) 415i, 4152, ... 415_n partitions the CIDs of its content into public and private portions, as shown at 450. Then it performs the GEN function of the fuzzy extractor on the private portions of the CIDs to generate a context signature Pi and a context validator Ri for each content, as shown at 452.

[00112] Next, the information originators send the public portions of the CIDs along with the corresponding signatures Pi generated from the private portions of the same CIDs to the subscribers 403 through the network 401. This is done for every single public/private CID pair (or CID/Context pair, if context is used instead of private CID).

[00113] Similarly, the information originators 415 send the publishers, such as publisher 407, the public CIDs of the content that the publishers store along with the validator Ri generated from the private portion of the same CID, as shown at 456.

[00114] The rest of the procedure follows a relatively standard ICN operation, with the pair <public CID, Ri> used in place of CID and a small modification in the Subscription and Matching process. That is, the publisher 407 publishes this pair as a Content Identifier to the RP 405, as shown at 458.

[00115] When the subscriber wishes to subscribe to a piece of content, the subscriber 403 generates a Context Validator Qj using the fuzzy extractor's REP function for each Pj it was provided in step 454 using its own local CID search term (for search against a private CID) and/or context encoding (for content match), as shown at 460.

[00116] The subscriber 403 sends a message to the RP 405 subscribing to all content having the pair <public CID, Qj>, as shown at 462.

[00117] The RP 405 matches publisher 407 and subscriber 403 IF AND ONLY IF the public CIDs match and Ri=OJ, as shown at 464.

[00118] Once this match is complete, the publisher sends the requested content toward the subscriber and the forwarding network is configured as is usual in ICN, as shown at 466. Note that, in the distributed type of embodiment of FIG. 4, the RP function 405 may reside at the publisher. Thus, in this exemplary embodiment, for instance, (1) the signalling that was shown in FIG. 3B for sending delivery requests to the publisher (see 358 in FIG. 3B) is not shown here and (2) the forwarding of the content from the publisher 407, through the network 401, and to the subscriber 403 also is not separately illustrated, but is deemed to be subsumed within signalling 466. 5 Optimized Secure Sketches

[001 19] Contextual information in ICN is likely to be encoded as metadata (e.g., XML documents, JSON objects, etc.). However, no secure sketch designed specifically for metadata has yet been developed, and secure sketches developed for other purposes, such as biometric authentication, may not work well for metadata. Accordingly, disclosed herein are Secure Sketches specifically optimized for metadata (and similarly structured objects). While the particular application of focus in this specification is ICN matching, the proposed Secure Sketches can be applied in any setting where a Secure Sketch for metadata-like objects is required.

5.1 Secure Sketches for String Edit Distance

[00120] This section describes two possible Secure Sketches for the "edit distance" metric on strings. Then, in Section 5.2 such a sketch is used as a building block of Secure Sketches for metadata represented as a labelled tree. However, any other Secure Sketch for edit distance can be used, see, e.g., [16] . Additionally, two flavors of "edit distance" are described, namely, a standard one and an extended one that allows for moves of entire substrings from one place in the "master" string to another as a single "edit" operation (which can be thought of as cut-and-paste operation).

[00121] Given two string w and w', let us define the edit distance disEdit(w,w') as the smallest number of insertions and deletions needed to get from w to w'. Note that a change in a character is equivalent to 2 edit operations (i.e., an insertion and a deletion in any order). Edit distance is a natural metric for applications such as password entry, where mis-types often result in missed and added characters. Further, recall that a Hamming distance, disH(w,w'), between two strings of the same length is the number of positions where the strings are different. Thus, because a change of character can be accomplished by one deletion and one insertion, disEdit(w,w')=2 disH(w,w'). However, this relationship is not absolute in all cases insofar as it is not always possible to absolutely determine a Hamming distance. Particularly, when two strings are not of the same length (especially when an error changes the length of a string), the Hamming distance between them is not well defined.

[00122] In a variation of disEdit(w,w'), one may count a single character change as just a single edit, as opposed to two edits. These two alternatives are the same for present purposes up to a factor of at most 2 in the actual value of the distance metric. As long as we keep this factor of 2 difference in mind, the rest of the discussion applies equally to both options. As such, we can and do use the two interchangeably herein.

[00123] Finally, given two string w and w', the edit distance with moves disEditMove(w,w') is defined as the smallest number of insertions, deletions, and sub-string cut-and-paste operations needed to get from w to w', where a sub-string cut-and-paste involves removing a sub-string from the string and pasting it into a different position in the string.

5.1.1 Construction 1 for String Edit Distance

[00124] This Secure Sketch for the edit distance is based on the shingling concept introduced in [15]. Particularly, consider a string w. Then, a c-shingle is a consecutive substring of w of length c. A c-shingling of w is the set of all c-shingles of w ignoring order in which the shingles occur or repetitions. For example, a 3-shingling of "abcdecdegh" is {abc, bed, cde, dec, ecd, deg, egh} . Note that cde appears only once, not twice. The shingling approach converts an edit distance problem into a set difference problem, wherein a single insertion, deletion, or character change results in at most 2c- 1 differences in the c- shingling. A single substring move results in at most 6c differences in the c-shingling (a substring move affects 3 adjacent character pairs), making that this approach is readily extendible to disEditMove.

[00125] For a general secure sketch, a c-shingling is not sufficient to recover the original sequence w. What is needed is a mapping function that describes the position(s) of each shingle in the string (recall that a single shingle may be repeated multiple times in a string, but only counts as one shingle). However, for a Fuzzy Extractor, this additional function is not necessary since a Fuzzy Extractor does not need to recover the original string (recall that the goal is to match a noisy copy to the original without storing anything that itself discloses any information about the original).

[00126] Once the Edit Distance problem is converted to a Set Distance, the techniques for Set Distance in [6]Error! Reference source not found, can be applied (and these themselves convert the Set Distance problem into a Hamming Distance one). We omit that discussion, but the interested reader may refer to [6], in particular the discussion in Section 6.3 of [6] (Large Universes via the Hamming Metric: Sublinear-Time Decoding). 5.1.2 Construction 2 for String Edit Distance

[00127] This second construction is based on the erasure-code based technique for remote file synchronization as described in [17] . Let us assume that a server which holds a string (equivalently a file) w that has changed a bit and it has a client which now holds a stale copy of it. Let us further assume that there is a protocol that will allow the server to efficiently send only an update (as opposed to the whole file) to the client in such a way as to allow the client to synchronize its file string. The "update" can be viewed as the secure sketch, the procedure of generating the update can be viewed as the SS function, and the procedure that the client uses to synchronize itself can be viewed as the REC function.

The SS Function

[00128] The construction operates as follows. Given a string w, both the server and the client start by partitioning it into a set of blocks B. The blocks should be of as equal length as possible, but this is not necessary (the more equal the blocks are in length the better the protocol will work). Then, each block is split into several blocks (again, for performance reasons, these should be as close in size as possible). For simplicity of exposition, let us assume each block is split into 2 sub-blocks. In fact, this is often the optimal choice from a performance point of view. However, splitting each block into a larger number of sub-blocks is possible.

[00129] This splitting operation is continued for N rounds, where N is an integer greater than or equal to 1 and is a design parameter. Preferably, N should not be so large as to result in the need to "split" a single-character block, as this would not be possible. We now have N+l levels of string partitions, where each level (n) contains 2nB blocks and each block at level n is contained within a single block at level n-1.

[00130] Next, each block at each level is hashed using any secure hash, except that, at the very lowest level, the blocks are not hashed (e.g., the hash function is an identity function). Preferably, the hash is short. In particular, preferably, it is quite a bit shorter than the block size at the top level. On the other hand, preferably, it is large enough to reduce the probability of collision to a negligible value.

[00131] Finally, at each level, a block-alphabet (i.e. non-binary) erasure code is applied to the set of hashes for that level. The code should be (i) systematic (meaning that the codeword contains the original input plus a set of check symbols) and (ii) designed to protect against at least 2k erasures, where k is the total number of edits and string moves needed to convert from the updated file to the outdated file. Existence of such codes is well known (see, e.g., Fountain Codes (https://en.wikipedia.org/wiki/Fountain_code)).

Secure Sketch

[00132] The set of hashes for the top level block plus all the erasure code check symbols together constitute the output of the Secure Sketch in this construction (e.g., S in FIG. 2).

The REC Function

[00133] To properly understand the REC function, we start with a file reconstruction procedure that involves multiple interactive rounds, but does not require the use of erasure codes (as in paragraph 131). The server starts at the top level and sends all hashes to the client. The receiver (client) attempts to match the received hashes to all possible alignments in its copy of the file and reports to the server which hashes were matched and which were not. For the hashes for which a match was not found, the server goes down one level and sends the hashes for the sub-blocks of these (un-matched) hashes. This protocol continues until either all hashes are matched or the lowest level of blocks is reached. At that point, any still unmatched blocks are sent without hashes (recall we do not hash the lowest level), thereby allowing the receiver (client) to fill in any remaining "holes" in its file.

[00134] Note the following features and aspects of this protocol. Let us consider a total of k edit (delete/insert/replace) and string move errors in a string/file of length n (where, since we are interested in strings with a small number of errors, k is significantly smaller than n). If we ignore the probability of hash collisions, then, per [17] [17], a proper selection of partitioning yields a result in which, at each level after the first one, only about 2k blocks are unmatched and thus only about 2k hashes have to be sent at each level (after the top level).

[00135] One such proper parameter selection (per [17]) is as follows. Each block has exactly two sub-blocks, with all blocks and sub-blocks as equally sized as possible. The largest sub-blocks (first level) should have size (n/k) (to a nearest integer). The smallest sub- blocks (lowest level) should have size log2(n) (to a nearest integer). [00136] Finally, if a hash collision does occur, the operation fails. This is a standard problem for most hash applications and the acceptable collision (i.e., failure) probability is a design criterion. Generally, it can be kept very low even for rather short hashes.

[00137] To obtain the actual REC procedure, we simply need to revise the multi-round protocol above into a single-round protocol as follows. The server sends the hashes for the top-level block as in the original protocol, plus all the check symbols for all the erasure codes for all other levels). The receiver (client) starts at the top block level as before. For the blocks whose hashes were matched, it is now able to obtain the original string and can therefore break the string up and compute the hashes of the sub-blocks in the next lower level. As noted above, this means that no more than 2k sub-hashes at the lower level are missing. These are recovered using erasure decoding - using the locally computed hashes and erasure check symbols - and these are now checked against the string itself. Again, some will match, and others will not. The matches can be used to compute more of the string and to compute the hashes for the next level. The procedure continues until the lowest level, where the erasure codes at the lowest level fill any "holes" still left in the string.

5.2 Secure Sketch for Tree Edit Distance

[00138] With this background in mind, a secure sketch for the tree edit is described herein below. Let us assume that the tree is rooted and ordered; specifically, that the tree T has a root node that has children, vi, ... , v_n,. Each child node, in turn, may also have one or more child nodes (which might be referred to as grandchildren nodes), each grandchild node may have one or more children nodes, and so on. For each node, its children are ordered according to a well-known order. These assumptions are actually not restricting since, in general, a root and ordering can always be imposed on any tree. Furthermore, in the case of Metadata (e.g. XML documents), a root is naturally imposed and a natural (often

alphabetical) ordering of child nodes is then easy to impose.

[00139] For a node v, note the following definitions: d(v) is the number of children of v;

if d(v)=0, then v is called a leaf node (otherwise, v is called an internal node);

π(ν) is the parent of v, with (r) = NULL since the root node does not have a parent node; T(v) is the subtree starting at v, i.e., where v is the root of the sub-tree;

d* = maxvd(v) is the maximal node degree in the tree (we assume that this is known and finite); and

the tree is finite, i.e., the tree has a finite number of nodes (this also implies that it has a finite depth; however, the actual depth is not important to the present calculations).

[00140] Finally, we are interested in labelled trees, specifically, a label l(v) is associated with each node v. Note that metadata typically is encoded using means that easily translate into a labelled tree. This may be illustrated with a simple XML-based metadata, taken from a W3C school tutorial on XML (http://www.w3schools.com/xml/xml_attributes.asp). The XML document (a set of attributes associated with e-mail messages where the body of the exchange would have been the "data") is shown in FIG. 5 and the corresponding labeled tree is shown in FIG. 6.

[00141] Observe from FIG. 6Error! Reference source not found, that the structure of the XML document implies a clear root (the top level label 601) as well as clear tree structure, i.e., each label has sub-labels, but no loop references, etc. Moreover, an order is easily implied (e.g., by note id at 1st level nodes 603, 605, and by ordering the labels

to/from/heading in the 2nd level nodes 607, 609. 611, 613, 615, 617). Finally, the tree is clearly labelled. In fact, the modeling of metadata and XML documents as labelled trees is well known.

[00142] Next we define the following "Tree Edit" operations: ChangeLabel(i/,/): set l(v)=l;

DeleteLeaf (i ): operation can only be called for a leaf node v and results in removing v from the tree;

InsertLeaf (ν,Ί,Ι): inserts a new child node for node v in position ; and label /, where we require d(v)≥ i-1 for the operation to make sense.

[00143] We note that entire sub-trees can be deleted, inserted, or changed through repeated calls on these basic operations. Given two trees Ti and T₂, we define a Tree Edit Distance disTree(Tl, T2) to be the smallest number of operation from the set above (ChangeLabel, DeleteLeaf, InsertLeaf) required to transform Ti into T₂. [00144] Additionally, we define a more complex operation MoveSubTree. For a node v that is not in the sub-tree T(w), MoveSubTree(v, w, i) moves the node w into the i-th child position of v, while preserving the entire sub-tree T(w) (i.e., the entire sub-tree moves with the sub-tree root node). Again we require d(v) > i-1 prior to the move for the operation to make sense. We can now define the SubTree Edit Distance dis_subT(Tl, T2) as the smallest number of operation from the set (ChangeLabel, DeleteLeaf, InsertLeaf, MoveSubTree) required to transform Ti into T2.

[00145] Clearly,

5.3 Converting a Tree into a String

[00146] Next, it will be shown that, with a proper transformation, any labelled ordered tree can be converted into a string in such a way that: (1) the operation is 1-to-l, i.e., the original tree can always be recovered from the resulting string,(2) the three basic edit operations defined above (ChangeLabel, DeleteLeaf, InsertLeaf) correspond to a small well-defined number of basic string edit operations (insert/delete); and (3) the MoveSubTree operation corresponds to a small well-defined number of basic string edit operations (insert/delete) plus one sub-string move.

[00147] Conditions (1) and (2) can be satisfied by any of the well-known traversal algorithms for trees, the two most common being Depth First Search (DFS) and Breadth First Search (BFS). In both cases, the tree labels are simply appended to each other in the order that the tree is searched. Special characters may be used to mark boundaries between labels and to record special information that is dependent on the type of search. For DFS, this special information usually includes the node degree (i.e., the number of children that a node has), a marker that indicates the direction to the next node (up or down the tree), etc. For BFS, this could be a node degree, a marker to indicate the last node in a level (which means that the traversal is moving one level down), etc. Many textbooks on algorithms are available for more information on tree traversal, e.g., [17].

[00148] The following illustrates the procedure described above using DFS as an example and shows how to convert the graph of FIG. 6Error! Reference source not found, into a string. The example uses the following special characters: \#, which precedes the node degree, and which is followed by \!, which indicates the node label boundary. The resulting string is: messages\#2\ ! node id =

501\#3\ ! to="Tove"\#0\ ! from="Jani"\#0 \ ! heading="Reminder"\#0 \ ! \ ! node id = 502\#3\!to="Jani"\#0\!from="Tove"\#0\!heading="Reminder" \#0\!

[00149] Let L be the maximum label size. Furthermore, let C be the number of digits in the maximum node degree. For trees representing metadata, it is unlikely that the number of children that a node would ever approach 100, so C is rarely more than 2 (assuming decimal notation, which is typical for metadata). Then, it is clear that, given any reasonable mapping from trees to strings (and particularly for both DFS and BFS mappings), there is a linear map from tree edit operations to string edit operations. In particular, ChangeLabel corresponds to a change of at most L characters and thus at most 2L string edit operations. DeleteLeaf involves deleting one label (at most L characters), two special characters, and the node degree (at most 2 characters), and then changing the parent's node degree (at most 2 character edit). Thus, it corresponds to, at most, +8 string edit operations. Finally, InsertLeaf is effectively the "mirror image" of DeleteLeaf, and also involves, at most, +8 string edit operations.

[00150] In fact, since most labels will be much shorter than the permitted maximum length L, these bounds are very loose.

[00151] Thus, in summary, the algorithm for the Secure Sketch for the Tree Edit distance disTree may be described as: (1) use any appropriate tree-traversal algorithm (e.g., BFS or DFS) to convert the tree to a string and (2) apply an appropriate Edit Distance Secure Sketch to the string.

[00152] While this procedure satisfies requirements (1) and (2) noted above (i.e., the operation is 1-to-l and the three basic edit operations ChangeLabel, DeleteLeaf, InsertLeaf correspond to a small well-defined number of basic string edit operations), it does not, in itself, address condition (3), i.e., it does not assure that the MoveSubTree operation corresponds to a small well-defined number of basic string edit operations (insert/delete) plus one sub-string move. Hence, it does not provide a Secure Sketch for the dissubT distance. In many applications, this indeed may be sufficient (i.e., disTree is a good distance measure). But in others, sub-tree moves may be common (such that a Secure Sketch that can address dissubT is, in fact, needed). Thus, to satisfy this last condition, one may restrict the procedure to the DFS tree traversal technique, and note that DFS preserves sub-trees. Specifically, when DFS is used to convert a labelled tree into a string, every sub-tree becomes a single contiguous sub-string of the overall string. Thus, if DFS is used for the conversion to a string, a sub-tree move becomes a sub-string move in a resulting string. Hence, with this restriction in place, both Secure Sketch constructions presented above can be used for the dissubT distance. As such, the conversion procedure presented above, when used with DFS tree traversal, inherently provides a secure sketch for the dissubT distance.

6 Embodiments for Avoiding Extra Signalling

[00153] Embodiments such as those of FIGS. 2, 3A, and 3B provide solutions utilizing extra signalling between the RP and the publications and subscribers in addition to the 'pure' signalling of publications and subscriptions. Furthermore, the embodiment of FIG. 3B requires instructions to be sent to the forwarding subsystem to "drop" content forwarding if R does not match Ri. While these embodiments can be realized by amending existing systems such as [1][2] [4] to add such additional signalling, alternately, the following section outlines embodiments that embed the solutions within the basic signalling that is already defined in [1] [2] [3].

6.1 Alternative Namespaces

[00154] One embodiment uses a design for a namespace that the RP, publishers, and subscribers can use for communicating the fuzzy extractor information and wherein the final decision of the (fuzzy extractor) match is performed at the RP. In this type of embodiment, the aspect of instructing the forwarding subsystem to "drop" content previously described is entirely avoided by matching only those publishers for which R=Ri to the subscription request. All other publishers are not matched and therefore never initiate the forwarding of any data that needs to be dropped. This embodiment is particularly suitable for ICN architectures such as described in [2] and [4].

[00155] FIG. 7 shows the proposed additional namespace, located under its own root identifier (/root) 710. The next level places each publisher (PUBi) 712 and subscriber (SUBj) 714 as a scope identifier [2] under the root identifier. SUBj 714 and PUBi 712 are used as examples for identifying a subscriber and publisher that has sent fuzzy extractor constraints to the RP, similarly to the embodiment of FIG. 3B. Under each publisher 712 is located the content identifier CID 716 for which that publisher has indicated availability of the content, and, under each subscriber 714 is located the content identifier CID 717 for which a subscriber has shown interest. In accordance with this embodiment, under each individual CID 716 and 717 is now located the fuzzy extractor information, e.g., calculated as described hereinabove. Specifically, in FIG. 7, they are exemplified as P 718 and R 720 (e.g., the context signature P and the context validator R, respectively, from the embodiment of FIG. 3B) for the subscriber 714 CID 717, and P 722, and Ri 724 (e.g., the context signature P and the validation mask Ri, respectively, from the same embodiment) for the publisher 712 CID 716.

[00156] More particularly, in order to build this namespace, the following communication relationships are created. The particular subscriber SUBj 714 publishes its fuzzy extractor information P 718 and R 720 to the scope /root/SUBi/CID 717. As will be seen, this will allow the subscriber to subsequently request content in accordance with this embodiment by simply issuing a 'standard' subscription to the RP, which identifies the requested content by only its CID.

[00157] Each publisher PUBi subscribes to the fuzzy extractor information under /root/ PUBi /CID for each CID that it offers as content to the system. Upon receiving, in response to that subscription, a publication of item P under any scope /root/ PUBi /CID (which exists in that location in accordance with the discussion in the following paragraph), the publisher PUBi will calculate the appropriate validation mask Ri for its copy of that content CID and publish that validation mask Ri back to the namespace under the same scope.

[00158] The RP subscribes to each SUBj and PUBi under the /root scope 710. Upon receiving, in response to each such subscription, a publication to a /CID under any SUBj 714 or PUBi 712, the RP will furthermore subscribe to the /root/ SUBj /CID scope or /root/ PUBi /CID scope, respectively, so that it receives any fuzzy extractor information pertaining to this CID. Upon receiving a publication in any /root/ SUBj /CID, the RP will subscribe to the items /root/ SUBj /CID/P and /root/ SUBj /CID/R to receive any fuzzy extractor constraints by the subscriber, e.g., P 718 and R 720. Upon receiving, in response thereto, publication under the items /root/ SUBj/CID/P and /root/ SUBj/CID/R, the RP will publish those received Ps under all /root/PUBi subscopes that contain content having the same CID (i.e., to all possible publishers of CID) and will subscribe to /root/PUBi/CID/Ri 724 in order to receive the validation mask Ri from publisher PUBi 716 (see next paragraph for description of the creation of Ri 724).

[00159] Upon receiving subscriptions to /root/PUBi/CID/Ri values from all of its publishers for CID, the RP can perform a positive matching to a 'standard' subscriber subscription to CID between all subscribers and publishers for which R= Ri holds true without the need to configure the forwarding system of the network to determine if R=Ri.

[00160] The procedures outlined above, acting upon the namespace of FIG. 7, can be easily implemented as an application-specific extension to the publisher, subscriber, and RP. With that, RPs can differentiate their 'standard' ICN operation with the fuzzy extractor functionality of the present invention. Furthermore, we can foresee the hosting of the fuzzy extractor namespace at a separate entity (e.g., another RP) than the local RP that also implements the communication behavior outlined above.

6.2 Additional Lookups at Local Forwarding Node

[00161] ICN architectures such as described in [1] do not perform a logically centralized rendezvous function. Instead, a periodic update of the so-called Forwarding Information Base (FIB) results in name-based forwarding tables that 'point' the node-local forwarding engine toward the next link along which the (published) information is likely to reside. Due to the periodic nature of the FIB updates (and its associated costs), it is unsuitable to consider the fuzzy extractor matching to be integrated into such a periodic update. Therefore, the additional signalling should be performed when making the local forwarding decision. In [1], subscriptions are sent by clients by issuing an INTEREST packet which contains the CID of the content to be retrieved, while a DATA packet is returned from any matching publisher of this item CID.

[00162] In one embodiment, the context signature P and the context validator R may be included as an XQUERY-compliant extension to the CID name, e.g.,

www.foo.com?P="P";R=R"R". When receiving the INTEREST packet, each CCN/NDN (Content Centric Networking/Name Data Networking) router may perform the following operations:

1. Extract the information on P and R from the extended CID information in the INTEREST packet; 2. Calculate Ri^REP(CXT(PUB),P), where we assume that CXT(PUB) for the publisher of CID is known at the routing node (e.g., CCN) having the FIB (note that, if the FIB entry for CID contains more than one entry, the calculation is done for several publishers, assuming all CXT(PUBi) to be known to the CCN router); and

3. The CCN router only forwards the INTEREST packet along the suitable link (which is associated with publisher PUBi) if R, as received in the INTEREST packet, matches Ri, as calculated in step 2 immediately above.

[00163] In one exemplary embodiment of step 2, one can assume that the information regarding CXT(PUB) is part of the periodic update of the FIB state information, e.g., using some form of link state protocol. Alternately, a resolution service may be used that retrieves the context information CXT(PUB) for any publisher PUB (this resolution function might operate an additional CCN router local cache in order to minimize the need for on-demand resolution for every incoming INTEREST packet).

[00164] In yet another embodiment, the CXT (SUB) is included in the interest packet and the (P,R) information for every Publishing node is appended to the CID entry in each FIB. Upon receiving an INTEREST packet with CXT(SUB) in it, each CCN node uses the P from each FIB to calculate R* from CXT(SUB) and forwards (or services) the interest according the entry where R* = R.

7 Conclusion

[00165] The functionality described hereinabove may be implemented in any reasonable manner, such as by software running on a processor, application specific integrated circuits (ASICs), logic circuits, analog circuitry, digital circuits, FPGAs, state machines, and/or any combinations of the above. In one likely embodiment, the functionality described hereinabove (e.g., imperfect matching, fuzzy extractor GEN and REC functions, assembling and transmitting messages, receiving and extracting information from messages) will be performed by software running on a processor incorporated into the particular device that performs other functions than those mentioned herein. That processor may interface with and at least partially control transmitter and receiver circuits to cause the described messages to be transmitted via networks (wired and/or wireless) or other means of electronic

communication between the various nodes. For instance, the apparatus, methods, and functionality described hereinabove may be incorporated into one or more of the nodes described herein in connection with FIGS. 1A-1E and may use the processors, receivers, transmitters, transceivers, antennas, and other components of such devices along with the appropriate software to perform the methods and/or create the apparatus described herein.

[00166] Throughout the disclosure, one of skill understands that certain representative embodiments may be used in the alternative or in combination with other representative embodiments.

[00167] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer readable medium for execution by a computer or processor. Examples of non- transitory computer-readable storage media include, but are not limited to, a read only memory (ROM), random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WRTU, UE, terminal, base station, RNC, or any host computer.

[00168] Moreover, in the embodiments described above, processing platforms, computing systems, controllers, and other devices containing processors are noted. These devices may contain at least one Central Processing Unit ("CPU") and memory. In accordance with the practices of persons skilled in the art of computer programming, reference to acts and symbolic representations of operations or instructions may be performed by the various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed", "computer executed", or "CPU executed".

[00169] One of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. An electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signals and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU's operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the data bits.

[00170] The data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory ("RAM")) or non-volatile ("e.g., Read-Only Memory ("ROM")) mass storage system readable by the CPU. The computer readable medium may include cooperating or interconnected computer readable medium, which exist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It is understood that the representative embodiments are not limited to the above- mentioned memories and that other platforms and memories may support the described methods.

[00171] No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. In addition, as used herein, the article "a" is intended to include one or more items. Where only one item is intended, the term "one" or similar language is used. Further, the terms "any of followed by a listing of a plurality of items and/or a plurality of categories of items, as used herein, are intended to include "any of," "any combination of," "any multiple of," and/or "any combination of multiples of the items and/or the categories of items, individually or in conjunction with other items and/or other categories of items. Further, as used herein, the term "set" is intended to include any number of items, including zero. Further, as used herein, the term "number" is intended to include any number, including zero.

[00172] Moreover, the claims should not be read as limited to the described order or elements unless stated to that effect. In addition, use of the term "means" in any claim is intended to invoke 35 U.S.C. §112, [ 6, and any claim without the word "means" is not so intended.

[00173] Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs); Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine.

[00174] A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WRTU), user equipment (UE), terminal, base station, Mobility Management Entity (MME) or Evolved Packet Core (EPC), or any host computer. The WRTU may be used m conjunction with modules, implemented in hardware and/or software including a Software Defined Radio (SDR), and other components such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (FM) radio unit, a Near Field Communication (NFC) Module, a liquid crystal display (LCD) display unit, an organic light-emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and/or any Wireless Local Area Network (WLAN) or Ultra Wide Band (UWB) module.

[00175] Although the invention has been described in terms of communication systems, it is contemplated that the systems may be implemented in software on microprocessors/general purpose computers (not shown). In certain embodiments, one or more of the functions of the various components may be implemented in software that controls a general -purpose computer.

[00176] In addition, although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims and without departing from the invention.

8 References

[00177] As least some of the following references, all of which are incorporated herein fully by reference, were mentioned hereinabove.

[1] V. Jacobson, "Networking named content", Proceedings of the 5th

international conference on Emerging networking experiments and technologies, ACM CoNext, 2009 [2] D. Trossen, G. Parisis, Designing and Realizing An Information-Centric Internet, IEEE Communications Magazine Special Issue on "Information-centric Networking", July 2012

[3] D. Trossen, G. Biczok, Not Paying the Truck Driver: Differentiated Pricing for the Future Internet, ReArch 2010 workshop in conjunction with ACM Conext, December 2010

[4] U.S. Provisional Patent Application No. 62/102,405, entitled Methods, Information-Centric Networking, filed January 12, 2015.

[5] U.S. Provisional Patent Application No. 62/146,641, entitled Methods, Apparatus and Systems for Use with Information-Centric Networking (ICN) filed April 13, 2015.

[6] Y. Dodis, et. al, "Fuzzy Extractors: How to Generate Strong Keys from Biometrics and Other Noisy Data," SIAM Journal on Computing, 38(1): 97-139, 2008.

[7] J.. Hastad, et. al, "Construction of a Pseudo-Random Generator from a One- Way Function," SIAM Journal on Computing, 28(4): 1364-1396, 1999.

[8] O. Goldreich, Foundation of Cryptography, Cambridge U. Press, 2001.

[9] M. Luby, Pseudorandomness and Cryptographic Applications, Princeton Computer Science Note, Princeton U. Press, 1996.

[10] L. Carter and M. N. Wegman, "Universal Classes of Hash Functions," JCSS 18(2): 143-154, 1979.

[11] M. N. Wegman and L. Carter, "New Hash Functions and Their Use in Authentication and Set Equality," JCSS 22(3): 265-279, 1981.

[12] Y. Dodis et. al, "Randomness Extraction and Key Derivation Using the CBC, Cascade and HMAC Modes," Advances in Cryptology - CRYPTO, August 2004.

[13] A. Juels and M. Wattenberg, "A fuzzy commitment scheme," in Proc. Sixth ACM Conf. on Computer and Comm. Security," ACM, Nov. 1999. [14] A. Juels and M. Sudan, "A fuzzy vault scheme," Designs, Codes and

Cryptography, 38(2): 237-257, 2006.

[15] A. Broder, "On the resemblance and containment of documents," in Proc. Of Compression and Complexity of Sequences, 1997.

[16] R. Ostrovsky and Y. Rabani, "Low-distortion embeddings for edit distance," in Proc. Of 37th ACM Symposium on Theory of Computing, pp. 218-224, May 2005.

[17] U. Irmak, S. Mihaylov and T. Suel, "Improved single-round protocols for remote file synchronization." In Proc. IEEE INFOCOM 2005, pp. 1665-1676.

[18] T. H. Cormen, C. E. Leiserson, R. L. Rivest and C. Stein, Introduction to Algorithms, 2nd Ed., 2001.

Claims

1. A method of matching a publisher of content with a subscriber of content in a network, the method comprising:

a subscriber performing a first randomness extraction function on contextual information associated with requested content to generate a first randomness-extracted credential imprecisely indicative of the contextual information;

the subscriber generating a subscription for the requested content, the subscription comprising at least a partial identification of the requested content (CID) and the first randomness-extracted credential;

transmitting the CID and first randomness-extracted credential toward at least one publisher;

the at least one publisher performing a second randomness extraction function corresponding to the first randomness extraction function on contextual information associated with a local copy of the content having content identification CID to produce a second randomness-extracted credential imprecisely indicative of the contextual information of the local copy of the content having context identification CID;

transmitting the local copy of the content having content identification CID toward the subscriber if the second randomness-extracted credential matches the first context signature.

2. The method of claim 1 wherein the network is an Information Centric Network (ICN).

3. The method of claim 1 further comprising:

the publishers advertising the content available at the publishers; and

maintaining a database of the content available at the publishers.

4. The method of claim 1 wherein the contextual information comprises at least one of storage format, transcoding rate, and network state.

5. A method of matching a publisher of content with a subscriber of content in a network, the method comprising: a subscriber performing a fuzzy extractor generate function on contextual information associated with requested content to generate a context signature (P) indicative of the contextual information and a context validator (R) indicative of the contextual information; the subscriber generating a subscription for the requested content, the subscription comprising at least a partial identification of the requested content (CID), P, and R;

transmitting the CID and P toward at least one publisher;

configuring the network to terminate delivery of content having content identification CID to the subscriber unless the content is associated with a context validator that matches R; the at least one publisher performing a fuzzy extractor reproduce function using P and contextual information of a local copy of the content having content identification CID to generate a context validator, Ri, and sending the copy of the local content having content identification CID and Ri toward the subscriber.

6. The method of claim 5 wherein the network is an Information Centric Network (ICN).

7. The method of claim 5 further comprising:

the network forwarding the content forward message to the subscriber if Ri matches

R; and

the network terminating forwarding of the content forward message to the subscriber if Ri does not match R.

8. The method of claim 5 further comprising:

the publishers advertising the content available at the publishers; and

maintaining a database of the content available at the publishers.

9. The method of claim 5 wherein the contextual information comprises at least one of storage format, transcoding rate, and network state.

10. A method implemented in a subscriber node of a network, the method comprising: performing a fuzzy extractor generate function on contextual information pertaining to a piece of content to generate a context signature, P, indicative of the contextual information and a context validator, R, indicative of the contextual information; sending a subscription message for content, the request message comprising at least a partial identification of the requested content (CID), P, and R; and

receiving content responsive to the subscription message.

11. The method of claim 10 wherein the contextual information comprises at least one of storage format, transcoding rate, and network state.

12. A method implemented in a publisher node of a network, the method comprising: receiving a subscription for content stored at the publisher node, the request including an identification of the requested content (CID) and a context signature (P) comprising an output of a secure sketch generation function of a fuzzy extractor performed on contextual information associated with the content, and being indicative of the contextual information; performing a fuzzy extractor reproduce function on P and contextual information of the content stored at the publisher corresponding to CID to generate a context validator, Ri, representative of contextual information of the content stored at the publisher corresponding to CID; and

sending the content and Ri responsive to the subscription.

13. The method of claim 12 further comprising:

advertising content available at the publisher to the network.

14. The method of claim 12 wherein the contextual information comprises at least one of storage format, transcoding rate, and network state.

15. A method of matching a publisher of content with a subscriber of content in a network, the method comprising:

receiving a subscription for content, the subscription message comprising at least a partial identification of requested content (CID), a context signature (P), and a context validator (R), wherein P and R are outputs of a fuzzy extractor generate function performed on contextual information associated with the content;

matching the subscription to one or more publishers having a copy of the requested content; providing the CID and P to at least one publisher having a copy of the requested content; and

causing the network to deliver content having content identification CID to the subscriber if the content is associated with a context validator that matches R and causing the network to not deliver content having content identification CID to the subscriber if the content is associated with a context validator that does not match R.

16. The method of claim 15 wherein the causing step comprises:

configuring the network to terminate delivery of content having content identification CID to the subscriber unless the content is associated with a context validator that matches R.

17. The method of claim 15 further comprising:

receiving from the publisher data as to the content available at the publisher; and maintaining a database of the content available at the publisher.

18. The method of claim 15 wherein the contextual information comprises at least one of storage format, transcoding rate, and network state.

19. A subscriber node of a network comprising:

a transmitter;

a receiver;

a processor in communication with the transmitter and the receiver, the processor adapted to:

perform a fuzzy extractor generate function on contextual information pertaining to requested content to generate a context signature, P, indicative of the contextual information and a context validator, R, indicative of the contextual information;

generate a subscription for the requested content, the subscription comprising at least a partial identification of the requested content (CID), P, and R;

control the transmitter to send the subscription toward at least one publisher; and

control the receiver to receive content responsive to the subscription.

20. The node of claim 19 wherein the contextual information comprises at least one of storage format, transcoding rate, and network state.

21. A publisher node of a network comprising:

a transmitter;

a receiver;

a processor in communication with the transmitter and the receiver, the processor adapted to:

receive a subscription for content stored at the publisher node, the subscription including an identification of the requested content (CID) and a context signature (P), wherein P comprises a signature output of a fuzzy extractor generate function performed on contextual information pertaining to the content and is indicative of contextual information;

perform a fuzzy extractor reproduce function on P and contextual information of the content stored at the publisher corresponding to CID to generate a context validator, Ri, representative of contextual information of the content stored at the publisher corresponding to CID; and

send the content and Ri responsive to the subscription.

22. The node of claim 21 further comprising:

advertising content available at the publisher to a rendezvous function (RP).

23. The method of claim 21 wherein the contextual information comprises at least one of storage format, transcoding rate, and network state.

24. A network node for matching a publisher of content with a subscriber of content in a network comprising:

a transmitter;

a receiver;

a processor in communication with the transmitter and the receiver, the processor adapted to: receive a subscription for content, the subscription message comprising at least a partial identification of the requested content (CID), a context signature (P), and a context validator (R), wherein P and R are outputs of a fuzzy extractor generate function performed on contextual information pertaining to the content;

match the subscription to one or more publishers having a copy of the requested content;

provide the CID and P to at least one publisher having a copy of the requested content; and

configure the network to terminate delivery of content having content identification CID to the subscriber unless the content is associated with a context validator that matches R.

25. The node of claim 24 wherein the processor is further adapted to:

receive from the publisher data as to the content available at the publisher; and maintain a database of the content available at the publisher.

26. The node of claim 24 wherein the contextual information comprises at least one of storage format, transcoding rate, and network state.

27. A method of matching a publisher of content with a subscriber of content in a network, the method comprising:

a subscriber performing a fuzzy extractor generate function on information pertaining to a desired content to generate a signature value (P) indicative of the information pertaining to the piece of desired content and a validator value (R) indicative of the information pertaining to the piece of desired content;

the subscriber generating a subscription for the desired content, the subscription comprising at least P and R;

providing at least P to at least one publisher;

configuring the network to terminate delivery of content to the subscriber in response to the subscription message unless that content is associated with a validator value equal to R; the at least one publisher performing a fuzzy extractor reproduce function using the received P and information associated with local content available from the publisher to generate a context validator, Ri, associated with the content available from the publisher, and sending the local content and the associated Ri.

28. The method of claim 27 wherein the information pertaining to the desired content is a partial identification of the content (CID*)

29. The method of claim wherein the information pertaining to the desired content is contextual information pertaining to the desired content.

26. The method of claim 23 wherein the contextual information comprises at least one of storage format, transcoding rate, and network state.

27. A method of matching a publisher of content with a subscriber of content in a network, the method comprising:

partitioning data about content into first and second portions;

performing a fuzzy extractor generation function on the first portion to generate a signature value (P) indicative of the identity of the content (CID) and a validator value (R) indicative of the CID;

sending the second portion and the P corresponding to the first portion to subscribers on the network; and

sending the second portion and the R corresponding to the first portion of the CID toward a publisher on the network.

28. The method of claim 27 wherein the first portion is at least a partial content identifier (CID) of the content.

29. The method of claim 28 wherein the second portion comprises contextual information about the content.

30. The method of claim 28 wherein the second portion comprises a portion of the CID of the content.

31. A method implemented in a subscriber node of a network, the method comprising: receiving at least a portion of a content identification (CID) of content and a signature (P), wherein P comprises a signature output of a fuzzy extractor generate function performed on information pertaining to the content;

performing a fuzzy extractor reproduce function on the at least a portion of the CID and P to generate a validator value (Q) representative of information about the content corresponding to the piece of content;

sending a subscription comprising the at least a portion of the CID and the Q of the corresponding content; and

receiving content responsive to the subscription.

36. A method of matching a publisher of content with a subscriber of content in a network, the method comprising:

receiving a publication from a publisher corresponding to content available from the publisher, the publication comprising at least a first portion and a second portion, the first portion comprising at least a portion of a content identification (CID) of the content, and the second portion comprising a first validator value (R) associated with the content, wherein R comprises a validator value generated by performing a fuzzy extractor generate function on information pertaining to the content;

storing the first and second portions of the publication in association with each other; receiving a subscription for requested content, the subscription comprising at least a first portion and a second portion, the first portion comprising a partial identification of the requested content and the second portion comprising second validator value (Q), wherein Q is a validator output of a fuzzy extractor reproduce function performed on information pertaining to the requested content and the P corresponding to the requested content;

determining if the first and second portions of the subscription match the first and second portions of the publication; and

if a match is determined, configuring the network to deliver the content to the subscriber.

37. A method of performing a Secure Sketch on a data set formulated in a tree structure, the method comprising: converting a first data set formulated in a tree structure into a second data set formulated as a data string; and applying an edit distance Secure Sketch to the second data set to generate a third data set representative of the first data set.

38. The method of claim 37 wherein the third data set is smaller than the first data set.

39. The method of claim 37 wherein the converting is performed using a Depth First Search (DFS).

40. The method of claim 37 wherein the converting is performed using a Breadth First Search (BFS).

41. The method of claim 37 wherein the first data set comprises metadata associated with a piece of content in an Information Centric Network (ICN).

42. The method of claim 37 wherein the first data set comprises metadata associated with a file.

43. The method of claim 37 wherein the first data set comprises at least one of storage format, transcoding rate, and network state of an associated piece of content.

44. A method of performing a fuzzy extractor generate function (GEN) on metadata associated with a requested piece of content to generate a context signature (P) indicative of the contextual information, the method comprising: converting a first data set comprising the metadata into a second data set formulated as a data string; and applying an edit distance Secure Sketch to the data string to generate a third data set representative of the metadata.

45. The method of claim 44 wherein the metadata comprises contextual information about the piece of content.

46. The method of claim 44 further comprising: including a random quantity, x, in the third data set to generate the context signature.

47. The method of claim 44 wherein the converting is performed using a Depth First Search (DFS).

48. The method of claim 44 wherein the converting is performed using a Breadth First Search (BFS).

49. The method of claim 44 wherein the edit distance Secure Sketch is a shingling function.

50. The method of claim 44 wherein the metadata set comprises at least one of storage format, transcoding rate, and network state of the piece of content.

51. A method of creating a namespace for matching at least one publisher of content to at least one subscriber of the content in a network, the method comprising: receiving from at least one subscriber of content on the network (SUBj), a request for content, the request including a content identifier (CIDsuBj), a context signature (PciDSUBj) indicative of contextual information pertaining to the at least one subscriber, and a context validator (RcrosuBj) indicative of the contextual information; storing in a root namespace a scope identifier for each such SUBj; storing under the each SUBj scope identifier a scope identifier for CIDSUB; storing under CIDsuBj, a scope identifier for PciDSUBj and a scope identifier for

RcrosuBj; storing in a root namespace a scope identifier for the at least one publisher (PUBi); receiving from the at least one publisher (PUBi) a publication of at least one identification of content available at PUBi (CIDpuBi) and a context validator (RCIDPUBI) indicative of contextual information pertaining to the at least one publisher; responsive to the publication, storing under the scope identifier corresponding to PUBi a scope identifier for CIDpuBi; storing under CIDpuBi, a scope identifier for RcrosuBj; and for each CIDsuBj that matches a CIDpuBi, storing under the scope identifier for PUBi a separate scope identifier for CIDpuBi, having stored thereunder a scope identifier for RCIDPUBI and a scope identifier for PcrosuBj. responsive to the subscription for content, determining a publisher offering content matching the at least partial CID for which the R scope identifier under that publisher matches the R identifier under the at least first one of the at least one subscribers.

52. A method implemented at a subscriber node of a communication network comprising: publishing to a namespace an identification of the subscriber (SUB); publishing to a scope identifier for SUB in the namespace an identification of a requested piece of content (CIDSUB); and publishing to a scope identifier for CIDSUB a context signature (PCIDSUB) indicative of contextual information pertaining to the at least one subscriber, and a context validator (RCIDSUB) indicative of the contextual information.

53. A method implemented at a publisher node of a communication network comprising publishing to a namespace an identification of the publisher (PUB); and publishing to a scope identifier for PUB in the namespace an identification of a piece of content (CIDPUB) available at PUB. subscribing to the scope identifier for CIDPUB and its sub scope identifiers; receiving in response to the subscription any context validator stored in a scope identifier under CIDPUB (PCIDPUB); performing a fuzzy extractor reproduce function using PCIDPUB and contextual information PUB to generate a context validator (Ri); and publishing Ri to the scope identifier for CIDPUB.

54. A method of matching at least one publisher of content to at least one subscriber of the content in a network, the method comprising: subscribing to a namespace in the network; subscribing to a scope identifier for a plurality of publishers of content and a plurality of subscribers of content on the network; receiving, in response to the subscriptions to the scope identifiers of the publishers and subscribers, publications of content identifiers (CIDs) under the publishers and subscribers subscribed to; subscribing to the scope identifiers of the CIDs under the publisher scope identifiers and the CIDS under the subscriber scope identifiers; receiving, in response to each subscription to a CID scope identifier that is under a subscriber scope identifier, a randomness-extracted credential imprecisely indicative of contextual information associated with the corresponding CID (Crsue); responsive to receiving a CrsuB, publishing CrsuB to each CID scope identifier under a publisher scope identifier that matches the CID corresponding to CrsuB; receiving from a subscriber a request for content identified by a CID; and selecting a publisher to provide the requested content to the requesting subscriber as a function of similarity of the CID of the requested content and CrsuB in the namespace with a CID and a randomness-extracted credential associated with a publisher (Crpue) in the namespace.

55. The method of claim 56 wherein each randomness-extracted credential comprises the output of a secure sketch function of a fuzzy extractor (P) and the output of a reproduce function of the fuzzy extractor (R).

56. The method of claim 55 wherein the selecting comprises matching the R associated with a publisher with the R associated with a subscriber.