Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .ac
DETAILED ACTION
2. This Office Action is in response to the filing with the office dated 07/16/2025.
Claims 20, 31 and 36 have been amended. Claims 1-19 have been cancelled. Claims 20, 31 and 36 are independent claims. Claims 20-38 are pending in this office action.
Priority
3. Applicant’s claim for the benefit of a prior-filed Application Number NL2026408 filed on 09/04/2020 is acknowledged by the examiner.
Applicant’s claim for the benefit of a prior-filed PCT Application No. PCT/NL2021/050539 filed on 09/06/2021 is acknowledged by the examiner.
Response to amendment/arguments
4. Applicant’s arguments with respect to the rejection of claims under 35 U.S.C. § 102 (a)(i) and 103(a) have been fully considered but are moot because the arguments are directed towards amended claims, thus necessitated the new ground of rejection as presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
Claim Rejections - 35 U.S.C. § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
5. Claims 20-27, 30-38 are rejected under 35 U.S.C. 103 as being unpatentable over Liao; Heng (US 6633865 B1) in view of RANGARAJAN; VIJAY (US 20080181139 A1), HARRIMAN; David (US 20160274923 A1) and in further view of HEINECKE; Alexander F. ( US 20190079767 A1).
Regarding independent claim 20, Liao; Heng (US 6633865 B1) teaches, a method of operating a storage device of an access point, the access point providing network access to a number of end node devices (Col 1, Lines 50-53 (6) network devices, such as routers, switches and bridges, are able to determine the network source and destination of a packet), each end node device having a device identifier and a device context (Col 1, Lines 40-45 (6) discloses MAC address lookup and layer 3 IP longest prefix match (Examiner interprets device identifier as MAC address and device context as IP address),
each context element having a context index and configured for storing a device identifier and a device context of an end node device, the method comprising the steps of: a hash table element with an index that is equal to a hashed device identifier stores a location of a subtree containing at least one data element linked with the device identifier (Fig. 1, Col 9 Lines 14-24 (23) Also included in the search context are search identifiers assigned by the header control, and a MAC address to be searched. Since the hash procedure outlined above is used for the MAC address lookup, a hash table entry address, calculated by the header control 130 using the MAC address to be searched as the hash key, is also included in the search context. Thus, the search context contains an assigned search identifier, which can be the MAC address to be searched, along with the relevant search parameters such as the hash table entry address, and, if the data packet is an IP data packet, the destination IP address (Examiner interprets context element as search context which has multiple matching elements based on a locator mechanism. Examiner interprets MAC address/ device identifier as search identifier and search parameter as device context). Also see Col 2 Lines 14-37, Col 5, Lines 58-64 (9),(10), (41));
creating, in the storage device of the access point, a hierarchical data structure comprising a plurality of levels of nodes, each node comprising at least one data element, each data element configured for at least storing a context index of a context element and being linked to a device identifier of an end node device (Fig. 1, Col 9, Lines 20-24 (23) the search context contains an assigned search identifier, which can be the MAC address to be searched, along with the relevant search parameters such as the hash table entry address, and, if the data packet is an IP data packet, the destination IP address.(Examiner interprets context index of the context element as IP address locating the network node and device identifier as MAC address. Therefore search identifier includes context index and device identifier). Also see Col 7, Lines 52-55 (8)) Hierarchical data structure is taught by RANGARAJAN et al (Fig. 1);
and operating the hierarchical data structure together with context elements to associate device identifiers linked to data elements of the hierarchical data structure with respective device contexts of end node devices stored in the context elements (Col 8 Lines 65-68, Col 9 Lines 1-24 (21), (22) discloses initiating a search from a receiving a network data packet and identifying the data elements and associating the device identifiers/ MAC address with respective device context/ ip address. Also see Col 9, Lines 31-43 (25));
Liao et al fails to explicitly teach, the storage device having a context array stored in a contiguous part thereof, the context array comprising a plurality of context elements; and each data element comprising one of:16-bit data, wherein a link to the device identifier is provided in the context index of the data element; and32-bit data comprising the context index and a converted device identifier; wherein a root node of the hierarchical data structure comprises a hash table, and wherein the different children node subtrees of the root node comprise different data structures selected from a set of predetermined data structures including at least one of an ordered block array, an unordered block array, a self-balanced tree, and a linked list, a type of data structure of a children node determined based on a number of data elements stored in a subtree of that node.
RANGARAJAN; VIJAY (US 20080181139 A1) teaches, the storage device having a context array stored in a contiguous part thereof, the context array comprising a plurality of context elements (Paragraph [0047], [0048] one or more leaf arrays are stored in a first set of memory channels of N+1 sets of memory channels, the N+1 sets of memory channels including N sets of memory channels plus the first set of memory channels, and each of N contiguous levels of the multiple tree arrays are stored in a different one of said N sets of memory channels, wherein each of the multiple tree arrays at a same level of said N contiguous levels is stored in the same memory channel set of said N sets of memory channels );
creating, in the storage device of the access point, a hierarchical data structure comprising a plurality of levels of nodes, each node comprising at least one data element (Fig. 1, shows a hierarchical data structure comprising plurality of levels of nodes);
wherein a root node of the hierarchical data structure comprises a hash table, a hash table element with an index that is equal to a hashed device identifier stores a location of a subtree containing at least one data element linked with the device identifier (Paragraph [0047]- [0049] discloses tree bitmap data structure and the hash table with an index stores a location of sub tree/ child nodes linked to the parent node/ device (i.e., matching the elements with the root/ parent node allows direct access to this result without having to parse a corresponding internal node), and wherein the different children node subtrees of the root node comprise different data structures selected from a set of predetermined data structures including at least one of an ordered block array, an unordered block array, a self-balanced tree, and a linked list, a type of data structure of a children node determined based on a number of data elements stored in a subtree of that node (Paragraph [0047] discloses, the data structures can be any type such as sets, queues, trees, heaps, lists, linked lists, arrays, tables, pointers, etc.).
Therefore it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Liao et al by providing the storage device having a context array stored in a contiguous part thereof, the context array comprising a plurality of context elements; wherein a root node of the hierarchical data structure comprises a hash table, and wherein the different children node subtrees of the root node comprise different data structures selected from a set of predetermined data structures including at least one of an ordered block array, an unordered block array, a self-balanced tree, and a linked list, a type of data structure of a children node determined based on a number of data elements stored in a subtree of that node, as taught by RANGARAJAN et al (Paragraphs [0047]-[0049]).
One of the ordinary skill in the art would have been motivated to make this modification, by doing so, the software reference implementation uses this optimization to save internal bit map processing; the hardware implementations use it only to reduce the access width size (because bit map processing is not an issue in hardware) as taught by RANGARAJAN et al (Paragraphs [0016], [0017]).
Liao et al and RANGARAJAN et al fails to explicitly teach, and each data element comprising one of:16-bit data, wherein a link to the device identifier is provided in the context index of the data element; and32-bit data comprising the context index and a converted device identifier.
HARRIMAN; David (US 20160274923 A1) teaches, and each data element comprising one of: wherein a link to the device identifier is provided in the context index of the data element; the context index and a converted device identifier (Paragraph [0107] discloses, a reference to a configuration context includes a reference that associates the configuration context with the device it is associated with. For example, assuming configuration storage 712 holds a cache configuration context for device 726, while device 726 is in a low power state, then in this embodiment a reference to the configuration context includes the configuration context itself in storage 712 and the reference, such as device ID, index, header, etc. that associates the context with device 726 in configuration storage 712. Also see [0210]).
Therefore it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Liao et al and RANGARAJAN et a by wherein a link to the device identifier is provided in the context index of the data element; the context index and a converted device identifier, as taught by HARRIMAN;et al (Paragraph [0107]).
One of the ordinary skill in the art would have been motivated to make this modification, by doing so, would improve user experience by providing an enhanced and persistent way to manage devices by embedding their identity within the data itself.
Liao et al, RANGARAJAN et al and HARRIMAN et al fails to explicitly teach, and each data element comprising one of:16-bit data …; and32-bit data.
HEINECKE; Alexander F. ( US 20190079767 A1) teaches, each data element comprising one of:16-bit data …; and32-bit data (Paragraph [0060] discloses, the length of the each data element can be 16 bit (2 byte) and 32 bit (4 byte).
Therefore it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Liao et al, RANGARAJAN et al and HARRIMAN et al by each data element comprising one of:16-bit data …; and32-bit data, as taught by HEINECKE et al (Paragraph [0060]).
One of the ordinary skill in the art would have been motivated to make this modification, by doing so, uniquely identifies the vector friendly instruction format, and thus occurrences of instructions in the vector friendly instruction format in instruction streams as taught by HEINECKE et al (Paragraph [0063]).
Regarding dependent claim 21, Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al teach, the method according to claim 20.
RANGARAJAN et al further teaches, wherein the different children node subtrees of the root node comprise data structures being a linked list (Fig. 2A shows children node subtrees of the root node includes linked list).
Regarding dependent claim 22, Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al teach, the method according to claim 21.
RANGARAJAN et al further teaches, wherein the subtree of each child node of the root node is a self-balanced tree (Fig. 2A, 2B Paragraph [0057]-[0062] [0059] the internal node pointer 235 in S3 (i.e., S3.fwdarw.I3), is replaced with the linkage S3-.fwdarw.L2 (230), where L2 is the longest match in level 2 corresponding to S3 (213). Based on specification Paragraph [0148] In this example, “chain” is represented as only one node. It can be contemplated by those skilled in the art that the chain may also be a tree structure of depth more than 1, more specifically self-balanced tree, more specifically a self-balanced tree where nodes contain ordered array of data elements. Therefore Fig. 2B chain tree structure is equated to the self-balanced tree of the instant claim)).
Regarding dependent claim 23, Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al each, the method according to claim 22.
RANGARAJAN et al further teaches, wherein descendant nodes of the root node are all children to the root node (Fig. 1A-1C shows descendant nodes of the root node are all children to the root node).
Regarding dependent claim 24, Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al teach, the method according to claim 22.
RANGARAJAN et al further teaches, wherein every node is comprised of an array of data elements ordered by values of device identifiers or converted device identifiers linked to the data elements (Paragraph Figs.1E, 2A, 2B shows every node comprises an array of elements ordered by values linked to the data elements. Examiner interprets converted device elements as hash values. Also see Paragraphs [0016, [0017]).
Regarding dependent claim 25, Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al teach, the method according to claim 20.
Liao et al further teaches, wherein the step of creating comprises the steps of: deriving an index from a device identifier of an end node device newly connected to the access point (Col 2 Lines 4-27 (8), (9) discloses deriving an index from the device identifier/ MAC address), the index pointing to a subtree of the hierarchical data structure comprising a number of data elements of lower levels (Paragraph (10 discloses index pointing to a subtree/ IP address);
RANGARAJAN et al further teaches, wherein the step of creating comprises the steps of: deriving an index from a device identifier of an end node device newly connected to the access point, the index pointing to a subtree of the hierarchical data structure comprising a number of data elements of lower levels (Fig. 1A, 2B Paragraph [0006], [0010], discloses deriving an index from the root node and the index pointing to the subtree in the hierarchical data structure). Also see Paragraph [0060]-[0062]);
adding a data element to the subtree of the hierarchical data structure and storing a context index of an available context element of the context array in the added data element; and storing a device context and the device identifier of the newly connected end node device in the available context element (Fig. 2A, 2B Paragraphs [0057]-[0062] discloses adding the data element from the root or child node and storing the context matching the prefix is stored as a newly connected end node. Also see Paragraph [0072]).
Regarding dependent claim 26, Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al teach, the method according to claim 20.
RANGARAJAN et al further teaches, wherein the step of operating comprises an adding operation being: storing a device identifier or a converted device identifier linked to a data element in the data element or associating a data element with a device identifier stored in a context element, the data element storing a same context index as the context element (Fig. 2A, 2B Paragraph [0057] discloses storing the device identifier/ root node linked to the data elements and associating the data element with the child node. Also see Paragraphs [0060-[0062], [0072]).
Regarding dependent claim 27, Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al teach, the method according to claim 20.
RANGARAJAN et al further teaches, further comprising a step of: creating, in the storage device, an indicator array comprising a plurality of indicator elements, each indicator element being used as a flag for context occupancy information associated with a respective context element (Fig. 7 Paragraph [0087] FIG. 7 illustrates a process used in one embodiment by requesting device 501 (FIG. 5). Processing begins with process block 700, and proceeds to process block 702 wherein a packet or other information is received. Next, in process block 704, a memory search request, such as initial search request 601 (FIG. 6A), is forwarded to traversing engine 500 (FIG. 5). Next, in process block 706, the result is received from traversing engine 500. As determined in process block 708, if the search is not completed (e.g., there are more bits to provide to traversing engine in a search request, such as for a continued search request 602 of FIG. 6A), processing returns to process block 704 to generate and transmit the search request. Otherwise, in process block 710, the packet or other information is processed based on the received result. Processing is complete for this search as indicated by process block 712 (i.e., plurality of indicators/ flags/ bits are created associated with context occupancy/ search information). Also see Paragraph [0021]).
Regarding dependent claim 30, Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al each, the method according to claim 20.
RANGARAJAN et al further teaches, implemented as a computer program product, comprising a computer readable storage medium storing instructions which, when executed on at least one processor (Fig. 4, Paragraph [0076]).
Liao et al and RANGARAJAN et al further teaches, cause the at least one processor to carry out the method (Please see the rejection of independent claim 20)).
Regarding independent claim 31, Liao; Heng (US 6633865 B1) teaches, a method of locating a device context of an end node device stored in a storage device of an access point, the access point providing network access to a number of end node devices (Col 1, Lines 50-53 (6) network devices, such as routers, switches and bridges, are able to determine the network source and destination of a packet), each end node device having a device identifier and a device context (Col 1, Lines 40-45 (6) discloses MAC address lookup and layer 3 IP longest prefix match (Examiner interprets device identifier as MAC address and device context as IP address),
each context element having a context index and configured for storing a device identifier and a device context of an end node device, the method comprising the steps of: (Fig. 1, Col 9 Lines 14-24 (23) Also included in the search context are search identifiers assigned by the header control, and a MAC address to be searched. Since the hash procedure outlined above is used for the MAC address lookup, a hash table entry address, calculated by the header control 130 using the MAC address to be searched as the hash key, is also included in the search context. Thus, the search context contains an assigned search identifier, which can be the MAC address to be searched, along with the relevant search parameters such as the hash table entry address, and, if the data packet is an IP data packet, the destination IP address (Examiner interprets context element as search context which has multiple matching elements based on a locator mechanism. Examiner interprets MAC address/ device identifier as search identifier and search parameter as device context). Also see Paragraphs (9),(10), (41));
identifying, by using a device identifier or a converted device identifier of the end node device, a node in a hierarchical data structure stored in the storage device, the hierarchical data structure comprising a plurality of levels of nodes, each node comprising at least one data element, each data element configured for at least storing a context index of a context element and being linked to a device identifier of an end node device (Fig. 1, Col 9, Lines 20-24 (23) the search context contains an assigned search identifier, which can be the MAC address to be searched, along with the relevant search parameters such as the hash table entry address, and, if the data packet is an IP data packet, the destination IP address.(Examiner interprets context index of the context element as IP address locating the network node and device identifier as MAC address. Therefore search identifier includes context index and device identifier). Also see Paragraph (8)), traversing at least one data element of a subtree belonging to the identified node to determine a data element comprising a context index of a context element comprising the device identifier of the end node device; and locating the device context stored in the context element comprising the device identifier of the end node device (Col 8 Lines 65-68, Col 9 Lines 1-24 (21), (22) discloses initiating a search from a receiving a network data packet and identifying the data elements and associating the device identifiers/ MAC address with respective device context/ ip address. Also see Col 9, Lines 31-43 (25));
Liao et al fails to explicitly teach, the storage device having a context array stored in a contiguous part thereof, the context array comprising a plurality of context elements; and locating the device context stored in the context element comprising the device identifier of the end node device; and each data element comprising one of:16-bit data, wherein a link to the device identifier is provided in the context index of the data element; and32-bit data comprising the context index and a converted device identifier.
RANGARAJAN; VIJAY (US 20080181139 A1) teaches, the storage device having a context array stored in a contiguous part thereof, the context array comprising a plurality of context elements; and locating the device context stored in the context element comprising the device identifier of the end node device; (Paragraph [0047], [0048] one or more leaf arrays are stored in a first set of memory channels of N+1 sets of memory channels, the N+1 sets of memory channels including N sets of memory channels plus the first set of memory channels, and each of N contiguous levels of the multiple tree arrays are stored in a different one of said N sets of memory channels, wherein each of the multiple tree arrays at a same level of said N contiguous levels is stored in the same memory channel set of said N sets of memory channels);
Therefore it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Liao et al by the storage device having a context array stored in a contiguous part thereof, the context array comprising a plurality of context elements; and locating the device context stored in the context element comprising the device identifier of the end node device, as taught by RANGARAJAN et al (Paragraphs [0047]-[0049]).
One of the ordinary skill in the art would have been motivated to make this modification, by doing so, the software reference implementation uses this optimization to save internal bit map processing; the hardware implementations use it only to reduce the access width size (because bit map processing is not an issue in hardware) as taught by RANGARAJAN et al (Paragraphs [0016], [0017]).
Liao et al and RANGARAJAN et al fails to explicitly teach, and each data element comprising one of:16-bit data, wherein a link to the device identifier is provided in the context index of the data element; and32-bit data comprising the context index and a converted device identifier.
HARRIMAN; David (US 20160274923 A1) teaches, and each data element comprising one of: wherein a link to the device identifier is provided in the context index of the data element; the context index and a converted device identifier (Paragraph [0107] discloses, a reference to a configuration context includes a reference that associates the configuration context with the device it is associated with. For example, assuming configuration storage 712 holds a cache configuration context for device 726, while device 726 is in a low power state, then in this embodiment a reference to the configuration context includes the configuration context itself in storage 712 and the reference, such as device ID, index, header, etc. that associates the context with device 726 in configuration storage 712. Also see [0210]).
Therefore it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Liao et al and RANGARAJAN et al by wherein a link to the device identifier is provided in the context index of the data element; the context index and a converted device identifier, as taught by HARRIMAN;et al (Paragraph [0107]).
One of the ordinary skill in the art would have been motivated to make this modification, by doing so, would improve user experience by providing an enhanced and persistent way to manage devices by embedding their identity within the data itself)
Liao et al, RANGARAJAN et al and HARRIMAN et al fails to explicitly teach, each data element comprising one of:16-bit data …; and32-bit data.
HEINECKE; Alexander F. ( US 20190079767 A1) teaches, each data element comprising one of:16-bit data …; and32-bit data (Paragraph [0060] discloses, the length of the each data element can be 16 bit (2 byte) and 32 bit (4 byte).
Therefore it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Liao et al, RANGARAJAN et al and HARRIMAN et al by each data element comprising one of:16-bit data …; and32-bit data, as taught by HEINECKE et al (Paragraph [0060]).
One of the ordinary skill in the art would have been motivated to make this modification, by doing so, uniquely identifies the vector friendly instruction format, and thus occurrences of instructions in the vector friendly instruction format in instruction streams as taught by HEINECKE et al (Paragraph [0063]).
Regarding dependent claim 32, Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al teach, the method according to claim 31.
RANGARAJAN et al further teaches, wherein the converted device identifier of the end node device is generated from the device identifier using a hash function (Paragraph Figs.1E, 2A, 2B shows every node comprises an array of elements ordered by values linked to the data elements. Examiner interprets converted device elements as hash values. Also see Paragraphs [0016, [0017]).
Regarding dependent claim 33, Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al teach, the method according to claim 31.
Liao et al further teaches, wherein the step of traversing comprises comparing the device identifier of the end node device with device identifiers linked to the data elements, the device identifiers linked to the data elements being one of device identifiers stored in the data elements, converted device identifiers stored in the data elements, and externally available devices identifier (Col 2 Lines 4-27 (8), (9) discloses deriving an index from the device identifier/ MAC address).
RANGARAJAN et al also further teaches, wherein the step of traversing comprises comparing the device identifier of the end node device with device identifiers linked to the data elements, the device identifiers linked to the data elements being one of device identifiers stored in the data elements, converted device identifiers stored in the data elements, and externally available devices identifier (Fig. 2B shows comparing the node with the identifier linked to the data elements).
Regarding dependent claim 34, Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al teach, the method according to claim 31.
Liao et al further teaches, wherein the device identifier of the end node device is a Medium Access Control (MAC) address of the end node device (Col 1, Lines 40-45 (6) discloses device identifier is a MAC address).
Regarding dependent claim 35, Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al teach, the method according to claim 31.
RANGARAJAN et al further teaches, implemented as a computer program product, comprising a computer readable storage medium storing instructions which, when executed on at least one processor (Fig. 4, Paragraph [0076]).
Liao et al and RANGARAJAN et al further teaches, cause the at least one processor to carry out the method (Please see the rejection of independent claim 31)).
Regarding independent claim 36, Liao; Heng (US 6633865 B1) teaches, an access device providing network access to a number of end node devices (Col 1, Lines 50-53 (6) network devices, such as routers, switches and bridges, are able to determine the network source and destination of a packet), each end node device having a device identifier and a device context (Col 1, Lines 40-45 (6) discloses MAC address lookup and layer 3 IP longest prefix match (Examiner interprets device identifier as MAC address and device context as IP address),
each context element having a context index and configured for storing a device identifier and a device context of an end node device (Fig. 1, Col 9 Lines 14-24 (23) Also included in the search context are search identifiers assigned by the header control, and a MAC address to be searched. Since the hash procedure outlined above is used for the MAC address lookup, a hash table entry address, calculated by the header control 130 using the MAC address to be searched as the hash key, is also included in the search context. Thus, the search context contains an assigned search identifier, which can be the MAC address to be searched, along with the relevant search parameters such as the hash table entry address, and, if the data packet is an IP data packet, the destination IP address (Examiner interprets context element as search context which has multiple matching elements based on a locator mechanism. Examiner interprets MAC address/ device identifier as search identifier and search parameter as device context). Also see Col 2 Lines 14-37, Col 5, Lines 58-64 (9),(10), (41));
the storage device further configured for storing a hierarchical data structure comprising a plurality of levels of nodes, each node comprising at least one data element, each data element configured for at least storing a context index of a context element and being linked to a device identifier of an end node device (Fig. 1, Col 9, Lines 20-24 (23) the search context contains an assigned search identifier, which can be the MAC address to be searched, along with the relevant search parameters such as the hash table entry address, and, if the data packet is an IP data packet, the destination IP address.(Examiner interprets context index of the context element as IP address locating the network node and device identifier as MAC address. Therefore search identifier includes context index and device identifier). Also see Col 7, Lines 52-55 (8));
and wherein the hierarchical data structure and the context elements are configured to operate together to associate device identifiers linked to data elements of the hierarchical data structure with respective device contexts of end node devices stored in the context elements (Col 8 Lines 65-68, Col 9 Lines 1-24 (21), (22) discloses initiating a search from a receiving a network data packet and identifying the data elements and associating the device identifiers/ MAC address with respective device context/ ip address. Also see Col 9, Lines 31-43 (25));
Liao et al fails to explicitly teach, the access device comprising: a storage device configured for storing a context array in a contiguous part thereof, the context array comprising a plurality of context elements; and each data element comprising one of:16-bit data, wherein a link to the device identifier is provided in the context index of the data element; and32-bit data comprising the context index and a converted device identifier.
RANGARAJAN; VIJAY (US 20080181139 A1) teaches, a storage device configured for storing a context array in a contiguous part thereof, the context array comprising a plurality of context elements (Paragraph [0047], [0048] one or more leaf arrays are stored in a first set of memory channels of N+1 sets of memory channels, the N+1 sets of memory channels including N sets of memory channels plus the first set of memory channels, and each of N contiguous levels of the multiple tree arrays are stored in a different one of said N sets of memory channels, wherein each of the multiple tree arrays at a same level of said N contiguous levels is stored in the same memory channel set of said N sets of memory channels).
Therefore it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Liao et al by the access device comprising: a storage device configured for storing a context array in a contiguous part thereof, the context array comprising a plurality of context elements, as taught by RANGARAJAN et al (Paragraphs [0047]-[0049]).
One of the ordinary skill in the art would have been motivated to make this modification, by doing so, the software reference implementation uses this optimization to save internal bit map processing; the hardware implementations use it only to reduce the access width size (because bit map processing is not an issue in hardware) as taught by RANGARAJAN et al (Paragraphs [0016], [0017]).
Liao et al and RANGARAJAN et al fails to explicitly teach, and each data element comprising one of:16-bit data, wherein a link to the device identifier is provided in the context index of the data element; and32-bit data comprising the context index and a converted device identifier.
HARRIMAN; David (US 20160274923 A1) teaches, and each data element comprising one of: wherein a link to the device identifier is provided in the context index of the data element; the context index and a converted device identifier (Paragraph [0107] discloses, a reference to a configuration context includes a reference that associates the configuration context with the device it is associated with. For example, assuming configuration storage 712 holds a cache configuration context for device 726, while device 726 is in a low power state, then in this embodiment a reference to the configuration context includes the configuration context itself in storage 712 and the reference, such as device ID, index, header, etc. that associates the context with device 726 in configuration storage 712. Also see [0210]).
Therefore it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Liao et al and RANGARAJAN et al by wherein a link to the device identifier is provided in the context index of the data element; the context index and a converted device identifier, as taught by HARRIMAN;et al (Paragraph [0107]).
One of the ordinary skill in the art would have been motivated to make this modification, by doing so, would improve user experience by providing an enhanced and persistent way to manage devices by embedding their identity within the data itself).
Liao et al, RANGARAJAN et al and HARRIMAN et al fails to explicitly teach, each data element comprising one of:16-bit data …; and32-bit data.
HEINECKE; Alexander F. ( US 20190079767 A1) teaches, each data element comprising one of:16-bit data …; and32-bit data (Paragraph [0060] discloses, the length of the each data element can be 16 bit (2 byte) and 32 bit (4 byte).
Therefore it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Liao et al, RANGARAJAN et al and HARRIMAN et al by each data element comprising one of:16-bit data …; and32-bit data, as taught by HEINECKE et al (Paragraph [0060]).
One of the ordinary skill in the art would have been motivated to make this modification, by doing so, uniquely identifies the vector friendly instruction format, and thus occurrences of instructions in the vector friendly instruction format in instruction streams as taught by HEINECKE et al (Paragraph [0063]).
Regarding dependent claim 37, Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al teach, the access device according to claim 36.
RANGARAJAN et al further teaches, further comprising: an identification device configured for identifying a node in the hierarchical data structure by using a device identifier or a converted device identifier of an end node device (Fig. 1A, 2B Paragraph [0006], [0010], discloses deriving an index from the root node and the index pointing to the subtree in the hierarchical data structure). Also see Paragraph [0060]-[0062]);
a traversing device configured for traversing at least one data element of a subtree belonging to the identified node to determine a data element comprising a context index of a context element comprising the device identifier of the end node device; and a locating device configured for locating a device context stored in the context element comprising the device identifier of the end node device (Fig. 2B shows comparing the node with the identifier linked to the data elements. Als see (Fig. 2B shows comparing the node with the identifier linked to the data elements. Als see Paragraph [0087] FIG. 7 illustrates a process used in one embodiment by requesting device 501 (FIG. 5). Processing begins with process block 700, and proceeds to process block 702 wherein a packet or other information is received. Next, in process block 704, a memory search request, such as initial search request 601 (FIG. 6A), is forwarded to traversing engine 500 (FIG. 5). Next, in process block 706, the result is received from traversing engine 500. As determined in process block 708, if the search is not completed (e.g., there are more bits to provide to traversing engine in a search request, such as for a continued search request 602 of FIG. 6A), processing returns to process block 704 to generate and transmit the search request. Otherwise, in process block 710, the packet or other information is processed based on the received result. Processing is complete for this search as indicated by process block 712 (i.e., plurality of indicators/ flags/ bits are created associated with context occupancy/ search information). Also see Paragraph [0021]).
Regarding dependent claim 38, Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al teach, the access device according to claim 36.
RANGARAJAN et al further teaches, wherein the storage device is further configured for storing an indicator array comprising a plurality of indicator elements, each indicator element being configured for storing context occupancy information associated with a respective context element (Paragraph (Fig. 2B shows comparing the node with the identifier linked to the data elements. Als see Paragraph [0087] FIG. 7 illustrates a process used in one embodiment by requesting device 501 (FIG. 5). Processing begins with process block 700, and proceeds to process block 702 wherein a packet or other information is received. Next, in process block 704, a memory search request, such as initial search request 601 (FIG. 6A), is forwarded to traversing engine 500 (FIG. 5). Next, in process block 706, the result is received from traversing engine 500. As determined in process block 708, if the search is not completed (e.g., there are more bits to provide to traversing engine in a search request, such as for a continued search request 602 of FIG. 6A), processing returns to process block 704 to generate and transmit the search request. Otherwise, in process block 710, the packet or other information is processed based on the received result. Processing is complete for this search as indicated by process block 712 (i.e., plurality of indicators/ flags/ bits are created associated with context occupancy/ search information). Also see Paragraph [0021]).
6. Claims 28 and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Liao; Heng (US 6633865 B1) in view of RANGARAJAN; VIJAY (US 20080181139 A1), HARRIMAN; David (US 20160274923 A1), HEINECKE; Alexander F. ( US 20190079767 A1), and in further view of HWANG; Joo-young (US 20100205363 A1).
Regarding dependent claim 28, Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al teach, the method according to claim 20.
Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al fails to explicitly teach, wherein the different children node subtrees of the root node are stored using buddy memory allocation.
HWANG; Joo-young (US 20100205363 A1) teaches, wherein the different children node subtrees of the root node are stored using buddy memory allocation (Paragraph [0057] discloses nodes and subnodes are stored using buddy memory allocation. Also see Paragraph [0027]).
Therefore it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Liao et al, RANGARAJAN et al, HARRIMAN et al and HEINECKE et al by providing wherein the different children node subtrees of the root node are stored using buddy memory allocation as taught by HWANG et al (Paragraph [0057]).
One of the ordinary skill in the art would have been motivated to make this modification, by doing so, the advantages of a buddy memory allocator are its efficient handling of memory fragmentation, particularly external fragmentation, due to its fast merging of adjacent free blocks ("coalescing") which is facilitated by its simple data structure and quick identification of "buddy" blocks using bitwise operations, making allocation and deallocation operations relatively fast compared to other allocation algorithms like first-fit or best-fit; it also offers good scalability and flexibility for handling different memory block sizes based on power-of-two sizes.
Regarding dependent claim 29, Liao et al, RANGARAJAN et al, HARRIMAN et al, HEINECKE et al and HWANG et al teach, the method according to claim 28.
HWANG; Joo-young (US 20100205363 A1) teaches, wherein a number of blocks of a highest level and a size of a block on every level and a size of the hash table are determined based on a maximum number of end node devices, time limitations of locating a device context, and memory footprint (Paragraph [0057]-[0059] The buddy allocation algorithm splits and manages a memory area into sections each having 2.sup.n pages. The buddy allocation algorithm searches for a requested block size of memory by splitting the whole memory into two equal blocks and determines if the split block size of memory is the suitable size for the requested block size of memory. If the split block size is not the suitable size of memory, the algorithm splits the blocks again. This is repeated until the size of the split blocks is the suitable size for the requested block size of memory. The split blocks are merged into one block after allocating memory to the searched block is released. The buddy allocation algorithm may perform page allocation based on a binary tree data structure or a hash table data structure. Herein, two equal blocks that are to be merged after memory allocation is released may be considered to be a buddy to each other (i.e., the number of blocks of a highest level and a size of a block on every level and a size of the hash table are determined are determined based on size of the memory).
Closest Prior Art
7. The prior art made of record and not relied upon is considered pertinent to the applicant’s disclosure.
Venkatraman; Kartik (US 20240427800 A1) teaches, a user device can maintain a multi-device context store. For example, the user device can receive device and/or user context information from multiple devices and store the context information in a local data store. The user device can collect local device and/or user context information and store the context information in the local context store. The user device can receive user/device context queries from client processes and send the client processes user/device context information from multiple devices in response to the queries (Abstract).
Dolganow; Andrew (US 20090219930 A1) teaches, [0040] FIG. 2 is a schematic diagram of an exemplary uncompressed packet 200. In various exemplary embodiments, uncompressed packet 200 includes, among others, packet header 210, source address 220, destination address 230, context identifier (ID) 240, and data 250 (Paragraph [0040]).
8. Examiner has pointed out particular references contained in the prior arts of record in the body of this action for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and Figures may apply as well. It is respectfully requested from the applicant, in preparing the response, to consider fully the entire references as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior arts or disclosed by the examiner. It is noted that any citation to specific pages, columns, figures, or lines in the prior art references any interpretation of the references should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. In re Heck, 699 F.2d 1331-33, 216 USPQ 1038-39 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 USPQ 275, 277 (CCPA 1968))).
Conclusion
Applicant’s amendments/Arguments necessitated new grounds of rejection as presented in this office action. THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUMAN RAJAPUTRA whose telephone number is (571) 272-4669. The examiner can normally be reached between 8:00 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Tony Mahmoudi (571) 272-4078 can be reached. 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. R./
Examiner, Art Unit 2163
/ALEX GOFMAN/ Primary Examiner, Art Unit 2163