DETAILED ACTION
This office action is in response to the application filed on 04/02/2025.
Claims 1-12 are presented for examination.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/02/2025, and 04/21/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 10 is rejected under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, because the claim purports to invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, but fails to recite a combination of elements as required by that statutory provision and thus cannot rely on the specification to provide the structure, material or acts to support the claimed function. As such, the claim recites a function that has no limits and covers every conceivable means for achieving the stated function, while the specification discloses at most only those means known to the inventor. Accordingly, the disclosure is not commensurate with the scope of the claim.
Additionally, regarding Claim 1, examiner notes that depending on how the singles means issue is resolved, the resulting claim may be subject to a 35 USC 101 software per se rejection or a 112(f)-claim interpretation.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 11 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the system claim does not recite any hardware elements, and therefore the claim is directed towards software per se.
Claim 11 recites “A node configured for the information-centric network according to claim 10.”, however the node of claim 11 is not described as comprising any hardware elements. Further, the claim is “configured for” the information centric network in claim 10, therefore claim 11 does not comprise the information centric network, that is, the node does not perform the means of claim 10 and also does not perform claim 1. Under broadest reasonable interpretation, claim 11 only requires a node with no hardware elements, that may be configured in a way that can be part of the information centric network of claim 10, but has no other limitations.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-6, 8-12 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Zhu et al. (hereinafter Zhu, US 10,257,077 B1).
Regarding Claim 1, Zhu discloses A computer-implemented method for transmitting data in an information- centric network (Zhu: Fig. 1 WMN 100 wireless mesh network 100, Col. 4 lines 27-51),
the information-centric network connected to a plurality of server devices for providing network service data, respectively (Zhu: Fig. 1 CDN 107, col. 4 lines 40-50 datacenter servers 120 in Fig. 7 col. 6 lines 13-18),
the information-centric network configured for receiving a request for network service data from a client device (Zhu: col. 7 lines 20-25 “ The AWS CloudFront service may include several point-of-presence (POP) racks that are co-located in datacenters that see a lot of customer traffic (for example an ISP), such as illustrated in datacenter 119 in FIG. 1. A POP rack has server devices to handle incoming client requests and storage devices to cache content for these requests.” Network 100 configured to receive client requests for content, i.e. network service data),
wherein the information-centric network includes a plurality of interconnected nodes (Zhu: col. 5 lines 25-35 “The WMN 100 also includes multiple mesh nodes 104-110 (also referred to herein as meshbox nodes and network hardware devices). The mesh nodes 104-110 may establish multiple P2P wireless connections 109 between mesh nodes 104-110 to form a network backbone.” Col. 5 lines 5-12 “The network hardware devices of the WMN 100 may not have direct access to the mini-POP device 102, but can use one or more intervening nodes to get content from the mini-POP device. The intervening nodes may also cache content that can be accessed by other nodes. The network hardware devices may also determine a shortest possible route between the requesting node and a node where a particular content file is stored.” WMN comprises wireless mesh nodes and a plurality of other nodes in network 100 as seen in Fig. 1 including any intervening nodes, all of which are interconnected.)
including, respectively, a cache for caching network service data (Zhu: Col. 5 lines 5-12 “The network hardware devices of the WMN 100 may not have direct access to the mini-POP device 102, but can use one or more intervening nodes to get content from the mini-POP device. The intervening nodes may also cache content that can be accessed by other nodes.” Each node comprises a cache to cache content. Col. 16 lines 11-29 “ The mesh network device 400 may also include one or more debug ports 446, which are coupled to the SoC 402. The memory and storage may be used to cache content, as well as store software, firmware or other data for the mesh network device 400.” Mesh nodes may also have caches in memory and storage to cache content.),
each of the nodes being configured for routing any request to another of the nodes along a corresponding routing path from the client device to a corresponding server device, the corresponding routing path having one or more nodes successively visitable by the request via one hop (Zhu: Fig. 6-7 nodes are configured for routing requests between nodes, col. 21 lines 4-40 “ The first node 601 may operate as a mesh router that has four radios operating concurrently or simultaneously to transfer mesh network traffic, as well as a radio to service connected client consumption devices… For routing data traffic between nodes 601-612, a MUL architecture is used for routing decisions where each node implements a MUL.” Col. 22 line 27-col. 23 line 7 “ The source node 778 may send, via the radio, the first broadcast frame, including the first request, to a first set of one or more mesh network devices in a mesh network. The first set may be identified by the mesh header TTL value.” Requests are routed to other nodes in the mesh, each node apart from each other via a hop. Col. 11 line 62- col. 12 line 14 “In some embodiments, the first network hardware device determines whether the first content file is stored in memory of the first network hardware device. The memory of the first network hardware device may be volatile memory, non-volatile memory, or a combination of both. When the first content file is not stored in the memory or the storage of the first network hardware device, the first network hardware device generates and sends the second request to a first network hardware device of the first set. Intervening network hardware devices can make similar determinations to locate the first content file in the WMN. In the event that the first content file is not stored in the second network hardware device or any intervening nodes, the second network hardware device can request the first content file from the mini-POP node, as described herein. When the mini-POP node does not store the first content file, the mini-POP can take action to obtain the first content file, such as requesting the first content file from a CDN over a point-to-point link. Alternatively, the human in the loop process can be initiated as described herein.” Requests from client devices can also be routed to the CDN server, with the path comprising several intervening nodes, pop node, etc, eventually leading to the CDN. The routing path starts from the requesting client, with any combination of the intervening nodes and pop, to the CDN.),
the method comprising:
a) determining, by each node currently visited by a request for network service data on the corresponding routing path, an availability of said network service data in a respective cache (Zhu: col. 23 line 1-21 “The first broadcast frame may include a first request for a service or a resource to be sent to a set of other mesh network devices via a radio of the source node 778. The source node 778 may send, via the radio, the first broadcast frame, including the first request, to a first set of one or more mesh network devices in a mesh network. The first set may be identified by the mesh header TTL value…. For example, the source node may begin by sending the first broadcast frame to only neighboring mesh network devices 769, 771, 776, and 779 (e.g., mesh network devices one hop away from the source node) identified by zone 780. Source node 778 may determine that a response to the first request was not received within a first time period. ” col. 11 line 62-col. 12 line 14 “In another embodiment, the first network hardware device receives a request for a content file from one of the network hardware devices over one of the P2P wireless connections. The request is from a requesting client consumption device connected to one of the multiple network hardware devices. The first network hardware device determines whether the content file is stored in the storage device. The first network hardware device generates and sends a first notification to the one of the network hardware devices over the one of the P2P wireless connections when the content file is not stored in the storage device.” request may be sent to each node on a routing path, i.e. all nodes within one hop in Fig. 7 zone 780. Each node makes a determination if they have the requested content cached), and,
when said network service data is not available in the respective cache, initiating an individual off-path look-up with respect to said on-path node (Zhu: col. 23 line 22-50 “In response to determining that the response was not received within the first time period, source node 778 may resend the first broadcast frame (e.g., send a second broadcast frame), including the first request and the modified mesh header TTL value, via the radio to a second set of one or more additional mesh network devices, where the mesh network devices of the second set are identified by the modified mesh header TTL value. For example, the second frame may be sent to the mesh network devices of zone 780 (e.g., the mesh network devices included in the first set) and to mesh network devices of zone 782, by increasing the TTL value to allow the mesh network devices of zone 780 to relay the second frame to those additional mesh network devices of zone 782.” In response to not receiving the responses, i.e. each neighboring node does not have the content, a second broadcast is sent out in an off path look up, that sends the request to nodes of zone 782 in Fig. 7),
said off- path look-up comprising: A) broadcasting, starting from the currently visited on-path node, a request to a respective broadcast selection of off-path neighbor nodes being located off the corresponding routing path and at a respective maximum distance of K hops, K>1, from said on-path node (Zhu: col. 23 line 22-50 “In response to determining that the response was not received within the first time period, source node 778 may resend the first broadcast frame (e.g., send a second broadcast frame), including the first request and the modified mesh header TTL value, via the radio to a second set of one or more additional mesh network devices, where the mesh network devices of the second set are identified by the modified mesh header TTL value. For example, the second frame may be sent to the mesh network devices of zone 780 (e.g., the mesh network devices included in the first set) and to mesh network devices of zone 782, by increasing the TTL value to allow the mesh network devices of zone 780 to relay the second frame to those additional mesh network devices of zone 782.” In response to not receiving the responses, i.e. each neighboring node does not have the content, a second broadcast is sent out in an off path look up, that sends the request to nodes of zone 782 in Fig. 7 such that nodes that are 2 hops away from the node are requested for the content., nodes 770, 768, 777, 773 and 775 being off path neighbor nodes 2 hops away.),
the respectively broadcast-selected off-path neighbor nodes and the currently visited on-path node as corresponding on-path node forming a corresponding broadcast group (Zhu: col. 23 line 22-50 “In response to determining that the response was not received within the first time period, source node 778 may resend the first broadcast frame (e.g., send a second broadcast frame), including the first request and the modified mesh header TTL value, via the radio to a second set of one or more additional mesh network devices, where the mesh network devices of the second set are identified by the modified mesh header TTL value. For example, the second frame may be sent to the mesh network devices of zone 780 (e.g., the mesh network devices included in the first set) and to mesh network devices of zone 782, by increasing the TTL value to allow the mesh network devices of zone 780 to relay the second frame to those additional mesh network devices of zone 782.” As the broadcast now includes each node in 782, which includes the nodes of 780, group 782 is the new target for the broadcast, i.e. broadcast group.),
B) by each broadcast-selected off-path neighbor node upon respectively receiving the request, determining the availability of the requested network service data in the respective cache (Zhu col. 23 line 50-55 “In another embodiment, the source node 778 may receive, within a second time period, a second unicast frame including a first response from a second mesh network device, where the first response indicates that the requested service or resource is stored on the second mesh network device.” The nodes after determining they have the content, sends a response indicating availability of the content.), and,
C) when the requested network service data is available in the respective cache, causing transmission of said network service data to the corresponding on- path node of the broadcast group for providing said network service data on the corresponding routing path (Zhu: col. 5 lines 5-12 “ The intervening nodes may also cache content that can be accessed by other nodes. The network hardware devices may also determine a shortest possible route between the requesting node and a node where a particular content file is stored.” Upon determining the node that has the content, the content is access via the route from the cache of the node, i.e. transmission of the content. Col. 7 lines 20-41 “A POP rack has server devices to handle incoming client requests and storage devices to cache content for these requests. If the content is present in the POP rack, the content is served to the client consumption device from there. If it is not stored in the POP rack, a cache miss is triggered and the content is fetched from the next level of cache, culminating in the “origin,” which is a central repository for all available content”);
b) when the requested network service data cannot be provided by the currently visited on-path node with the individual off-path look-up, forwarding the request along the corresponding routing path for providing the requested network service data on the corresponding routing path (Zhu: col. 11 line 61-col. 12 line 14 “ When the first content file is not stored in the memory or the storage of the first network hardware device, the first network hardware device generates and sends the second request to a first network hardware device of the first set. Intervening network hardware devices can make similar determinations to locate the first content file in the WMN. In the event that the first content file is not stored in the second network hardware device or any intervening nodes, the second network hardware device can request the first content file from the mini-POP node, as described herein. When the mini-POP node does not store the first content file, the mini-POP can take action to obtain the first content file, such as requesting the first content file from a CDN over a point-to-point link. Alternatively, the human in the loop process can be initiated as described herein.” The process checks each hardware device, then checks each inventing nodes, such as the mesh nodes in fig. 6-7, then the mini pop nodes are checked, and ultimately the file can be obtained via the CDN, thereby showing when the on path and off path nodes check fails to find the content, the request is forwarded in the routing path to the CDN); and
c) upon providing the requested network service data on the corresponding routing path, transmitting said network service data along the corresponding reverse routing path to the client device (Zhu: col. 11 lines 39-51 “ In some embodiments, a path between the first network hardware device and the second network hardware device could include zero or more hops of intervening network hardware devices. In some cases, the path may include up to 12-15 hops within a mesh network of 100×100 network hardware devices deployed in the WMN.” Col. 14 line 29 to col. 14 line 51 “. The first node determines a location of the content file within the self-contained mesh network and sends a second request for the content file via a second P2P channel to at least one of the mini-POP or a second node, the second request to initiate delivery of the content file to the requesting client consumption device over a second path between the location of the content file and the requesting client consumption device.” The path between the first node and the node that has the content is used to discover where the content may be, and the same path may be used to obtain the content for the requesting device.).
Regarding Claim 2, Zhu discloses claim 1 as set forth above.
Zhu further discloses wherein step a) further comprises: al) by each visited off-path neighbor node being located at a distance of k hops,1<=k < K, from the corresponding on-path node, broadcasting the request to a respective broadcast-selection of off-path neighbor nodes being located off the corresponding routing path and at a distance of k + 1 hops, from the corresponding on-path node (Zhu: col. 23 line 22-50 “In response to determining that the response was not received within the first time period, source node 778 may resend the first broadcast frame (e.g., send a second broadcast frame), including the first request and the modified mesh header TTL value, via the radio to a second set of one or more additional mesh network devices, where the mesh network devices of the second set are identified by the modified mesh header TTL value. For example, the second frame may be sent to the mesh network devices of zone 780 (e.g., the mesh network devices included in the first set) and to mesh network devices of zone 782, by increasing the TTL value to allow the mesh network devices of zone 780 to relay the second frame to those additional mesh network devices of zone 782. Source node 778 may continue to send out the first frame including the first request with a larger and larger hop-limit value until an affirmative response to the request is received or it is determined that the requested service or resource does not exist. ” the request is broadcasted with a hop limit value K, therefore when visited by an off path node at distance k, it can forward the broadcast one more time to a distance of k+1, in this case K=k+1).
Regarding Claim 3, Zhu discloses claim 1 as set forth above.
Zhu further discloses wherein step a) further comprises: a2) broadcast-selecting by disregarding off-path neighbor nodes previously visited by said request off the corresponding routing path (Zhu: col. 24 lines 17-34 “In one embodiment, the second mesh network device 779 is a receiving node. Receiving node 779 may receive via a first radio, from a second mesh network device (e.g., source node 778), a first broadcast frame comprising a first request for a first service or a first resource and determine that the first service or the first resource is not stored on the first mesh network device. Receiving node 779 may determine that a first mesh header time to live (TTL) value for the first broadcast frame is above a threshold value (e.g., zero) and resend the first broadcast frame via at least one of: a first radio, a second radio, a third radio, or a fourth radio to one or more mesh network devices (e.g., 768-777) in the mesh network. Receiving node 779 may decrease the mesh header TTL value prior to resending the first broadcast frame. Receiving node may modify a first path associated with the first broadcast frame, to include identifying information (e.g., an IP address and/or MAC address) of the source node 779.” After node 779 obtains the request from node 778, it sends the message to nodes 768-777, i.e. not sending to 778 which was previously visited.).
Regarding Claim 4, Zhu discloses claim 1 as set forth above.
Zhu further discloses d) collecting, along the corresponding routing path, information related to each off-path neighbor node and on-path node visited by the request (Zhu: col. 20 lines 20-38 “In one embodiment, the broadcast frame includes a path (e.g., a path request) associated with the request. The path may identify one or more mesh network devices through which the request has previously traveled. When the broadcast frame is received by the mesh network device, hop-aware multicast engine 558 may modify the path to append information associated with the network device. By modifying the path to include the mesh network device that received the broadcast frame before relaying the broadcast frame to the next mesh network device, the path includes a complete summary of the route traveled by the broadcast frame. The path may be modified to include the IP address and/or media access control (MAC) address associated with the mesh network devices through which the broadcast frame travels. Advantageously, this allows for a mesh network device to return a response to the requesting mesh network device, and allows for the requesting mesh network device to directly route a subsequent service and/or resource request to the responding mesh network device.” During the process of fig. 7 wherein broadcasts are sent throughout the mesh network to obtain content, information related to each off path neighbor is obtained, allowing the service to be obtained via the route as established in the broadcast response.); and
e) caching the requested network service data in one or more visited nodes selected based on the information (Zhu: col. 12 line 15-24 “In a further embodiment, the second network hardware device receives the second request for the first content file and retrieves the first content file from the single ingress node when the first content file is not previously stored at the second network hardware device. The second network hardware device sends a response to the second request with the first content file retrieved from the single ingress node. The second network hardware device may store a copy of the first content file in memory or persistent storage of the second network hardware device for a time period.” Col. 16 lines 11-29 “ The mesh network device 400 may also include one or more debug ports 446, which are coupled to the SoC 402. The memory and storage may be used to cache content, as well as store software, firmware or other data for the mesh network device 400.” The second network hardware device obtains information that the content file is stored at the single ingress node, i.e. via the process as described above in col. 20 lines 20-38, obtains the content using the information and stores the content).
Regarding Claim 5, Zhu discloses claim 4 as set forth above.
Zhu further discloses wherein step d) and e) comprise: d1) collecting, by each corresponding broadcast group, node information related to each respectively visited off-path neighbor node and the corresponding on-path node (Zhu: col. 20 lines 20-38 “In one embodiment, the broadcast frame includes a path (e.g., a path request) associated with the request. The path may identify one or more mesh network devices through which the request has previously traveled. When the broadcast frame is received by the mesh network device, hop-aware multicast engine 558 may modify the path to append information associated with the network device. By modifying the path to include the mesh network device that received the broadcast frame before relaying the broadcast frame to the next mesh network device, the path includes a complete summary of the route traveled by the broadcast frame. The path may be modified to include the IP address and/or media access control (MAC) address associated with the mesh network devices through which the broadcast frame travels. Advantageously, this allows for a mesh network device to return a response to the requesting mesh network device, and allows for the requesting mesh network device to directly route a subsequent service and/or resource request to the responding mesh network device.” During the process of fig. 7 wherein broadcasts are sent throughout the mesh network to obtain content, information related to each node that has been visited is collected, i.e. including both nodes in 780 and 782 in Fig. 7, allowing the service to be obtained via the route as established in the broadcast response.); and
e1) by each broadcast group, caching the requested network service data in one or more visited nodes respectively thereof selected based on the node information respectively collected by the broadcast group (Zhu: col. 12 line 15-24 “In a further embodiment, the second network hardware device receives the second request for the first content file and retrieves the first content file from the single ingress node when the first content file is not previously stored at the second network hardware device. The second network hardware device sends a response to the second request with the first content file retrieved from the single ingress node. The second network hardware device may store a copy of the first content file in memory or persistent storage of the second network hardware device for a time period.” Col. 16 lines 11-29 “ The mesh network device 400 may also include one or more debug ports 446, which are coupled to the SoC 402. The memory and storage may be used to cache content, as well as store software, firmware or other data for the mesh network device 400.” When a node retrieves the content file from another node along the path to send the content back to the requesting node, at least one of the visited node caches a copy of the content in their storage for a period of time.).
Regarding Claim 6, Zhu discloses claim 4 as set forth above.
Zhu further discloses wherein the information of a reference node include or is based on one, several, or all of the following: an identifier for identifying the reference node (Zhu: col. 20 lines 20-38 “In one embodiment, the broadcast frame includes a path (e.g., a path request) associated with the request. The path may identify one or more mesh network devices through which the request has previously traveled. When the broadcast frame is received by the mesh network device, hop-aware multicast engine 558 may modify the path to append information associated with the network device. By modifying the path to include the mesh network device that received the broadcast frame before relaying the broadcast frame to the next mesh network device, the path includes a complete summary of the route traveled by the broadcast frame. The path may be modified to include the IP address and/or media access control (MAC) address associated with the mesh network devices through which the broadcast frame travels. Advantageously, this allows for a mesh network device to return a response to the requesting mesh network device, and allows for the requesting mesh network device to directly route a subsequent service and/or resource request to the responding mesh network device.” Each node includes in the broadcast its own identifier therefore an identifier is maintained for each visited node for the path, in this case an IP or MAC address.);
a degree of the reference node, said degree corresponding to a number of neighboring nodes at one hop distance therefrom; a bandwidth of the reference node; an available cache space of the reference node; a number of requests received previously by the reference node for a requested network service; and the hop distance to the corresponding on-path node (Zhu: col. 20 lines 20-38 “In one embodiment, the broadcast frame includes a path (e.g., a path request) associated with the request. The path may identify one or more mesh network devices through which the request has previously traveled. When the broadcast frame is received by the mesh network device, hop-aware multicast engine 558 may modify the path to append information associated with the network device. By modifying the path to include the mesh network device that received the broadcast frame before relaying the broadcast frame to the next mesh network device, the path includes a complete summary of the route traveled by the broadcast frame. The path may be modified to include the IP address and/or media access control (MAC) address associated with the mesh network devices through which the broadcast frame travels. Advantageously, this allows for a mesh network device to return a response to the requesting mesh network device, and allows for the requesting mesh network device to directly route a subsequent service and/or resource request to the responding mesh network device.” As each visited node incorporates its own identify to the broadcast, the broadcast packet further includes an indication of hop distance, i.e. number of addresses in the packet.).
Regarding Claim 8, Zhu discloses claim 1 as set forth above.
Zhu further discloses further comprising one or both of the following: h) by each visited off-path neighbor node, causing transmission of respective node-related information to the corresponding on-path node (Zhu: col. 20 lines 20-38 “In one embodiment, the broadcast frame includes a path (e.g., a path request) associated with the request. The path may identify one or more mesh network devices through which the request has previously traveled. When the broadcast frame is received by the mesh network device, hop-aware multicast engine 558 may modify the path to append information associated with the network device. By modifying the path to include the mesh network device that received the broadcast frame before relaying the broadcast frame to the next mesh network device, the path includes a complete summary of the route traveled by the broadcast frame. The path may be modified to include the IP address and/or media access control (MAC) address associated with the mesh network devices through which the broadcast frame travels. Advantageously, this allows for a mesh network device to return a response to the requesting mesh network device, and allows for the requesting mesh network device to directly route a subsequent service and/or resource request to the responding mesh network device.” Col. 25 lines 1-15 “Receiving node 779 may determine that the second service or the second resource is stored on the first mesh network device, and send a first indication that the second service or the second resource is stored on the first mesh network device. In one embodiment, the first indication is sent back to the requesting mesh network device on the same path that the request followed.” Each visited node includes its own node related information prior to sending/forwarding the packet to the next node. This broadcast eventually responds with a response travelling backwards, therefore each node sends an indication back to the on-path node, including its own information.); and
i) broadcasting, transmitting, forwarding, or any combination thereof the request by adding respective node-related information thereto (Zhu: col. 20 lines 20-38 “In one embodiment, the broadcast frame includes a path (e.g., a path request) associated with the request. The path may identify one or more mesh network devices through which the request has previously traveled. When the broadcast frame is received by the mesh network device, hop-aware multicast engine 558 may modify the path to append information associated with the network device. By modifying the path to include the mesh network device that received the broadcast frame before relaying the broadcast frame to the next mesh network device, the path includes a complete summary of the route traveled by the broadcast frame. The path may be modified to include the IP address and/or media access control (MAC) address associated with the mesh network devices through which the broadcast frame travels. Advantageously, this allows for a mesh network device to return a response to the requesting mesh network device, and allows for the requesting mesh network device to directly route a subsequent service and/or resource request to the responding mesh network device.” Prior to forwarding the broadcast to the next node, each node includes node related information into the packet.).
Regarding Claim 9, Zhu discloses claim 1 as set forth above.
Zhu further discloses wherein step b) further comprises: bl) forwarding the request to a nearest node or a server device for retrieving the data in a shortest possible time by using routing information available in each on-path node (Zhu: col. 5 lines 1-12 “The network hardware devices may also determine a shortest possible route between the requesting node and a node where a particular content file is stored.” The shortest possible route may be determined and used to obtain the content.).
Regarding Claim 10, Zhu discloses the method of claim 1 as set forth above.
Zhu further discloses An information-centric network comprising: means for carrying out the method according to claim 1 (Zhu: col. 7 lines 20-25 “ The AWS CloudFront service may include several point-of-presence (POP) racks that are co-located in datacenters that see a lot of customer traffic (for example an ISP), such as illustrated in datacenter 119 in FIG. 1. A POP rack has server devices to handle incoming client requests and storage devices to cache content for these requests.” col. 11 lines 39-51 “ In some embodiments, a path between the first network hardware device and the second network hardware device could include zero or more hops of intervening network hardware devices. In some cases, the path may include up to 12-15 hops within a mesh network of 100×100 network hardware devices deployed in the WMN.” Col. 14 line 29 to col. 14 line 51 “. The first node determines a location of the content file within the self-contained mesh network and sends a second request for the content file via a second P2P channel to at least one of the mini-POP or a second node, the second request to initiate delivery of the content file to the requesting client consumption device over a second path between the location of the content file and the requesting client consumption device.” Network 100 configured to receive client requests for content, i.e. network service data).
Regarding Claim 11, Zhu discloses claim 10 as set forth above.
Zhu further discloses A node configured for the information-centric network according to claim 10 (Zhu: col. 5 lines 25-35 “The WMN 100 also includes multiple mesh nodes 104-110 (also referred to herein as meshbox nodes and network hardware devices). The mesh nodes 104-110 may establish multiple P2P wireless connections 109 between mesh nodes 104-110 to form a network backbone.” Col. 5 lines 5-12 “The network hardware devices of the WMN 100 may not have direct access to the mini-POP device 102, but can use one or more intervening nodes to get content from the mini-POP device. The intervening nodes may also cache content that can be accessed by other nodes. The network hardware devices may also determine a shortest possible route between the requesting node and a node where a particular content file is stored.” WMN comprises wireless mesh nodes and a plurality of other nodes in network 100 as seen in Fig. 1 including any intervening nodes, all of which are interconnected.).
Regarding Claim 12, Zhu discloses claim 1 as set forth above.
Zhu further discloses A non-transitory computer readable medium storing a computer program comprising instruction which, when the program is executed by an information-centric network (Zhu: Fig. 1 network 100 col. 7 lines 20-25 “ The AWS CloudFront service may include several point-of-presence (POP) racks that are co-located in datacenters that see a lot of customer traffic (for example an ISP), such as illustrated in datacenter 119 in FIG. 1. A POP rack has server devices to handle incoming client requests and storage devices to cache content for these requests.” Network 100 of Fig. 1), cause the information-centric network to carry out the method of claim 1 (Zhu: col. 28 line 57-67 “The network hardware device 900 also includes a data storage device 914 that may be composed of one or more types of removable storage and/or one or more types of non-removable storage. The data storage device 914 includes a computer-readable storage medium 916 on which is stored one or more sets of instructions embodying any of the methodologies or functions described herein.” The network 100 comprises nodes that have computer readable storage medium performing claim 1 as set forth above.).
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) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (hereinafter Zhu, US 10,257,077 B1) in view of Westphal (US 2018/0295204 A1).
Regarding Claim 7, Zhu discloses Claim 1 as set forth above.
However Zhu does not explicitly disclose further comprising: f) counting, by each node, a number of requests received for the requested network service data, said number being indicative of a popularity of said network service data; and g) caching, by the one or more caching-selected nodes, the requested network service data by replacing other network service data based on the popularity.
Westphal discloses further comprising: f) counting, by each node, a number of requests received for the requested network service data, said number being indicative of a popularity of said network service data (Westphal: para.0083 “ In one embodiment, a popularity score is determined at step 700 for each content item to be placed into the network system 100. In one embodiment, the popularity score for a content item is derived from historical data associated with the content item, such as data on the number of user requests for that content item, frequency of requests within a time period, or the like.” A popularity of content may be determined based on the number of requests for that item); and
g) caching, by the one or more caching-selected nodes, the requested network service data by replacing other network service data based on the popularity (Westphal: Para.0098 “If, on the other hand, the cache is full, the cache replacement algorithm may evaluate how the incoming content item will affect centrality of the node (e.g., popularity-weighted, content-based centrality), as compared to the content item having the smallest, current contribution to the centrality of the node. If the incoming content item has a greater effect on the centrality of the node, it replaces the smallest, current contributor.” Based on the popularity of the content, it may replace other less popular content in the cache.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Zhu with Westphal in order to incorporate f) counting, by each node, a number of requests received for the requested network service data, said number being indicative of a popularity of said network service data; and g) caching, by the one or more caching-selected nodes, the requested network service data by replacing other network service data based on the popularity, to the caching process of Zhu, that already caches retrieved content for a period of time in col. 12 line 15-24.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved efficiency in hosting content with limited storage (Westphal: Para.0098).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Liu et al US 2011/0225312 A1, para.0015 showing broadcasting in the mesh network to locate cached content and a route to obtain the content.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EUI H KIM whose telephone number is (571)272-8133. The examiner can normally be reached 7:30-5 M-R, M-F alternating.
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, Kamal B Divecha can be reached at 5712725863. 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.
/EUI H KIM/Examiner, Art Unit 2453
/KAMAL B DIVECHA/Supervisory Patent Examiner, Art Unit 2453
Prosecution Insights