UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`EPIC GAMES, INC.,
`Petitioner,
`
`v.
`
` INGENIOSHARE, LLC,
` Patent Owner.
`
`
`Case No. IPR2022-00295
`Patent No. 10,492,038
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`PATENT OWNER’S SUR-REPLY
`_____________________________________________________
`
`
`
`Mail Stop PATENT BOARD, PTAB
`Commissioner for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`EPIC GAMES, INC.,
`Petitioner,
`
`v.
`
` INGENIOSHARE, LLC,
` Patent Owner.
`
`
`Case No. IPR2022-00295
`Patent No. 10,492,038
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`PATENT OWNER’S SUR-REPLY
`_____________________________________________________
`
`
`
`Mail Stop PATENT BOARD, PTAB
`Commissioner for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`
`
`TABLE OF CONTENTS
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Page
`
`
`
`
`I.
`
`
`
`
`
`II. GROUND I – HULLFISH COMBINED WITH TANIGAWA
`DOES NOT OBVIATE CLAIMS 7, 10-12, 22-24, 33-36,
`38-41,46,49,51-53, 55, 57-58, AND 64-66 TO A POSITA
`
`INTRODUCTION ………………………………………………
`
`A. No Rebuttal Testimony …………………………………
`
`B.
`
`Petitioner’s Attacks Of Dr. Rouskas Are Baseless ……...
`
`.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`1
`
`1
`
`1
`
`3
`
`3
`
`6
`
`16
`
`17
`
`21
`
`21
`
`21
`
`26
`
`A. No Motivation To Combine ……………….…….……
`
`B.
`
`[7.0] The Alleged Combination Does Not Teach
`A Network Based Portal (“NBP”) …………….……..
`
`[7.1] The Alleged Combination Does Not Teach A “Prior
`Registration Process” …………………………...……..
`
`[7.3] “Any Of The Plurality Of Modes Of
`Communication” “All Depending On An Identifier”
`Is Not Obviated By Tanigawa And Hullfish ..……..…….
`
`[7.4] “Block” Is Not Rendered Obvious By The
`Alleged Combination ………………………………….
`
`[7.5] Is Not Rendered Obvious By The Alleged
`Combination
`………………………………………..
`
`[7.8] Is Not Rendered Obvious By The Alleged
`Combination
`…………………………….………….
`
`C.
`
`
`D.
`
`E.
`
`F.
`
`G.
`
`
`
`III. GROUND II – CLAIMS 8, 9, 43, 44, 47, 48, 50, AND 54
`ARE NOT RENDERED OBVIOUS BY TANIGAWA
`IN VIEW OF HULLFISH AND LOVELAND …………….
`
`
`
`
`
`
`
`
`i
`
`
`
`IV. GROUND III – CLAIMS 37, 42, 56, 59–63, AND 67
`GROUNDIII — CLAIMS37, 42, 56, 59-63, AND 67
`IV.
`ARE NOT RENDERED OBVIOUS BY TANIGAWA IN
`ARE NOT RENDERED OBVIOUS BY TANIGAWAIN
`VIEW OF HULLFISH AND TAKAHASHI ……………………
`VIEW OF HULLFISH AND TAKAHASHI....................004.
`
`
`V. GROUND IV – CLAIM 45 IS NOT RENDERED OBVIOUS
`GROUNDIV — CLAIM 45 IS NOT RENDERED OBVIOUS
`BY TANIGAWA IN VIEW OF HULLFISH, LOVELAND,
`BY TANIGAWAIN VIEW OF HULLFISH, LOVELAND,
`AND TAKAHASHI ………………………………………..
`AND TAKAHASHI
`on. cece eee eee c eee cece cece eee eee eee een ans
`
`
`VI. CONCLUSION ………………………………………………
`CONCLUSION oo... eee cce cece ee ee eee eee e eens eenaeen ees
`VI.
`
`
`
`27
`27
`
`27
`27
`
`28
`28
`
`
`
`ii
`
`
`
`PATENT OWNER’S EXHIBIT LIST
`
`Complaint
`
`Epic Games Inc.’s Preliminary Invalidity Contentions
`
`Order Setting Markman Hearing
`
`Epic Games Inc.’s Opening Claim Construction Brief
`
`Declaration of Dr. George N. Rouskas, Ph.D.
`
`Decision Denying Institution, IPR2022-00297
`(PTAB May 26, 2022)
`
`Judge Chang, IPR2022-00294, Paper No. 13
`(PTAB June 7, 2022) (dissent)
`
`CV of Dr. George N. Rouskas, Ph.D.
`
`U.S. Patent Application 2002/0116461 (“Diacakis”)
`
`
`Exhibit 2001
`
`Exhibit 2002
`
`Exhibit 2003
`
`Exhibit 2004
`
`Exhibit 2005
`
`Exhibit 2006
`
`
`Exhibit 2007
`
`
`Exhibit 2008
`
`Exhibit 2009
`
`
`
`
`
`
`
`
`iii
`
`
`
`I.
`
`
`
`INTRODUCTION
`
`A. No Rebuttal Testimony
`
`Petitioner’s Reply does not include any rebuttal testimony from an expert
`
`even though it could have. Practice Guide at 73. As a result, Petitioner’s Reply is
`
`based on attorney argument and the original Petition Declaration. More
`
`importantly, Dr. Rouskas’s POR Declaration and his deposition testimony stand
`
`unrebutted.
`
`
`
`
`
`B.
`
`Petitioner’s Attacks On Dr. Rouskas Are Baseless
`
`First, Petitioner cross-examined (deposed) Dr. Rouskas for two days. Exhibit
`
`1043. Dr. Rouskas testified at length regarding his opinions to the point that
`
`Petitioner’s counsel interrupted Dr. Rouskas because Petitioner believed that Dr.
`
`Rouskas’s testimony was too detailed. Id. at 265-66. Tellingly, Petitioner does not
`
`cite to any cross-examination question that Dr. Rouskas was not able to answer.
`
`Dr. Rouskas testified that the opinions expressed in his Declaration (Exhibit 2001)
`
`are his own and that he spent “anywhere between 80 and 100 hours” preparing his
`
`Declaration. Id. at 24-25.
`
`
`
`Second, Petitioner’s reliance on Hulu and Juniper Networks is inapplicable.
`
`Petitioner failed to provide a single example of how Dr. Rouskas’s testimony is
`
`“cursory or unsupported”. That the POR relies upon and incorporates Dr.
`
`Rouskas’s testimony is the norm in IPR practice. Doing otherwise risks exclusion.
`
`
`
`1
`
`
`
`Practice Guide at 35-36 (Ҥ 42.6(a)(3) prohibits incorporating arguments by
`
`reference from one document into another. Thus, parties that incorporate expert
`
`testimony by reference … risk having the testimony not considered by the
`
`Board.”).
`
`
`
`Finally, the rule of completeness shows that Dr. Rouskas did not contradict
`
`his Declaration testimony. Fed. R. Evid. 106. Indeed, Petitioner had four attorneys
`
`and its expert, Dr. Almeroth, attend in person Dr. Rouskas’s deposition. Exhibit
`
`1043 at 3-4. Petitioner’s five-person team huddled during breaks to review the
`
`real-time transcript in an effort to create out of context “sound bites” that Petitioner
`
`could use to distort Dr. Rouskas’s testimony by asking, re-asking, and asking again
`
`the same question in a manner that would never be allowed in a “live” trial. Of
`
`course, Petitioner’s Reply never addresses any one of PO’s objections to
`
`Petitioner’s “asked and answered” questioning scheme.
`
`Rather than trying to tarnish the reputation of a Distinguished Graduate
`
`Professor at N.C. State University, a better approach would have been to submit a
`
`rebuttal declaration from Dr. Almeroth who theoretically could have rebutted Dr.
`
`Rouskas’s testimony if it truly is so baseless. Exhibit 2008 at 1; Exhibit 1043 at 4.
`
`
`
`
`
`
`
`2
`
`
`
`II. GROUND I – HULLFISH COMBINED WITH TANIGAWA DOES
`NOT OBVIATE CLAIMS 7, 10-12, 22-24, 33-36, 38-41,46,49,51-53, 55,
`57-58, AND 64-66 TO A POSITA
`
`
`
`
`A. No Motivation To Combine
`
`The POR shows there is no motivation to combine Tanigawa and Hullfish.
`
`POR at 8-12. Petitioner’s Reply argument is incorrect.
`
`
`
`First, PO does not contend that “the Petition proposes using the entirety of
`
`Hullfish’s ‘electronic message forwarding method’ within Tanigawa ….” Reply at
`
`6-7. Petitioner mischaracterizes PO’s position and Dr. Rouskas’s testimony. PO
`
`listed several aspects in which the entirety of Hullfish is incompatible with the
`
`Tanigawa system. POR at 8-12. As explained below, however, PO also pointed
`
`out that the specific blocking features of Hullfish that Petitioner relies on would be
`
`impossible to implement in Tanigawa’s system. Id.
`
`Second, PO’s motivation to combine arguments focus on fundamental and
`
`principal differences in design and operation between Tanigawa and Hullfish. POR
`
`at 12-14. Petitioner characterizes the differences as “minute” and
`
`“inconsequential” but does not even attempt to explain how these incompatibilities
`
`between the Tanigawa system and Hullfish’s blocking features could be overcome.
`
`Reply at 7-8. Specifically, any and all of Hullfish’s one-to-one blocking features
`
`based on the sender’s address or phone number would not work with Tanigawa’s
`
`system because (1) Tanigawa’s users “join a group after receiving invitations from
`
`
`
`3
`
`
`
`a server, not from another user” (POR at 13) and (2) Tanigawa teaches that users
`
`send their messages to a conference room address at a server, the server mixes
`
`messages from the various users, and then forwards them to the group. In other
`
`words, users receive messages from a server’s address not from the address of
`
`another user (POR at 2-3, 5, 7, and 32-33). Therefore, it is not possible for a
`
`Tanigawa user to selectively block another user as Petitioner argues. Similarly,
`
`Hullfish’s method of blocking a user based on its message’s contents would fail
`
`because each user receives a “synthesized mix” of messages from the server “with
`
`no information of who said what” (POR at 32-33). Petitioner’s Reply does not
`
`address these POR arguments. Petitioner therefore failed to meet its burden of
`
`proof. 37 C.F.R. § 42.1(d); Practice Guide at 42.
`
`Regarding the blocking of “abusive messages”, PO established that it would
`
`not be technically possible for a Tanigawa user who receives a “synthesized mix”
`
`of messages from a server to block messages from a specific user. POR at 5 and
`
`32-33.
`
`Regarding one-to-one blocking in group chatting, Dr. Rouskas further
`
`explained that allowing one participant to block another participant would result in
`
`a chaotic situation that defeats the fundamental purpose of a group communication
`
`in Tanigawa, i.e., engage in the exchange of ideas among the participants. Exhibit
`
`1043 at 341:12-343:16. As Dr. Rouskas pointed out, when a participant A blocks a
`
`
`
`4
`
`
`
`participant B, A will not hear what B says. Id. When a third participant C responds
`
`to something B said, A will not be able to follow the discussion, understand what is
`
`said, or respond appropriately – completely undermining the purpose of group
`
`discussion in Tanigawa. Therefore, allowing the one-to-one blocking feature of
`
`Hullfish in Tanigawa’s system (assuming it were possible to do so, which it is not),
`
`would result in chaos in Tanigawa. Id.
`
`Regarding the motivation to “avoid messages at inconvenient times”,
`
`Petitioner fails to understand the nature of Tanigawa’s system. As the POR clearly
`
`explains, participants join the group chat only after accepting an invitation. If the
`
`invitation arrives at an inconvenient time, a participant may simply decline it as
`
`Tanigawa teaches; there is no need or motivation to implement an additional one-
`
`to-one blocking feature. POR at 10, 12-13, and 33-34.
`
`Third, Dr. Rouskas did not admit “that PO’s arguments boil down to a
`
`POSITA’s inability to ‘incorporate’ Hullfish wholly into Tanigawa’s system.”
`
`Reply at 8. Petitioner again mischaracterizes PO’s position and does not even
`
`attempt to address either the POR arguments or Dr. Rouskas’s testimony. PO
`
`established that (1) Hullfish’s blocking features would fail in Tanigawa’s system
`
`(see above), and (2) even if, hypothetically, one-to-one blocking were technically
`
`possible in Tanigawa’s system, it would be a nonsensical solution that a POSITA
`
`
`
`5
`
`
`
`would not be motivated to implement. Exhibit 1043 at 315:14-316:9, 341:12-
`
`343:16.
`
`More fundamentally, Petitioner’s Reply does not address PO’s argument that
`
`Tanigawa’s system, by design and implementation, is for communication “among
`
`buddies, i.e., users who have mutually agreed to engage in communication.” POR
`
`at 9. In Tanigawa, buddies would not wish to block other buddies during a group
`
`conversation and Tanigawa teaches they can decline invitations that come at an
`
`inconvenient time. Id. Petitioner therefore failed to meet its burden of proof. 37
`
`C.F.R. § 42.1(d); Practice Guide at 42.
`
`
`
`
`
`
`B.
`
`[7.0] The Alleged Combination Does Not Teach A Network Based
`Portal (“NBP”)
`
`The Reply “first” argues that there is nothing to limit the claimed portal to a
`
`server or a website. Reply at 10. The POR shows that in the ʼ038 patent a “portal”
`
`and a “gateway” are used synonymously; and a “gateway” is a “networked server”.
`
`POR at 17-18. Petitioner’s Reply is incorrect and is not supported by any rebuttal
`
`expert testimony. Petitioner therefore failed to meet its burden of proof. 37 C.F.R.
`
`§ 42.1(d); Practice Guide at 42.
`
`Petitioner’s unsupported arguments are contradicted by Petitioner’s Reply
`
`Exhibit 1042, which states “[a] mobile portal is an Internet gateway that enables
`
`mobile devices to connect remotely ... typically via a Web browser interface.”
`
`Thus, Exhibit 1042 defines a “portal” as an Internet “gateway” and differentiates it
`6
`
`
`
`
`
`from a web browser interface, which is only used to connect a device to the portal.
`
`The definition of a portal in Exhibit 1042 is consistent with Dr. Rouskas’s
`
`testimony. Exhibit 1043 at 90:4-9, 91:10-15. As explained, when a user wishes to
`
`connect to a portal, they type the URL of the portal in the browser interface of their
`
`device and establish a connection to the portal which is a computer/server distinct
`
`from the user’s device. Id. at 80:7-81:22. Reply Exhibit 1041 also contradicts
`
`Petitioner’s attorney-only arguments as it defines a “portal” as a “platform,” not a
`
`user interface. Exhibit 1041.
`
`Moreover, that a definition includes the term “interface” does not mean a
`
`“portal” is an interface. The term “interface” is used to indicate how a user
`
`accesses the portal (i.e., via a web browser interface), not what a portal is. A web
`
`browser (as in Petitioner’s definition) is an interface found on all client devices
`
`(computers, laptops, phones, etc.) whether those devices access a portal or not. As
`
`Dr. Rouskas explained, a user uses their device’s web interface to request content
`
`stored at the portal, not on the user’s device. The portal sends the content to the
`
`user’s device after it receives the request, and the content is simply displayed on
`
`the device via the web browser interface. Exhibit 1043 at 80:1-81:22.
`
`Regarding “hosting” a web page, the Petitioner’s exhibit expressly states that
`
`devices access the portal by “connect[ing] remotely ... typically via a Web browser
`
`interface.” Exhibit 1042. Since the devices use a “Web browser interface” they
`
`
`
`7
`
`
`
`must necessarily connect to a website hosted at the portal. Id. In fact, the Figure in
`
`Petitioner’s Exhibit 1041 shows a “portal” that is consistent with PO’s evidence
`
`and Dr. Rouskas’s deposition testimony that a “portal” is not a “user interface” but
`
`rather at least includes the server hosting the site WWW.COMPANY.COM (a
`
`website), accessible by many:
`
`
`
`Exhibit 1041 at 2. User RAY in the figure types the URL into his browser to
`
`connect to the server of the portal site; the server collects information from various
`
`sources at the site to present to user RAY via the web browser interface. Exhibit
`
`1043 at 80:7-81:22. “Portals represent an early paradigm shift for enterprises
`
`online, which was to build websites that were customer-centric, rather than
`
`business-centric. Ideally, a portal enables an enterprise to design sites and
`
`navigations that are based on the user’s needs, rather than an organizational
`
`structure that only makes sense internally.” Exhibit 1041 at 3 (emphasis added).
`
`
`
`8
`
`
`
`Second, the Reply argues that PO incorrectly argues the ʼ038 patent defines
`
`“portal” as a “gateway” and that a gateway is always a “networked server.” Reply
`
`at 10-11. As shown above, however, Petitioner’s own Exhibit 1042 also defines
`
`“portal” as a “gateway”. Indeed, Dr. Rouskas’s testimony that to a POSITA the
`
`word “or” in the specification means that “portal” and “gateway” are used
`
`synonymously is unrebutted. POR at 17; Exhibit 1043 at 90:4-9, 91:10-15.
`
`Petitioner therefore failed to meet its burden of proof. 37 C.F.R. § 42.1(d); Practice
`
`Guide at 42.
`
`Third, the Reply argues that it is a “distinction without a difference” that the
`
`NBP and client devices have different functionalities because the NBP allows
`
`worldwide access to the user, whereas a client communication device is associated
`
`with a user. Reply at 11-12. Figure 12 of Tanigawa shows a user interface of a
`
`client resident on a client communication device connected to a network and which
`
`Petitioner argues is the claimed NBP:
`
`
`
`9
`
`
`
`
`
`Exhibit 1008 at Fig. 12. As a result, Tanigawa’s user interface is provided by and
`
`displayed in an IP terminal on the client-side of the network and Tanigawa’s IP
`
`terminals are client communication devices. Id.
`
`Petitioner claims that the user interface of Fig. 12 is the claimed NBP
`
`because “Tanigawa’s client terminal (1) connects a user to a network via the NBP
`
`and (2) is associated with that user.” Reply at 11 (emphasis in original). This
`
`statement is wrong. As explained in the POR, “[t]he ʼ038 specification and claims
`
`are clear that multiple users may access the ‘portal’.” POR at 22. Specifically,
`
`claim element [7.0] requires “each of the plurality of users having an identifier for
`
`use with the different communication modes, with the corresponding identifier
`
`being set via the network-based portal.” Exhibit 1001, ʼ038 Patent at Claim 7. As
`
`the POR demonstrates, user devices are assigned private IP addresses and cannot
`
`
`
`10
`
`
`
`be accessed from the public Internet; therefore “a user terminal/communication
`
`device allows access to its user only” and may not be accessed by other users to set
`
`their identifiers. POR at 20-22. Therefore, a user interface at a client
`
`terminal/communication device, such as the one shown in Fig. 12, cannot meet this
`
`claim element [7.0]. Id. The Reply is silent on this contradiction and does not even
`
`attempt to respond to PO’s arguments. Petitioner therefore failed to meet its
`
`burden of proof. 37 C.F.R. § 42.1(d); Practice Guide at 42.
`
`
`
`Fourth, the Reply argues that PO made a strawman argument “that only the
`
`sender’s device contains the NBP”. Reply at 12. Petitioner mischaracterizes PO’s
`
`position and its argument contains several incorrect statements. PO never claimed
`
`“that only the sender’s device contains the NBP.” The POR simply stated that
`
`Tanigawa’ user interface in Fig. 12 is on a user device: “Fig. 12 is a diagram
`
`showing an example of a user interface of an IM client, which is displayed in an IP
`
`terminal 7.” Exhibit 1010 at [0025]. Therefore, according to Tanigawa, each IP
`
`terminal 7-1, 7-2, and 7-3 of Fig. 1 includes the user interface of Fig. 12:
`
`
`
`11
`
`
`
`
`
`Exhibit 1010 at Fig. 1. The Reply admits as much: “all users of Tanigawa’s
`
`system access it via client terminals (7-1, 7-2, 7-3), which contain a user interface
`
`that connects clients to a network”. Reply at 12 (emphasis in original).
`
`The Reply, however, then claims that all these user interfaces are
`
`Petitioner’s claimed NBP: “all users (including senders and recipients) use
`
`Tanigawa’s NBP to connect to Tanigawa’s network-i.e., the NBP does not solely
`
`exist in a sender’s device” and “all users of Tanigawa’s system access it via client
`
`terminals (7-1, 7-2, 7-3), which contain a user interface that connects clients to a
`
`network (i.e., the NBP), indicating that both senders and recipients use this
`
`interface.” Reply at 12. But there is no NBP taught in Tanigawa, let alone a single
`
`“Tanigawa’s NBP” as the Reply claims; rather, Tanigawa teaches, and the Reply
`
`admits, that the user interface of Figure 12 exists in all IP terminals (e.g., 7-1, 7-2,
`12
`
`
`
`
`
`and 7-3 in Fig. 1). The Reply does not point to any specific one of these interfaces
`
`as the single NBP via which the plurality of users set their corresponding identifier,
`
`as claim element [7.0] requires. Instead, it collectively refers to these distinct user
`
`interfaces as “Tanigawa’s NBP” completely sidestepping the claim requirement of
`
`a single portal via which each of the plurality of users set their corresponding
`
`identifier.
`
`PO’s argument, which Petitioner mischaracterizes, was simply that the
`
`single NBP of the claims cannot exist on a user device because the user device can
`
`be accessed by its own user but cannot be accessed by any other user (e.g., to set
`
`the other user’s identifier). For instance, in Fig. 1, the user of IP terminal 7-1 may
`
`connect to the network via Tanigawa’s user interface at IP terminal 7-1 and the
`
`user of IP terminal 7-2 may connect to the network via Tanigawa’s user interface
`
`at IP terminal 7-2. But there is no teaching of the user of IP terminal 7-1 accessing
`
`Tanigawa’s user interface at IP terminal 7-2, and vice versa. Since the claim
`
`requires the plurality of users to set their identifiers “via the network-based portal”
`
`it follows that (1) the single portal cannot be on a user terminal/device, and (2)
`
`Petitioner’s claim that the distinct Tanigawa user interfaces on the various IP
`
`terminals are the claimed NBP is wrong. Petitioner therefore failed to meet its
`
`burden of proof. 37 C.F.R. § 42.1(d); Practice Guide at 42.
`
`
`
`13
`
`
`
`
`
`Fifth, regarding whether PO’s construction excludes a preferred
`
`embodiment (Fig. 7-12), the Reply argues that “because the patent’s figures are
`
`embodiments of the patent, they must include an NBP.” Reply at 16. Petitioner
`
`completely fails to address the POR’s evidence explaining why Figs. 7-12 are not
`
`directed to the use of a NBP. POR at 22-24. Petitioner’s position that every issued
`
`claim must encompass every figure/embodiment of a patent is wrong as a matter of
`
`law. The fact is that PO’s evidence submitted after the Institution Decision shows
`
`that a POSITA would understand that the embodiments of Figs. 7-12 are not
`
`directed to NBP operations but are instead directed to client-side operations at a
`
`client device; and this post-institution evidence stands unrebutted. Id.
`
`
`
`Petitioner’s argument that “the client devices described by the ʼ038 Patent
`
`enable messages to be received, as annotated in Figure 7 below” is irrelevant and
`
`side-steps PO’s argument:
`
`
`
`14
`
`
`
`
`
`Reply at 15-16. Indeed, Figure 7 does not teach a POSITA the use of a NBP. POR
`
`at 22-23. As evidenced in the POR:
`
`“Fig. 7 is a flow diagram of a personal call response process 200
`according to one embodiment of the invention. The personal call
`response process 200 is performed by an electronic device, such as a
`mobile communication device (e.g., mobile telephone).
`
`
`POR at 23-24. Similar language is used in describing Figures 8-12. Id. Figures 7-
`
`12 concern how a recipient user interacting with their client device can respond to
`
`an incoming call or message. As a result, a construction that has the NBP at a
`
`server distinct from the second user’s communication device does not exclude a
`
`
`
`15
`
`
`
`preferred embodiment, if anything, it enables them. POR 24. Petitioner therefore
`
`failed to meet its burden of proof. 37 C.F.R. § 42.1(d); Practice Guide at 42.
`
`
`
`
`
`C.
`
`[7.1] The Alleged Combination Does Not Teach A “Prior
`Registration Process”
`
`The POR proves that neither Tanigawa nor Hullfish teach a user registering
`
`with their own client device. POR at 28-29. Petitioner’s Reply is incorrect and is
`
`not supported by any rebuttal evidence from the perspective of a POSITA. Reply at
`
`16-17. Petitioner therefore failed to meet its burden of proof. 37 C.F.R. § 42.1(d);
`
`Practice Guide at 42.
`
`
`
`As the Petition states and Petitioner admits, [7.1] requires “the first user
`
`being identified at least depending on a prior registration process by the first user
`
`regarding the use of the network-based portal.” Exhibit 1001, ʼ038 Patent at Claim
`
`7 (emphasis added); Petition at 28; and Reply at 17. Both Tanigawa and Hullfish
`
`teach that users register their own information (e.g., usernames, addresses, phone
`
`numbers, etc.) with a server so as to use the communication services offered at the
`
`server. Exhibit 1010 at [0049]-[0054], [0062]-[0065], and [0085]; Exhibit [1011] at
`
`5:63-66, 6:12-13, and 10:12-17; and POR at 28. Neither Tanigawa nor Hullfish
`
`teach a registration process “regarding the use of the network-based portal;” in
`
`fact, the word “portal” does not appear in either Tanigawa or Hullfish.
`
`
`
`The Reply again mischaracterizes PO’s argument. PO did not “attempt to
`
`add extraneous language to the claim” by arguing that Tanigawa and Hullfish do
`16
`
`
`
`
`
`not “teach a user registering with their own device.” Reply at 17. PO simply
`
`pointed out that Petitioner’s arguments regarding Petitioner’s claimed NBP and the
`
`registration process are contradictory. Specifically, as the POR explained and as
`
`discussed above, the user interface of Fig. 12, i.e., Petitioner’s claimed NBP, is on
`
`a user terminal/device. A user may simply open and use an interface on their
`
`device without first having to register “regarding the use of” that interface (i.e., the
`
`claimed NBP). POR at 29. “Therefore, if, as Petitioner contends, the claimed
`
`‘network-based portal’ was a ‘user interface that connects clients to a network,’
`
`then no registration process would be required.” Id. Conversely, if a registration
`
`process is required, then the NBP cannot be an interface on a user terminal/device.
`
`
`
`
`
`D.
`
`[7.3] “Any Of The Plurality Of Modes Of Communication” “All
`Depending On An Identifier” Is Not Obviated By Tanigawa And
`Hullfish
`
`Petitioner mischaracterizes PO’s argument regarding the combination’s
`
`failure to teach “identifiers”. Reply at 18-19. Element [7.3] requires “wherein the
`
`messages are eligible to be received … based on any of the plurality of
`
`communication modes, all depending on an identifier associated with the second
`
`user.” Therefore, the identifier must be sufficient to route the messages to the
`
`second user in different communication modes (i.e., at least text messaging and
`
`voice communication, per element [7.2]).
`
`
`
`17
`
`
`
`Contrary to Petitioner’s argument (Reply at 17), and as explained in the POR
`
`(POR at 29-31), Tanigawa does not teach this claim element. Specifically,
`
`Tanigawa teaches that the nickname (i.e., Petitioner’s claimed “identifier”) is not
`
`sufficient to establish communication. Rather, Tanigawa teaches that at a user
`
`terminal, “the event analyzing portion 789 receives a specification of an account
`
`name of the chat buddy to be invited to the conference room” and sends it to the
`
`IM server. Exhibit 1010 at [0131]; POR at 30. The IM server then “identifies
`
`records 440 having the account names included in the participation requesting
`
`command” and “obtains an address registered in each of the fields 432 of the IM
`
`clients, which are determined as being able to participate therein.” Exhibit 1010 at
`
`[0132]. Finally, “the participation inviting command is sent to the IM terminal 7-1
`
`(account name of the IM client: client D) and the IM terminal 7-3 (account name of
`
`the IM client: client F).” Id. at [0133]. Therefore, Tanigawa expressly teaches that
`
`to establish communication the addresses in 432 of the clients must be used, and
`
`hence, the nickname is not sufficient.
`
`Dr. Rouskas stated that a “screen name” such as “taro” is an identifier to
`
`contact a buddy in a text messaging system and is different than a phone number
`
`that must be used to call that same buddy. Exhibit 1043 at 284:4-291:14.
`
`
`
`18
`
`
`
`Petitioner also mischaracterizes Figs. 3 and 10 of Tanigawa when it claims
`
`that “even where a second user has multiple devices, these devices are identified
`
`by the same nickname.” Reply at 17-18.
`
`
`
`
`
`
`
`Exhibit 1010 at Figs. 3 and 10. From these two Figures, a POSITA would
`
`understand that a nickname such as “hanako” is not sufficient to identify the two
`
`devices of user “hanako;” rather, the client name (client D or client E) or better yet
`
`the corresponding address is necessary to identify whether user “hanako”
`
`communicates with their IP terminal 7-1 or their VoIP telephone 8. Tanigawa also
`
`
`
`19
`
`
`
`requires a user to register a separate record 440 for each of his/her devices, each
`
`record including a separate account name and address that corresponds to the
`
`specific device. Exhibit 1010 at [0050] and Fig. 3.
`
`Further, with respect to Fig. 10, Tanigawa teaches that users “hanako” and
`
`“yoshi” participate in an IM using account names “client D” and “client F,”
`
`respectively, (Ex. 1010 at [0116]) but are invited to participate in the voice chat via
`
`account names “client E” and “client G,” respectively. Exhibit 1010 at [0145].
`
`Fig. 12 of Tanigawa also refutes Petitioner’s argument that the nicknames
`
`are sufficient for communication:
`
`
`
`Exhibit 1010 at Fig. 12. Specifically, the display area for text chatting 140 identify
`
`the communicating buddies using their account names, “Client A” and “Client C,”
`
`not their nicknames. Similarly, the presence information display area 135
`
`
`
`20
`
`
`
`identifies buddies using account names, not nicknames. Therefore, Tanigawa
`
`expressly teaches that nicknames are not sufficient, and buddies use their account
`
`names for communication. Id.
`
`E.
`
`[7.4] “Block” Is Not Rendered Obvious By The Alleged
`Combination
`
`As the Reply fails to address [7.4], Ground I should be denied. POR at 32-
`
`
`
`34. Petitioner failed to meet its burden of proof. 37 C.F.R. § 42.1(d); Practice
`
`Guide at 42.
`
`F.
`
`[7.5] Is Not Rendered Obvious By The Alleged
`Combination
`
`As the Reply also fails to address [7.5], Ground I should be denied. POR at
`
`
`
`34. Petitioner failed to meet its burden of proof. 37 C.F.R. § 42.1(d); Practice
`
`Guide at 42.
`
`G.
`
`[7.8] Is Not Rendered Obvious By The Alleged
`Combination
`
`First, the POR (POR at 35-46) clearly demonstrates that contact information
`
`
`
`
`is provided to the user’s IP terminal and is used by the user. The IP terminal
`
`“receives an instruction for requesting information regarding chat buddies from the
`
`user ‘taro,’” creates “a buddy list requesting command” and sends it “to the IM
`
`server.” Exhibit 1010 at [0141]. The IM server receives the request, creates “a
`
`buddy list in which information regarding each of the chat buddies is registered
`
`including various information (except for the authentication key at least) registered
`21
`
`
`
`
`
`in each of the identified records 440,’’ and sends it to the IP terminal. Exhibit 1010
`
`at [0143]. Note that the information in records 440 of Fig. 3 includes “client
`
`addresses” 432. Exhibit 1010 at Fig 3 and [0146].
`
`The above passages from Tanigawa establish that (1) a user requests
`
`information about his/her buddies, and (2) the server returns a “buddy list” that
`
`includes information about the user’s buddies, including their client addresses (i.e.,
`
`contact information). Exhibit 1010 at [0144] (information written in the buddy list
`
`is displayed), [0146] (the voice chatting request includes “client addresses”). The
`
`Reply, and Dr. Almeroth, fail to address paragraphs [0141], [0143], [0144], [0146],
`
`and Fig. 3. Reply at 27.
`
`More specifically with respect to Fig. 3, Petitioner highlights the client
`
`addresses (green) and presence information (yellow), but ignores the caption that
`
`says “Presence Information Management Table 488”:
`
`
`
`22
`
`
`
`
`
`The presence information is not separate from the client addresses and remaining
`
`information in the table; it is managed along with the client addresses. For
`
`instance, the presence information “text” in the fifth row is associated with account
`
`name “Client D” and the listed client address to identify where the user hanako is
`
`available for text messages; whereas the presence information “voice” in the sixth
`
`row is associated with account name “Client E” and corresponding client address
`
`to identify where the user hanako is available for voice communication. And as
`
`explained below, Tanigawa teaches that the client addresses (i.e., contact
`
`information) are used by users to initiate communication with their buddies.
`
`
`
`23
`
`
`
`
`
`Second, “Tanigawa teaches that a second user’s address information,
`
`contained in field 432, is sent to a first user communication device.” POR at 38-39.
`
`The IP terminal receives the buddy list and “causes the output data creating portion
`
`786 to display data for information written in the buddy list in the display device,
`
`whereby, the information on the chat buddies is notified to the user ‘taro.’ Thus,
`
`the user ‘taro’ can check ... whether or not the buddy ... can voice-chat.” Exhibit
`
`1010 at [0144]. Also, “in accordance with the instruction ... from the user ‘taro,’”
`
`the IP terminal creates “a voice chatting request command including various
`
`informations [sic] (such as the account names, the client addresses and the client
`
`nicknames) of the IM client of the user ‘taro’ and the IM clients to be invited the
`
`chat.” Exhibit 1010 at [0146] (emphasis added).
`
`
`
`The above passages from Tanigawa further establish that (3) the user’s
`
`terminal is in possession of this information and notifies the user, (4) the user
`
`accesses (checks) that information, and (5) instructs the terminal to create a voice
`
`chatting request with this information (including the client addresses).
`
`
`
`Dr. Almeroth’s prior statement that the text chatting area of Fig. 12 does not
`
`provide contact information is irrelevant for two reasons. First, it ignores the
`
`express teachings of Tanigawa summarized above. Second, the “text chatting”
`
`area of Fig. 12 as the name implies is for
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
