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-00291
`Patent No. 10,708,727
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`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-00291
`Patent No. 10,708,727
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`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 ………………………………………………………
`
`
`
`
`[1.0] Diacakis Does Not Teach A NBP
`
`……………..
`
`[1.3] “Any Of The Plurality Of Modes Of
`Communication” “All Depending On An Identifier”
`“Previously Set By The Second User” Is Not
`Obviated By Diacakis ………………………………..…
`
`A.
`
`B.
`
`
`
`
`
`
`
`C.
`
`D.
`
`[1.5] Diacakis’s P&A System Does Not Teach Or
`Support Sending Messages Between Two Users ………
`
`[1.8] Diacakis Teaches That Contact Information
`Is Provided ……………………………………………….
`
`
`
`
`III. GROUND II – CLAIMS 7-9 ARE NOT RENDERED
`OBVIOUS BY DIACAKIS AND LOVELAND .………………
`
`E.
`
`The Reply Ignores [3.0], [6.0], [9.0], and [17.0]
`
`.……..
`
`
`IV. GROUND III – CLAIM 16 IS NOT RENDERED
`OBVIOUS BY DIACAKIS AND TAKAHASHI …………….
`
`
`V. GROUND IV – HULLFISH COMBINED WITH
`TANIGAWA DOES NOT OBVIATE CLAIMS 1-3,
`6, 15, and 17 TO A POSITA …………………………………
`
`
`
`
`
`
`
`A. No Motivation To Combine ……………….…….……
`
`
`i
`
`Page
`
`1
`
`1
`
`1
`
`3
`
`3
`
`9
`
`10
`
`11
`
`15
`
`15
`
`15
`
`16
`
`16
`
`
`
`B.
`
`C.
`
`[1.0] The Combination Does Not Teach A NBP
`
`[1.3] “Any Of The Plurality Of Modes Of
`Communication” “All Depending On An Identifier”
`Is Not Obviated By Tanigawa And Hullfish ..……..…….
`
`.……..
`
`D.
`
`[1.4] “Block” Is Not Obviated By The Combination
`
`.
`
`
`
`
`
`
`
`
`
`
`VI. GROUND V – CLAIMS 7-9 ARE NOT RENDERED
`OBVIOUS BY TANIGAWA, HULLFISH,
`AND LOVELAND
`………………………………………..
`
`E.
`
`F.
`
`[1.8] Is Not Obviated By The Combination ……………..
`
`The Reply Ignores [3.0], [6.0], and [17.0] …………….
`
`
`VII. GROUND VI – CLAIM 16 IS NOT RENDERED
`OBVIOUS BY TANIGAWA, HULLFISH,
`AND TAKAHASHI ………………………………………..
`
`VIII. CONCLUSION ………………………………………………
`
`
`
`
`
`
`
`19
`
`19
`
`21
`
`21
`
`24
`
`24
`
`25
`
`25
`
`
`
`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
`
`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
`
`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 ʼ727 patent a “portal”
`
`and a “gateway” are used synonymously; and a “gateway” is a “networked server”.
`
`POR at 11-12. 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 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
`
`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.
`
`
`
`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 1042. 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 ʼ727 Patent defines
`
`“portal” as a “gateway” and that a gateway is always a “networked server.” Reply
`
`at 8. As shown above, however, Petitioner’s 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 11-12; Exhibit 1043 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 1043 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 1043 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 1043 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
`
`1043 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 1043 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 1043 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 Petitioner’s claimed
`
`NBP, interface 112, for display. Exhibit 1043 at 202:1-4.
`
`
`
`Second, the Reply incorrectly states “all users … use Diacakis’s [alleged]
`
`NBP to connect to Diacakis’s network.” 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). The interface 112 in every device in Diacakis’s system is for a user to
`
`receive contact information of individuals they wish to contact. Exhibit 1043 at
`
`419:6-13. But every device in Diacakis’s system will also have another 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, 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-8 and 26-29.
`
`
`
`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
`
`directed to the use of a NBP. Petitioner’s position that every issued claim must
`
`
`
`8
`
`
`
`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 17-19.
`
`B.
`
`[1.3] “Any Of The Plurality Of Modes Of Communication” “All
`Depending On An Identifier” “Previously Set By The Second
`User” Is Not Obviated By Diacakis
`
`The POR proves that Diacakis’s indicator cannot be used to receive
`
`
`
`messages. POR at 20-22. Petitioner’s Reply argument is incorrect and is not
`
`supported by any evidence from the perspective of a POSITA. Reply at 15.
`
`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 20-21.
`
`
`
`9
`
`
`
`
`
`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
`
`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.
`
`
`
`
`
`C.
`
`[1.5] 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 23-24. Petitioner’s Reply argument is
`
`incorrect and is not supported by any evidence from the perspective of a POSITA.
`
`Reply at 14-17.
`
`
`
`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
`
`1043 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 1043 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
`
`
`
`10
`
`
`
`phonebook.” Reply at 16; Exhibit 1007 at [0006]-[0007], [0056], and [0064]; and
`
`Exhibit 1043 at 134:9-135:4, 201:22-202:17.
`
`
`
`D.
`
`[1.8] Diacakis Teaches That Contact Information Is Provided
`
`The POR proves that Diacakis teaches a POSITA that contact information is
`
`provided. POR at 24-31. 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 24-25. 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.
`
`
`
`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 17. 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 11 and 22.
`
`Now that the POR has shown that Diacakis does not teach the negative limitation,
`
`
`
`11
`
`
`
`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
`
`26-29.
`
`
`
`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
`
`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
`
`
`
`12
`
`
`
`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 18. 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
`
`“blocked” persons cannot communicate with the recipient who blocked them. POR
`
`at 31.
`
`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 18 (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
`
`
`
`13
`
`
`
`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 19. Indeed, 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 1043 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
`
`
`
`14
`
`
`
`information incorrectly above and beyond what the user profiles indicate. Id.
`
`Thus, in Diacakis the system can send all the contact information. Id.
`
`
`
`
`
`E.
`
`The Reply Ignores [3.0], [6.0], [9.0], and [17.0]
`
`The Reply’s failure to address [3.0], [6.0], [9.0], and [17.0], or present any
`
`rebuttal evidence from the perspective of a POSITA, means that Ground I of the
`
`Petition should be denied. POR at 31-32.
`
`III. GROUND II – CLAIMS 7-9 ARE NOT RENDERED OBVIOUS BY
`DIACAKIS AND LOVELAND
`
`
`
`As explained in the POR, Diacakis and Loveland would not be combined as
`
`their objectives are diametrically opposite to each other. POR at 31-32. The Reply
`
`does not address – or present any rebuttal evidence – of how the two would be
`
`combined or how the combination would operate. Ground II should therefore be
`
`dismissed.
`
`IV. GROUND III – CLAIM 16 IS NOT RENDERED OBVIOUS BY
`DIACAKIS AND TAKAHASHI
`
`
`
`Claim 16 is not rendered obvious to a POSITA for the reasons set forth in
`
`the POR at 33.
`
`
`
`
`
`
`
`15
`
`
`
`V. GROUND IV – HULLFISH COMBINED WITH TANIGAWA DOES
`NOT OBVIATE CLAIMS 1-3, 6, 15, and 17 TO A POSITA
`
`
`
`
`A. No Motivation To Combine
`
`The POR shows there is no motivation to combine Tanigawa and Hullfish.
`
`POR at 33-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
`
`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 40-43. 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 43-46. 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 22-23. 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 44) and (2) Tanigawa
`16
`
`
`
`
`
`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). Petitioner’s Reply is silent on the
`
`POR arguments above.
`
`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 56-57.
`
`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
`
`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
`
`
`
`17
`
`
`
`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 41-42.
`
`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 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 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
`
`
`
`18
`
`
`
`buddies, i.e., users who have mutually agreed to engage in communication.” POR
`
`at 41-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. POR at 46-54. Thus, the
`
`alleged combination of Tanigawa and Hullfish fails to render obvious a NBP.
`
`
`
`
`
`C.
`
`[1.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 24-26. Element [1.5] requires “enabling the
`
`first message to be provided to the second user, using the selected mode of
`
`communication, depending on the 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.2]). Contrary to Petitioner’s argument (Reply at
`
`25), and as explained in the POR (POR at 54-55), 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,
`
`
`
`19
`
`
`
`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]. 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 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.
`
`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.” Petition at 24-25. 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
`
`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
`
`
`
`20
`
`
`
`specific device. Exhibit 1010 at [0050] and Fig.
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
