DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 09/16/2026 has been entered.
Accordingly, claims 1-20 are pending in this application. Claims 1, 10, and 19 are currently amended; claims 7 and 16 are as previously presented; claims 2-6, 8, 9, 11-15, 17, 18, and 20 are original.
Claim Rejections - 35 USC § 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 (i.e., changing from AIA to pre-AIA ) 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.
Claims 1, 2, 5, 6, 10, 11, 14, 15, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ho et al. (US 2016/0086110 A1), hereinafter Ho, in view of Shadmon et al. (cited in IDS filed 07/16/2025)(US 2002/0120598 A1), hereinafter Shadmon, and further in view of Prilepov et al. (previously presented)(US 2014/0281943 A1), hereinafter Prilepov.
As to claim 1, Ho discloses a method for efficiently encoding a trie data structure for transmission, the method comprising:
receiving, by a computing system, an application programming interface (API) request pertaining to the trie data structure ([0032], Lines 1-6, [0041], [0061], Lines 11-14; A user initiates a request to select desired stored prefix trees, i.e. trie data structures, via a user interface. The desired trees must be provided to enable selection. The user interface thus being a program interacting with a storage program via software “input/output interfaces” analogous to the claimed API request.), wherein the trie data structure is indicative of flows of customer interactions with automated agents of a contact center (Figs. 3-4; [0038], [0055], The prefix trees represent workflows corresponding to customer interactions with agents, either agents as people or self-service website, i.e. an automated agent.);
obtaining, by the computing system, the trie data structure in which each node of multiple nodes of the trie data structure has an associated prefix key that defines a path from a root to the corresponding node (Fig. 4; [0055], [0061], Selected prefix trees are obtained as in Fig. 4.);
transmitting, by the computing system, a response to the API request based on the trie data structure (Fig. 4; [0041], [0061], Selected prefix trees are obtained and transmitted to the user interfaces in Fig. 4 to enable user selection for analysis.) .
Ho does not disclose encoding, by the computing system, the nodes of the trie data structure in a transmission format having a dictionary data structure, in which an identifier of each node is defined as a key of the corresponding node and a parent node identifier for each node is defined as a value of the corresponding node, wherein the nodes in the transmission format do not have the prefix key that defines the path from the root to the corresponding node; and
transmitting, by the computing system, a response to the API request based on the trie data structure encoded in the transmission format.
However, Shadmon discloses encoding, by the computing system, the nodes of the trie data structure in a transmission format having a dictionary data structure that enables O(1) lookups of nodes by corresponding node identifiers, in which an identifier of each node is defined as a key of the corresponding node and a parent node identifier for each node is defined as a value of the corresponding node, wherein the nodes in the transmission format do not have the prefix key that defines the path from the root to the corresponding node (Figs. 2-4, 6, 8; [0161], [0183], [0203]-[0206]; A tree data structure (e.g. Fig. 2) is encoded using a dictionary (Fig. 4) into a trie data structure (e.g. Fig. 3) forming a prefix path of the node values from a root to a leaf node (e.g. as in the Path Strings in Fig. 6). This trie structure is encoded into an analogous ‘transmission format’ (E.g. Fig. 8) where the nodes do not have the prefix from the root to the corresponding node, but rather the parent value and the identifier for the given node. E.g. #88 includes only the parent node value ‘F’ with the value ‘ABC Corp.’ for the given node. Shadmon uses a compressed trie structure. The trie structure inherently ‘enables’ O(1) lookups from one node to the next. Furthermore, if the leaf node is only one level, then the entire lookup will be O(1). The limitation does not specify any specific structure enabling the O(1), how it ‘enables O(1) lookups, or what the constraints of the lookups are (e.g. from root to any/all leaf nodes, from a given vertex to a leaf, etc. As such, the compressed trie structure of Shadmon discloses enablement of O(1) lookups as claimed.).
Shadmon does not specifically disclose transmitting, by the computing system, a response to the API request based on the trie data structure encoded in the transmission format.
However, Prilepov discloses receiving, by a computing system, an application programming interface (API) request pertaining to the trie data structure (Fig. 14; [0086] A request for a prefix tree, i.e. a trie data structure, is made via a user application, i.e. using a required API to communicate requests and information to/from the client application and server application.);
encoding, by the computing system, the nodes of the trie data structure in a transmission format, and transmitting, by the computing system, a response to the API request based on the trie data structure encoded in the transmission format (Fig. 14; [0067]-[0068], Lines 1-4; [0087], The prefix tree is encoded to reduce transmission criteria and sent from the server to the client application in response to the request.).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Ho with the teachings of Shadmon and Prilepov by modifying Ho such that the requests for prefix trees of Ho result in the returned prefix trees being encoded for transmission back to the user’s application of Ho by encoding the prefix trees of Ho using Patricia trie with a dictionary format with reduced path prefixes like is done with the node prefixes in Shadmon. Said artisan would have been motivated to do so in order to compress the trie data structures of Ho (Shadmon, [0196], [0204]) so as to reduce the network transfer size, the memory footprint, and the workload on the client requesting and receiving the trie data structures (Prilepov, [0067]).
As to claim 10, Ho discloses a system for efficiently encoding a trie data structure for transmission, the system comprising:
at least one processor (Fig. 1; [0034]); and
at least one memory comprising a plurality of instructions stored thereon that, in response to execution by the at least one processor, causes the system to (Fig. 1; [0034]):
receive an application programming interface (API) request pertaining to the trie data structure ([0032], Lines 1-6, [0041], [0061], Lines 11-14; A user initiates a request to select desired stored prefix trees, i.e. trie data structures, via a user interface. The desired trees must be provided to enable selection. The user interface thus being a program interacting with a storage program via software “input/output interfaces” analogous to the claimed API request.), wherein the trie data structure is indicative of flows of customer interactions with automated agents of a contact center (Figs. 3-4; [0038], [0055], The prefix trees represent workflows corresponding to customer interactions with agents, either agents as people or self-service website, i.e. an automated agent.);
obtain the trie data structure in which each node of multiple nodes of the trie data structure has an associated prefix key that defines a path from a root to the corresponding node (Fig. 4; [0055], [0061], Selected prefix trees are obtained as in Fig. 4.);
and
transmit a response to the API request based on the trie data structure (Fig. 4; [0041], [0061], Selected prefix trees are obtained and transmitted to the user interfaces in Fig. 4 to enable user selection for analysis.) .
Ho does not disclose encode the nodes of the trie data structure in a transmission format having a dictionary data structure, in which an identifier of each node is defined as a key of the corresponding node and a parent node identifier for each node is defined as a value of the corresponding node, wherein the nodes in the transmission format do not have the prefix key that defines the path from the root to the corresponding node; and
transmit a response to the API request based on the trie data structure encoded in the transmission format.
However, Shadmon discloses encoding, by the computing system, the nodes of the trie data structure in a transmission format having a dictionary data structure that enables O(1) lookups of nodes by corresponding node identifiers, in which an identifier of each node is defined as a key of the corresponding node and a parent node identifier for each node is defined as a value of the corresponding node, wherein the nodes in the transmission format do not have the prefix key that defines the path from the root to the corresponding node (Figs. 2-4, 6, 8; [0161], [0183], [0203]-[0206]; A tree data structure (e.g. Fig. 2) is encoded using a dictionary (Fig. 4) into a trie data structure (e.g. Fig. 3) forming a prefix path of the node values from a root to a leaf node (e.g. as in the Path Strings in Fig. 6). This trie structure is encoded into an analogous ‘transmission format’ (E.g. Fig. 8) where the nodes do not have the prefix from the root to the corresponding node, but rather the parent value and the identifier for the given node. E.g. #88 includes only the parent node value ‘F’ with the value ‘ABC Corp.’ for the given node. Shadmon uses a compressed trie structure. The trie structure inherently ‘enables’ O(1) lookups from one node to the next. Furthermore, if the leaf node is only one level, then the entire lookup will be O(1). The limitation does not specify any specific structure enabling the O(1), how it ‘enables O(1) lookups, or what the constraints of the lookups are (e.g. from root to any leaf, from a given vertex to a leaf, etc. As such, the compressed trie structure of Shadmon discloses enablement of O(1) lookups as claimed.).
Shadmon does not specifically disclose transmitting, by the computing system, a response to the API request based on the trie data structure encoded in the transmission format.
However, Prilepov discloses receiving, by a computing system, an application programming interface (API) request pertaining to the trie data structure (Fig. 14; [0086] A request for a prefix tree, i.e. a trie data structure, is made via a user application, i.e. using a required API to communicate requests and information to/from the client application and server application.);
encoding, by the computing system, the nodes of the trie data structure in a transmission format, and transmitting, by the computing system, a response to the API request based on the trie data structure encoded in the transmission format (Fig. 14; [0067]-[0068], Lines 1-4; [0087], The prefix tree is encoded to reduce transmission criteria and sent from the server to the client application in response to the request.).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Ho with the teachings of Shadmon and Prilepov by modifying Ho such that the requests for prefix trees of Ho result in the returned prefix trees being encoded for transmission back to the user’s application of Ho by encoding the prefix trees of Ho using Patricia trie with a dictionary format with reduced path prefixes like is done with the node prefixes in Shadmon. Said artisan would have been motivated to do so in order to compress the trie data structures of Ho (Shadmon, [0196], [0204]) so as to reduce the network transfer size, the memory footprint, and the workload on the client requesting and receiving the trie data structures (Prilepov, [0067]).
As to claim 19, Ho discloses one or more non-transitory machine-readable storage media comprising a plurality of instructions stored thereon that, in response to execution by a computing system, causes the computing system to (Fig. 1; [0034]):
receive an application programming interface (API) request pertaining to the trie data structure ([0032], Lines 1-6, [0041], [0061], Lines 11-14; A user initiates a request to select desired stored prefix trees, i.e. trie data structures, via a user interface. The desired trees must be provided to enable selection. The user interface thus being a program interacting with a storage program via software “input/output interfaces” analogous to the claimed API request.), wherein the trie data structure is indicative of flows of customer interactions with automated agents of a contact center (Figs. 3-4; [0038], [0055], The prefix trees represent workflows corresponding to customer interactions with agents, either agents as people or self-service website, i.e. an automated agent.);
obtain the trie data structure in which each node of multiple nodes of the trie data structure has an associated prefix key that defines a path from a root to the corresponding node (Fig. 4; [0055], [0061], Selected prefix trees are obtained as in Fig. 4.);
and
transmit a response to the API request based on the trie data structure (Fig. 4; [0041], [0061], Selected prefix trees are obtained and transmitted to the user interfaces in Fig. 4 to enable user selection for analysis.) .
Ho does not disclose encode the nodes of the trie data structure in a transmission format having a dictionary data structure, in which an identifier of each node is defined as a key of the corresponding node and a parent node identifier for each node is defined as a value of the corresponding node, wherein the nodes in the transmission format do not have the prefix key that defines the path from the root to the corresponding node; and
transmit a response to the API request based on the trie data structure encoded in the transmission format.
However, Shadmon discloses encoding, by the computing system, the nodes of the trie data structure in a transmission format having a dictionary data structure that enables O(1) lookups of nodes by corresponding node identifiers, in which an identifier of each node is defined as a key of the corresponding node and a parent node identifier for each node is defined as a value of the corresponding node, wherein the nodes in the transmission format do not have the prefix key that defines the path from the root to the corresponding node (Figs. 2-4, 6, 8; [0161], [0183], [0203]-[0206]; A tree data structure (e.g. Fig. 2) is encoded using a dictionary (Fig. 4) into a trie data structure (e.g. Fig. 3) forming a prefix path of the node values from a root to a leaf node (e.g. as in the Path Strings in Fig. 6). This trie structure is encoded into an analogous ‘transmission format’ (E.g. Fig. 8) where the nodes do not have the prefix from the root to the corresponding node, but rather the parent value and the identifier for the given node. E.g. #88 includes only the parent node value ‘F’ with the value ‘ABC Corp.’ for the given node. Shadmon uses a compressed trie structure. The trie structure inherently ‘enables’ O(1) lookups from one node to the next. Furthermore, if the leaf node is only one level, then the entire lookup will be O(1). The limitation does not specify any specific structure enabling the O(1), how it ‘enables O(1) lookups, or what the constraints of the lookups are (e.g. from root to any leaf, from a given vertex to a leaf, etc. As such, the compressed trie structure of Shadmon discloses enablement of O(1) lookups as claimed.).
Shadmon does not specifically disclose transmitting, by the computing system, a response to the API request based on the trie data structure encoded in the transmission format.
However, Prilepov discloses receiving, by a computing system, an application programming interface (API) request pertaining to the trie data structure (Fig. 14; [0086] A request for a prefix tree, i.e. a trie data structure, is made via a user application, i.e. using a required API to communicate requests and information to/from the client application and server application.);
encoding, by the computing system, the nodes of the trie data structure in a transmission format, and transmitting, by the computing system, a response to the API request based on the trie data structure encoded in the transmission format (Fig. 14; [0067]-[0068], Lines 1-4; [0087], The prefix tree is encoded to reduce transmission criteria and sent from the server to the client application in response to the request.).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Ho with the teachings of Shadmon and Prilepov by modifying Ho such that the requests for prefix trees of Ho result in the returned prefix trees being encoded for transmission back to the user’s application of Ho by encoding the prefix trees of Ho using Patricia trie with a dictionary format with reduced path prefixes like is done with the node prefixes in Shadmon. Said artisan would have been motivated to do so in order to compress the trie data structures of Ho (Shadmon, [0196], [0204]) so as to reduce the network transfer size, the memory footprint, and the workload on the client requesting and receiving the trie data structures (Prilepov, [0067]).
As to claims 2, 11, and 20, the claims are rejected for the same reasons as claims 1, 10, and 19 above. In addition, Ho, as previously modified with Shadmon and Prilepov, discloses wherein encoding the nodes of the trie data structure in the transmission format comprises:
stripping away an identifier of each node from the prefix key of the corresponding node (Shadmon, Figs. 3, 6, and 8; [0204], [0206], The trie is encoded by compressing as a Patricia trie such that the identifier from the ancestor are stripped away, and the parent node identifier is set in the prefix key. E.g. F as the parent in F ABC Corp for the prefix key of node 88.); and
setting the parent node identifier for the corresponding node as a node identifier immediately preceding the identifier of the corresponding node in the prefix key (Shadmon, Figs. 3, 6, and 8; [0204], [0206], The trie is encoded by compressing as a Patricia trie such that the identifier from the ancestor are stripped away, and the parent node identifier is set in the prefix key. E.g. F as the parent in F ABC Corp for the prefix key of node 88.).
As to claims 5 and 14, the claims are rejected for the same reasons as claims 1 and 10 above. In addition, Ho, as previously modified with Shadmon and Prilepov, discloses wherein transmitting the response to the API request comprises transmitting flow count data only for leaf nodes represented in the trie data structure (Ho, [0044], “counts, from a collection of execution logs, the number of sessions ever reaching the particular node J”).
As to claims 6 and 15, the claims are rejected for the same reasons as claims 1 and 10 above. In addition, Ho, as previously modified with Shadmon and Prilepov, discloses receiving, by the computing system, the response to the API request pertaining to the trie data structure (Prilepov, Fig. 14; [0068]; [0087], The compressed/encoded prefix tree is received.);
reconstructing, by the computing system, the prefix keys for nodes of the trie data structure based on parent node identifier data associated with each node (Prilepov, [0068], [0088], The compressed/encoded prefix tree is decoded to rebuild the prefix tree.);
storing, by the computing system, the trie data structure in a storage format based on the reconstructed prefix keys for the nodes (Prilepov, Fig. 10; [0068], The trie is stored on the client.).
Claims 3, 4, 12, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Ho, Shadmon, and Prilepov as applied above, and further in view of Cobb et al. (previously presented)(US 2011/0043626 A1), hereinafter Cobb.
As to claims 3 and 12, the claims are rejected for the same reasons as claims 1 and 10 above. In addition, Ho, as previously modified with Shadmon and Prilepov, discloses does not explicitly disclose transmitting the response to the API request comprises excluding, from the response, redundant data pertaining to flows for each node.
However, Cobb discloses transmitting the response to the API request comprises excluding, from the response, redundant data pertaining to flows for each node (Fig. 5D, [0053] [0066], Nodes along a flow which contain the same data, i.e. are redundant, have the redundant data removed.).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Ho, as previously modified with Shadmon and Prilepov, with the teachings of Cobb by further modifying Ho such that nodes in an interaction flow of Ho which are repetitive, can have redundant elements removed like in Cobb. Said artisan would have been motivated to do so in order to further compress the trie structure in order to further reduce transmission requirements of Ho, as previously modified with Shadmon and Prilepov (Prilepov, [0072]).
As to claims 4 and 13, the claims are rejected for the same reasons as claims 3 and 12 above. In addition, Ho, as previously modified with Shadmon, Prilepov, and Cobb, discloses wherein excluding redundant data comprises excluding, from the response, redundant identifier data values for each flow associated with each node (Cobb, Fig. 5D, [0053] [0066], E.g. the symbols.).
Ho, as previously modified with Shadmon, Prilepov, and Cobb, does not explicitly disclose wherein excluding redundant data comprises excluding, from the response, redundant version, and type data values for each flow associated with each node.
However, Cobb discloses excluding redundant data corresponding to flows in a trie. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to recognize that any redundant data stored in the nodes in the flows of Ho could be excluded if present. As such, specifying any specific type of data, e.g. redundant identifier, version, and type data values, and any other redundant data values would obviously be excluded when detected. Accordingly, it would have been obvious to said artisan to further modify Ho to more explicitly also exclude redundant version, and type data values for each flow associated with each node like is done with identifiers. Said artisan would have been motivated to do so in order to better ensure all redundant data is removed to maintain an efficiently compressed trie (version, and type data values for each flow associated with each node (Prilepov, [0072]).
Allowable Subject Matter
Claims 7-9 and 16-18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant's arguments filed 09/16/2026 have been fully considered but they are not fully persuasive. For Examiner’s response, see discussion below:
(a) At pages 11-14, with respect to the rejections of independent claims 1, 10, and 19 under 35 USC §103, Applicant argues that Shadmon does not disclose a transmission format having a dictionary data structure that enables O(1) lookups of nodes as now recited in the claims due to the trie structure of Shadmon.
As to (a), Applicant’s arguments have been fully considered but are not persuasive. Applicant’s amendments to not any additional details to the structure of the dictionary data structure, only that it somehow “enables O(1) lookups of nodes by corresponding node identifiers” without any details as to how this is enabled. The claim does not state what nodes are looked up, or from where, corresponding to the trie represented by the data structure. Accordingly, a traversal of a trie data structure from one node to the next must look up that next node by its identifier. This process is an O(1) lookup for any number of one hop jumps. Furthermore, in a small trie, desired leaves in a first level can be looked up in O(1) time. This is further exemplified in Elsheikh et al. (‘What is the Best/Worst/Average Case Big-O Runtime of a Trie Data Structure?’. July 2013. Stack Overflow. Retrieved on 22 September 2026. Retrieved from the Internet <URL: https://stackoverflow.com/questions/17891442/what-is-the-best-worst-average-case-big-o-runtime-of-a-trie-data-structure > 3 pages.), hereinafter Elsheikh, which discloses a best case trie lookup as O(1) (See response by aerin on 31 July 2017). As such, a trie structure, such as Patricia tries, do “enable” O(1) lookups as claimed. Accordingly, the compressed tries of Shadmon, and similarly Prilepov, disclose broadly enabling O(1) lookups as claimed.
(b) Applicant’s arguments to dependent claims 2-9, 11-18, and 20, have been fully considered, but are not persuasive for at least the same reasons as set forth in (a) above with respect to claims 1, 10, and 19.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Elsheikh et al. (‘What is the Best/Worst/Average Case Big-O Runtime of a Trie Data Structure?’. July 2013. Stack Overflow. Retrieved on 22 September 2026. Retrieved from the Internet <URL: https://stackoverflow.com/questions/17891442/what-is-the-best-worst-average-case-big-o-runtime-of-a-trie-data-structure > 3 pages.) discloses a best case trie lookup as O(1) (See response by aerin on 31 July 2017).
Meyerzon et al. (US 2021/0133216 A1) discloses flattening a trie structure into a dictionary structure comprising key-value pairs for the nodes (Fig. 14; [0107], [0112], [0113]).
Pfenning (‘Lecture Notes on Tries’. 15-122: Principles of Imperative Computation’, Lecture 18, 26 October 2010. Retrieved on 22 September 2026. Archived on Archive.org on 13 February 2019. Retrieved from the Internet <URL: https://web.archive.org/web/20190213162839/http://www.cs.cmu.edu/~fp/courses/15122-f10/lectures/18-tries.pdf>) discloses the lookup time of a word in a binary search tree as, at most O(k) (pgs. L18.3, L18.5).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES E RICHARDSON whose telephone number is (571)270-1917. The examiner can normally be reached Mon-Fri 9:00-5:30.
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, Sherief Badawi can be reached at (571) 272-9782. 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.
/James E Richardson/Primary Examiner, Art Unit 2169
Prosecution Insights