DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In view of the Pre-Appeal Brief filed on 09/24/2025, PROSECUTION IS HEREBY REOPENED. A new prior art rejection is set forth below.
To avoid abandonment of the application, appellant must exercise one of the following two options:
(1) file a reply under 37 CFR 1.111 (if this Office action is non-final) or a reply under 37 CFR 1.113 (if this Office action is final); or,
(2) initiate a new appeal by filing a notice of appeal under 37 CFR 41.31 followed by an appeal brief under 37 CFR 41.37. The previously paid notice of appeal fee and appeal brief fee can be applied to the new appeal. If, however, the appeal fees set forth in 37 CFR 41.20 have been increased since they were previously paid, then appellant must pay the difference between the increased fees and the amount previously paid.
A Supervisory Patent Examiner (SPE) has approved of reopening prosecution by signing below:
Response to Arguments
Applicant’s arguments, see pages 2-5, filed 09/24/2025, with respect to the rejection(s) of claim(s) 1-20 under 35 U.S.C. 102(a)(1) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in further view of Qin (US 2017/0339238). Qin teaches the limitations concerning the producer and producer component as seen in the correction below.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Muscariello et al (US 2018/0241679) in view of Qin (US 2017/0339238)
Regarding claim 1, Muscariello teaches A method of transmitting data from a producer component to a consumer component using a distributed-clustered application, the method comprising: in response to the request, supplying the payload to an acceleration layer ([0123] In at least one embodiment, an Authentication Data field of AH header portion 470 can carry a content signature for content carried in the data payload portion of the IPv6 IP Data packet 450. In at least one embodiment, the content signature can written in the ICV field of the AH by the data producer. In at least one embodiment, the ICV can be computed as described in RFC 4302. Signature computation, key exchange and signature verification mechanisms may be implemented in accordance with the IPSec protocol suite. Optionally, confidentiality can also be implemented, for example, using IPSec ESP as defined in RFC 4303); receiving a unique identifier from the acceleration layer, wherein the acceleration layer stores the payload to a storage repository in association with the unique identifier ([0190] Consider an operational example in which the fast in-network authentication mechanism can exploit the hash chain verification mechanism. Consider, for example, that after the mobile user authenticates (1020) to the registration server 1008 via edge node 1006.1 and every edge node 1006.1-1006.3 in the IP network 1010 receives (1022) the user security context from the registration server 1008. Consider that the mobile user 1002 transitions (1030) to another geographic location and connects for the first time to a different access point say, for example, edge node 1006.3, The mobile user 1002 can issue (1032) an authentication interest that includes the value for the step of the chain preceding the chain anchor, namely Hn-1(m). An authentication interest can be an IP Interest that includes the chain anchor in the data payload portion of the packet. On receiving of the authentication interest, the edge node 1006.3 can apply the hash function to Hn-1(m) and can determine (1034) whether the resulting value matches with the anchor of the chain (e.g., Hn(m)) contained in the security user context. Based on a determination that the two values match, the edge node 1006.3 can forward (1036) the IP Interest toward the requested resource or service and the requested resource can be sent (not shown) to the mobile user according to embodiments discussed herein. In some embodiments, an authorization can be performed in which an edge node grants access to a mobile user by communicating (1038) an explicit grant to the mobile user. Subsequent user movements would be repeated as described above. Each time a mobile user moves from one access point to another, the user would authenticate to the target access point by releasing the step in the chain that precedes the step used in the last fast authentication step (e.g., that precedes the anchor of the chain)); and in response to receiving the unique identifier, providing the unique identifier to the distributed-clustered application, wherein the consumer component pulls the unique identifier from the distributed-clustered application and uses the unique identifier to receive the payload from the storage repository via the acceleration layer ([0196] ICN and hICN communication networks are natively multipath. To ensure maximum network resource utilization, each node should be able to split the traffic at each hop in an optimal way. Herein, a solution is described for a client node (e.g., an ICN consumer an ICN architecture or hICN consumer for an hICN architecture), where a load-balance forwarding strategy splits the traffic in an optimal way over multiple paths, even if the client is connected to the network using different RATs with very different characteristics. Not all protocols work properly in cases where the available paths have different propagation delays. Typical protocols tend to prefer the path with a small propagation delay, even in cases in which the smallest propagation delay path may have less bandwidth than others. This can lead to a sub-optimal usage of network resources. In addition, some load balancers offer suboptimal behavior when multiple paths with different propagation delays are used. In particular, some load balancers are biased toward the path with the smallest propagation delay).
Muscariello does not explicitly teach receiving a request from the producer component to provide a payload to the distributed-clustered application;
Qin teaches receiving a request from the producer component to provide a payload to the distributed-clustered application; ([0037] Receiving very large messages (e.g., messages of ten megabytes or more) at the message brokering cluster may unbalance the cluster and/or give rise to a memory and/or bandwidth shortage. Thus, the Kafka cluster may be configured to accept messages up to a maximum message size (e.g., one megabyte). Although the maximum message size may be chosen to handle the vast majority of use cases, in cases where a producer needs to send a message that is larger than the maximum message size (i.e., send an oversized message), the producer splits the oversized message, which has a corresponding unique message id, into multiple segments that are smaller than the maximum message size and sends each of the segments individually, but with the same message id. Because each segment is a separate message to a broker or broker cluster, each segment is assigned a unique offset in accordance with the order in which the segments are sent within its Kafka topic partition, in addition to its message id.)
Accordingly, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have modified the teachings of Muscariello to include receiving a request from the producer component to provide a payload to the distributed-clustered application as taught by Qin. It would be advantageous since it enables the transfer of large messages without the problems as seen in Qin [0004].
Regarding claim 2, Muscariello in view of Qin teaches The method of claim 1, Muscariello further teaches wherein supplying the payload to the acceleration layer comprises: storing the payload to a location in host memory shared with the acceleration layer, wherein the acceleration layer retrieves the payload from the location ([0190] Consider an operational example in which the fast in-network authentication mechanism can exploit the hash chain verification mechanism. Consider, for example, that after the mobile user authenticates (1020) to the registration server 1008 via edge node 1006.1 and every edge node 1006.1-1006.3 in the IP network 1010 receives (1022) the user security context from the registration server 1008. Consider that the mobile user 1002 transitions (1030) to another geographic location and connects for the first time to a different access point say, for example, edge node 1006.3, The mobile user 1002 can issue (1032) an authentication interest that includes the value for the step of the chain preceding the chain anchor, namely Hn-1(m). An authentication interest can be an IP Interest that includes the chain anchor in the data payload portion of the packet. On receiving of the authentication interest, the edge node 1006.3 can apply the hash function to Hn-1(m) and can determine (1034) whether the resulting value matches with the anchor of the chain (e.g., Hn(m)) contained in the security user context. Based on a determination that the two values match, the edge node 1006.3 can forward (1036) the IP Interest toward the requested resource or service and the requested resource can be sent (not shown) to the mobile user according to embodiments discussed herein. In some embodiments, an authorization can be performed in which an edge node grants access to a mobile user by communicating (1038) an explicit grant to the mobile user. Subsequent user movements would be repeated as described above. Each time a mobile user moves from one access point to another, the user would authenticate to the target access point by releasing the step in the chain that precedes the step used in the last fast authentication step (e.g., that precedes the anchor of the chain)).
Regarding claim 3, Muscariello in view of Qin teaches The method of claim 2, Muscariello further teaches wherein receiving the unique identifier comprises: retrieving the unique identifier from the host memory shared with the acceleration layer ([0190] Consider an operational example in which the fast in-network authentication mechanism can exploit the hash chain verification mechanism. Consider, for example, that after the mobile user authenticates (1020) to the registration server 1008 via edge node 1006.1 and every edge node 1006.1-1006.3 in the IP network 1010 receives (1022) the user security context from the registration server 1008. Consider that the mobile user 1002 transitions (1030) to another geographic location and connects for the first time to a different access point say, for example, edge node 1006.3, The mobile user 1002 can issue (1032) an authentication interest that includes the value for the step of the chain preceding the chain anchor, namely Hn-1(m). An authentication interest can be an IP Interest that includes the chain anchor in the data payload portion of the packet. On receiving of the authentication interest, the edge node 1006.3 can apply the hash function to Hn-1(m) and can determine (1034) whether the resulting value matches with the anchor of the chain (e.g., Hn(m)) contained in the security user context. Based on a determination that the two values match, the edge node 1006.3 can forward (1036) the IP Interest toward the requested resource or service and the requested resource can be sent (not shown) to the mobile user according to embodiments discussed herein. In some embodiments, an authorization can be performed in which an edge node grants access to a mobile user by communicating (1038) an explicit grant to the mobile user. Subsequent user movements would be repeated as described above. Each time a mobile user moves from one access point to another, the user would authenticate to the target access point by releasing the step in the chain that precedes the step used in the last fast authentication step (e.g., that precedes the anchor of the chain))..
Regarding claim 4, Muscariello in view of Qin teaches The method of claim 1, Muscariello further teaches wherein supplying the payload to the acceleration layer comprises: adding the payload to a ring buffer of payloads, wherein the acceleration layer stores the payloads to the storage repository in an order in which the payloads were added to the ring buffer ([0186] Leveraging ICN network principles can provide content security and user identity management in a more flexible way. As illustrated in the embodiment of FIG. 10, a fast and distributed authentication mechanism can be implemented for mobile users (e.g., UE 1002) that desire access to content or services while moving in the network. In at least one embodiment, the mechanism exploits the ICN content based communications to verify a user's claimed user identity and bind it with user requests for accessing content or services. Thus, this mechanism can implement per-content request access control by applying access policies on the verified user identity. The mechanism can be facilitated through the use of the hash-chains to implement a fast and computationally lightweight user authentication that allows a distributed user authentication among the access point of a network. More specifically, hash-chains can be applied to authenticate consumers transmitting IP Interests to access content (e.g., via the ICNET socket)).
Regarding claim 5, Muscariello in view of Qin teaches The method of claim 1, Muscariello further teaches wherein the storage repository comprises a file-based storage system and wherein the acceleration layer stores the payload to a location in a first file in the file-based storage system and stores the unique identifier in a second file with an offset to the location in the first file ([0188] The fast in-network authentication mechanism illustrated for the embodiment of FIG. 10 assumes that central registration server 1008 is a network element that authenticates (1020) the mobile user 1002 (e.g., the hICN consumer) the first time the user issues a request for a content (e.g., via the ICNET socket). Such an authentication mechanism can be used to verify the authenticity of the identity expressed by the user. In at least one embodiment, the user can express its identity in the payload portion of an IP Interest packet. The result of this authentication phase can produce a user security context containing specific information for regulating the access of the user to the required content).
Regarding claim 6, Muscariello in view of Qin teaches The method of claim 1, Muscariello further teaches wherein the storage repository comprises network attached storage (NAS) ([0210] Referring to FIG. 13, FIG. 13 is a simplified block diagram 1300 illustrating example details that can be associated with a remote adaptive active queue management (RAAQM) transport protocol in accordance with some embodiments of the present disclosure. FIG. 13 includes a ICN node 1302.1 having a consumer application provisioned therefor (e.g., a ICN consumer), ICN nodes 1302.2-1304.5, each having a producer application provisioned therefor (e.g., ICN producers) and an ICN network 1310 including a number of ICN routing nodes 1312.1-1312.7. Each ICN node 1302.1 and 1302.2-1302.4 and each ICN routing node 1312.1-1312.7 can be provisioned with a number of ICN faces identified using a ‘FX’ labelin).
Regarding claim 7, Muscariello in view of Qin teaches The method of claim 6, Muscariello further teaches wherein the acceleration layer includes one or more user-space networking stacks to access the NAS ([0210] Referring to FIG. 13, FIG. 13 is a simplified block diagram 1300 illustrating example details that can be associated with a remote adaptive active queue management (RAAQM) transport protocol in accordance with some embodiments of the present disclosure. FIG. 13 includes a ICN node 1302.1 having a consumer application provisioned therefor (e.g., a ICN consumer), ICN nodes 1302.2-1304.5, each having a producer application provisioned therefor (e.g., ICN producers) and an ICN network 1310 including a number of ICN routing nodes 1312.1-1312.7. Each ICN node 1302.1 and 1302.2-1302.4 and each ICN routing node 1312.1-1312.7 can be provisioned with a number of ICN faces identified using a ‘FX’ labelin).
Regarding claim 8, Muscariello in view of Qin teaches The method of claim 1, Muscariello further teaches wherein the storage repository is accessed using Network File System (NFS), Common Internet File System (CIFS), or Internet Small Computer Systems Interface (iSCSI) ([0213] In at least one embodiment, the protocol can make use of several parameters that can be optimized for different kind of network accesses such as, for example, WiFi, LTE, or the like which are very different than Ethernet. Optimal parameterization utilizes a tuning algorithm to select the best or optimal set of parameters for a given network setting. Moreover, tuning is preferably done for applications with heterogeneous access where a mobile terminal can simultaneously connect to one or multiple networks with very different characteristics in terms of loss rate, delay and variability. It is desirable to automatically tune RAAQM transport protocol parameters in ICN and hICN architectures whose performance has been extensively tested by experimentation. Auto tuning for transport protocols exists for TCP and is implemented in different ways in the different operating systems: Windows®, MAC OS®, Linux, etc).
Regarding claim 9, Muscariello teaches A method of transmitting data from a producer component to a consumer component using a distributed-clustered application, the method comprising: ([0043] Communication in a conventional ICN network, such as ICN network 110, is typically driven by consumer(s), also sometimes referred to as requestors, which can initiate requests for information using Interest packets. For example, ICN node 102.1 provisioned with a consumer application can represent a consumer, which can request a piece of content by generating and sending an Interest packet into ICN network 110. The Interest can include, at least in part, the content name (e.g., the name-prefix) identifying the content desired by the consumer); in response to the request, retrieving a unique identifier associated with the payload from the distributed-clustered application ([0123] In at least one embodiment, an Authentication Data field of AH header portion 470 can carry a content signature for content carried in the data payload portion of the IPv6 IP Data packet 450. In at least one embodiment, the content signature can written in the ICV field of the AH by the data producer. In at least one embodiment, the ICV can be computed as described in RFC 4302. Signature computation, key exchange and signature verification mechanisms may be implemented in accordance with the IPSec protocol suite. Optionally, confidentiality can also be implemented, for example, using IPSec ESP as defined in RFC 4303); providing the unique identifier to an acceleration layer; receiving the payload from the acceleration layer, wherein the acceleration layer retrieves the payload from a storage repository using the unique identifier, and wherein the acceleration layer stored the payload from the producer component to the storage repository in association with the unique identifier [0190] Consider an operational example in which the fast in-network authentication mechanism can exploit the hash chain verification mechanism. Consider, for example, that after the mobile user authenticates (1020) to the registration server 1008 via edge node 1006.1 and every edge node 1006.1-1006.3 in the IP network 1010 receives (1022) the user security context from the registration server 1008. Consider that the mobile user 1002 transitions (1030) to another geographic location and connects for the first time to a different access point say, for example, edge node 1006.3, The mobile user 1002 can issue (1032) an authentication interest that includes the value for the step of the chain preceding the chain anchor, namely Hn-1(m). An authentication interest can be an IP Interest that includes the chain anchor in the data payload portion of the packet. On receiving of the authentication interest, the edge node 1006.3 can apply the hash function to Hn-1(m) and can determine (1034) whether the resulting value matches with the anchor of the chain (e.g., Hn(m)) contained in the security user context. Based on a determination that the two values match, the edge node 1006.3 can forward (1036) the IP Interest toward the requested resource or service and the requested resource can be sent (not shown) to the mobile user according to embodiments discussed herein. In some embodiments, an authorization can be performed in which an edge node grants access to a mobile user by communicating (1038) an explicit grant to the mobile user. Subsequent user movements would be repeated as described above. Each time a mobile user moves from one access point to another, the user would authenticate to the target access point by releasing the step in the chain that precedes the step used in the last fast authentication step (e.g., that precedes the anchor of the chain));; and in response to receiving the payload, supplying the payload to the consumer component ([0196] ICN and hICN communication networks are natively multipath. To ensure maximum network resource utilization, each node should be able to split the traffic at each hop in an optimal way. Herein, a solution is described for a client node (e.g., an ICN consumer an ICN architecture or hICN consumer for an hICN architecture), where a load-balance forwarding strategy splits the traffic in an optimal way over multiple paths, even if the client is connected to the network using different RATs with very different characteristics. Not all protocols work properly in cases where the available paths have different propagation delays. Typical protocols tend to prefer the path with a small propagation delay, even in cases in which the smallest propagation delay path may have less bandwidth than others. This can lead to a sub-optimal usage of network resources. In addition, some load balancers offer suboptimal behavior when multiple paths with different propagation delays are used. In particular, some load balancers are biased toward the path with the smallest propagation delay)..
Muscariello does not teach receiving a request from the consumer component to retrieve a payload from the distributed-clustered application.
Qin teaches receiving a request from the consumer component to retrieve a payload from the distributed-clustered application. ([0017] The disclosed embodiments provide a method, apparatus, and system that support the passing of large messages within a publish-subscribe messaging scheme. During operation of the messaging scheme, a consumer process (i.e., a consumer), which executes on a particular computing device (e.g., a server located within a data center), subscribes to a message stream in order to receive a continual stream of corresponding messages (e.g., messages corresponding to discrete events) published by one or more producer processes associated with the stream (i.e., producers), which execute on one or more servers that are usually remote from the consumer. The publish-subscribe messaging scheme is brokered by a messaging brokering cluster that includes one or more servers (i.e., brokers).)
Accordingly, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have modified the teachings of Muscariello to include receiving a request from the consumer component to retrieve a payload from the distributed-clustered application as taught by Qin. It would be advantageous since it enables the transfer of large messages without the problems as seen in Qin [0004].
Regarding claim 10, Muscariello in view of Qin teaches The method of claim 9, Muscariello further teaches wherein receiving the payload from the acceleration layer comprises: retrieving the payload from a location in host memory shared with the acceleration layer, wherein the acceleration layer stored the payload in the location ([0190] Consider an operational example in which the fast in-network authentication mechanism can exploit the hash chain verification mechanism. Consider, for example, that after the mobile user authenticates (1020) to the registration server 1008 via edge node 1006.1 and every edge node 1006.1-1006.3 in the IP network 1010 receives (1022) the user security context from the registration server 1008. Consider that the mobile user 1002 transitions (1030) to another geographic location and connects for the first time to a different access point say, for example, edge node 1006.3, The mobile user 1002 can issue (1032) an authentication interest that includes the value for the step of the chain preceding the chain anchor, namely Hn-1(m). An authentication interest can be an IP Interest that includes the chain anchor in the data payload portion of the packet. On receiving of the authentication interest, the edge node 1006.3 can apply the hash function to Hn-1(m) and can determine (1034) whether the resulting value matches with the anchor of the chain (e.g., Hn(m)) contained in the security user context. Based on a determination that the two values match, the edge node 1006.3 can forward (1036) the IP Interest toward the requested resource or service and the requested resource can be sent (not shown) to the mobile user according to embodiments discussed herein. In some embodiments, an authorization can be performed in which an edge node grants access to a mobile user by communicating (1038) an explicit grant to the mobile user. Subsequent user movements would be repeated as described above. Each time a mobile user moves from one access point to another, the user would authenticate to the target access point by releasing the step in the chain that precedes the step used in the last fast authentication step (e.g., that precedes the anchor of the chain))..
Regarding claim 11, Muscariello teaches A method of transmitting data from a producer component to a consumer component using a distributed-clustered application, the method comprising: ([0043] Communication in a conventional ICN network, such as ICN network 110, is typically driven by consumer(s), also sometimes referred to as requestors, which can initiate requests for information using Interest packets. For example, ICN node 102.1 provisioned with a consumer application can represent a consumer, which can request a piece of content by generating and sending an Interest packet into ICN network 110. The Interest can include, at least in part, the content name (e.g., the name-prefix) identifying the content desired by the consumer): providing a unique identifier to the connector component, wherein the connector component provides the unique identifier to the distributed-clustered application ([0123] In at least one embodiment, an Authentication Data field of AH header portion 470 can carry a content signature for content carried in the data payload portion of the IPv6 IP Data packet 450. In at least one embodiment, the content signature can written in the ICV field of the AH by the data producer. In at least one embodiment, the ICV can be computed as described in RFC 4302. Signature computation, key exchange and signature verification mechanisms may be implemented in accordance with the IPSec protocol suite. Optionally, confidentiality can also be implemented, for example, using IPSec ESP as defined in RFC 4303); and storing the payload in association with the unique identifier to the storage repository; retrieving the payload from the storage repository using the unique identifier to identify the payload in the storage repository [0190] Consider an operational example in which the fast in-network authentication mechanism can exploit the hash chain verification mechanism. Consider, for example, that after the mobile user authenticates (1020) to the registration server 1008 via edge node 1006.1 and every edge node 1006.1-1006.3 in the IP network 1010 receives (1022) the user security context from the registration server 1008. Consider that the mobile user 1002 transitions (1030) to another geographic location and connects for the first time to a different access point say, for example, edge node 1006.3, The mobile user 1002 can issue (1032) an authentication interest that includes the value for the step of the chain preceding the chain anchor, namely Hn-1(m). An authentication interest can be an IP Interest that includes the chain anchor in the data payload portion of the packet. On receiving of the authentication interest, the edge node 1006.3 can apply the hash function to Hn-1(m) and can determine (1034) whether the resulting value matches with the anchor of the chain (e.g., Hn(m)) contained in the security user context. Based on a determination that the two values match, the edge node 1006.3 can forward (1036) the IP Interest toward the requested resource or service and the requested resource can be sent (not shown) to the mobile user according to embodiments discussed herein. In some embodiments, an authorization can be performed in which an edge node grants access to a mobile user by communicating (1038) an explicit grant to the mobile user. Subsequent user movements would be repeated as described above. Each time a mobile user moves from one access point to another, the user would authenticate to the target access point by releasing the step in the chain that precedes the step used in the last fast authentication step (e.g., that precedes the anchor of the chain));; receiving a second request from a consumer-connector component of the consumer component to retrieve the payload; and in response to the second request, supplying the payload to the consumer component ([0196] ICN and hICN communication networks are natively multipath. To ensure maximum network resource utilization, each node should be able to split the traffic at each hop in an optimal way. Herein, a solution is described for a client node (e.g., an ICN consumer an ICN architecture or hICN consumer for an hICN architecture), where a load-balance forwarding strategy splits the traffic in an optimal way over multiple paths, even if the client is connected to the network using different RATs with very different characteristics. Not all protocols work properly in cases where the available paths have different propagation delays. Typical protocols tend to prefer the path with a small propagation delay, even in cases in which the smallest propagation delay path may have less bandwidth than others. This can lead to a sub-optimal usage of network resources. In addition, some load balancers offer suboptimal behavior when multiple paths with different propagation delays are used. In particular, some load balancers are biased toward the path with the smallest propagation delay)..
Muscariello does not teach receiving a first request from a producer-connector component of the producer component to store a payload to a storage repository; in response to the first request.
Qin teaches receiving a first request from a producer-connector component of the producer component to store a payload to a storage repository; in response to the first request([0037] Receiving very large messages (e.g., messages of ten megabytes or more) at the message brokering cluster may unbalance the cluster and/or give rise to a memory and/or bandwidth shortage. Thus, the Kafka cluster may be configured to accept messages up to a maximum message size (e.g., one megabyte). Although the maximum message size may be chosen to handle the vast majority of use cases, in cases where a producer needs to send a message that is larger than the maximum message size (i.e., send an oversized message), the producer splits the oversized message, which has a corresponding unique message id, into multiple segments that are smaller than the maximum message size and sends each of the segments individually, but with the same message id. Because each segment is a separate message to a broker or broker cluster, each segment is assigned a unique offset in accordance with the order in which the segments are sent within its Kafka topic partition, in addition to its message id.)
Accordingly, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have modified the teachings of Muscariello to include receiving a first request from a producer-connector component of the producer component to store a payload to a storage repository; in response to the first request as taught by Qin. It would be advantageous since it enables the transfer of large messages without the problems as seen in Qin [0004].
Regarding claim 12, Muscariello in view of Qin teaches The method of claim 11, Muscariello further teaches, comprising: retrieving the payload from a location in host memory shared with the producer-connector component, wherein the producer-connector component added the payload to the location ([0188] The fast in-network authentication mechanism illustrated for the embodiment of FIG. 10 assumes that central registration server 1008 is a network element that authenticates (1020) the mobile user 1002 (e.g., the hICN consumer) the first time the user issues a request for a content (e.g., via the ICNET socket). Such an authentication mechanism can be used to verify the authenticity of the identity expressed by the user. In at least one embodiment, the user can express its identity in the payload portion of an IP Interest packet. The result of this authentication phase can produce a user security context containing specific information for regulating the access of the user to the required content).
.
Regarding claim 13, Muscariello in view of Qin teaches The method of claim 12, Muscariello further teaches wherein the location is part of a ring buffer of payloads and wherein the payload is retrieved from the ring buffer in an order in which it was added to the ring buffer by the producer-connector component([0188] The fast in-network authentication mechanism illustrated for the embodiment of FIG. 10 assumes that central registration server 1008 is a network element that authenticates (1020) the mobile user 1002 (e.g., the hICN consumer) the first time the user issues a request for a content (e.g., via the ICNET socket). Such an authentication mechanism can be used to verify the authenticity of the identity expressed by the user. In at least one embodiment, the user can express its identity in the payload portion of an IP Interest packet. The result of this authentication phase can produce a user security context containing specific information for regulating the access of the user to the required content).
.
Regarding claim 14, Muscariello in view of Qin teaches The method of claim 11, Muscariello further teaches wherein supplying the payload comprises: storing the payload in memory shared with the consumer-connector component, wherein the producer-connector component retrieves the payload from the memory ([0190] Consider an operational example in which the fast in-network authentication mechanism can exploit the hash chain verification mechanism. Consider, for example, that after the mobile user authenticates (1020) to the registration server 1008 via edge node 1006.1 and every edge node 1006.1-1006.3 in the IP network 1010 receives (1022) the user security context from the registration server 1008. Consider that the mobile user 1002 transitions (1030) to another geographic location and connects for the first time to a different access point say, for example, edge node 1006.3, The mobile user 1002 can issue (1032) an authentication interest that includes the value for the step of the chain preceding the chain anchor, namely Hn-1(m). An authentication interest can be an IP Interest that includes the chain anchor in the data payload portion of the packet. On receiving of the authentication interest, the edge node 1006.3 can apply the hash function to Hn-1(m) and can determine (1034) whether the resulting value matches with the anchor of the chain (e.g., Hn(m)) contained in the security user context. Based on a determination that the two values match, the edge node 1006.3 can forward (1036) the IP Interest toward the requested resource or service and the requested resource can be sent (not shown) to the mobile user according to embodiments discussed herein. In some embodiments, an authorization can be performed in which an edge node grants access to a mobile user by communicating (1038) an explicit grant to the mobile user. Subsequent user movements would be repeated as described above. Each time a mobile user moves from one access point to another, the user would authenticate to the target access point by releasing the step in the chain that precedes the step used in the last fast authentication step (e.g., that precedes the anchor of the chain))..
Regarding claim 15, Muscariello in view of Qin teaches The method of claim 11, Muscariello further teaches comprising: storing, in a payload cache, the payload in association with the unique identifier; and in response to the second request, identifying the payload associated with the unique identifier in the payload cache([0190] Consider an operational example in which the fast in-network authentication mechanism can exploit the hash chain verification mechanism. Consider, for example, that after the mobile user authenticates (1020) to the registration server 1008 via edge node 1006.1 and every edge node 1006.1-1006.3 in the IP network 1010 receives (1022) the user security context from the registration server 1008. Consider that the mobile user 1002 transitions (1030) to another geographic location and connects for the first time to a different access point say, for example, edge node 1006.3, The mobile user 1002 can issue (1032) an authentication interest that includes the value for the step of the chain preceding the chain anchor, namely Hn-1(m). An authentication interest can be an IP Interest that includes the chain anchor in the data payload portion of the packet. On receiving of the authentication interest, the edge node 1006.3 can apply the hash function to Hn-1(m) and can determine (1034) whether the resulting value matches with the anchor of the chain (e.g., Hn(m)) contained in the security user context. Based on a determination that the two values match, the edge node 1006.3 can forward (1036) the IP Interest toward the requested resource or service and the requested resource can be sent (not shown) to the mobile user according to embodiments discussed herein. In some embodiments, an authorization can be performed in which an edge node grants access to a mobile user by communicating (1038) an explicit grant to the mobile user. Subsequent user movements would be repeated as described above. Each time a mobile user moves from one access point to another, the user would authenticate to the target access point by releasing the step in the chain that precedes the step used in the last fast authentication step (e.g., that precedes the anchor of the chain)).
Regarding claim 16, Muscariello in view of Qin teaches The method of claim 15, Muscariello further teaches wherein the payload cache comprises a key-value store and wherein the unique identifier is a key in the key-value store and the payload is a value in the key-value store corresponding to the key ([0186] Leveraging ICN network principles can provide content security and user identity management in a more flexible way. As illustrated in the embodiment of FIG. 10, a fast and distributed authentication mechanism can be implemented for mobile users (e.g., UE 1002) that desire access to content or services while moving in the network. In at least one embodiment, the mechanism exploits the ICN content based communications to verify a user's claimed user identity and bind it with user requests for accessing content or services. Thus, this mechanism can implement per-content request access control by applying access policies on the verified user identity. The mechanism can be facilitated through the use of the hash-chains to implement a fast and computationally lightweight user authentication that allows a distributed user authentication among the access point of a network. More specifically, hash-chains can be applied to authenticate consumers transmitting IP Interests to access content (e.g., via the ICNET socket)).
.
Regarding claim 17, Muscariello in view of Qin teaches The method of claim 11, Muscariello further teaches comprising: predicting the unique identifier will be received in the second request prior to receiving the second request, wherein the payload is retrieved prior to receiving the second request ([0190] Consider an operational example in which the fast in-network authentication mechanism can exploit the hash chain verification mechanism. Consider, for example, that after the mobile user authenticates (1020) to the registration server 1008 via edge node 1006.1 and every edge node 1006.1-1006.3 in the IP network 1010 receives (1022) the user security context from the registration server 1008. Consider that the mobile user 1002 transitions (1030) to another geographic location and connects for the first time to a different access point say, for example, edge node 1006.3, The mobile user 1002 can issue (1032) an authentication interest that includes the value for the step of the chain preceding the chain anchor, namely Hn-1(m). An authentication interest can be an IP Interest that includes the chain anchor in the data payload portion of the packet. On receiving of the authentication interest, the edge node 1006.3 can apply the hash function to Hn-1(m) and can determine (1034) whether the resulting value matches with the anchor of the chain (e.g., Hn(m)) contained in the security user context. Based on a determination that the two values match, the edge node 1006.3 can forward (1036) the IP Interest toward the requested resource or service and the requested resource can be sent (not shown) to the mobile user according to embodiments discussed herein. In some embodiments, an authorization can be performed in which an edge node grants access to a mobile user by communicating (1038) an explicit grant to the mobile user. Subsequent user movements would be repeated as described above. Each time a mobile user moves from one access point to another, the user would authenticate to the target access point by releasing the step in the chain that precedes the step used in the last fast authentication step (e.g., that precedes the anchor of the chain)).
.
Regarding claim 18, Muscariello in view of Qin teaches The method of claim 11, Muscariello further teaches wherein the storage repository comprises a file-based storage system and wherein storing the payload in association with the unique identifier to the storage repository comprises: storing the payload to a location in a first file in the file-based storage system and stores the unique identifier in a second file with an offset to the location in the first file ([0188] The fast in-network authentication mechanism illustrated for the embodiment of FIG. 10 assumes that central registration server 1008 is a network element that authenticates (1020) the mobile user 1002 (e.g., the hICN consumer) the first time the user issues a request for a content (e.g., via the ICNET socket). Such an authentication mechanism can be used to verify the authenticity of the identity expressed by the user. In at least one embodiment, the user can express its identity in the payload portion of an IP Interest packet. The result of this authentication phase can produce a user security context containing specific information for regulating the access of the user to the required content).
Regarding claim 19, Muscariello in view of Qin teaches The method of claim 18, Muscariello further teaches wherein retrieving the payload from the storage repository comprises: retrieving the offset from the second file using the unique identifier; and retrieving the payload at the offset from the first file ([0186] Leveraging ICN network principles can provide content security and user identity management in a more flexible way. As illustrated in the embodiment of FIG. 10, a fast and distributed authentication mechanism can be implemented for mobile users (e.g., UE 1002) that desire access to content or services while moving in the network. In at least one embodiment, the mechanism exploits the ICN content based communications to verify a user's claimed user identity and bind it with user requests for accessing content or services. Thus, this mechanism can implement per-content request access control by applying access policies on the verified user identity. The mechanism can be facilitated through the use of the hash-chains to implement a fast and computationally lightweight user authentication that allows a distributed user authentication among the access point of a network. More specifically, hash-chains can be applied to authenticate consumers transmitting IP Interests to access content (e.g., via the ICNET socket)).
Regarding claim 20, Muscariello in view of Qin teaches The method of claim 11, Muscariello further teaches wherein the storage repository comprises network attached storage (NAS) and the NAS is accessed using one or more user-space networking stacks ([0210] Referring to FIG. 13, FIG. 13 is a simplified block diagram 1300 illustrating example details that can be associated with a remote adaptive active queue management (RAAQM) transport protocol in accordance with some embodiments of the present disclosure. FIG. 13 includes a ICN node 1302.1 having a consumer application provisioned therefor (e.g., a ICN consumer), ICN nodes 1302.2-1304.5, each having a producer application provisioned therefor (e.g., ICN producers) and an ICN network 1310 including a number of ICN routing nodes 1312.1-1312.7. Each ICN node 1302.1 and 1302.2-1302.4 and each ICN routing node 1312.1-1312.7 can be provisioned with a number of ICN faces identified using a ‘FX’ labelin)..
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMUEL SHARPLESS whose telephone number is (571)272-1521. The examiner can normally be reached M-F 7:30 AM- 3:30 PM (ET).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, ALEKSANDR KERZHNER can be reached at 571-270-1760. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/S.C.S./Examiner, Art Unit 2165
/ALEKSANDR KERZHNER/Supervisory Patent Examiner, Art Unit 2165