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-00295
`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
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`EPIC GAMES, INC.,
`Petitioner,
`
`v.
`
` INGENIOSHARE, LLC,
` Patent Owner.
`
`
`Case No. IPR2022-00295
`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 – CLAIMS 7, 10–12, 22–24, 33–36, 38–41, 46,
`49, 51–53, 55, 57–58, AND 64–66 ARE NOT RENDERED
`OBVIOUS BY TANIGAWA IN VIEW OF HULLFISH ………
`
`INTRODUCTION ………………………………………………
`
`TERMINOLOGY ………………………………………………
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`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 ʼ038 Patent …………………………..
`
`
`
`
`
`
`D.
`
`
`
`
`
`1.
`
`2.
`
`Tanigawa And Hullfish Are Incompatible ………
`
`Petitioner’s Alleged Motivation To Combine
`Is Nonsense ………………………………………..
`
`[7.0] “Network-Based Portal” …………………………..
`
`1.
`
`A “Portal” Is Not A User Terminal Or A
`Client Communication Device ……………………
`
`2.
`
`3.
`
`4.
`
`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 ……………
`
`i
`
`Page
`
`1
`
`1
`
`1
`
`2
`
`7
`
`8
`
`8
`
`12
`
`14
`
`16
`
`17
`
`17
`
`19
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`E.
`
`F.
`
`G.
`
`H.
`
`I.
`
`5.
`
`6.
`
`7.
`
`
`8.
`
`9.
`
`
`Petitioner’s Construction Is Contradictory ……..
`
`Tanigawa’s User Interface Is Not A
`“Network-Based Portal” …………………………..
`
`Patent Owner’s Construction Of NBP Does
`Not Exclude A Preferred Embodiment
`
`………
`
`Petitioner’s Construction Is Contradictory ………
`
`Tanigawa’s User Interface Is Not A “Network-
`Based Portal” …………………………………
`
`10.
`
`[7.0] Summary …………………………………
`
`[7.1] “A Prior Registration Process” Is Not Obviated
`By The Combination Of Tanigawa And Hullfish ………
`
`[7.3] “Messages Are Eligible To Be Received … All
`Depending On An Identifier” Is Not Rendered Obvious
`By The Alleged Combination …………………….…….
`
`[7.4] “Block” Is Not Rendered Obvious By The
`Alleged Combination ………………………………….
`
`[7.5] The Alleged Combination Does Not Render
`Obvious “Enabling, Via The Network-Based Portal,
`The First Message To Be Received” “Depending On
`The Identifier” “In View Of The Second User
`Not Blocking The First User” …………………………..
`
`[7.8] “Even When The Message Is Received” “The
`Contact Information” “Is Not Provided” Is Not Rendered
`Obvious By The Alleged Combination
`…………….
`
`1.
`
`The Petitioner’s Positions On “NBP” And “Contact
`Information Not Provided” Are Incompatible ……..
`
`
`19
`
`21
`
`22
`
`24
`
`25
`
`28
`
`28
`
`30
`
`32
`
`34
`
`
`
`35
`
`35
`
`ii
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`2.
`
`The Combination Teaches That The Recipient’s
`Contact Information Is Sent To The Sender’s Client
`Communication Device …………………………..
`
`
`
`
`
`
`
`3.
`
`4.
`
`5.
`
`6.
`
`7.
`
`i.
`
`ii.
`
`iii.
`
`Tanigawa Teaches A POSITA That Contact
`Information Is Provided ……………………
`
`Tanigawa Teaches A POSITA That IM
`Clients Receive Presence Information ………
`
`Tanigawa Teaches A POSITA That IM
`Clients Use Client Addresses To Initiate
`Communication …………………………..
`
`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
`
`.……..
`
`The Institution Decision …………………………..
`
`[7.8] Summary …………………………………
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IV. GROUND II – CLAIMS 8, 9, 43, 44, 47, 48, 50, AND 54
`ARE NOT RENDERED OBVIOUS BY TANIGAWA
`IN VIEW OF HULLFISH AND LOVELAND …………….
`
`
`V. GROUND III – CLAIMS 37, 42, 56, 59–63, AND 67
`ARE NOT RENDERED OBVIOUS BY TANIGAWA IN
`VIEW OF HULLFISH AND TAKAHASHI ……………………
`
`
`VI. GROUND IV – CLAIM 45 IS NOT RENDERED OBVIOUS
`BY TANIGAWA IN VIEW OF HULLFISH, LOVELAND,
`AND TAKAHASHI ………………………………………..
`
`
`VII. CONCLUSION ………………………………………………
`iii
`
`
`
`36
`
`36
`
`39
`
`40
`
`41
`
`41
`
`44
`
`46
`
`46
`
`46
`
`47
`
`48
`
`49
`
`
`
`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.
`
`U.S. Patent Application 2002/0116461 (“Diacakis”)
`
`
`Exhibit 2001
`
`Exhibit 2002
`
`Exhibit 2003
`
`Exhibit 2004
`
`Exhibit 2005
`
`Exhibit 2006
`
`
`Exhibit 2007
`
`
`Exhibit 2008
`
`Exhibit 2009
`
`
`
`
`
`
`
`
`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-00295, 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 – CLAIMS 7, 10–12, 22–24, 33–36, 38–41, 46,
`49, 51–53, 55, 57–58, AND 64–66 ARE NOT RENDERED
`OBVIOUS BY TANIGAWA IN VIEW OF HULLFISH
`
`
`
`Ground I of the Petition is based on the alleged combination of Tanigawa
`
`(Exhibit 1010) and Hullfish (Exhibit 1011). Petitioner alleges that ʼ038
`
`independent claims 7, 38, and 46, and dependent claims 10-12, 22-24, 33-36, 39-
`
`41, 49, 51-53, 55, 57-58, and 64-66, are rendered obvious by this combination. For
`
`the reasons set forth below, they are not. Exhibit 2005, Rouskas Declaration at 12
`
`¶34.
`
`
`
`
`
`
`
`1
`
`
`
`A.
`
`Tanigawa (Exhibit 1010)
`
`Tanigawa describes a communication system for group communications
`
`using text (IM) and voice (voice channel) over the Internet. Exhibit 2005, Rouskas
`
`Declaration at 12, ¶35. Group communication is a synchronous form of
`
`communication in that all users must be present and available at the same time for
`
`the communication to take place. Id. at 12-13, ¶35. Users use a client
`
`communication device such as a PC, a fixed-line telephone, or a mobile telephone
`
`to communicate. Id. at 13, ¶35.
`
`Tanigawa’s system includes:
`
`(1) for text chatting, an IM server that manages text chatting among the IM
`
`clients; the IM server also manages presence information of the IM clients. The
`
`IM server further “manages a connection between each of the IM clients
`
`participating [in] the chat and the IM server 4, merges text from each of the
`
`participating IM clients and distributes the result to each of the participating IM
`
`clients”. Exhibit 1010, Tanigawa at Abstract; Exhibit 2005, Rouskas Declaration at
`
`13, ¶36);
`
`(2) for voice chatting, “an AP server 5 manages a connection between each
`
`of the IM clients participating [in] the chat and an MD server 6, mixes voice from
`
`each of the participating IM clients except for a focused IM client and distributes
`
`
`
`2
`
`
`
`the result to the focused participating IM clients.” Exhibit 1010, Tanigawa at
`
`Abstract; Exhibit 2005, Rouskas Declaration at 13, ¶36; and
`
`(3) a VR server (called a voice relay server) for a telephone and IP network
`
`interface, changing phone network analog data to IP digital data, and allowing
`
`phone analog data to go to voice network. Exhibit 2005, Rouskas Declaration at
`
`13, ¶36.
`
`
`
`Tanigawa teaches that to participate in a group chat, one of the users must
`
`first create a conference room and have an address and nickname assigned to the
`
`conference room. Exhibit 1010, Tanigawa at [0125]-[0129], Fig. 3, and packets
`
`S1006 and S1009 in Fig. 10; Exhibit 2005, Rouskas Declaration at 13-14, ¶37.
`
`Tanigawa also teaches that the contact information of the buddies as well as
`
`the contact information of the conference room are sent to the users. Exhibit 1010,
`
`Tanigawa at [0122]-[0123] and [0143]-0144; Exhibit 2005, Rouskas Declaration at
`
`14, ¶38. Indeed, Tanigawa’s paragraphs [0143]-[0144] tell a POSITA that contact
`
`information is exchanged:
`
`to create a buddy list in which information regarding each of the chat
`buddies is registered including various information (except for the
`authentication key at least) registered in each of the identified records
`440.
`
`to display data for information written in the buddy list in the display
`device, whereby, the information on the chat buddies is notified to the
`user “taro”. Thus, the user “taro” can check, through the text chat he
`is executing, whether or not the buddy participating in the conference
`room can voice-chat, and, if so, which IM client (which can be
`3
`
`
`
`
`
`identified from the account name and the client nickname) is used for
`the voice chat.”
`
`
`Exhibit 1010, Tanigawa at [0143]-[0144]; Exhibit 2005, Rouskas Declaration at
`
`14, ¶38. Figs. 10, 11, and 15-19 also teach a POSITA that the buddy list is sent
`
`back to user taro at terminal 7-2:
`
`
`
`Exhibit 1010, Tanigawa at Figs. 10, 11, and 15-19; Exhibit 2005, Rouskas
`
`Declaration at 14-15, ¶38.
`
`
`
`Tanigawa also teaches that to participate in a voice chat, the AP server, not a
`
`user, calls the chat participants who respond to the AP server. Exhibit 1010,
`
`Tanigawa at [0147]-[0151] and packets S1018, S1019 of Fig. 11 (showing the call
`
`requests from the AP server, relayed by the VR server, and responses S1020A,
`
`
`
`4
`
`
`
`S1020B, S1020C); Exhibit 2005, Rouskas Declaration at 15, ¶39. Tanigawa also
`
`teaches a POSITA “[i]n this way, each of the IM clients specified by the voice chat
`
`request is called out by the AP server 5.” Exhibit 1010, Tanigawa at [0151].
`
`Exhibit 2005, Rouskas Declaration at 15, ¶39.
`
`Tanigawa further teaches a POSITA that Tanigawa’s client devices send
`
`voice packets to the address for voice chatting, not directly to the participants:
`
`“[m]ore specifically, the voice packet sent from each of the IM clients to the
`
`address for voice chatting”. Exhibit 1010, Tanigawa at [0155]; Exhibit 2005,
`
`Rouskas Declaration at 15-16, ¶40. The address for voice chatting is assigned to
`
`the MD server. Exhibit 1010, Tanigawa at [0152]; Exhibit 2005, Rouskas
`
`Declaration at 16, ¶40. The MD server mixes the voice packets from all the IM
`
`client devices, and distributes the synthesized result to each of the IM client
`
`devices. Exhibit 1010, Tanigawa at [0154]-[0156]; Exhibit 2005, Rouskas
`
`Declaration at 16, ¶40.
`
`Fig. 10 of Tanigawa shows an embodiment for a method for text chatting
`
`among a group of users. Exhibit 2005, Rouskas Declaration at 16, ¶41. Typically,
`
`chatting starts with terminal 7-2 requesting a buddy list from the IM server. Id.
`
`After getting the buddy list from the IM server, terminal 7-2 requests the creation
`
`of a conference room. Id. In Fig. 10 terminal 7-2 sends a request to open a
`
`conference room to the IM server. Exhibit 1010, Tanigawa at Fig. 10 and [122]-
`
`
`
`5
`
`
`
`[130]; Exhibit 2005, Rouskas Declaration at 16, ¶41. The IM server opens the
`
`conference room, assigns it an address, and returns the information to the terminal.
`
`Exhibit 2005, Rouskas Declaration at 16, ¶41. Then, the terminal sends a
`
`participation request to IM server that includes the list of buddies to be invited to
`
`the group chat. Id. The IM server then sends a call for participation (invitation) to
`
`each of the buddies; the invitation includes the nickname and address of the
`
`conference room. Id. Each buddy wishing to participate in the group chat responds
`
`to the IM server with an admission request; upon reception of an admission
`
`request, the IM server updates its information to allow the terminal of the buddy
`
`who sent the admission request to participate in the chat. Id. Finally, Tanigawa
`
`teaches that the IM server merges the text messages from all buddies to each buddy
`
`separately. Id. at 16-17, ¶41. As a result, all of Tanigawa’s client devices have
`
`contact information of the conference room, and the user who created the
`
`conference room has contact information of all the clients/communication devices.
`
`Exhibit 1010, Tanigawa at Fig. 10 and [130]-[139]; Exhibit 2005, Rouskas
`
`Declaration at 17, ¶41.
`
`
`
`Fig. 11 of Tanigawa is similar to Fig. 10 but shows an embodiment of a
`
`method for voice, rather than text, chatting among a group of users. Exhibit 2005,
`
`Rouskas Declaration at 17, ¶42. As in Fig. 10, the method starts with terminal 7-2
`
`requesting a buddy list from the IM server. Id. After receiving the buddy list,
`
`
`
`6
`
`
`
`terminal 7-2 sends a voice chat request to the AP server; the request includes the
`
`addresses of the buddies to be invited to the chat. Exhibit 1010, Tanigawa at Fig.
`
`11 and [145]-[146]; Exhibit 2005, Rouskas Declaration at 17, ¶42. The AP server
`
`assigns an address to the voice chat and instructs the MD server to carry out voice
`
`mixing for the voice chat. Exhibit 2005, Rouskas Declaration at 17, ¶42. The AP
`
`server then calls each of the buddies to invite them to participate in the voice chat
`
`and sends them the voice chat address. Id. Once a buddy responds to the call, they
`
`can participate in the chat by sending their voice packets to the voice chat address
`
`at the MD server. Id. The MD server mixes the voice packets from each
`
`participating buddy and distributes them to each buddy. Id. Therefore, Tanigawa
`
`teaches that all client devices have the voice chat address, and that the user who
`
`initiated the voice chat has the contact information of all client devices. Exhibit
`
`1010, Tanigawa at Fig. 11 and [147]-[154]; Exhibit 2005, Rouskas Declaration at
`
`17, ¶42.
`
`
`
`B. Hullfish (Exhibit 1011)
`
`Hullfish is directed to managing electronic message communications
`
`between two users. Exhibit 2005, Rouskas Declaration at 18, ¶43. The electronic
`
`message communications of Hullfish are an asynchronous form of communication
`
`in that the recipient does not have to be present and available at the time the
`
`message is sent by the sender. Exhibit, 1011, Hullfish; Exhibit 2005, Rouskas
`
`
`
`7
`
`
`
`Declaration at 18, ¶43. Hullfish teaches that an SMS message sent by a first user
`
`may be forwarded as an SMS message to a second user’s mobile phone/client
`
`device or as an IM message to a second user’s IM-enabled client communication
`
`device. Exhibit 2005, Rouskas Declaration at 18, ¶43. Hullfish also teaches a
`
`method for blocking SMS messages based on source information or other rules
`
`such as time and date. Id.
`
`
`
`
`
`C. A POSITA Would Not Be Motivated To Combine Tanigawa
`And Hullfish To Implement The Claimed Invention Of The ʼ038
`Patent
`
`Tanigawa’s synchronous system is for extending voice and text message
`
`communications from a one-to-one system to a group system. Exhibit 1010,
`
`Tanigawa at [0005]-[0006]; Exhibit 2005, Rouskas Declaration at 18, ¶44.
`
`Hullfish’s asynchronous electronic message forwarding method, on the other hand,
`
`is a one-to-one system for sending SMS messages using IM. Exhibit 1011,
`
`Hullfish; Exhibit 2005, Rouskas Declaration at 18, ¶44. A POSITA would not
`
`have been motivated to combine Hullfish with Tanigawa. Exhibit 2005, Rouskas
`
`Declaration at 18, ¶44.
`
`
`
`
`
`
`
`1.
`
`Tanigawa And Hullfish Are Incompatible
`
`A POSITA would not have combined Hullfish with Tanigawa because they
`
`are incompatible for at least the following reasons. Exhibit 2005, Rouskas
`
`Declaration at 19, ¶45.
`
`
`
`8
`
`
`
`First, Tanigawa’s system is synchronous in that users participating in a
`
`group (voice or text) chat are present and available at the same time. Exhibit 2005,
`
`Rouskas Declaration at 19, ¶46. Hullfish’s system, on the other hand, is
`
`asynchronous in that an SMS message can be sent without consulting the receiver
`
`or knowing whether the user is available. Id. By definition, Tanigawa’s group chat
`
`system may not be used in asynchronous mode, as users who are not present or
`
`available at the same time cannot possibly participate in a group chat. Id.
`
`Conversely, Hullfish’s asynchronous message forwarding system cannot be used in
`
`a synchronous group chat: when a user is participating, say, in a group SMS chat
`
`on his/her phone, and hence is present and available on SMS, there is no reason to
`
`use the Hullfish system to forward incoming SMS messages to the user’s IM
`
`account. Id.
`
`Second, despite Petitioner’s claim that a POSITA would be motivated to
`
`implement the blocking features of Hullfish in Tanigawa’s system (Petition at 33-
`
`34), Tanigawa expressly states that it is an object of the invention to “achieve
`
`group chat using multimedia” among buddies, i.e., users who have mutually agreed
`
`to engage in communication. Exhibit 1010, Tanigawa at [0008], [0010]; Exhibit
`
`2005, Rouskas Declaration at 19, ¶47. Tanigawa never teaches a user to block a
`
`buddy. Id. In fact, a POSITA would understand that if a user wishes to stop
`
`communicating with a buddy there would not be any need to use the Hullfish
`
`
`
`9
`
`
`
`blocking feature; the user may simply remove the buddy from his/her buddy list.
`
`Id. at 19-20, ¶47. Even if Tanigawa did teach that a user may decline an invitation
`
`to join a group chat, a POSITA would understand that just because a user who is in
`
`an important meeting may decline a call or group chat invitation from a buddy, it
`
`does not mean the user wishes to permanently stop receiving all messages from
`
`his/her buddies participating in the chat. Id. at 20, ¶47. Importantly, the fact that a
`
`Tanigawa user may decline the group chat invitation is possible only because the
`
`user is receiving messages from the buddy who sent the invitation. Id. Therefore,
`
`Tanigawa’s teachings are antithetical to the Hullfish blocking feature. Id.
`
`Third, in Tanigawa, users join a group chat by contacting a “conference
`
`room.” Exhibit 1010, Tanigawa at [0135]; Exhibit 2005, Rouskas Declaration at
`
`20, ¶48. Tanigawa also teaches that a conference room is created (opened) [0125]-
`
`[0129], users are sent the conference room address and invited to join [0131]-
`
`[0134], and they use the conference room address to request admission (join) to the
`
`conference room [0135]-[0138]. Exhibit 1010, Tanigawa at [0125]-[0129] and
`
`[0131]-[0138]; Exhibit 2005, Rouskas Declaration at 20, ¶48. Therefore, to use
`
`group chat/voice, participants communicate with/send messages to a conference
`
`room, not to a contact address of a recipient as in Hullfish’s one-to-one SMS
`
`communication method. Exhibit 2005, Rouskas Declaration at 20, ¶48.
`
`
`
`10
`
`
`
`
`
`Fourth, Tanigawa’s system requires an admission process for users to
`
`participate in a group chat: a conference room is created and users must be
`
`admitted to the conference room before actual data transmission. Exhibit 2005,
`
`Rouskas Declaration at 21, ¶49. In Hullfish, a user may send SMS messages at
`
`will and there is no requirement that the user first receive admission to engage in a
`
`chat. Exhibit 1010, Tanigawa at [0125]-[0128]; Exhibit 1011, Hullfish at Col. 3,
`
`line 39-Col. 4, line 6; Exhibit 2005, Rouskas Declaration at 21, ¶49.
`
`
`
`Fifth, in Tanigawa a signaling protocol is needed to establish a data session.
`
`Exhibit 2005, Rouskas Declaration at 21, ¶50. In Hullfish no signaling protocol is
`
`needed to send a message. Exhibit 1010, Tanigawa at [0131]-[0135]; Exhibit 1011,
`
`Hullfish at Col. 3, line 39-Col. 4, line 6; Exhibit 2005, Rouskas Declaration at 21,
`
`¶50.
`
`
`
`Sixth, in Tanigawa at the end of a data session, the session needs to be ended
`
`by another signaling exchange. Exhibit 2005, Rouskas Declaration at 21, ¶51. In
`
`Hullfish, signaling exchanges are not needed to end a communication. Exhibit
`
`1010, Tanigawa at Figs. 13-19 and [0158]-[0160]; Exhibit 1011, Hullfish at Col. 3,
`
`line 39-Col. 4, line 6; Exhibit 2005, Rouskas Declaration at 21, ¶51.
`
`
`
`For these reasons, a POSITA would not have been motivated to combine
`
`Hullfish with Tanigawa to achieve the ʼ038 patent’s claimed invention(s). Exhibit
`
`2005, Rouskas Declaration at 21, ¶52. The only motivation to combine Hullfish
`
`
`
`11
`
`
`
`with Tanigawa is Petitioner’s motivation to invalidate the challenged claims. This
`
`is classic impermissible hindsight.
`
`
`
`
`
`
`
`2.
`
`Petitioner’s Alleged Motivation To Combine Is Nonsense
`
`Petitioner asserts five reasons why a POSITA allegedly would combine
`
`Hullfish with Tanigawa. See Petition at 33-36. For the reasons set forth above a
`
`POSITA would not be motivated to combine Hullfish with Tanigawa. Exhibit
`
`2005, Rouskas Declaration at 21, ¶53. In addition to those reasons, Petitioner’s
`
`alleged reasons to combine the references are not valid. Exhibit 2005, Rouskas
`
`Declaration at 21-22, ¶53.
`
`First, a POSITA would not combine Hullfish’s blocking feature with
`
`Tanigawa. Exhibit 2005, Rouskas Declaration at 22, ¶54. Even if Tanigawa
`
`teaches declining a specific chat, declining a specific chat is only possible because
`
`the recipient is receiving communications (i.e., the chat invitation), which is not
`
`the same thing as blocking a user from any and all future communications. Id.
`
`Instead, Tanigawa’s teaching to merely decline a chat on a specific chat-by-chat
`
`basis teaches away from Hullfish’s teaching a wholesale block of all future
`
`communications between a sender and a recipient. Id.
`
`Second, Tanigawa teaches that a conference room is created (opened), users
`
`are sent the conference room address and invited to join, and the invitations to join
`
`the chat come not from individual users but from the IM server or AP server.
`
`
`
`12
`
`
`
`Exhibit 1010, Tanigawa at [0125]-[0133] and [0141]-[0151]; Exhibit 2005,
`
`Rouskas Declaration at 22, ¶55. Petitioner fails to evidence how Hullfish’s
`
`blocking feature could be implemented in Tanigawa when in Tanigawa’s system
`
`users join a group after receiving invitations from a server, not from another user.
`
`Id. Hullfish’s one-to-one blocking feature simply would not work with the way
`
`that Tanigawa teaches group chats. Id.
`
`Third, the combination does not represent using a “known technique to
`
`improve similar devices [and methods] in the same way” as Petitioner improperly
`
`suggests. Exhibit 2005, Rouskas Declaration at 22, ¶56. As shown above,
`
`Tanigawa and Hullfish are incompatible: Tanigawa teaches synchronous
`
`communications whereas Hullfish teaches asynchronous communications. Id. at
`
`22-23, ¶56. Moreover, Hullfish and Tanigawa are philosophically different in that
`
`Hullfish teaches a complete block of all communications between a sender and a
`
`recipient, but Tanigawa merely declines a specific communication, rather than all
`
`communications from a specific sender. Id. at 23, ¶56.
`
`Fourth, the combination does not yield a “predictable result.” Exhibit 2005,
`
`Rouskas Declaration at 23, ¶57. As stated, Petitioner fails to evidence how
`
`Hullfish’s wholesale blocking feature could be implemented in Tanigawa when in
`
`Tanigawa’s system, users receive chat invitations from a server, not a user. Id.
`
`Hullfish’s wholesale blocking feature would not work with the way that Tanigawa
`
`
`
`13
`
`
`
`teaches group chats. Id. Importantly, combining features of a synchronous
`
`communication with features of an asynchronous one is not straightforward, does
`
`not lead to predictable results, and may be impossible to accomplish. Id.
`
`Fifth, a POSITA would not have had a reasonable expectation of success in
`
`combining Hullfish’s blocking features with Tanigawa’s communications system.
`
`Exhibit 2005, Rouskas Declaration at 23, ¶58. For the reasons set forth above,
`
`Hullfish and Tanigawa are incompatible such that a POSITA would not expect any
`
`success. Id.
`
`In sum, Petitioner’s and Dr. Almeroth’s statements regarding an alleged
`
`“motivation to combine”, “known technique to improve similar devices [and
`
`methods] in the same way”, “predictable results”, “expectation of success”, are
`
`merely conclusory and fail to account for all the differences between Hullfish and
`
`Tanigawa and/or show how a POSITA actually would add Hullfish into
`
`Tanigawa’s system. Exhibit 2005, Rouskas Declaration at 23-24, ¶59.
`
`
`
`D.
`
`[7.0] “Network-Based Portal”1
`
`The Petition relies solely on Tanigawa for allegedly teaching a “network-
`
`based portal.” Petition at 37-43. Petitioner asserts that a network-based portal
`
`(“NBP”) is “a user interface that connects clients to a network (shown below in
`
`
`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.
`
`
`
`14
`
`
`
`Figure 12)”. Petition at 38-39; Exhibit 1003, Almeroth Declaration at ¶¶397-398.
`
`More specifically, Petitioner contends that “Tanigawa’s IP terminal contains a
`
`‘network-based portal,’ which is a user interface that connects clients to a network
`
`(shown below in Figure 12)”. Petition at 38-39; Exhibit 2005, Rouskas Declaration
`
`at 24, ¶60.
`
`Figure 1 of Tanigawa shows three IP terminals (7-1, 7-2, 7-3) acting as
`
`client communication devices:
`
`Exhibit 1010, Tanigawa at Fig. 1; Exhibit 2005, Rouskas Declaration at 24-25,
`
`
`
`¶61.
`
`Figure 12 of Tanigawa shows a user interface of a client, which resides on a
`
`client communication device connected to a network:
`
`
`
`15
`
`
`
`Exhibit 1010, Tanigawa at Fig. 12 and [0025]; Exhibit 2005, Rouskas Declaration
`
`
`
`at 25, ¶62.
`
`As a result, Tanigawa’s user interface is provided by and displayed in an IP
`
`terminal on the client-side of the network. Petition at 38-39; Exhibit 2005, Rouskas
`
`Declaration at 26, ¶63. Tanigawa’s IP terminals are client communication devices.
`
`Exhibit 1010, Tanigawa at [0162]-[0166]; Exhibit 2005, Rouskas Declaration at
`
`26, ¶63.
`
`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
`
`26, ¶64. “Portal is a term, generally synonymous with gateway, for a World Wide
`
`
`
`16
`
`
`
`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. Id. There are
`
`general portals and specialized or niche portals.” Id. Websites are hosted on web
`
`servers, not on communication devices such as Tanigawa’s client terminals 7-1, 7-
`
`2, 7-3. 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
`
`2005, Rouskas Declaration at 26-27, ¶65. 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 27, ¶65. Importantly, the ʼ038 specification does not define “portal”
`
`or “network-based portal” as a client communication device. Exhibit 2005,
`
`Rouskas Declaration at 27, ¶65.
`
`
`
`
`
`
`
`17
`
`
`
`
`
`
`
`
`
`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. Exhibit 2005, Rouskas Declaration at 27, ¶66.
`
`Specifically, a POSITA would understand that a portal allows “worldwide access”,
`
`whereas a client device is “associated with a user”. Id. 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”
`
`
`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
`
`from their communication device); and
`
`
`
`“for the second user to receive messages via an electronic
`(4)
`
`device associated with the second user”
`
`
`Id. at Col. 2, lines 25-29; Exhibit 2005, Rouskas Declaration at 27-28, ¶66.
`
`
`
`18
`
`
`
`In light of the common meaning of “portal,” and 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 28, ¶67. They are two distinct things.
`
`Id.
`
`
`
`
`
`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 “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
`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 28-29, ¶68; see also Exhibit 1001, ʼ038 Patent at Claim 38 ([38.7]
`
`and [38.8] and Claim 46 ([46.7] and [46.8]).
`
`
`
`
`
`
`
`19
`
`
`
`
`
`
`
`
`
`
`5.
`
`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”. Rouskas Declaration
`
`at 29, ¶69. 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, IP terminals, mobile phones, and other
`
`handheld devices are typically 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 them) from the public Internet. Exhibit 2005, Rouskas Declaration at
`
`29, ¶70. 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. at 29-30, ¶70. Dr.
`
`Rouskas’s testimony is corroborated by checking (1) that one cannot connect over
`
`
`
`20
`
`
`
`the Internet and access the devices of one’
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
