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-00202
`Patent No. 10,142,810
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`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-00202
`Patent No. 10,142,810
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`PATENT OWNER’S SUR-REPLY
`_____________________________________________________
`
`
`
`Mail Stop PATENT BOARD, PTAB
`Commissioner for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`
`
`TABLE OF CONTENTS
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`INTRODUCTION ………………………………………………
`
`A. No Rebuttal Testimony …………………………………
`
`B.
`
`Petitioner’s Attacks Of Dr. Rouskas Are Baseless ……...
`
`
`
`
`I.
`
`
`
`
`
`II. GROUND I ………………………………………………………
`
`
`
`
`A.
`
`B.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`C.
`
`D.
`
`E.
`
`F.
`
`
`G.
`
`H.
`
`[1.0] Diacakis Does Not Teach A NBP
`
`……………..
`
`[1.1] Diacakis Does Not Teach “A Prior
`Registration Process” ……..……………………..……
`
`[1.3] The Diacakis Indicator Is Not For Messages ………
`
`Petitioner’s Reply Fails To Address [1.4] …….………
`
`Petitioner’s Reply Fails To Address [1.6] …….………
`
`[1.8] Diacakis’s P&A System Does Not Teach Or
`Support Sending Messages Between Users ….…………
`
`[1.9] Diacakis Teaches That Contact Information
`Is Provided ……………………………………………….
`
`Petitioner's Reply Fails To Address [3.0], [7.0], and
`[10.0]
`………………………………………..……..
`
`………………………………………………
`
`Page
`
`1
`
`1
`
`1
`
`3
`
`3
`
`9
`
`10
`
`11
`
`11
`
`11
`
`12
`
`16
`
`17
`
`17
`
`
`III. GROUND II
`
`
`A. No Motivation To Combine ……………….…….……
`
`B.
`
`[1.0] The Combination Does Not Teach A NBP ………….. 20
`
`[1.3] The Users Are Not Represented By A Single
`
`C.
`
`i
`
`
`
`
`
`
`
`
`
`20
`
`22
`
`25
`
`
`
`
`
`
`D.
`
`Identifier For All Communications ……………..…….
`
`[1.9] The Combination Teaches That Contact
`Information Is Provided ………………………………....
`
`
`IV. CONCLUSION ………………………………………………
`
`
`
`
`
`
`
`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.
`
`
`Exhibit 2001
`
`Exhibit 2002
`
`Exhibit 2003
`
`Exhibit 2004
`
`Exhibit 2005
`
`Exhibit 2006
`
`
`Exhibit 2007
`
`
`Exhibit 2008
`
`
`
`
`
`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
`
`1042. 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
`
`1042 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 1042 at 4.
`
`
`
`
`
`
`
`2
`
`
`
`II. GROUND I
`
`A.
`
`[1.0] Diacakis Does Not Teach A NBP
`
`
`
`The Reply “first” argues that there is nothing to limit the claimed portal to a
`
`server or a website. Reply at 7. The POR shows that in the ʼ810 patent a “portal”
`
`and a “gateway” are used synonymously; and a “gateway” is a “networked server”.
`
`POR at 11. Petitioner’s Reply is incorrect and is not supported by any rebuttal
`
`expert testimony.
`
`Petitioner’s unsupported arguments are contradicted by Petitioner’s Reply
`
`Exhibit 1041, which states “[a] mobile portal is an Internet gateway that enables
`
`mobile devices to connect remotely ... typically via a Web browser interface.”
`
`Thus, Exhibit 1041 defines a “portal” as an Internet “gateway” and differentiates it
`
`from a web browser interface, which is only used to connect a device to the portal.
`
`The definition of a portal in Exhibit 1041 is consistent with Dr. Rouskas’s
`
`testimony. Exhibit 1042 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 1040 also contradicts
`
`Petitioner’s attorney-only arguments as it defines a “portal” as a “platform,” not a
`
`user interface. Exhibit 1040.
`
`
`
`3
`
`
`
`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.
`
`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 1041. Since the devices use a “Web browser interface” they
`
`must necessarily connect to a website hosted at the portal. Id.
`
`Second, the Reply argues that PO incorrectly argues the ʼ810 Patent defines
`
`“portal” as a “gateway” and that a gateway is always a “networked server.” Reply
`
`at 7-8. As shown above, however, Petitioner’s Exhibit 1041 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 11; Exhibit 1042 at 90:4-9, 91:10-15.
`
`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 8-9.
`
`
`
`4
`
`
`
`Petitioner claims that “Diacakis’s client terminal connects a user to a
`
`network via the NBP.” This statement is wrong because (1) Diacakis only
`
`describes messages related to the management of P&A information, not direct
`
`communication between users, and (2) interface 112 (i.e., the Petitioner’s claimed
`
`NBP) cannot be used to send user messages. Exhibit 1042 at 134:3-135:4 and
`
`417:17-21. Petitioner conflates messages related to management of P&A
`
`information with direct messages between users. As Dr. Rouskas explained, and as
`
`Diacakis teaches, the Diacakis P&A system operates in a publisher-subscriber
`
`model. Exhibit 1042 at 141:5-142:12. When the profile of an individual changes,
`
`these changes are sent to the P&A server; the server then forwards the updated
`
`contact information to the subscribers. Id. However, the Diacakis system cannot
`
`be used by one user to call or send communication messages directly to another
`
`user. Id.
`
`Interface 112 cannot be used to send any user messages and may only
`
`receive contact information from the P&A server. Hence it does not provide
`
`“worldwide access to the user.” As Dr. Rouskas explained, whether a user’s
`
`mobile phone allows worldwide access to that user is irrelevant, as the Petition
`
`does not point to the “mobile phone” as the claimed NBP, but rather argues that
`
`interface 112 of Diacakis is the claimed NBP. Exhibit 1042 at 415:23-416:6 and
`
`417:17-21. To communicate with other users (i.e., make or receive calls, emails,
`
`
`
`5
`
`
`
`or IMs), a user must interact with specific application interfaces (i.e., the Phone,
`
`Email, or IM interface, respectively) that allow for the sending or receipt of
`
`messages. Just because a phone allows worldwide access to a user does not imply
`
`that the interface 112 of Diacakis also provides worldwide access to the user
`
`because the interface 112 cannot be used for user-to-user communication.
`
`Further, as Dr. Rouskas explained, whereas Diacakis uses double-headed
`
`arrows in Fig. 11 to denote bidirectional communication, Diacakis expressly uses a
`
`single-headed arrow in Fig. 9 to denote communication only in the direction from
`
`the P&A server to the client device 22; since Diacakis understood that double-
`
`headed arrows correspond to “bidirectional movement of communication” (Exhibit
`
`1042 at 212:8-10), if Diacakis wanted to also indicate communication to the P&A
`
`server Diacakis would have used a double-headed, not single-headed arrow. This
`
`is consistent with the teachings of Diacakis (Ex. 1007 at [0064]) that “the indicator
`
`module 110 may receive availability information from one or more P&A
`
`management servers 12 … for display by the user interface 112”. Nothing in
`
`Diacakis indicates that a user may use interface 112 to either receive or send
`
`communication messages to other users. Figure 9 expressly shows that interface
`
`112 is only connected to the Indicator module 110, and only for displaying
`
`information that module 110 receives from the P&A server. Interface 112 is not
`
`connected to any module that can be used for user-to-user communication. Due to
`
`
`
`6
`
`
`
`the single-headed arrow, Fig. 9 does not allow for any communication from
`
`interface 112, either to the P&A server or to other users, and hence it cannot be
`
`used for sending messages from a first user to a second user, as the claim requires.
`
`Finally, since modules 110 and 112 of Fig. 9 only receive information from the
`
`P&A server, module 112 cannot receive user-to-user messages and hence it cannot
`
`allow “worldwide access” to the user. Exhibit 1042 at 415:4-419:24.
`
`
`
`Fourth, the Reply argues that PO made a strawman argument “that only the
`
`sender’s device contains the NBP”. Reply at 9. Petitioner’s argument contains
`
`several incorrect statements. First, it states “[a]s the Petition explained, Diacakis’s
`
`users provide their contact information to a P&A server” which “is different from
`
`the NBP.” As Dr. Rouskas testified, the Diacakis P&A system operates in a
`
`publisher-subscriber model. Exhibit 1042 at 140:10-141:3. When the profile of an
`
`individual changes, these changes are sent to the P&A server; the server then
`
`forwards the updated contact information to the users, i.e., to interface 112, for
`
`display. Hence, the contact information is indeed sent to the claimed NBP,
`
`interface 112, for display. Exhibit 1042 at 202:1-4.
`
`
`
`Second, the Reply incorrectly states “… the NBP, which is the interface that
`
`allows users to connect to the P&A server.” Reply at 9. This is not true; as
`
`explained above, interface 112 may only receive messages from the P&A server.
`
`Hence, it even cannot be used to connect users to the P&A server.
`
`
`
`7
`
`
`
`
`
`Third, Petitioner mischaracterizes PO’s argument. Interface 112,
`
`Petitioner’s claimed NBP, can only receive information from the P&A server (see
`
`above). Every device in Diacakis’s system including interface 112 is only for a
`
`user to receive contact information of individuals they wish to contact. Exhibit
`
`1042 at 419:6-13. A device in Diacakis’s system will also have an interface (not
`
`shown in Diacakis) that allows the user to connect to the P&A server to provide
`
`their contact information to the server and configure their profile and access
`
`groups. But that interface is separate from interface 112. The Diacakis system
`
`must implement different interfaces, one for configuring the contact information,
`
`profiles, and access groups, and one for receiving contact information: the former
`
`is a configuration function while the latter is a digital phonebook (i.e., a Contacts
`
`app). Exhibit 1007 at Fig. 9, [0031], [0036], and [0063]-[0064],.
`
`
`
`Finally, Petitioner is wrong in claiming that “PO misreads element 1.8.”
`
`Reply at 9. Indeed, the Reply ignores all the examples PO provided in the POR of
`
`Diacakis teachings that the contact information is displayed to the user, including
`
`Figs. 2, 3, and 8. POR at 6-7 and 27-30.
`
`
`
`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 14. Petitioner
`
`completely fails to address the POR’s evidence explaining why Figs. 7-12 are not
`
`
`
`8
`
`
`
`directed to the use of a NBP. 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. POR at 16-17.
`
`
`
`B.
`
`[1.1] Diacakis Does Not Teach A “Prior Registration Process”
`
`The POR proves that Diacakis does not teach a POSITA the claimed
`
`registration process because a user in Diacakis does not go through a registration
`
`process with their contacts app. POR at 19-20. Petitioner’s Reply is incorrect and
`
`is not supported by any evidence from the perspective of a POSITA. Reply at 14.
`
`
`
`Petitioner argues that Diacakis teaches a “prior registration process”
`
`“regarding the use of the network-based portal” because a subscriber subscribes to
`
`the second user. Reply at 14 citing Petition at 37-38. However, Diacakis teaches
`
`that clients are “subscribers of the individual’s information.” Exhibit 1007 at
`
`[0029]. Even assuming that a subscription process is equivalent to a registration
`
`process, the subscription is not “regarding the use of” the interface 112 (the alleged
`
`NBP) on the subscriber’s (the first user’s) device, but regarding a different
`
`individual’s (the second user’s) contact information. As the POR states, interface
`
`112 is an application on the subscriber’s device and “they simply open it and use
`
`
`
`9
`
`
`
`it.” POR at 19. Even before a user subscribes to the information of any individual,
`
`i.e., before going through any subscription process, they would open and use
`
`interface 112 on their device.
`
`C.
`
`[1.3] The Diacakis Indicator Is Not For Messages
`
`The POR proves that the Diacakis indicator is not for, and is not used to,
`
`receive messages. POR at 20-21. Petitioner’s Reply argument is incorrect and is
`
`not supported by any evidence from the perspective of a POSITA. Reply at 16.
`
`Diacakis expressly teaches that “the single summary indicator may be a summary
`
`of the individual’s availability” and hence, as the POR states, the “indicator is not
`
`for, and cannot be used to, receive messages.” Exhibit 1007 at [0059]; POR at 20.
`
`According to Diacakis “the single summary indicator contain[s] several
`
`different icons or states, .... the icons may indicate types of data the individual is
`
`available to receive such as, for example, text files audio files, ….” As the POR
`
`explains, when a user selects indicator “Jonathan” in Fig. 8 of Diacakis, the
`
`availability information of contact “Jonathan” is shown in the left-hand side of Fig.
`
`8 and no communication transpires. Exhibit 1007 at [0059]; POR at 21.
`
`
`
`Petitioner’s Reply does not contest PO’s arguments that (1) a POSITA
`
`would understand that “Jonathan” may not be used to “receive [any] messages”, let
`
`alone “all of the communications”, or (2) if a user selects “Jonathan” no
`
`
`
`10
`
`
`
`communication transpires. POR at 20-21. Petitioner’s failure to address these
`
`points is an admission that Ground I of the Petition should be denied.
`
`
`
`
`
`D.
`
`Petitioner’s Reply Fails To Address [1.4]
`
`The POR proves that Diacakis does not teach or suggest [1.4] to a POSITA
`
`because (1) there is no teaching about its server 12 gaining knowledge of a selected
`
`mode of communication, and (2) there is no component in the P&A server 12
`
`related to establishing user-to-user communication. As Petitioner’s Reply fails to
`
`address these aspects of [1.4], Ground I of the Petition should be denied.
`
`
`
`
`
`E.
`
`Petitioner’s Reply Fails To Address [1.6]
`
`The POR proves that Diacakis does not teach or suggest [1.6] to a POSITA
`
`because (1) the phone call or IM does not transpire in, or use, the Diacakis P&A
`
`system, and (2) as previously determined by the Board, Diacakis does not provide
`
`user messages. POR at 24-25. As Petitioner’s Reply fails to address these aspects
`
`of [1.6], Ground I of the Petition should be denied.
`
`
`
`
`
`F.
`
`[1.8] Diacakis’s P&A System Does Not Teach Or Support Sending
`Messages Between Two Users
`
`The POR proves that Diacakis’s P&A system does not teach or support
`
`sending messages between users. POR at 25-26. Petitioner’s Reply argument is
`
`incorrect and is not supported by any evidence from the perspective of a POSITA.
`
`Reply at 14-17.
`
`
`
`11
`
`
`
`
`
`Petitioner accurately characterizes the Diacakis system as a “digital
`
`phonebook.” Reply at 16. As Dr. Rouskas explained, Diacakis expressly limits the
`
`scope of the invention (i.e., the P&A management system) to two primary and two
`
`secondary functions that are unrelated to user-to-user communication. Exhibit
`
`1042 at 134:9-135:4.
`
`Dr. Rouskas further explained that Fig. 8 of Diacakis shows the information
`
`displayed by interface 112 (the alleged NBP). Exhibit 1042 at 201:22-202:17. This
`
`information includes a list of names and their contact, presence, and availability
`
`information, which is what the Diacakis system manages. Therefore, it is a “digital
`
`phonebook.” Reply at 16; Exhibit 1007 at [0006]-[0007], [0056], and [0064]; and
`
`Exhibit 1042 at 134:9-135:4, 201:22-202:17.
`
`
`
`G.
`
`[1.9] Diacakis Teaches That Contact Information Is Provided
`
`The POR proves that Diacakis teaches a POSITA that contact information is
`
`provided. POR at 27-32. First, for the reasons set forth in the POR, the negative
`
`limitation of contact information not provided is inconsistent with an interpretation
`
`that the NBP is within the sender’s device in Diacakis. POR at 27-30. The
`
`unrebutted evidence shows that in Diacakis if the second user receives a message
`
`from the first user, the first user has the second user’s contact information to send
`
`the message. Id.
`
`
`
`12
`
`
`
`
`
`Second, regarding Judge Chang’s opinion that Diacakis does not teach the
`
`negative limitation, the Reply asserts that “[n]either the POR nor the Rouskas
`
`Declaration provides any additional analysis or evidence related to those already-
`
`considered views.” Reply at 18. The POR and Rouskas Declaration did not exist at
`
`the time of the Institution Decision, so it was impossible for the arguments and
`
`evidence set forth in the POR to have been “already-considered”. In fact, the
`
`Board recognized in its Institution Decision that it was not able to fully consider
`
`the PO’s position until the record is complete. Institution Decision at 19. Now that
`
`the POR has shown that Diacakis does not teach the negative limitation, the Board
`
`should agree with Judge Chang’s opinion and deny Ground I. Indeed, the POR’s
`
`evidence is unrebutted.
`
`
`
`Third, without any citation, or evidence from a POSITA, the Reply posits
`
`“the Diacakis system does not provide contact information simply because one
`
`user contacts another; rather, it determines whether or not to provide information
`
`subject to the recipient’s preferences.” Reply at 18. In contrast, the POR sets forth
`
`many unrebutted examples of Diacakis teaching that the contact information not
`
`only is provided, but is displayed to the user, including Figs. 2, 3, and 8. POR at
`
`28-30.
`
`
`
`That the server “takes into account [the recipient’s] preference setting for the
`
`subscriber’s access group” does not imply that the server “determines whether or
`
`
`
`13
`
`
`
`not to provide information subject to the recipient’s preferences,” as Petitioner
`
`argues. Reply at 18. Rather, consistent with Diacakis’s teachings on “access
`
`groups”, the quoted sentence simply recognizes that if, say, the “Normal” access
`
`group does not have access to, e.g., the IM address, then the server will not provide
`
`it; but will provide the telephone, voicemail, and email addresses to which the
`
`“Normal” group has access. Exhibit 1007 at [0032]-[0037] and Figs. 2, 3.
`
`
`
`Diacakis does not include any embodiment in which an access group is not
`
`provided any contact information but still can communicate with a recipient. All
`
`embodiments differentiate among access groups only in that each has access to
`
`different pieces of a recipient’s contact information. Exhibit 1007 at [0032]. In
`
`fact, Diacakis expressly defines a “Blocked access level” as “persons” who
`
`“receive not [sic] contact information at all.” Id. But persons in the “Blocked”
`
`level cannot contact the recipient. Therefore, Petitioner’s attorney argument that
`
`the Diacakis system allows a user who receives no contact information to
`
`communicate with a recipient is baseless and not supported by any POSITA
`
`evidence.
`
`
`
`Fourth, PO does not conflate two techniques that allow Diacakis’s users to
`
`control their interactions. Reply at 19. PO never claimed that Petitioner relies on
`
`the blocking feature of Diacakis. PO simply pointed out that Diacakis clearly
`
`teaches that only “blocked” persons receive no contact information and that
`
`
`
`14
`
`
`
`“blocked” persons cannot communicate with the recipient who blocked them. POR
`
`at 32.
`
`Moreover, the Reply (and Petition) cites Diacakis’s teaching that users can
`
`“control what contact information observers are allowed to view” and argues that
`
`this implies that Diacakis teaches the negative limitation. Reply at 19 (emphasis
`
`added). It does not. This citation from Diacakis is consistent with its other
`
`teachings (Figures 2, 3, 8, and [0032]-[0037]) which, as discussed above,
`
`differentiate among access groups in that each has access to different pieces
`
`(“what”) of contact information. For instance, as Fig. 3 shows, the recipient can
`
`control “what” contact information each access group receives, with the
`
`“Important” group receiving more contact information than the “Normal” group,
`
`which in turn receives more contact information than the “Restricted” group. But
`
`Diacakis does not teach any embodiment where a group receives no contact
`
`information and still can communicate with the recipient.
`
`Fifth, PO does not confuse Diacakis’s presence and availability information
`
`with contact information. Reply at 19. As shown above, Petitioner cites two
`
`sentences that expressly state that Diacakis provides contact information: “server
`
`12 provides the appropriate IM address to the subscriber” and “control what
`
`contact information observers are allowed to view.” Reply at 18-19. Indeed,
`
`
`
`15
`
`
`
`Diacakis defines access groups based on the amount of contact information they
`
`receive. Exhibit 1007 at [0032].
`
`Petitioner’s characterization of a “misbelief” on the part of Dr. Rouskas is
`
`wrong and not supported by any POSITA evidence. Diacakis expressly states that
`
`steps must be taken to “cease from relaying the inconsistent contact information to
`
`subscribers.” Exhibit 1007 at [0048]. For the Diacakis system to “cease” from
`
`relaying inconsistent contact information, it must be that it has been relaying such
`
`inconsistent information in the first place. Exhibit 1042 at 179:20-181:12. Thus, as
`
`Dr. Rouskas testified, a POSITA would understand that the Diacakis system not
`
`only provides contact information to subscribers, but it also may provide such
`
`information incorrectly above and beyond what the user profiles indicate. Id.
`
`Thus, in Diacakis the system can send all the contact information. Id.
`
`
`
`
`
`H. The Reply Ignores [3.0], [7.0], and [10.0]
`
`The Reply’s failure to address [3.0], [7.0], and [10.0], or present any rebuttal
`
`evidence from the perspective of a POSITA, means that Ground I of the Petition
`
`should be denied. POR at 33-34.
`
`
`
`
`
`
`
`16
`
`
`
`III. GROUND II
`
`
`
`A. No Motivation To Combine
`
`The POR shows there is no motivation to combine Tanigawa and Hullfish.
`
`POR at 40-46. 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
`
`20-21. 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 41-45. 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.
`
`Second, PO’s motivation to combine arguments focus on fundamental and
`
`principal differences in design and operation between Tanigawa and Hullfish. POR
`
`at 41-45. 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 21-22. 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 a server, not from another user” (POR at 45) and (2) Tanigawa
`
`
`
`17
`
`
`
`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 39). 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 57-58). Petitioner’s Reply is silent on the
`
`POR arguments above.
`
`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 22-23. 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
`
`would not be motivated to implement. Exhibit 1042 at 315:14-316:9, 341:12-
`
`343:16.
`
`
`
`18
`
`
`
`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 57-58.
`
`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 buddies. Exhibit
`
`1043 at 341:12-343:16. As Dr. Rouskas pointed out, when a participant A blocks a
`
`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 to implement an additional one-to-one blocking
`
`feature. POR at 38-39.
`
`
`
`19
`
`
`
`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 42. 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.
`
`
`
`B.
`
`[1.0] The Combination Does Not Teach A NBP
`
`For the reasons set forth above for Ground I, and in the POR, a user interface
`
`on an IP terminal (client device) is not the claimed NBP. Thus, the alleged
`
`combination of Tanigawa and Hullfish fails to render obvious a NBP.
`
`C.
`
`
`[1.3] The Users Are Not Represented By A Single Identifier For
`All Communication Options
`
`Petitioner mischaracterizes PO’s argument regarding the combination’s
`
`
`
`failure to teach “identifiers”. Reply at 25-26. Element [1.6] requires “enabling, via
`
`the network-based portal, the message to be received by the second user through
`
`the electronic device associated with the second user, using the selected option of
`
`communication, based on the one identifier associated with the second user.”
`
`Therefore, the identifier must be sufficient to route the messages to the second user
`
`in different communication options (i.e., at least text messaging and voice
`
`communication, per element [1.3]). Contrary to Petitioner’s argument (Reply at
`
`25), and as explained in the POR (POR at 55-56), Tanigawa does not teach this
`20
`
`
`
`
`
`claim element. Specifically, Tanigawa teaches that the nickname (i.e., the 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 1008 at [0131]. 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.” Id. 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
`
`t
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
