throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`EPIC GAMES, INC.,
`Petitioner,
`
`v.
`
` INGENIOSHARE, LLC,
` Patent Owner.
`
`
`Case No. IPR2022-00291
`Patent No. 10,708,727
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`PATENT OWNER’S 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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket