UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`BloomReach, Inc.,
`Petitioner,
`
`v.
`
`Guada Technologies LLC,
`Patent Owner.
`
`
`Case IPR2019-01304
`Patent No. 7,231,379
`
`
`GUADA’S PRELIMINARY RESPONSE
`
`Dated: October 25, 2019
`
`Isaac Rabicoff
`Reg. No. 74,147
`RABICOFF LAW LLC
`Lead Counsel for Patent Owner
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`BloomReach, Inc.,
`Petitioner,
`
`v.
`
`Guada Technologies LLC,
`Patent Owner.
`
`
`Case IPR2019-01304
`Patent No. 7,231,379
`
`
`GUADA’S PRELIMINARY RESPONSE
`
`Dated: October 25, 2019
`
`Isaac Rabicoff
`Reg. No. 74,147
`RABICOFF LAW LLC
`Lead Counsel for Patent Owner
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`TABLE OF CONTENTS
`
`1. Introduction .......................................................................................................... 1
`
`2. Wesemann fails to teach key limitations of each of the challenged claims,
`leaving the board with no basis for institution (Grounds 1 and 2). ........................... 1
`
`2.1 Wesemann teaches how to automatically traverse connected nodes of telephone
`service systems, because these legacy systems cannot jump nodes. ......................... 1
`
`3. Fratkina also fails to teach the jumping limitation recited by each of the
`challenged claims, leaving the board with no basis for institution (Grounds 3 and
`4). 8
`
`3.1 Fratkina’s menu embodiments fail to teach the jumping limitation. ................... 8
`
`3.2 Bloomreach cannot combine the alleged “jumping” feature of
`autocontextualization to the menu embodiment. .....................................................11
`
`4. Conclusion .........................................................................................................17
`
`
`
`
`
`
`
`
`
`— ii —
`
`
`
`1.
`
`Introduction
`
`When evaluating BloomReach’s petition for inter partes
`
`review, the Board should consider these key points:
`
`• Wesemann (the first of two primary references) teaches
`how to automatically traverse connected nodes of telephone
`service systems, because these legacy systems cannot jump
`nodes;
`
`the menu embodiment of Fratkina (the second of two
`•
`primary references) also fails to teach the jumping limitation;
`and
`
`Bloomreach cannot combine Fratkina’s alleged
`•
`“jumping” feature of autocontextualization to its menu
`embodiment.
`BloomReach has therefore failed to show “that it is more likely
`
`than not that at least 1 of the claims challenged in the petition is
`
`unpatentable” and therefore institution of inter partes review must be
`
`denied. 35 U.S.C. § 324(a).
`
`2. Wesemann fails to teach key limitations of each of the
`challenged claims, leaving the board with no basis for
`institution (Grounds 1 and 2).
`
`2.1 Wesemann teaches how to automatically traverse
`connected nodes of telephone service systems, because
`these legacy systems cannot jump nodes.
`
`“Jumping” nodes—as undisputedly construed here—is contrary
`
`
`
`— 1 —
`
`
`
`to the teachings of Wesemann.1 Element 1(b)2 recites: identifying at
`
`least one node, other than the first node, that is not directly connected
`
`to the first node but is associated with the at least one keyword, and
`
`jumping to the at least one node. Ex. 1001, claim 1 (emphasis
`
`added) (also referred to as the “jumping limitation”).
`
`Wesemann provides a user interface for navigating legacy
`
`telephone service systems that can only receive dual tone multi-
`
`frequency signals as inputs. See Ex.1004, Abstract. These legacy
`
`telephone systems cannot jump to non-connected menu states (i.e.
`
`nodes):
`
`
`
`
`1 Bloomreach adopted Guada’s construction of “jumping”, citing the prosecution
`history and the Patent Owner Opposition to Motion to Dismiss. Presumably,
`Bloomreach thereby also adopts the construction of “Jumping to the At Least One
`Node” and “Jumping to the Vertex”, which makes clear that the subject doing the
`jumping is the “system”. See Ex. 1003, 18-19 (where these terms are construed as
`“the system jumping to the at least one node” and “the system jumping to the
`vertex”, respectively; emphasis added).
`2 Bloomreach acknowledges that all of the challenged claims possess an
`equivalent jumping limitation, whether jumping across nodes (independent claim
`1 with corresponding dependent claims 2-6) or jumping across vertices
`(independent claim 7). See Petition, 39 (Bloomreach opines that the jumping
`limitation of Claim 1(b) as equivalent to the same limitation in Claim 7(c)).
`— 2 —
`
`
`
`
`
`Wesemann teaches moving between connected menu states only
`because of the inherent limitations of telephone service systems
`
`“To cause the telephone service system to jump from a first menu
`state to a second menu state, the voice-enabled user interface
`generates and transmits output to the telephone service system that
`causes the telephone service system to traverse the one or more
`menu states it is jumping over, steps 536, 538. For example, if the
`telephone service system is in the menu state of business laptop
`sales 662 when the user speaks “home laptop sales,” then the
`voice-enabled user interface generates and transmits output to
`the telephone service system that causes the telephone service
`system to first transition to business computer sales 660, then to
`sales 630, then to home computer sales 650, and then finally to
`home laptop sales 652. It should be appreciated that all of the
`communications associated with jumping from one menu state to
`another menu state are conducted without the knowledge and efforts
`of the user, which is an improvement over the prior art.” (Ex. 1004,
`12:53-65; emphasis added.)
`
`
`As an example, when a user requests home laptop sales 652
`
`while in the business laptop sales 662 menu state, Wesemann teaches
`
`how to automatically transition between connected menu states
`
`without user interaction. In this way, Weisman’s user interface (which
`
`provides inputs to, but is inherently limited by, the telephone service
`
`system) generates the following series of connected menu state
`
`transitions in order to move from business laptop sales 662
`
`(highlighted yellow) to home laptop sales 652 (highlighted purple):
`
`
`
`
`
`— 3 —
`
`
`
`
`
`Ex. 1004, Fig. 6 (annotated above); see also id., 12:53-65.
`
`As shown in the flow diagram below, Wesemann’s user
`
`interface generates the connected menu states needed to transition
`
`from home laptop sales 652 to business laptop sales 662. These
`
`connected, transition menu states are determined at step 536
`
`(highlighted blue), and outputted to the telephone service system at
`
`step 538 (highlighted green):
`
`
`
`— 4 —
`
`
`
`
`
`Ex. 1004, Fig. 5 (annotated above); see also id., 12:53-65.
`
`Wesemann therefore addresses a problem in the art that
`
`requires transitioning between connected menu states (i.e. nodes) and
`
`not non-connected nodes. As such, Wesemann defines “jumping”
`
`between menu states differently than here: transitioning across
`
`multiple connected menu states without user interaction. See Ex.
`
`1004, 12:53-65 (noting that the user interface generates the connected
`
`transition menu states needed to reach the requested menu state, and
`
`that “[i]t should be appreciated that all of the communications
`
`associated with jumping from one menu state to another menu state
`
`are conducted without the knowledge and efforts of the user, which is
`— 5 —
`
`
`
`
`
`an improvement over the prior art.”).
`
`As such, when Bloomreach suggests that Wesemann teaches
`
`“jumping” nodes, that is “jumping” according to Wesemann, not
`
`according to the parties agreed construction of jumping here. What’s
`
`worse, Bloomreach cites a passage that mentions “jumping menu
`
`states” but cuts off the lines immediately following where Wesemann
`
`explains how its form of jumping is accomplished (i.e. by traversing
`
`across connected menu states). See Petition, 28 (citing Ex. 1004,
`
`12:25-42; but omitting 12:42-65, which explains the “process” that
`
`allows “jump[ing] from one menu state to another menu state. . .”.)
`
`In fact, Bloomreach’s jumping-related passage reveals the
`
`contradiction between the definitions of “jumping” from Wesemann
`
`and the challenged patent. Wesemann spares the user from entering
`
`input while the user interface transitions between connected menu
`
`states to reach the requested menu state, but does not allow for
`
`transitions between non-connected nodes: “the invention enables a
`
`user to jump from one menu state to another menu state without
`
`having to enter input for every ‘in between’ menu state.” Id.,
`
`12:27-30.
`
`Nor does Smyth (Bloomreach’s employed expert) provide
`
`
`
`— 6 —
`
`
`
`evidence—let alone even alleges—that the system jumps across
`
`unconnected nodes. He certainly fails to explain away the contrary
`
`teaching, discussed above, that requires the system to navigate
`
`through connected nodes. Rather, his declaration confirms, in two
`
`passages, that Wesemann only spares the user from needing to make
`
`multiple requests or interactions to navigate across multiple connected
`
`nodes.
`
`Smyth’s first passage merely shows that the transfer across
`
`nodes will be automatic for the user rather than a showing a system
`
`that can jump across non-connected nodes. See Ex. 1007, ¶ 55
`
`(“Although extension 123 is not directly connected to main menu state
`
`610, upon receiving the input ‘123,’ the system will ‘identify the user
`
`input as a valid input for another state of the menu hierarchy,’ (i.e.,
`
`identifying a node other than the first node) and the user will
`
`‘automatically be transferred’ by the system to extension 123,
`
`without forcing the user to traverse through the intermediate
`
`node, ‘Directory of Personnel’ 640 (i.e., jumping the user to the other
`
`node)”; emphasis added).
`
`Faring no better, in Smyth’s second passage Smyth uses his
`
`own words when he says that the “system will jump” across nodes,
`
`
`
`— 7 —
`
`
`
`but even there he acknowledges that it is the user that is saved from
`
`traversing intermediate steps rather the system avoiding those steps by
`
`jumping. See id., ¶ 56 (“the system will ‘jump’ from home laptop
`
`sales 652 to home computer support 646 without requiring the user
`
`to traverse intermediate steps”; emphasis added).
`
`Wesemann therefore teaches transitioning only between
`
`connected menus states (i.e. nodes) without user interactions and does
`
`not teach jumping between non-connected nodes. Wesemann
`
`therefore contradicts what the jumping limitation requires and renders
`
`no challenged claim obvious.
`
`3.
`
`Fratkina also fails to teach the jumping limitation recited by
`each of the challenged claims, leaving the board with no
`basis for institution (Grounds 3 and 4).
`
`3.1 Fratkina’s menu embodiments fail to teach the
`jumping limitation.
`
`Fratkina’s menu embodiment (Figures 10-12) involve
`
`movements across connected menu-related nodes that were created by
`
`a dialog designer. The dialog offers a limited set of menu options
`
`leading to connected nodes.
`
`The annotated figures below show parent nodes outlined in red
`
`and the directly-connected child nodes outlined in green.
`
`
`
`— 8 —
`
`
`
`DIALOG ”STATE
`
`uuasmws ammo
`DURING 0mm; mu USER
`
`mwzres {SELECTIONS}
`
`
`
`ITERAIICIN N+1
`
`HOW lN'UULI) YOU LIK:
`YOUR EGGS PREPARED?
`
`ITERATIG'N N+2
`
`
`
`
`SCRAM BLED
`
`PGACH ED
`
`BENEDICT
`
`1120
`
`
`
`
`
`
`Ex. 1006, Fig. 11 (annotated) (at the breakfast node: offering directly-
`
`connected eggs or pancakes; at the eggs node: offering directly
`
`connected scrambled, poached, or benedict); see also id., 26:46-60
`
`(describing how the dialog in Figure 11 leads the user through
`
`directly-connected, predetermined node options).
`
`
`
`— 9 —
`
`
`
`
`QUESTIONS OENERATEO
`DURING DIALOO AND USER
`ANSWERS (SELECTIONS)
`
`
`DIALOO STATE
`
`ITERATJON N
`
`ARE YOU ON ANY DIET?
`
`WHICH OF THE FOLLOWING
`WOULD YOU LIKE TO GET?
`
`creoleGool
`I
`
`node=poncokes;
`
`HOW WOULD YOU
`LIKE YOUR PANCAKE?
`
`
`
`F
`BREAK AST
`
`
`
`
`
`
`WITH SYRUP WITHOUT SYRUP
`
`ITERATION N+I
`
`
`IT (breakfast, confirmed)
`
`I
`
`
`
`Id., Fig. 12 (at the menu node: offering directly-connected breakfast,
`
`lunch or dinner; at the pancakes node: offering with or without syrup).
`
`
`
`
`
`— 10 —
`
`
`
`And Fratkina specifically teaches that dialogs always lead to
`
`node-to-node traversal (as shown in the next section, the only
`
`exception is autocontextualization, which is involved with an
`
`incompatible form of goal resolution). During such dialogs, the focus
`
`node always generates answer selections that lead to that node’s
`
`directly-connected children:
`
`Focus nodes present selections leading to directly-connect child
`nodes
`
`“A. Focus Nodes/Target Nodes
`
`Each goal is comprised of one or more "target" concept nodes
`paired with one or more focus nodes. The concept nodes represent
`the node or nodes within the taxonomy at which the dialog will
`ultimately terminate, while the focus node represents the starting
`location in the taxonomy. The focus node of the goal captures the
`current status of the goal resolution process. The focus node is the
`most detailed information available to the dialog engine at each
`point in the dialog. Each question posed to a user is generated
`from the focus node of the goal, while the answer selections
`offered to the user are the focus node's children.” (Ex. 1006,
`22:54-65
`
`
`3.2 Bloomreach cannot combine the alleged “jumping”
`feature of autocontextualization to the menu
`embodiment.
`
`For Fratkina’s menu embodiments, or any taxonomy with
`
`predetermined nodes with associated keywords (i.e. the only node
`
`
`
`— 11 —
`
`
`
`arrangement that could also satisfied Element 1(a)), a user’s response
`
`to a dialog prompt will return a confirmed node selection:
`
`When a user selects a predetermined menu option, the node selected
`is a confirmed node
`
`“[I]n 1120 when the user answers "scrambled" 55 in response to the
`question "How would you like your eggs prepared," the goal of the
`dialog proceeds from the "eggs" node to the "scrambled" node 1130.
`In this example, the nodes selected are confirmed nodes since
`they represent nodes whose relevance to the user's information
`need has 60 been established.” (Ex. 1006, 26:54-60.)
`
`
`And yet autocontextualization never returns confirmed nodes,
`
`making it unusable in a system where confirmed nodes with
`
`associated keywords are traversed:
`
`Autocontextualization never returns confirmed nodes, unlike the
`menu embodiments
`
`“All the text the user provides to the system is autocontextualized
`against the taxonomies in the knowledge map. This results in topic
`spotter nodes that represent the system's understanding of the user's
`input. Unlike confirmed nodes (discussed above), topic spotter
`nodes cannot automatically accepted [sic] as true since there is
`always the possibility that dialog engine 232 misunderstood the
`user's input.” (Ex. 1006, 29:5-11; emphasis added.)
`
`“Since it is assumed the underlying information need of the user
`does not change in the course of a single dialog, the dialog
`engine can always use confirmed nodes to advance goals.
`However sometimes other information cannot be fully trusted.
`
`
`
`— 12 —
`
`
`
`In particular, autocontextualization, being an automatic
`process, can make mistakes. Therefore it may not be safe to
`assume that correct concept tags have been extracted from the
`query.” (Ex. 1006, 33:49-56.)
`
`
`What’s more, Bloomreach fails to mention that the unique tags
`
`(the alleged “keywords”) associated with menu nodes created by a
`
`dialog designer are not the same tags as those created by
`
`autocontextualization3:
`
`Autocontextualization creates tags that cannot be the same tags
`associated with menu nodes
`
`“The taxonomy tag 60 also includes an attribution (not shown)
`which records whether the tag was created by a person [i.e. a dialog
`designer], or automatically by the system using
`autocontextualization.” (Ex. 1006, 14:31-34; citations omitted.)
`
`
`Smyth merely parrots Bloomreach’s analysis, and offers no
`
`evidence as to why the teachings of autocontextualization and the
`
`menu embodiments would collectively disclose the jumping
`
`
`3 Bloomreach suggests—without support and contrary to Fratkina’s teachings—
`that the tags (i.e. alleged “keywords) in the menu nodes (which are created by a
`dialog desire) are the same as the tags returned by autocontexualization. See
`Petition 58-59 (“a user may use “keyword or natural language” queries to request
`actions or make choices, and a “dialog engine” converts the user’s input into tags
`to be processed by the system using an ‘autocontextualization’ process.”)
`— 13 —
`
`
`
`
`
`limitation. Instead, Smyth concludes—without explanation—that
`
`autocontextualization would allow a user to jump over nodes like
`
`those in the menu embodiments: “The system is able to identify the
`
`non-adjacent node to which the user would like to go through
`
`“autocontexualization.” Ex. 1007, ¶ 84. But as shown above, the
`
`nodes returned by autocontextualization are topic spotter nodes, not
`
`the confirmed nodes that would result from a user selecting menu-type
`
`node options constructed by a dialog designer. Smyth leaps to the
`
`desired conclusion with no supportive analysis or reference citation.
`
`The Board should therefore reject it.
`
`3.3 Merely uttering the word “jumping” does not satisfy
`this limitation: autocontextualization does not teach
`the jumping limitation.
`
`“Jumping” appears in Fratkina 3 times in total, over 2 short
`
`passages related to autocontextualization. As discussed in the previous
`
`section, nodes returned by autocontextualization are not confirmed
`
`and require a series of follow-up questions to avoid misunderstanding.
`
`See § 3.2 above. So instead of teaching autocontextualization to jump
`
`from a breakfast node to a scrambled eggs node, this feature is used
`
`when the user’s input creates “uncertainty as to which branch applies
`
`or when multiple branches are relevant”:
`
`— 14 —
`
`
`
`
`
`
`
`Jumping with autocontextualization is only used to advance
`multiple subgoals when the system is uncertain about which subgoal
`branch applies
`
`“The process of choosing one path over another is sometimes
`difficult, particularly if there is uncertainty as to which branch
`applies or when multiple branches are relevant. It is a good
`practice during taxonomy building to avoid branches that are likely
`to be difficult to choose between, but it is not possible to avoid the
`issue entirely. If such a situation occurs, and the user chooses
`multiple nodes at a branching point, the dialog engine will
`create multiple subgoals for a goal. Subgoals of a goal are a
`mechanism to deal with uncertainty or multiplicity of the
`interaction. Resolution of each subgoal will be pursued in parallel
`by the dialog engine until the conditions are reached that resolve the
`parent goal of the subgoals. In fact, the system uses properties of
`subgoals in the process of goal resolution, so one subgoal is always
`created. Subgoals are identified by the node that represents the most
`detailed information. This node is referred to as focus of a subgoal.
`In the process of goal resolution, the focus is typically advanced
`along the edges of the taxonomy graph, but may jump to a node
`(or set of nodes) more than one edge away from the previous
`focus. Subgoals are resolved when their focus reaches the target set
`of concept nodes.” Ex. 1006, 27:22-43.
`
`
`This passage fails to teach or render obvious the jumping
`
`limitation for two key reasons.
`
`• This passage teaches how to resolve a goal when the user
`input suggests multiple branches in a hierarchy, where a the
`“focus” may advance multiple edges during goal resolution
`as the uncertainty is reduced (i.e. not where a user is
`presented with clear menu options, constructed by a dialog
`designer, and within an pre-identified branch such as
`— 15 —
`
`
`
`
`
`“breakfast”); and
`
`• Nowhere does this passage suggest that user input of
`predetermined menu-like keywords caused a jump—the
`opposite is true: if the user identified keywords associated
`with a non-adjacent node, the system would not be dealing
`with uncertainty over the correct branches or location in the
`hierarchy, i.e. the very problem addressed by
`autocontextualization according to Fratkina.
`
`Bloomreach cites the next jumping-by-autocontextualization
`
`passage without including the passage immediately above that
`
`explains how this autocontextualization actually operates.
`
`Autocontextualization never deals with user-provided keywords
`
`associated with non-adjacent nodes, since it creates nodes based on
`
`user input rather than “jumping” to nodes that it confirms. See also §
`
`3.2 above (distinguishing nodes returned by autocontextualization and
`
`the confirmed nodes used to navigate connected menu nodes.)
`
`Autocontextualized nodes are different from the confirmed nodes
`used to navigate a menu taxonomy
`
`“Since it is assumed the underlying information need of the user
`does not change in the course of a single dialog, the dialog
`engine can always use confirmed nodes to advance goals.
`However sometimes other information cannot be fully trusted.
`In particular, autocontextualization, being an automatic
`process, can make mistakes. Therefore it may not be safe to
`assume that correct concept tags have been extracted from the
`query.” (Ex. 1006, 33:49-56.)
`
`
`
`— 16 —
`
`
`
`“As mentioned above, dialog engine 232 generates followup
`questions to the user in the process of resolving active goals. The
`type of question to be generated can be specified by the dialog
`designer. The answers to these questions advance the state of the
`subgoal to a new location in the taxonomy—e.g. change the focus of
`the subgoal. Changing the focus of a subgoal may be by path
`traversal within the knowledge map (e.g., the focus may change
`from parent node to child node). Autocontextualization can be
`used to jump to a specific place in the taxonomy and the dialog
`designer can explicitly specify a place to jump to.” (Id., 34:32-
`42.)
`
`
`Yet again, Bloomreach fails to explain how nodes created by
`
`autocontextualization are used to navigate an existing hierarchy of
`
`nodes, such as meal options on a menu. That’s because Fratkina’s
`
`invention teaches no such thing.
`
`4.
`
`Conclusion
`
`Guada therefore requests that the Board deny institution on all
`
`grounds raised by BloomReach’s Petition.
`
`
`
`— 17 —
`
`
`
`Dated: October 25, 2019
`
`Respectfully submitted,
`
`/Isaac Rabicoff/
`Isaac Rabicoff
`Reg. No. 74,147
`RABICOFF LAW LLC
`73 W Monroe St
`Chicago, IL 60603
`773-669-4590
`isaac@rabilaw.com
`
`Counsel for Patent Owner
`Guada Technologies LLC
`
`
`
`
`
`— 18 —
`
`
`
`CERTIFICATION UNDER 37 C.F.R. § 42.24(D)
`
`This Petition complies with the requirements of 37 C.F.R. §
`
`42.24. As calculated by the word count feature of Microsoft Word for
`
`Office 365, it contains 2,946 words, excluding the words contained in
`
`the following: Table of Contents, Table of Authorities, List of
`
`Exhibits, Certification Under § 42.24(d), and Certificate of Service.
`
`
`
`
`/Isaac Rabicoff/
`Isaac Rabicoff, Reg. No. 74,147
`
`
`
`— 19 —
`
`
`
`
`
`
`
`CERTIFICATE OF SERVICE
`
`It is hereby certified that on October 25, 2019, a copy of the
`
`foregoing document was served via Electronic Mail upon the
`
`following:
`
`Dion M. Bregman
`Michael J. Lyons
`Ahren C. Hsu-Hoffman
`BloomReach-IPR@morganlewis.com
`
`
`
`/Isaac Rabicoff/
`Isaac Rabicoff, Reg. No. 74,147
`
`
`
`— 20 —
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
