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-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

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