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-00294
`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-00294
`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
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`INTRODUCTION ………………………………………………
`
`A. No Rebuttal Testimony …………………………………
`
`B.
`
`Petitioner’s Attacks Of Dr. Rouskas Are Baseless ……...
`
`
`
`
`I.
`
`
`
`
`
`II. GROUND I – DIACAKIS DOES NOT OBVIATE
`CLAIMS 7, 10-12, 22-24, 33-36, 38-41, 46, 49,
`51-53, 55, 57-58, OR 64-66 …………………………………..…
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`A.
`
`B.
`
`C.
`
`D.
`
`E.
`
`[7.0] Diacakis Does Not Teach A Network Based
`Portal (“NBP”) ………………………………………..
`
`[7.1] Diacakis Does Not Teach A “Prior Registration
`Process” ………………………………………………
`
`[7.3] The Diacakis Indicator Is Not Used to Send or
`Receive Messages Between Users
`.…………………..
`
`[7.5] Diacakis’s P&A System Does Not Teach Or
`Support Sending Messages Between Two Users ………
`
`[7.8] Diacakis Teaches That Contact Information
`Is Provided ………………………………………………
`
`
`III. GROUND II – CLAIMS 8, 9, 43, 44, 47, 48, 50, AND 54
`ARE NOT RENDERED OBVIOUS BY DIACAKIS
`AND LOVELAND
`………………………………………..
`
`
`IV. GROUND III – CLAIMS 37, 42, 56, 59–63, AND 67 ARE
`NOT RENDERED OBVIOUS BY DIACAKIS AND
`TAKAHASHI ………………………………………………
`
`
`V. GROUND IV – CLAIM 45 IS NOT RENDERED
`OBVIOUS BY DIACAKIS, LOVELAND, AND
`TAKAHASHI ………………………………………………
`
`
`
`i
`
`Page
`
`1
`
`1
`
`1
`
`3
`
`3
`
`15
`
`16
`
`17
`
`22
`
`26
`
`27
`
`28
`
`
`
`
`VI. CONCLUSION ………………………………………………
`CONCLUSION
`VI.
`
`
`
`
`
`29
`
`
`
`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 – DIACAKIS DOES NOT OBVIATE CLAIMS 7, 10-12,
`22-24, 33-36, 38-41, 46, 49, 51-53, 55, 57-58, OR 64-66
`
`A.
`
`[7.0] Diacakis 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 5. 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 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. 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
`
`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:
`
`
`
`4
`
`
`
`
`
`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).
`
`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 6-7. 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
`
`
`
`5
`
`
`
`unrebutted. POR at 11-12; 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 8-9.
`
`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 or receive 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.
`
`
`
`6
`
`
`
`Interface 112 cannot be used to send or receive 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,
`
`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 user-
`
`to-user 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, Diacakis uses double-headed arrows in
`
`Fig. 11 to denote bidirectional communication:
`
`
`
`7
`
`
`
`Exhibit 1007, Fig. 11. However, 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:
`
`
`
`
`
`Exhibit 1007, Fig. 9. 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
`
`
`
`8
`
`
`
`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 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 8. 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
`
`
`
`9
`
`
`
`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 8. 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.
`
`Third, Petitioner mischaracterizes PO’s argument and is incorrect in stating
`
`that “all users (including senders and recipients) use Diacakis’s NBP to connect to
`
`Diacakis’s network):
`
`
`
`10
`
`
`
`
`
`
`
`
`
`Reply at 8-10 (emphasis in original). Figures 1 and 9 do not indicate to a POSITA
`
`that “both senders and recipients use this interface.” First, interface 112,
`
`Petitioner’s claimed NBP, can only receive information from the P&A server (see
`
`above). Specifically, the interface 112 in Diacakis’s system is for a user to receive
`
`contact information of individuals they wish to contact: “Fig. 9 is a block diagram
`
`of the client terminal 22 … for realizing the single indicator described previously.
`
`… The indicator module 110 may receive availability information from one or
`
`more P&A management servers 12 and merge the contact information for each
`
`individual into a single indicator … for display by the user interface 112.” Exhibit
`
`1007 at Fig. 9, [0063]-[0064]. Exhibit 1043 at 419:6-13.
`
`
`
`Diacakis’s system will also have another interface (not shown in any figure
`
`of Diacakis) that allows the user to connect to the P&A server to provide their
`
`
`
`11
`
`
`
`contact information to the server and configure their profile and access groups.
`
`Exhibit 1007 at [0031], [0036]. 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). Accordingly, Diacakis discusses
`
`the two interfaces separately. The configuration interface is discussed in paragraph
`
`[0036] within the section spanning paragraphs [0031]-[0037] that is concerned
`
`with user profiles and their configuration. Interface 112 is concerned with
`
`displaying the contact info related to the single indicator, and is discussed in
`
`paragraphs [0063]-[0064] within the section spanning paragraphs [0059]-[0068]
`
`that describe the Diacakis indicator. The fact that Diacakis discusses the two
`
`interfaces separately and expressly states that the embodiment of Fig. 9 only
`
`receives information from the P&A server specifically “for display by the user
`
`interface 112” indicates to a POSITA that interface 112 is not used for connecting
`
`users to the network. Exhibit 1007 at Fig. 9, [0031], [0036], and [0063]-[0064];
`
`Exhibit 1043 at 419:6-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 10. Petitioner
`
`
`
`12
`
`
`
`completely fails to address the POR’s evidence explaining why Figs. 7-12 are not
`
`directed to the use of a NBP. POR at 19-21. 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:
`
`
`
`13
`
`
`
`
`
`Reply at 11. Indeed, Figure 7 does not teach a POSITA the use of a NBP. POR at
`
`19-21. 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 19-20. Similar language is used in describing Figures 8-12. POR at 20.
`
`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
`
`
`
`14
`
`
`
`NBP at a server distinct from the second user’s communication device does not
`
`exclude a preferred embodiment, if anything, it enables them. POR 20.
`
`
`
`B.
`
`[7.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 21-22. Petitioner’s Reply is incorrect and
`
`is not supported by any rebuttal evidence from the perspective of a POSITA. Reply
`
`at 12.
`
`
`
`Petitioner argues that Diacakis teaches a “prior registration process by the
`
`first user regarding the use of the network-based portal” because a subscriber
`
`subscribes to the second user. Reply at 12. 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 (Petitioner’s 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
`
`it.” POR at 22. 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.
`
`
`
`15
`
`
`
`C.
`
`[7.3] The Diacakis Indicator Is Not Used To Send Or Receive
`Messages Between Users
`
`The POR proves that the Diacakis indicator is not used to send or receive
`
`
`
`user-to-user messages. POR at 22-25. Petitioner’s Reply argument is incorrect and
`
`is not supported by any rebuttal evidence from the perspective of a POSITA. Reply
`
`at 14. 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 23.
`
`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 23-24.
`
`
`
`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 23-25. Petitioner’s failure to address these
`
`points is an admission that Ground I of the Petition should be denied.
`
`
`
`
`
`
`
`16
`
`
`
`
`
`
`
`D.
`
`[7.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 22-25. Petitioner’s Reply argument is
`
`incorrect and is not supported by any rebuttal evidence from the perspective of a
`
`POSITA. Reply at 12-15.
`
`
`
`Petitioner accurately characterizes the Diacakis system as a “digital
`
`phonebook.” Reply at 14. 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; 201:22-202:17. The two primary functions are: (i) “to collect
`
`information from multiple sources to determine the presence and ... the availability
`
`of a given person” and (ii) to “distribute the availability information of a given
`
`person to interested individuals on a selective basis.” Id. The two secondary
`
`functions are (i) “to configure access control settings” and (ii) “to store user
`
`information to enable the use of the presence and availability management service
`
`regardless of the user's network device.” Id.
`
`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
`17
`
`
`
`
`
`phonebook.” Reply at 16; Exhibit 1007 at [0006]-[0007], [0056], and [0064]; and
`
`Exhibit 1043 at 134:9-135:4, 201:22-202:17.
`
`The fact that Diacakis may disclose that a user may communicate with
`
`another user is irrelevant. Contrary to Petitioner’s attorney argument, “a system
`
`that actually allows a user to make a communication” is not shown in Fig. 11:
`
`
`
`Reply at 12. Rather, Fig. 11 simply shows “relay hosts” that relay (i.e., forward)
`
`messages. Exhibit 1007 at [0072]-[0073]. As Dr. Rouskas explained, message
`
`forwarding takes place every time a user, e.g., makes a call, and the Diacakis
`
`system is not involved in the initiation of the call. Exhibit 1043, 421:18-422:2 and
`
`422:19-423:6. There is nothing in Diacakis, within Figure 11 or elsewhere, that
`
`teaches, or even implies, that the Diacakis P&A system may be used to initiate or
`
`carry out user-to-user communication. Id.
`
`
`
`18
`
`
`
`
`
`That the Diacakis’s P&A system does not teach or support sending messages
`
`between two users is also evidenced by the fact that all embodiments of a P&A
`
`server/system in Diacakis are limited to the exchange of P&A information. As
`
`explained below, no embodiment provides even a hint or indication that the
`
`Diacakis system may be used for user-to-user communication. Id.
`
`Figure 1 of Diacakis and the accompanying discussion clearly show that the
`
`P&A server 12 consists of a presence detection engine, an availability management
`
`engine, and a profile database, and its function is to receive profile information
`
`from clients and forward P&A information to subscribers in a publisher-subscriber
`
`model. Exhibit 1007 at Fig. 1 and [0024]-[0031]. There are no components for
`
`enabling or carrying out direct user-to-user communication and no such
`
`communication is indicated in Fig. 1 as the P&A server is shown connected to a
`
`single client terminal. Id. Figure 3 of Diacakis and the corresponding text only
`
`show and discuss the configuration of profiles stored at the P&A server and the
`
`transmission of the P&A information (including contact information, as shown in
`
`Fig. 8, [0056] and [0064]) to subscribers at various access groups. Again, no user-
`
`to-user communication is indicated or implied. Exhibit 1007 at Fig. 3 and [0033]-
`
`[0037].
`
`Figure 4 of Diacakis and the accompanying text again show that the P&A
`
`server 1) only collects P&A information from the clients and 2) only transmits
`
`
`
`19
`
`
`
`availability information (including contact information, as explained above) to the
`
`subscribers. There are no diagrams or discussion of any components used for user-
`
`to-user communication. Exhibit 1007 at Fig. 4 and [0038]-[0048].
`
`Figure 5 is a “diagram of the process flow of the P&A management server
`
`12 according to one embodiment” of Diacakis; in other words, the figure describes
`
`the main functionality and operation of the P&A server in Diacakis. Exhibit 1007
`
`at Fig. 5 and [0049]. The process shown in the figure and described in the
`
`corresponding text involves the processing of user profiles along with presence and
`
`availability information, and the distribution of availability information (including
`
`contact information, as explained above) to subscribers. The process provides no
`
`evidence whatsoever that the P&A server may initiate or carry out user-to-user
`
`communication as part of its functionality. Exhibit 1007 at Fig. 5 and [0049]-
`
`[0050].
`
`Figure 6 of Diacakis shows another embodiment of the P&A server that
`
`differs from the embodiments in Figs. 1 and 4 only in that it includes an adaptive
`
`feedback module 100. Exhibit 1007 at Figs. 1, 4, 6, and [0051]. “The adaptive
`
`feedback module 100 may determine whether the individual’s availability
`
`information is, for example, inaccurate or unusable” and hence this embodiment
`
`does not add any capabilities or functions for user-to-user communication. Exhibit
`
`1007 at [0052].
`
`
`
`20
`
`
`
`Figure 7 and the corresponding text describe the process flow of the P&A
`
`server according to the embodiment of Fig. 6. Exhibit 1007 at Figs. 6-7 and
`
`[0054]-[0055]. As with Fig. 5 above, the process of Fig. 7 is limited to the
`
`processing and distribution of presence and availability information based on user
`
`profiles and provides no teaching or even a hint that the P&A server is used for
`
`user-to-user communication. Id.
`
`As discussed above, Fig. 9 and the accompanying text expressly demonstrate
`
`that the indicator module 110 and user interface 112 only receive availability
`
`information from the P&A server, Exhibit 1007 at Fig. 9, [0063], [0068]. There is
`
`no teaching or indication that modules 110 or 112 are used to receive or send any
`
`user-to-user messages. Id.
`
`Figure 10 “is a diagram of the process flow through the indicator module
`
`110;” that is, the figure describes the functionality and operation of the indicator
`
`module 110. Exhibit 1007 at Fig. 10 and [0065]. Figure 10 and the corresponding
`
`text make clear that the indicator module 110 only receives, processes, and
`
`displays availability information including contact information, as explained
`
`earlier) of each individual to which the user subscribes. Exhibit 1007 at Fig. 10
`
`and [0065]-[0067]. Therefore, as explained above, the Diacakis indicator is not
`
`used to send or receive user-to-user messages.
`
`
`
`21
`
`
`
`Figure 11 is not an embodiment of a P&A server. The figure depicts client
`
`devices 22 and 140, relay hosts 142a and 142b, domain name servers 144 and 146,
`
`resolver 148, and IP address database 150, but no P&A server. Exhibit 1007 at Fig.
`
`11 and [0072]-[0076]. Therefore, Fig. 11 does not provide any teaching that the
`
`Diacakis P&A server and system is used for user-to-user communication. Id.
`
`Petitioner therefore failed to meet its burden of proof. 37 C.F.R. § 42.1(d); Practice
`
`Guide at 42.
`
`
`
`E.
`
`[7.8] Diacakis Teaches That Contact Information Is Provided
`
`The POR proves that Diacakis teaches a POSITA that contact information is
`
`provided. POR at 27-35. 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-28. 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 16. The POR and Rouskas Declaration did not exist at
`
`the time of the Institution Decision, so it was impossible for the arguments and
`
`
`
`22
`
`
`
`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 16. 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
`
`29-32.
`
`
`
`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 16. 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
`
`
`
`23
`
`
`
`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 17. 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” pers
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
