`
`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 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 1-6, 15, and 17 ..………………………………………
`
`INTRODUCTION ………………………………………………
`
`TERMINOLOGY ………………………………………………
`
`A. Diacakis (Exhibit 1007) …………………………………
`
`
`
`1.
`
`Diacakis Does Not Provide Or Support Messages …
`
`B.
`
`[1.0] “Network-Based Portal” …………………………..
`
`
`
`
`
`
`
`
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`6.
`
`7.
`
`A “Portal” Is Not A User Terminal Or A
`Client Communication Device ……………………
`
`The ʼ727 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 …..
`
`Requiring The “Portal” To Be On The Sender’s
`Client Communication Device Leads To A
`Contradiction …………………………………
`
`The User Interface Of Diacakis Is Not A
`“Portal” ………………………………………..
`
`Dr. Almeroth’s Testimony Is Not Supported By
`The Specification …………………………………
`
`Patent Owner’s Construction Of A NBP Does
`Not Exclude A Preferred Embodiment …………….
`
`
`i
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Page
`
`1
`
`1
`
`1
`
`1
`
`8
`
`9
`
`11
`
`11
`
`12
`
`13
`
`14
`
`16
`
`17
`
`
`
`
`
`C.
`
`D.
`
`E
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`8.
`
`[1.0] Summary …………………………………
`
`19
`
`[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 ……………………
`
`1.
`
`Requiring The “Portal” To Be On The
`Sender’s Client Communication
`Device Leads To A Contradiction …………….
`
`[1.5] Is Not Obviated By Diacakis ……………………
`
`[1.8] “Even When The Message Is Received”
`“Contact Information” “Is Not Provided” Is
`Not Obviated By Diacakis
`…………………………..
`
`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 …………………………..
`
`20
`
`22
`
`23
`
`24
`
`24
`
`26
`
`1.
`
`2.
`
`
`
`
`
`
`
`3.
`
`4.
`
`i.
`
`ii
`
`iii
`
`Diacakis Teaches A POSITA That
`Contact Information Is Provided
`
`………
`
`26
`
`The Board Already Determined That
`Diacakis Teaches A POSITA That
`Contact Information Is Provided
`
`………
`
`29
`
`Judge Chang Also Determined That
`Diacakis Teaches A POSITA That
`Contact Information Is Provided ………
`
`Diacakis’s Blocked Users Do Not Receive
`A Message ………………………………………..
`
`[1.8] Summary …………………………………
`ii
`
`30
`
`31
`
`31
`
`
`
`
`
`
`
`F.
`
`[3.0] ………………………………………………………
`
`G.
`
`H.
`
`[6.0] ………………………………………………………
`
`[9.0] ………………………………………………………
`
`I.
`
`[17.0] ………………………………………………………
`
`
`
`
`
`
`IV. GROUND II – CLAIMS 7-9 ARE NOT RENDERED
`OBVIOUS BY DIACAKIS AND LOVELAND …………….
`
`
`V. GROUND III – CLAIM 16 IS NOT RENDERED
`OBVIOUS BY DIACAKIS AND TAKAHASHI …………….
`
`
`VI. GROUND IV – HULLFISH COMBINED WITH
`TANIGAWA DOES NOT OBVIATE CLAIMS
`1-3, 6, 15, and 17 TO A POSITA …………………………..
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Tanigawa (Exhibit 1010) …………………………………
`
`A.
`
`B. Hullfish (Exhibit 1011) …………………………………
`
`C. A POSITA Would Not Be Motivated To Combine
`Tanigawa And Hullfish To Implement The Claimed
`Invention Of The ʼ727 Patent …………………………..
`
`
`
`
`
`
`D.
`
`
`1.
`
`2.
`
`Tanigawa And Hullfish Are Incompatible ………
`
`Petitioner’s Alleged Motivation To
`Combine Is Nonsense …………………………..
`
`[1.0] “Network-Based Portal” …………………………..
`
`1.
`
`2.
`
`A “Portal” Is Not A User Terminal Or
`A Client Communication Device …………….
`
`The ʼ727 Specification Defines “Portal” As
`A “Gateway” And Defines A “Gateway”
`As A “Networked Server”
`…………………..
`iii
`
`31
`
`31
`
`31
`
`32
`
`32
`
`33
`
`33
`
`33
`
`39
`
`40
`
`40
`
`43
`
`46
`
`48
`
`48
`
`
`
`
`
`
`
`
`
`E.
`
`F.
`
`G.
`
`3.
`
`4.
`
`5.
`
`The Functionality Of A “Portal” Is
`Different Than That Of A Client
`Communication Device …………………………..
`
`Petitioner’s Construction Is Contradictory ………
`
`Tanigawa’s User Interface Is Not A
`“Network-Based Portal” …………………………..
`
`[1.3] “Any Of The Plurality Of Modes Of
`Communication” “All Depending On An
`Identifier” Is Not Obviated By Tanigawa And
`Hullfish ………………………………………………
`
`[1.4] “Block” Is Not Rendered Obvious By
`The Combination ………………………………………..
`
`[1.5] The Combination Does Not Obviate
`“Enabling The First Message” “Depending
`On The Identifier” “In View Of The Second
`User Not Blocking The First User” ……………………
`
`H.
`
`[1.8] Is Not Obviated By The Combination …………….
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`1.
`
`2.
`
`
`
`
`
`
`
`
`
`49
`
`50
`
`51
`
`54
`
`56
`
`58
`
`58
`
`58
`
`59
`
`The Petitioner’s Positions On “NBP”
`And “Contact Information Not Provided”
`Are Incompatible …………………………………
`
`The Combination Teaches That The
`Recipient’s Contact Information Is
`Sent To The Sender’s Client
`Communication Device …………………………..
`
`i.
`
`ii.
`
`Tanigawa Teaches A POSITA That
`Contact Information Is Provided
`
`………
`
`60
`
`Tanigawa Teaches A POSITA That IM
`Clients Receive Presence Information ………
`iv
`
`62
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`iii.
`
`Tanigawa Teaches A POSITA That IM
`Clients Use Client Addresses To Initiate
`Communication …………………………..
`
`3.
`
`4.
`
`5.
`
`6.
`
`Tanigawa Does Not Teach Or Suggest Hiding
`Contact Information …………………………..
`
`Petitioner’s Reliance On Dr. Almeroth Is
`Misplaced ………………………………………..
`
`Petitioner’s Argument Is Wrong And Is
`Outweighed By Patent Owner’s Evidence ………
`
`[1.8] Summary …………………………………
`
`I.
`
`[3.0] ………………………………………………………
`
`J.
`
`K.
`
`[6.0] ………………………………………………………
`
`[17.0] ………………………………………………………
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`VII. GOUND V – CLAIMS 7-9 ARE NOT RENDERED
`OBVIOUS BY TANIGAWA, HULLFISH, AND
`LOVELAND
`………………………………………………
`
`
`VIII. GROUND VI – CLAIM 16 IS NOT RENDERED
`OBVIOUS BY TANIGAWA, HULLFISH, AND
`TAKAHASHI ………………………………………………
`
`
`IX. CONCLUSION ………………………………………………
`
`
`
`
`
`
`
`v
`
`64
`
`64
`
`65
`
`67
`
`68
`
`68
`
`68
`
`69
`
`69
`
`69
`
`70
`
`
`
`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
`
`
`
`
`
`
`
`
`
`
`
`vi
`
`
`
`I.
`
`INTRODUCTION
`Patent Owner, IngenioShare, LLC submits this Response to the Petition for
`
`inter partes review of U.S. Patent No. 10,708,727, Case No. IPR2022-00291, 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 ʼ727 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.
`
`III. GROUND I – DIACAKIS DOES NOT OBVIATE CLAIMS 1-6, 15,
`And 17
`
`
`
`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.
`
`
`
`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-
`
`
`
`3
`
`
`
`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, ¶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
`
`14-16, ¶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 14-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 2005, Rouskas Declaration at 14-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 claim 1 of the ʼ727 patent requires.
`
`Exhibit 2005, Rouskas Declaration at 18, ¶44. In fact, Diacakis does not show
`
`anyone making a call or receiving a call because this is outside the scope of the
`
`invention. According to Diacakis, the invention is related specifically to “presence
`
`and availability management systems” and to a server and method for
`
`“communicating communication network availability information regarding an
`
`individual”.” Exhibit 1007, Diacakis at [0003], [0009]-[0010]; 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.
`
`8
`
`
`
`
`
`
`
`Exhibit 2006, Decision Denying Institution, IPR2022-00297 at 26 (PTAB May 26,
`
`2022) (emphasis added); Exhibit 2005, Rouskas Declaration at 18-19, ¶45.
`
`
`
`B.
`
`[1.0] “Network-Based Portal” (“NBP”)
`
`The Petition defines a “network-based portal” as “a web page or interface
`
`that connects clients to a network.” See Petition at 36. Petitioner points to the
`
`“client terminal 22” containing the “user interface 112”:
`
`
`
`
`
`
`
`9
`
`
`
`
`
`Petitioner contends “Diacakis’ client terminal 22” contains “a network-based
`
`portal”. See Petition at 35-37 (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, Diacakis 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 ʼ727 Specification Defines “Portal” As A “Gateway”
`And Defines A “Gateway” As A “Networked Server”
`
`Consistent with its common meaning, the specification of the ʼ727 patent
`
`
`
`defines a “portal” as a “communication gateway”. Exhibit 1001, ʼ727 Patent at
`
`Col. 4, line 3 and lines 43-44, Col. 6, lines 57-58 and line 61; Exhibit 2005,
`
`
`
`11
`
`
`
`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, ʼ727 Patent at Col. 15, line 67-Col. 16, line 3. Importantly, the ʼ727
`
`specification does not define “portal” or network-based portal” as an end-user
`
`device or client communication device. Exhibit 2005, Rouskas Declaration at 22,
`
`¶50.
`
`
`
`
`
`
`
`3.
`
`The Functionality Of A “Portal” Is Different Than That Of
`A Client Communication Device
`
`Based on the ʼ727 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. Exhibit 2005, Rouskas Declaration at 22, ¶51.
`
`Specifically, a POSITA would understand that a portal allows “worldwide access”,
`
`whereas a client communication device is “associated with a user”. Id. This is
`
`consistent with the teachings of the ʼ727 specification:
`
`(1)
`
`“The portal allows worldwide access to the user”
`
`
`
`
`
`Exhibit 1001, ʼ727 Patent at Col. 4, lines 33-34;
`
`“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. 6, lines 57-60 (indicating that a portal can be accessed by multiple users
`
`through the Internet); and
`
`“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 12-19 (indicating again that multiple users may access the
`
`portal); 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”. Exhibit 2005, Rouskas Declaration at 23, ¶52. They are two distinct things.
`
`Id.
`
`
`
`
`
`4.
`
`Requiring The “Portal” To Be On The Sender’s
`Client Communication Device Leads To A Contradiction
`
`In addition to the specification, the claim language also clearly differentiates
`
`between a “portal” and a client communication device. Exhibit 2005, Rouskas
`
`Declaration at 23, ¶53. For example, claim element [1.8] states:
`
`“contact information associated with the second user and provided by
`the second user to the network-based portal”
`
`Exhibit 1001, ʼ727 Patent at Claim 1 (emphasis added).
`
`
`
`13
`
`
`
`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
`
`35-37. But if that were the case, then the method of claim 1 could not possibly be
`
`carried out because [1.8] requires the recipient’s (second user’s) contact
`
`information for messages to be “provided by the second user to the network-based
`
`portal”, 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 23-24, ¶54. However, [1.8] specifically further requires that the
`
`second user’s “contact information” “is not be provided via the network-based
`
`portal to the first user”, i.e. the sender’s client communication device. Id.
`
`Thus, adopting Petitioner’s argument leads to a contradiction, making the
`
`method useless. Exhibit 2005, Rouskas Declaration at 24, ¶55. This contradiction,
`
`however, is resolved by following the ʼ727 specification’s and the claims’ teaching
`
`that the NBP is distinct from the sender’s client communication device. Id.
`
`
`
`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”. Exhibit 2005, Rouskas
`
`Declaration at 24, ¶56. A POSITA would understand this based on Diacakis’s
`
`teachings that:
`
`
`
`14
`
`
`
`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 24-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. Id. at 25, ¶57. In contrast, the ʼ727 “portal” or NBP allows a
`
`recipient to receive messages from multiple senders:
`
`(1)
`
`“The portal allows worldwide access to the user”,
`
`Exhibit 1001, ʼ727 Patent at Col 4, 33-34.
`
`
`
`
`
`(2)
`
`“Peter wants to make a mobile phone call to the user. In one
`
`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.”
`
`Id. at Col. 6, lines 12-29; Exhibit 2005, Rouskas Declaration at 25, ¶57.
`
`
`
`
`
`
`
`15
`
`
`
`
`
`
`
`
`
`
`6.
`
`
`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 ʼ727 patent, which
`
`draws a clear distinction between a “portal” and a client communication device.
`
`Exhibit 2005, Rouskas Declaration at 25, ¶58. For example, contrary to Dr.
`
`Almeroth’s litigation-inspired testimony, the ʼ727 specification clearly states:
`
`
`
`(1)
`
`“As an example, the portal can be the user’s ISP.”
`
`
`
`Exhibit 1001, ʼ727 Patent at Col 6, lines 13-14;
`
`“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 ….”
`
`
`Id. at Claim 1 at Col. 6, lines 30-34; and
`
`
`
`
`
`“The portal or gateway can then facilitate download of a
`(3)
`
`database or update thereto to a communication device, such as a phone.”
`
`
`Id. at Col. 6, lines 61-63; Exhibit 2005, Rouskas Declaration at 25-26, ¶58.
`
`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 26, ¶ 59. There can be no more clear distinction in the
`
`Internet community than between a “portal” or a gateway and a user
`
`terminal/communication device. Id. The ʼ727 specification is clear that multiple
`
`users may access the “portal”. Exhibit 1001, ʼ727 Patent at Col. 4, lines 33-34
`
`
`
`16
`
`
`
`(“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 26, ¶59.
`
`7.
`
`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 “’727 patent’s
`
`specification discloses embodiments where claimed functionality resides in a
`
`‘mobile phone,’ i.e., a client-side device.” Institution Decision at 11. In doing so,
`
`the Board relied on the notion that the ’727 patent’s specification discloses
`
`embodiments “where the portal functionality is implemented in a ‘mobile phone,’
`
`i.e., a client-side device.” Id. citing Ex. 1001, 3:10-19, 9:3-10:2, 10:17-13:27,
`
`14:64-15:54, Figs. 7–11. However, as explained below, the embodiment in Figs.
`
`7-11 are not embodiments concerning use of a NBP. Exhibit 2005, Rouskas
`
`Declaration at 26-27, ¶60. Indeed, the Board noted that the “parties will have an
`
`opportunity to elaborate on their positions for a proper construction of ‘network-
`
`based portal’ during trial.” Institution Decision at 11.
`
`Respectfully, construing the NBP as distinct from a client communication
`
`device, such as Diacakis’s client communication device, does not exclude a
`
`preferred embodiment. Exhibit 2005, Rouskas Declaration at 27, ¶61.
`17
`
`
`
`
`
`Indeed, for Fig. 7, the ʼ727 specification states:
`
` “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, ʼ727 Patent at Col. 9, lines 4-8; Exhibit 2005, Rouskas Declaration at
`
`27, ¶61. Similar language is used in describing Figures 8-11. Exhibit 1001, ʼ727
`
`Patent at Figures 8-11; Exhibit 2005, Rouskas Declaration at 27, ¶61.
`
`
`
`The method of claim 1 concerns “managing electronic communications
`
`using at least a network-based portal” and requires “enabling, via the network-
`
`based portal, the 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, ʼ727 Patent at Figures 7-11; Exhibit 2005,
`
`Rouskas Declaration at 27-28, ¶62. 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 ‘727 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. Exhibit 2005, Rouskas Declaration at 27-
`
`28, ¶62.
`
`
`
`18
`
`
`
`
`
`Moreover, with respect to Diacakis, Petitioners argue that the claimed NBP
`
`is the user interface at the first user’s device (sender) – not the second user’s
`
`device. Petition at 35-37. 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
`
`28, ¶63. Furthermore, since Diacakis does not teach making or receiving calls, it
`
`necessarily excludes the embodiments shown in Figs. 7-11. Id. In other words,
`
`Figs. 7-11 of the ʼ727 patent are not embodiments using a NBP as the claims of the
`
`ʼ727 patent require. Id. 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.
`
`[1.0] Summary
`8.
`Diacakis’s P&A system does not render [1.0] obvious to a POSITA. Id. at
`
`29, ¶64. The claim term “network-based portal” also appears in claim elements
`
`[1.1], [1.2], [1.3], [1.4], [1.5], and [1.8]. The preamble therefore breaths life and
`
`meaning into claim 1. Claims 2-6, 15, and 17 are not rendered obvious to a
`
`POSITA for the same reasons. Id.
`
`
`
`
`
`
`
`19
`
`
`
`
`
`
`
`
`C.
`
`[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
`
`[1.3] requires “wherein messages are eligible to be received by the second
`
`user via the network-based portal, based on a plurality of modes of communication,
`
`all depending on an identifier … previously set by the second user via the network-
`
`based portal”. Exhibit 1001, ʼ727 Patent at Claim 1 (emphasis added); Exhibit
`
`2005, Rouskas Declaration at 29, ¶65.
`
`
`
`Diacakis teaches a P&A system that lets people know how to contact
`
`someone at a given time. Diacakis, however, does not teach a system that actually
`
`allows a user to make a communication. Exhibit 2005, Rouskas Declaration at 29,
`
`¶66. Moreover, a POSITA would understand that “Jonathan” may not be used “to
`
`receive [any] messages”, let alone “all” of the messages. Id.
`
`Petitioner cites [0056], [0059], [0062]-[0064], and Fig. 8 of Diacakis and
`
`argues that the identifier of [1.3] is met by Diacakis’s indicator “Jonathan”.
`
`Petition at 41-43. This is not true. Exhibit 2005, Rouskas Declaration at 29-30,
`
`¶67. The Diacakis indicator is not for, and cannot be used to, receive messages. Id.
`
`For example, in Fig 8:
`
`
`
`20
`
`
`
`
`
`the indicator, such as “Jonathan”, indicates Jonathan’s different modes of
`
`communication and for which mode(s) Jonathan is available. Exhibit 1007,
`
`Diacakis at Fig. 8. If a user selects “Jonathan” no communication transpires.
`
`Exhibit 2005, Rouskas Declaration at 29-30, ¶67. Instead, to communicate, the
`
`user must use either the IM or the telephone number provided on the left-hand side
`
`of Fig. 8 to contact Jonathan outside of Diaca