`
`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 RESPONSE
`UNDER 37 C.F.R. § 42.120
`_____________________________________________________
`
`
`
`Mail Stop PATENT BOARD, PTAB
`Commissioner for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`
`
`TABLE OF CONTENTS
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`I.
`
`II.
`
`III. 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 ………………………………………
`
`INTRODUCTION ………………………………………………
`
`TERMINOLOGY ………………………………………………
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`A. Diacakis (Exhibit 1007) …………………………………
`
`
`
`B.
`
`1.
`
`Diacakis Does Not Provide Or Support
`Messages ………………………………………..
`
`[7.0] “Network-Based Portal” …………………………..
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`6.
`
`
`
`
`A “Portal” Is Not A User Terminal Or
`A “Client Communication Device” …………….
`
`The ʼ038 Specification Defines “Portal”
`As A “Gateway” And Defines A “Gateway”
`As A “Networked Server”
`……………………
`
`The Functionality Of A “Portal” Is Different
`Than That Of A Client Communication Device …..
`
`The Claims Also Distinguish A “Portal”
`From A Client Communication Device
`
`……….
`
`The User Interface Of Diacakis Is Not A
`“Portal” ………………………………………..
`
`Petitioner’s Construction Of A Network-
`Based Portal Impermissibly Requires “A
`Plurality Of Users” To Have Access To The
`First User’s Device
`…………………………..
`
`
`i
`
`
`
`
`
`
`
`
`
`
`
`
`Page
`
`1
`
`1
`
`1
`
`1
`
`8
`
`9
`
`11
`
`11
`
`12
`
`13
`
`15
`
`16
`
`
`
`
`
`
`
`C.
`
`D.
`
`
`E.
`
`F.
`
`G.
`
`
`
`
`
`
`
`
`
`7.
`
`8.
`
`9.
`
`Dr. Almeroth’s Testimony Is Not Supported
`By The Specification …………………………..
`
`Patent Owner’s Construction Of A NBP
`Does Not Exclude A Preferred Embodiment ………
`
`[7.0] Summary …………………………………
`
`[7.1] Is Not Obviated By Diacakis ……………………
`
`[7.3] “Messages Are Eligible To Be Received …
`All Depending On An Identifier” Is Not Rendered
`Obvious By Diacakis …………..……………………..
`
`[7.5] Is Not Obviated By Diacakis ……………………
`
`[7.7] Is Not Rendered Obvious By Diacakis …………….
`
`[7.8] “Even When The Message Is Received” “The
`Contact Information” “Is Not Provided” Is
`Not Rendered Obvious By Diacakis
`.…………………..
`
`1.
`
`2.
`
`
`
`
`
`
`
`The Petitioner’s Positions On “NBP” And
`“Contact Information Not Provided” Are
`Incompatible
`…………………………………
`
`Diacakis Teaches That The Recipient’s
`Contact Information Is Sent To The Sender’s
`Client Device …………………………………
`
`i.
`
`ii
`
`iii
`
`Diacakis Teaches A POSITA That Contact
`Information Is Provided ……………………
`
`The Board Already Determined That
`Diacakis Teaches A POSITA That Contact
`Information Is Provided ……………………
`
`Judge Chang Also Determined That Diacakis
`Teaches A POSITA That Contact Information
`Is Provided …………………………………
`ii
`
`17
`
`19
`
`21
`
`21
`
`22
`
`25
`
`26
`
`27
`
`27
`
`29
`
`29
`
`32
`
`32
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`33
`
`34
`
`35
`
`36
`
`36
`
`38
`
`38
`
`
`
`
`
`
`3.
`
`
`
`
`
`4.
`
`5.
`
`Diacakis’s Blocked Users Do Not Receive A
`Message ………………………………………..
`
`The Institution Decision …………………………..
`
`[7.8] Summary …………………………………
`
`
`
`
`
`
`IV. GROUND II – CLAIMS 8, 9, 43, 44, 47, 48, 50, AND 54
`ARE NOT RENDERED OBVIOUS BY DIACAKIS
`AND LOVELAND
`………………………………………..
`
`
`V. GROUND III – CLAIMS 37, 42, 56, 59–63, AND 67 ARE
`NOT RENDERED OBVIOUS BY DIACAKIS AND
`TAKAHASHI ………………………………………………
`
`
`VI. GROUND IV – CLAIM 45 IS NOT RENDERED
`OBVIOUS BY DIACAKIS, LOVELAND, AND
`TAKAHASHI ………………………………………………
`
`
`VII. CONCLUSION ………………………………………………
`
`
`
`
`
`
`
`iii
`
`
`
`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
`
`
`
`
`
`
`
`
`
`
`iv
`
`
`
`I.
`
`INTRODUCTION
`Patent Owner, IngenioShare, LLC submits this Response to the Petition for
`
`inter partes review of U.S. Patent No. 10,492,038, Case No. IPR2022-00294, and
`
`the subsequent Institution Decision. For the reasons explained herein, the
`
`patentability of all Challenged Claims should be confirmed.
`
`II. TERMINOLOGY
`
`The claims of the ʼ038 patent use the term “first user” to refer to the sender
`
`and “second user” to refer to the recipient of a message. The specification and the
`
`prior art references use other terminology as well, including “user,” “client,”
`
`“subscriber,” “person,” etc. To avoid confusion, Patent Owner uses the terms
`
`“sender” and “recipient” herein. Exhibit 2005, Rouskas Declaration at 12, ¶33.
`
`III. 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. Diacakis (Exhibit 1007)
`
`Diacakis teaches a “presence and availability management system.”
`
`Diacakis defines “presence” as “the ability of an individual to access a particular
`
`communications network” and “availability” as “the willingness of an individual
`
`who is present in one or more communications networks to be reached by one or
`
`more persons.” Exhibit 1007, Diacakis at [0003], [0026], [0027]; Exhibit 2005,
`
`Rouskas Declaration at 12, ¶34.
`
`
`
`1
`
`
`
`
`
`Diacakis’s presence and availability (P&A) management system determines
`
`whether a user is present on the network (i.e., whether the user’s device is powered
`
`on); determines whether a user is available on the network (whether the user is
`
`willing to receive communications from others); and communicates P&A
`
`information to others, depending on the user’s preference.
`
`
`Exhibit 1007, Diacakis at Fig. 4; Exhibit 2005, Rouskas Declaration at 12-13, ¶35.
`
`
`
`
`
`Diacakis teaches that an individual may create profiles, such as the office
`
`profile in Fig. 2, to instruct the P&A system how to distribute his/her contact
`
`information. A profile specifies what subset of the individual’s contact
`
`information subscribers at a given access level receive:
`
`
`
`2
`
`
`
`For example, an individual may have an office profile as indicated in
`FIG. 2. Thus, a subscriber with an access level of “Important” would
`receive the items marked “Yes” in the “Important” column, with the
`preference indicated (where appropriate), thereby making it very easy
`for “important” subscribers to communicate with the individual.
`Persons in the “Normal” access level would receive less contact
`information than persons in the “Important” access level, and persons
`in the “Restricted” access level would receive even less contact
`information.
`
`
`Exhibit 1007, Diacakis at [0032] (emphasis added); Exhibit 2005, Rouskas
`
`Declaration at 13, ¶36.
`
`
`
`Diacakis Fig. 3 also shows that subscribers at the “Restricted” access level
`
`receive only the voicemail number, subscribers in the “Normal” access level
`
`receive the work phone number, voicemail number, and e-mail, and subscribers in
`
`the “Important” access level receive two phone numbers, a voicemail number, two
`
`e-mails, and an IM address. Also, “the indicator module 110 may determine
`
`whether an address for each data content type (e.g., telephone, text (IM), video,
`
`graphic, audio, etc.) has been transmitted from the P&A management server 12.”
`
`Exhibit 1007, Diacakis at [0066]; Exhibit 2005, Rouskas Declaration at 14, ¶37.
`
`
`
`3
`
`
`
`
`
`Exhibit 1007, Diacakis at Fig. 3; Exhibit 2005, Rouskas Declaration at 14, ¶37.
`
`
`
`According to Diacakis, the P&A management system employs a publisher-
`
`subscriber model that updates the subscribers of an individual’s presence and
`
`availability status as soon as the individual publishes a change to the profile:
`
`When the individual transmits a change in profile to the server 12, the
`server publishes the change to each of the connected clients 22 that
`are subscribers of the individual's information. The publisher-
`subscriber model enables subscribers to observe a particular
`individual’s P&A information instantly.
`
`
`Exhibit 1007, Diacakis at [0029]; Exhibit 2005, Rouskas Declaration at 14-15, ¶38.
`
`
`
`Subscribers access an individual’s P&A information on their client terminals
`
`via a “Contacts Program” akin to the Contacts application in today’s smartphones.
`
`Exhibit 1007, Diacakis at [0056] and Fig. 8; Exhibit 2005, Rouskas Declaration at
`
`15, ¶39.
`
`
`
`4
`
`
`
`
`As shown in the left-hand window of Fig. 8, a subscriber has access to the contact
`
`
`
`information of an individual:
`
`As illustrated, the subscriber may navigate the list of names in the
`right hand window (“Contacts Program”) to access the P&A
`information regarding the highlighted individual in the left hand
`window (“Contact Properties”).
`
`
`Exhibit 1007, Diacakis at [0056]; Exhibit 2005, Rouskas Declaration at 15-16, ¶39.
`
`For instance, the left-hand window in Fig. 8 shows multiple phone numbers, voice
`
`numbers, IM addresses, and e-mails for the contact “Jonathan” who is highlighted
`
`in the right-hand window of Fig. 8. Exhibit 1007, Diacakis at Fig. 8; Exhibit 2005,
`
`Rouskas Declaration at 15-16, ¶39.
`
`
`
`5
`
`
`
`
`
`Diacakis’s P&A management system updates the availability information by
`
`updating the indicator next to each availability means (i.e., piece of contact
`
`information):
`
`The contact information in the left hand window may be updated
`based on availability information transmitted from the identified
`individual’s P&A management server 12.
`
`
`Exhibit 1007, Diacakis at [0056]. For instance, according to the left-hand window,
`
`contact “Jonathan” is available by all means except the second IM address. Exhibit
`
`1007, Diacakis at Fig. 8; Exhibit 2005, Rouskas Declaration at 16, ¶40.
`
`
`
`Diacakis teaches conventional systems that display multiple entries for a
`
`contact, each entry corresponding to an available address, e.g., as in the left-hand
`
`window of Fig. 8, where there are multiple lines for contact Jonathan. Exhibit
`
`1007, Diacakis at Fig. 8. Diacakis, on the other hand, discloses a method which
`
`“may relate the various entries for an individual and merge them together as one
`
`entry.” Id. at [0059]. For instance, the left-hand window of Fig. 8 shows that
`
`contact Jonathan is available on one IM address but not the other. Id. at Fig. 8.
`
`This information is summarized in the right-hand window into a single IM icon
`
`that shows contact Jonathan as available through IM. Id. Similarly, contact
`
`Jonathan is available on both phone numbers listed in the left-hand window, and
`
`this is summarized into a single phone icon in the right-hand window that shows
`
`
`
`6
`
`
`
`contact Jonathan as available via a telephone. Id.; Exhibit 2005, Rouskas
`
`Declaration at 16-17, ¶41.
`
`
`
`As explained in Diacakis, the user interface is implemented at the subscriber
`
`(client) terminal and is simply the interface of the subscriber’s Contact application:
`
`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, as described
`previously in connection with FIG. 8, for display by the user interface
`112.
`
`
`Exhibit 1007, Diacakis at [0064]. Therefore, the user interface of Diacakis simply
`
`allows the subscriber who owns the device to access all his/her contacts and their
`
`availability – it does not enable worldwide access to a particular individual. Exhibit
`
`2005, Rouskas Declaration at 17, ¶42.
`
`
`
`Diacakis also teaches that the names appearing in Fig. 8 are simply the
`
`names of the subscriber’s contacts:
`
`the subscriber may navigate the list of names in the right hand
`window (“Contacts Program”) to access the P&A information
`regarding the highlighted individual in the left hand window
`(“Contact Properties”).
`
`
`Exhibit 1007, Diacakis at [0056].
`
`For example, with reference to FIG. 8, the indicator for Jonathan
`identifies Jonathan by name and indicates that Jonathan is available to
`the subscriber to receive data content by telephone and instant
`messaging.
`
`7
`
`
`
`
`
`
`
`Exhibit 1007, Diacakis at [0064]. Diacakis’s use of first names in the Contacts
`
`Program indicates that these are not meant as unique identifiers. Exhibit 2005,
`
`Rouskas Declaration at 17-18, ¶43.
`
`
`
`
`
`1.
`
`Diacakis Does Not Provide Or Support Messages
`
`Diacakis is an improved P&A system that does not include a communication
`
`system for users to interact, i.e., Diacakis does not provide or support messages
`
`communicated from one user to another, as independent claims 7, 38, and 46 of the
`
`ʼ038 patent requires. For example, Diacakis does not show anyone making a call
`
`or receiving a call via the P&A system. Exhibit 2005, Rouskas Declaration at 18,
`
`¶44.
`
`In a related IPR proceeding, the Board recently determined that Diacakis
`
`does not provide messages from a subscriber to an individual:
`
`In short, based on the evidence of record, Petitioner shows only that
`the server in Diacakis provides the appropriate address or phone
`number and the presence and availability information regarding the
`individual to the subscriber who wishes to contact an individual, not
`that the server receives the “message” the subscriber is trying to
`convey to the individual.
`
`
`Exhibit 2006, Decision Denying Institution, IPR2022-00297 at 26 (PTAB May 26,
`
`2022) (emphasis added); Exhibit 2005, Rouskas Declaration at 18, ¶45.
`
`
`
`
`
`
`
`8
`
`
`
`
`
`B.
`
`[7.0] “Network-Based Portal” (“NBP”)1
`
`The Petition defines a “network-based portal” as “a web page or interface
`
`that connects clients to a network.” See Petition at 34, 55-56, and 57. Petitioner
`
`points to the “client terminal 22” containing the “user interface 112”:
`
`
`
`
`
`
`1 The claim term “network-based portal” appears several times throughout claim 7
`(and independent claims 38 and 46). Since this claim term first appears in [7.0],
`Patent Owner addresses it here.
`
`
`
`9
`
`
`
`
`
`Petitioner contends “Diacakis’ client terminal 22” contains “a network-based
`
`portal”. See Petition at 34-35 (emphasis added); Exhibit 2005, Rouskas Declaration
`
`at 19-20, ¶46.
`
`With respect to “client terminal 22,” Diacakis repeatedly teaches that the
`
`client terminal is just that, a client terminal at the client side of a network; it is not
`
`a server at the server side of a network. See Exhibit 1007 at [0024], [0030], [0034],
`
`[0035], and [0056] (Diacakis). Diacakis’s “client terminal” is a “communication
`
`device”:
`
`The client terminal 22 is illustrated as a personal computer in FIG. 1,
`although according to other embodiments the client terminal may be
`another type of communication device such as, for example, a wireless
`telephone (such as a WAP (Wireless Application Protocol)-enabled
`phone) or a wireless or connected personal digital assistant (PDA).
`
`
`Exhibit 1007, Diacakis at [0024] (emphasis added); Exhibit 2005, Rouskas
`
`Declaration at 20, ¶47.
`
`
`
`10
`
`
`
`
`
`With respect to the “user interface 112,” Diacakis teaches that the “user
`
`interface 112” is provided by the client device and that it “may include, for
`
`example, a GUI (Graphical User Interface) or a CUI (Character-based user
`
`interface).” Exhibit 1007, Diacakis at [0063]; Exhibit 2005, Rouskas Declaration at
`
`20-21, ¶48.
`
`1.
`
`A “Portal” Is Not A User Terminal Or A Client
`Communication Device
`
`“In the context of the Internet, a portal refers to any commonly used website
`
`
`
`serving as an entry point to the Internet, usually with many links to a wide variety
`
`of information, data, resources and services.” Exhibit 2005, Rouskas Declaration at
`
`21, ¶49. “Portal is a term, generally synonymous with gateway, for a World Wide
`
`Web site that is or proposes to be a major starting site for users when they get
`
`connected to the Web or that users tend to visit as an anchor site. There are general
`
`portals and specialized or niche portals.” Id. Websites are hosted on web servers,
`
`not on client communication devices such as Diacakis’s client terminal 22. Id.
`
`2.
`
`The ʼ038 Specification Defines “Portal” As A “Gateway”
`And Defines A “Gateway” As A “Networked Server”
`
`Consistent with its common meaning, the specification of the ʼ038 patent
`
`
`
`defines a “portal” as a “communication gateway”. Exhibit 1001, ʼ038 Patent at
`
`Col. 4, line 22, Col. 4, lines 62-63, Col. 7, lines 11-12, and Col. 7, line 15; Exhibit
`
`
`
`11
`
`
`
`2005, Rouskas Declaration at 21, ¶50. The specification also defines a “gateway”
`
`as a “networked server”:
`
`The remote server computer can be a networked server coupled to the
`network 108. One example of a networked server is a gateway
`computer for a wireless 10 electronic device, such as a mobile
`telephone.
`
`
`Exhibit 1001, ʼ038 Patent at Col. 16, lines 15-18; Exhibit 2005, Rouskas
`
`Declaration at 21-22, ¶50. Importantly, the ʼ038 specification does not define
`
`“portal” or “network-based portal” as an end-user device or client communication
`
`device. Id.
`
`
`
`
`
`
`
`3.
`
`The Functionality Of A “Portal” Is Different Than That Of
`A Client Communication Device
`
`Based on the ʼ038 specification’s use of the term “portal”, a POSITA would
`
`understand that the functionality of the claimed “portal” is different than that of a
`
`client communication device. Specifically, a POSITA would understand that a
`
`portal allows “worldwide access”, whereas a client communication device is
`
`“associated with a user”. This is consistent with the teachings of the ʼ038
`
`specification:
`
`(1)
`
`“The portal allows worldwide access to the user”
`
`
`
`
`
`Exhibit 1001, ʼ038 Patent at Col. 4, lines 52-53;
`
`“A portal or gateway approach could provide general Internet
`(2)
`access to one or more embodiments of the communication management
`systems”
`
`12
`
`
`
`
`
`
`
`Id. at Col. 7, lines 11-14 (indicating that a portal can be accessed by multiple users
`
`through the Internet);
`
`“Peter wants to make a mobile phone call to the user. In one
`(3)
`embodiment, Peter calls a portal…. In another example, Peter is also a
`registered user of the portal.”
`
`
`Id. at Col. 6, lines 33-39 (indicating again that multiple users may access the
`
`portal);
`
`
`
`“not provided to the first user via the electronic device
`(4)
`
`associated with the first user, … the message is received by the second user
`via the electronic device associated with the second user,”
`
`
`Id. at Col. 2, lines 25-29; Exhibit 2005, Rouskas Declaration at 22-23, ¶51.
`
`In light of the common meaning of “portal,” and the specification’s use of
`
`the term “portal”, a POSITA would understand that the functionality of a “portal”
`
`is different than that of a client communication device because a “portal” allows
`
`“worldwide access”, whereas a client communication device is “associated with a
`
`user”. They are two distinct things. Exhibit 2005, Rouskas Declaration at 23, ¶52.
`
`
`
`4.
`
`The Claims Also Distinguish A “Portal” From A
`Client Communication Device
`
`In addition to the specification, the claim language also clearly differentiates
`
`
`
`between a “portal” and a client communication device. For example, claim
`
`elements [7.7] and [7.8] state, respectively:
`
`“computer program code for receiving, from the second user, contact
`information associated with the second user to allow the second user
`
`
`
`13
`
`
`
`to participate and at least receive messages via the network-based
`portal;
`
`and
`
`“wherein … the contact information associated with the second user is
`not provided via the network-based portal to the first user via an
`electronic device associated with the first user”
`
`
`Exhibit 1001, ʼ038 Patent at Claim 7 (emphasis added); Exhibit 2005, Rouskas
`
`Declaration at 23-24, ¶53; see also Exhibit 1001, ʼ038 Patent at Claim 38 ([38.7]
`
`and [38.8] and Claim 46 ([46.7] and [46.8]); Exhibit 2005, Rouskas Declaration at
`
`23-24, ¶53.
`
`Petitioner argues that the user interface on the sender’s (first user’s) client
`
`communication device is the claimed network-based portal (“NBP”). Petition at
`
`33-35. But if that were the case, claim 7 (and claims 38 and 46) could not possibly
`
`be carried out because [7.7] (and [38.7] and [46.7]) requires the recipient’s (second
`
`user’s) contact information for messages to be received via the NBP, and since
`
`Petitioner claims the NBP is on the sender’s client communication device, the
`
`recipient’s contact information necessarily must also be provided to the sender’s
`
`client communication device. Exhibit 2005, Rouskas Declaration at 24, ¶54.
`
`However, [7.8] (and [38.8] and [46.8]) specifically requires that the contact
`
`information not be provided to the sender’s client communication device. Id.
`
`Thus, adopting Petitioner’s argument leads to a contradiction, making the
`
`method useless. This contradiction, however, is resolved by following the ʼ038
`14
`
`
`
`
`
`specification’s and the claims’ teaching that the NBP is distinct from the sender’s
`
`client communication device. Exhibit 2005, Rouskas Declaration at 24, ¶55.
`
`
`
`5.
`
`The User Interface Of Diacakis Is Not A
`“Portal”
`
`The user interface of Diacakis is just that, the user interface of a sender’s
`
`
`
`client communication device. It is not a “portal”. A POSITA would understand this
`
`based on Diacakis’s teachings that:
`
`the subscriber may navigate the list of names in the right hand
`window (“Contacts Program”) to access the P&A information
`regarding the highlighted individual in the left hand window
`(“Contacts Properties”).
`
`
`Exhibit 1007, Diacakis at [0056]. Based on this teaching, a POSITA would
`
`understand that the Diacakis user interface is the interface of the Contacts
`
`application on the sender’s client communication device; it is not a “portal”.
`
`Exhibit 2005, Rouskas Declaration at 25, ¶56.
`
`
`
`The Diacakis user interface merely provides contact and availability
`
`information to a sender who wants to send messages to his/her contacts using their
`
`contact information. Exhibit 2005, Rouskas Declaration at 25, ¶57. In contrast, the
`
`ʼ038 “portal” or NBP allows a recipient to receive messages from multiple senders:
`
`(1)
`
`“The portal allows worldwide access to the user”,
`
`Exhibit 1001, ʼ038 Patent at Col 4, 52-53.
`
`
`
`(2)
`
`“Peter wants to make a mobile phone call to the user. In one
`
`15
`
`
`
`
`
`
`
`embodiment, Peter calls a portal. As an example, the portal can be the user’s
`
`ISP. The portal first verifies the caller’s identity to be Peter…. In
`
`establishing contact, the portal can access the user’s database and determine
`
`that Peter belongs to ContactClass2.”
`
`Exhibit 1001, ʼ038 Patent at Col. 6, lines 33-50; Exhibit 2005, Rouskas
`
`Declaration at 25-26, ¶57.
`
`
`
`
`
`
`
`
`6.
`
`Petitioner’s Construction Of A Network-Based Portal
`Impermissibly Requires “A Plurality Of Users” To Have
`Access To The First User’s Device
`
`[7.0] expressly states that “each of the plurality of users” have their
`
`“corresponding identifier” “set via the network-based portal”. Exhibit 2005,
`
`Rouskas Declaration at 26, ¶58. Therefore, accepting Petitioner’s construction of
`
`NBP as the user interface on the first user’s device would require “a plurality” of
`
`users to have access to the first user’s device so that “each of the plurality of users”
`
`can set their respective identifier(s). Id. Indeed, a POSITA would understand that
`
`in the context of claim 7 (and claims 38 and 46) the “plurality” of users means not
`
`just “three or more” users, but “a large number”. Id. This is impermissible for the
`
`following reasons. Id.
`
`
`
`User devices, including computers, mobile phones, and other handheld
`
`devices are assigned private IP addresses (e.g., in the range 10.X.Y.Z or
`
`192.168.X.Y) and therefore they cannot be accessed (i.e., no traffic can be sent to
`
`
`
`16
`
`
`
`them) from the public Internet. Id. at 26, ¶59. The use of private addresses ensures
`
`data protection, privacy and security. Id. Therefore, individual users, corporations
`
`that provide devices to employees, and device (e.g., mobile phone) manufacturers
`
`go to great lengths to ensure that user devices cannot be accessed from the public
`
`Internet. Id. Dr. Rouskas’s testimony is corroborated by checking (1) that one
`
`cannot connect over the Internet and access the devices of one’s contacts, and (2)
`
`one’s contacts cannot connect over the Internet and access one’s personal device.
`
`Id. at 26-27, ¶59.
`
`A POSITA would understand that typically a user’s contact (or anyone else)
`
`is not allowed access to the user’s device. Id. Since the recipients (contacts)
`
`cannot possibly use the sender’s communication device to set their identifier, the
`
`preamble’s requirement that “each of the plurality of users” has his/her
`
`“corresponding identifier” “set via the network-based portal” invalidates
`
`Petitioner’s arguments that the NBP may be on the first user’s communication
`
`device. Id. at 27, ¶60.
`
`
`
`
`
`
`
`
`7.
`
`
`Dr. Almeroth’s Testimony Is Not Supported By The
`Specification
`
`Dr. Almeroth’s testimony is entitled to no or little weight because his
`
`testimony is unreliable as it contradicts the specification of the ʼ038 patent, which
`
`draws a clear distinction between a “portal” and a client communication device.
`
`
`
`17
`
`
`
`Exhibit 2005, Rouskas Declaration at 27, ¶61. For example, contrary to Dr.
`
`Almeroth’s litigation-inspired testimony, the ʼ038 specification clearly states:
`
`
`
`(1)
`
`“As an example, the portal can be the user’s ISP.”
`
`
`
`Exhibit 1001, ʼ038 Patent at Col 6, lines 34-35;
`
`“The database can, for example, be in the portal. In another
`(2)
`
`embodiment, the database is in a personal communication device of the user.
`The portal accesses the personal communication device…”
`
`
`Exhibit 1001, ʼ038 Patent at Col. 6, lines 51-54; and
`
`
`
`
`
`“The portal or gateway can then facilitate download of a
`(3)
`
`database or update thereto to a communication device, such as a phone.”
`
`
`Exhibit 1001, ʼ038 Patent at Col. 7, 15-17; Exhibit 2005, Rouskas Declaration at
`
`27-28, ¶61.
`
`As shown above, it was well known to a POSITA that a “portal” or gateway
`
`connects distinct networks, whereas a user terminal device does not. Exhibit 2005,
`
`Rouskas Declaration at 28, ¶62. There can be no more clear distinction in the
`
`Internet community than between a “portal” or a gateway and a user
`
`terminal/communication device. The ʼ038 specification is clear that multiple users
`
`may access the “portal”. Exhibit 1001, ʼ038 Patent at Col. 4, lines 52-53 (“The
`
`portal allows worldwide access to the user”). But a user terminal/communication
`
`device allows access to its user only, and by definition is not accessible
`
`“worldwide”. Exhibit 2005, Rouskas Declaration at 28, ¶62.
`
`
`
`
`
`
`
`18
`
`
`
`8.
`
`Patent Owner’s Construction Of A NBP Does Not Exclude
`A Preferred Embodiment
`
`The Institution Decision rejected Patent Owner’s Preliminary Response
`
`
`
`
`argument that a “network-based portal” resides only “at the server-side of a
`
`network” and excludes “client-side functionality” because the “’038 patent’s
`
`specification discloses embodiments where claimed functionality resides in a
`
`‘mobile phone,’ i.e., a client-side device.” Institution Decision at 23. In doing so,
`
`the Board relied on the notion that “[t]he ’038 patent’s specification discloses
`
`embodiments where claimed functionality resides in a ‘mobile phone,’ i.e., a
`
`client-side device. See Ex. 1001, 3:20–27, 9:11–10:8, 10:24–13:35, 15:4–61, Figs.
`
`7–11.” Institution Decision at 23. However, as explained below, the embodiment
`
`in Figs. 7-11 are not embodiments concerning use of a NBP. Exhibit 2005,
`
`Rouskas Declaration at 28-29, ¶63. Nonetheless, the Board “invite[d] the parties to
`
`provide additional briefing in the Response, Reply, and Sur-reply about the
`
`meaning of ‘network-based portal’ in the ’038 patent’s claims.” Institution
`
`Decision at 24; Exhibit 2005, Rouskas Declaration at 29, ¶63.
`
`Respectfully, construing the NBP as distinct from a communication device,
`
`such as Diacakis’s communication device, does not exclude a preferred
`
`embodiment. Exhibit 2005, Rouskas Declaration at 29, ¶64.
`
`Indeed, for Fig. 7, the ʼ038 specification states:
`
`
`
`19
`
`
`
` “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).
`
`
`Exhibit 1001, ʼ038 Patent at Col. 9, lines 22-26; Exhibit 2005, Rouskas
`
`Declaration at 29, ¶64. Similar language is used in describing Figures 8-11.
`
`Exhibit 1001, ʼ038 Patent at Figures 8-11; Exhibit 2005, Rouskas Declaration at
`
`29, ¶64.
`
`
`
`Claim 7 concerns “managing electronic communications of a plurality of
`
`users using at least a network-based portal” and requires “enabling, via the
`
`network-based portal, the first message to be received by the second user”;
`
`whereas the embodiments of Figs. 7-11 are methods performed by the second
`
`user’s device upon receiving a message. Exhibit 1001, ʼ038 Patent at Figures 7-11;
`
`Exhibit 2005, Rouskas Declaration at 29, ¶65. In other words, Figures 7-11 are not
`
`embodiments for “managing electronic communications using at least a network-
`
`based portal” as are the claims of the ʼ038 Patent. Instead, Figures 7-11 concern
`
`how a recipient user interacting with their client device can respond to an incoming
`
`call or message. As a result, a construction that has the NBP at a server distinct
`
`from the second user’s communication device does not exclude a preferred
`
`embodiment, if anything, it enables them. Id. at 29-30, ¶65.
`
`
`
`Moreover, with respect to Diacakis, Petitioner argues that the claimed NBP
`
`is the user interface at the first user’s device (sender) – not the second user’s
`20
`
`
`
`
`
`device. Petition at 33-35. Petitioner’s construction therefore is the one that
`
`excludes the embodiments shown in Figs. 7-11 because the methods of Figs. 7-11
`
`cannot be performed by the sender’s device. Exhibit 2005, Rouskas Declaration at
`
`30, ¶66. In other words, Figs. 7-11 of the ʼ038 patent are not embodiments using a
`
`NBP as the claims of the ʼ038 patent require. Instead, Figs. 7-11 concern different
`
`embodiments operating at a client communication device that occur after a
`
`recipient receives a message/call, and thus are not concerned with managing
`
`electronic communication at an NBP. Id.
`
`9.
`
`[7.0] Summary
`
`Diacakis’s P&A system does not render [7.0] obvious to a POSITA. Id. at
`
`30, ¶67. The claim term “network-based portal” also exists in [7.1], [7.3], [7.4],
`
`[7.5], [7.7], and [7.8]. Independent claims 38 and 46 are not rendered obvious to a
`
`POSITA for the same reasons. Id. As a result, no claim challenged in the Petition
`
`is rendered obvious such that the patentability of all challenged claims should be
`
`confirmed. Id.
`
`
`
`C.
`
`[7.1] Is Not Obviated By Diacakis
`
`[7.1] requires “the first user being identified at least depending on a prior
`
`registration process by the first user regarding the use of the network-based
`
`portal”. Exhibit 1001, ʼ038 Patent at Claim 7 (emphasis added); Exhibit 2005,
`
`Rouskas Declaration at 31, ¶68.
`
`
`
`21
`
`
`
`As Petitioner claims that the NBP is the Contacts user interface on the
`
`sender’s client device, there is no registration process as required by the claim
`
`because a user does not go through a registration process with their Contact app
`
`before they can use it; they simply open it and use it. Exhibit 2005, Rouskas
`
`Declaration at 31, ¶69. Registration is applicable when a user wishes to access a
`
`service offered by an external website or system. Id. The Contacts app, on the
`
`other hand, runs on a user’s own device and accesses data on the device, and
`
`therefore no registration process is required or takes place. Id.
`
`Thus, Diacakis’s P&A system does not render [7.1] obvious to a POSITA.
`
`Id. at 31, ¶70. Independent claim 38 [38.1] is not rendered obvious for the same
`
`reason. Id.
`
`
`
`
`
`
`D.
`
`[7.3] “Messages Are Eligible To Be Received … All Depending On
`An Identifier” Is Not Rendered Obvious By Diacakis
`
`[7.3] requires “wherein messages are eligible to be received by the electronic
`
`device associated with the second user … all depending on an identifier associated
`
`with the second user ….” Exhibit 1001, ʼ038 Patent at Claim 7 (emphasis