`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`MICROSOFT CORPORATION
`Petitioner
`
`v.
`
`UNILOC 2017 LLC
`Patent Owner
`
`
`
`
`IPR2020-00101
`U.S. PATENT NO. 8,495,359
`
`
`
`
`
`
`
`
`
`
`
`
`PATENT OWNER PRELIMINARY RESPONSE TO PETITION
`PURSUANT TO 37 C.F.R. § 42.107(a)
`
`

`

`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`I.
`
`Table of Contents
`
`INTRODUCTION .............................................................................................. 1
`
`II. The '359 Patent ................................................................................................... 1
`
`A. Effective Filing Date of the '359 Patent ........................................................ 1
`
`B. Overview of the '359 Patent .......................................................................... 2
`
`C. Prosecution History of the '359 Patent .......................................................... 8
`
`III. RELATED PROCEEDINGS ........................................................................... 10
`
`IV. LEVEL OF ORDINARY SKILL IN THE ART ............................................. 10
`
`V. PETITIONER DOES NOT PROVE A REASONABLE
`LIKELIHOOD OF UNPATENTABILITY FOR ANY
`CHALLENGED CLAIM ................................................................................. 11
`
`A. Claim Construction Standard ...................................................................... 11
`
`B. Overview of Olkin (Ex. 1003) and Kim (Ex. 1004). .................................. 12
`
`1. Overview of Olkin (Ex. 1003). ................................................................ 12
`
`2. Overview of Kim (Ex. 1004). .................................................................. 14
`
`C. No proof that sufficient motivation exists to combine the
`teachings of Olkin (Ex. 1003) with those of Kim (Ex. 1004). .................... 17
`
`D. The Petition does not establish that Olkin (Ex. 1003), Kim
`(Ex. 1004), or any combination thereof teaches or suggests “
`a gateway server configured to: … derive an encryption key
`from the device identifier for the first computing device;
`[and] send the encryption key to the second computing
`device” as recited in Claims 1 and 6. .......................................................... 21
`
`E. The Petition does not establish that Olkin (Ex. 1003), Kim
`(Ex. 1004), or any combination thereof teaches or suggests “a
`gateway server configured to: … confirm to the first
`computing device that the encryption key was requested by
`the second computing device and was sent to the second
`computing device” as recited in Claims 1 and 6. ........................................ 25
`
`F. The Petition does not establish that Olkin (Ex. 1003), Kim
`(Ex. 1004), or any combination thereof teaches or suggests
`“receiving at the recipient computing device the secured
`electronic communication, wherein the secured electronic
`
`ii
`
`

`

`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`communication is encrypted by a sending computing device
`with a first encryption key derived from the device identifier
`by the gateway server” of Claim 11. ........................................................... 30
`
`G. The Petition does not establish that Olkin (Ex. 1003), Kim
`(Ex. 1004), or any combination thereof teaches or suggests
`“querying, by the recipient computing device, the gateway
`server for confirmation that the sending computing device
`requested the first encryption key” of Claim 11. ........................................ 31
`
`H. The Petition fails to establish prima facie obviousness of the
`challenged dependent Claims 2-5, 7-10, and 12-15. ................................... 32
`
`VI. CONCLUSION ................................................................................................ 32
`
`iii
`
`

`

`
`I.
`
`INTRODUCTION
`
`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`Pursuant to 35 U.S.C. §313 and 37 C.F.R. §42.107(a), Uniloc 2017 LLC (the
`
`“Patent Owner” or “Uniloc”) submits its Preliminary Response to the Petition for
`
`Inter Partes Review (“Pet.” or “Petition”) of United States Patent No. 8,495,359
`
`(“the '359 Patent” or “Ex. 1001”) filed by Microsoft Corporation (“Petitioner”) in
`
`IPR2020-00101.
`
`In view of the reasons presented herein, the Petition should be denied in its
`
`entirety as failing to meet the threshold burden of proving there is a reasonable
`
`likelihood that at least one challenged claim is unpatentable.
`
`Uniloc addresses each ground and provides specific examples of how
`
`Petitioner failed to establish that it is more likely than not that it would prevail with
`
`respect to at least one of the challenged '359 Patent claims.
`
`Accordingly, Uniloc respectfully requests that the Board decline institution of
`
`trial on Claims 1-15 of the '359 Patent.
`
`
`II. THE '359 PATENT
`
`A. Effective Filing Date of the '359 Patent
`
`The '359 Patent is entitled “System and Method For Securing an Electronic
`
`Communication.” The '359 Patent issued on July 23, 2013, from U.S. Patent
`
`Application No. 12/792,249 filed on June 2, 2010, and claiming priority to
`
`provisional application 61/219,062, filed on June 22, 2009.
`
`
`
`1
`
`

`

`
`
`B. Overview of the '359 Patent
`
`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`The '359 Patent is directed to a system and method for securing an electronic
`
`communication sent to a first computing device from a second computing device
`
`using a gateway server. ('359 Patent, column 1, lines 33-37). Generally speaking,
`
`the system uses characteristics of a computing device to derive a device identifier
`
`(i.e., fingerprint) that uniquely identifies that computing device from among other
`
`computing devices on a network. (Id, column 3, line 36 – column 4, line 23). The
`
`device identifier is then stored on the computing device as well as on a server, which
`
`may be separate from the computing device and is accessible by other computing
`
`devices. (Id, column 3, lines 8-10, column 7, lines 20-23). When another computing
`
`device desires to send a message to the subject computing device, that other
`
`computing device may access an encryption key derived from the device identifier
`
`stored on the server, encrypt the message, and transmit the encrypted message to the
`
`subject computing device. (Id, column 6, line 61 – column 6, line 13). Due to the
`
`strong level of uniqueness provided by the device identifier, the subject computing
`
`device can use its internally stored device identifier to decrypt the message. (Id
`
`column 4, lines 6-23).
`
`Fig. 3B of the '359 Patent, which illustrates a process that may be used, by the
`
`gateway server, to store and distribute device identifiers that can be used to facilitate
`
`transmission of an encrypted message from a second computing device to a first
`
`computing device is reproduced herein below:
`
`2
`
`

`

`
`
`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`Here, the gateway server receives and stores the device identifiers and
`
`associated network addresses (e.g., e-mail addresses) of computing devices that may
`
`use the message encryption system at step 311. (Id, column 6, lines 61-64). At a
`
`later point in time, the gateway server receives a request from the second computing
`
`device that desires to send an encrypted message to a first computing device at step
`
`313. In response, the gateway server generates and stores an encryption key based
`
`upon a device identifier associated with the first computing device, and sends the
`
`3
`
`

`

`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`encryption key to the second computing device at steps 315 and 317. (Id, column 6,
`
`line 64 – column 7, line 12). As an added feature, the gateway server may also send
`
`a message directly to the first computing device (e.g., the receiving computer) that
`
`its encryption key was requested by another computing device. This feature is
`
`particularly advantageous in that security may be enhanced by confirming to the first
`
`computing device that the encrypted message, which it is to receive, was authorized
`
`by the gateway server. (Id, column 7, lines 13-17).
`
`Fig. 3C of the '359 Patent, which illustrates a process that may be used by the
`
`first computing device (e.g., the receiving computing device) to receive and decrypt
`
`the encrypted message is shown herein below:
`
`
`
`
`
`Here, at step 321, the first computing device receives the encrypted message
`
`from the second computing device. Thereafter, at step 323, the first computing
`
`device generates an encryption key using its own device identifier. (Id, column 7,
`
`lines 18-22). Because the encryption key generated by the first computing device
`
`uses the same device identifier as that used by the gateway server to generate its
`
`4
`
`

`

`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`encryption key, and because the device identifier is tightly coupled to the first
`
`computing device, there exists a high likelihood (probability) that the encryption key
`
`generated by the first computing device is the same as the encryption key generated
`
`by the gateway server. Thus, at step 323, the first computing device decrypts the
`
`encrypted message. (Id, column 7, lines 23-25).
`
`The message can be decrypted with a relatively high level of certainty and
`
`security, even when used in a publicly accessible network, where myriads of other
`
`computing devices exist and are not directly controlled by either user of the first
`
`computing device, second computing device, and/or gateway server. Furthermore,
`
`because the device identifier is generated using non-user-configurable parameters
`
`associated with the first computing device, spoofing of the device identifier by an
`
`illicit user (e.g., a hacker) would be difficult if not impossible due to the fact that the
`
`illicit user would need to have direct, physical access to the non-user-configurable
`
`parameters of the first computing device. (Id, column 4, line 6 – column 6, line 23).
`
`The '359 Patent issued with three independent claims, namely Claims 1, 6,
`
`and 11. The text of Claims 1, 6, and 11 are copied herein for the convenience of the
`
`Board:
`
`1. A system for securing an electronic communication, the
`
`system comprising:
`
`a gateway server configured to:
`
`receive and store a device identifier and a network address from
`
`a first computing device, wherein the device identifier is generated by
`
`the first computing device from a combination of user-configurable and
`
`5
`
`

`

`
`
`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`non-user-configurable parameters of the first computing device and
`
`uniquely identifies the first computing device, and wherein the network
`
`address is associated with the first computing device;
`
`receive from a second computing device the network address for
`
`the first computing device and an encryption key request;
`
`derive an encryption key from the device identifier for the first
`
`computing device;
`
`send the encryption key to the second computing device, and
`
`confirm to the first computing device that the encryption key was
`
`requested by the second computing device and was sent to the second
`
`computing device.
`
`
`
`6. A method of securing an electronic communication, the
`
`method comprising:
`
`receiving and storing at a gateway server store a device identifier
`
`and a network address from a first computing device, wherein the
`
`device identifier is generated by the first computing device from a
`
`combination
`
`of
`
`user-configurable
`
`and
`
`non-user-configurable
`
`parameters of the first computing device and uniquely identifies the
`
`first computing device, and wherein the network address is associated
`
`with the first computing device;
`
`receiving from a second computing device the network address
`
`for the first computing device and an encryption key request;
`
`deriving from the device identifier an encryption key for the first
`
`computing device;
`
`sending the encryption key to the second computing device; and
`
`6
`
`

`

`
`
`confirming to the first computing device that the encryption key
`
`was requested by the second computing device and was sent to the
`
`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`second computing device.
`
`
`
`11. A method of receiving a secured electronic communication,
`
`the method comprising:
`
`providing from a recipient computing device to a gateway server
`
`a network address and a device identifier for the recipient computing
`
`device, the device identifier generated by the recipient computing
`
`device from a combination of user-configurable and non-user-
`
`configurable parameters of the recipient computing device and
`
`uniquely identifying the recipient computing device;
`
`receiving at the recipient computing device the secured
`
`electronic
`
`communication, wherein
`
`the
`
`secured
`
`electronic
`
`communication is encrypted by a sending computing device with a first
`
`encryption key derived from the device identifier by the gateway
`
`server;
`
`querying, by the recipient computing device, the gateway server
`
`for confirmation that the sending computing device requested the first
`
`encryption key;
`
`generating at the recipient computing device a second encryption
`
`key from the device identifier; and
`
`decrypting at the recipient computing device the secured
`
`electronic communication using the second encryption key.
`
`
`
`7
`
`

`

`
`
`C.
`
`Prosecution History of the '359 Patent
`
`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`The '359 Patent issued on July 23, 2013 from U.S. Patent Application No.
`
`12/792,249, which was filed on June 2, 2010.
`
`On December 12, 2010, a Request for Peer Review was filed in this case under
`
`the Public Submission of Peer Reviewed Prior Art Pilot Program of the U.S. Patent
`
`and Trademark Office. (Ex. 1002, p. 36). Thereafter on April 12, 2011, a Third-
`
`Party Submission under the Peer Review Pilot Program was filed in which the article
`
`entitled “FC 4252 The Secure Shell, Authentication Protocol” was cited. In
`
`particular, the Third-Party Submission cited an excerpt of the article, which is
`
`reproduced herein below:
`
`Some sites wish to allow authentication based on the host that
`
`the user is coming from and the user name on the remote host.
`
`While this form of authentication is not suitable for high-
`
`security sites, it can be very convenient in many environments.
`
`This form of authentication is OPTIONAL. When used, special
`
`care SHOULD be taken to prevent a regular user from obtaining
`
`the private host key. The client requests this form of
`
`authentication by sending the following message. It is similar
`
`to
`
`the UNIX "rtwsts"
`
`arid "
`
`hosts.equiv" styles of authentication, except that the
`
`identity of the client host is checked more rigorously. This
`
`method works by having the client send a signature created with
`
`the private key of the client host, which the server checks with
`
`that host's public key. Once the client host's identity is
`
`8
`
`

`

`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`established, authorization (but no further authentication) is
`
`performed based on the user names on the server and the client,
`
`and the client host name. (Id, p. 364).
`
`On October 27, 2011, the Third-Party Submission was acknowledged by the
`
`examiner. (Id, p. 360). A first Non-Final Office Action was then issued on October
`
`28, 2011, in which all of the claims, namely Claims 1-20, were rejected under 35
`
`U.S.C. 103(a) as being unpatentable over U.S. Publication No. 2003/0070067 to
`
`Saito (“Saito”) in view of U.S. Patent Publication No. 2010/0034207 to McGrew
`
`(“McGrew”). (Id, pp. 326-352). A response to the Non-Final Office Action was
`
`submitted on April 30, 2012.
`
`Thereafter on July 11, 2012, a Final Office Action was filed that repeated the
`
`rejection made in the previous Non-Final Office Action. (Id, pp. 115-141). A
`
`response to the Final Office Action along with a Request For Continued Examination
`
`(RCE) was submitted on October 11, 2012 in which the independent claims were
`
`amended to recite “wherein the device identifier uniquely identifies the first
`
`computing device,” and patentability over Saito in view of McGrew based on this
`
`amendment was argued. (Id, pp. 94-113).
`
`On October 24, 2012, a second Non-Final Office Action was filed in which
`
`Examiner Rahman conceded the patentability of the claims over the Saito/McGrew
`
`combination, yet introduced another reference, namely U.S. Patent Publication No.
`
`US 2007/0005974 to Kudou (“Kudou”), to the existing Saito/McGrew combination.
`
`(Id, pp. 60-93). A response to the Non-Final Office Action was then submitted on
`
`January 25, 2013 in which the independent claims were amended to recite “a
`
`9
`
`

`

`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`gateway server configured to: … confirm to the first computing device that the
`
`encryption key was sent to the second computing device,” along with arguments in
`
`support of the amendment. (Id, pp. 40-57).
`
`On May 15, 2013, an Examiner-Initiated Interview was conducted in which it
`
`was agreed that patentability would be allowed if the limitations of dependent
`
`Claims 21 and 22 were incorporated into the independent claims. (Id, p. 5).
`
`Thereafter on July 3, 2013, an Issue Notification was filed, and the Patent
`
`Application issued on July 23, 2013.
`
`
`III. RELATED PROCEEDINGS
`
`The ’359 patent is involved in the following district court case: Uniloc 2017
`
`LLC v. Microsoft Corporation, 8-19-cv-00783 (C.D. Cal.).
`
`
`IV. LEVEL OF ORDINARY SKILL IN THE ART
`
`
`
`The Petition proposes that the plain and ordinary meaning to a person having
`
`ordinary skill in the art (PHOSITA) be applied to all claim terms, and contends that
`
`no claim terms require specific construction to resolve the unpatentability issues
`
`presented herein. (Petition, p. 9). Additionally, the Petition contends that in view
`
`of the Board’s expertise in patent law and technology, that the ’359 patent recites
`
`claims that do not require proposed constructions that differ from the claim language
`
`in order for the Board to compare the prior art to the claims. (Id). For purposes of
`
`this Preliminary Response only, Patent Owner does not dispute Petitioner’s
`
`10
`
`

`

`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`definition of a PHOSITA. Moreover, Patent Owner does not provide its own
`
`definition because, even applying the multiple and varying alternative definitions
`
`proposed by Petition, the Petition has not met its burden of showing that the cited
`
`references anticipate or render obvious, any of the disputed claims of the '359 Patent.
`
`
`
`V.
`
`PETITIONER DOES NOT PROVE A REASONABLE LIKELIHOOD
`OF UNPATENTABILITY FOR ANY CHALLENGED CLAIM
`
`Patent Owner demonstrates that Petitioner has failed to establish that it is more
`
`likely than not that it would prevail with respect to at least one of the challenged '359
`
`Patent claims. By not addressing additional arguments, Patent Owner in no way
`
`concedes that any argument by Petitioner is correct.
`
`Petitioner has the burden of proof to establish entitlement to relief. 37 C.F.R.
`
`§ 42.108(c). Petitioner “must specify where each element of the claim is found in
`
`the prior art patents or printed publications relied upon.” 37 C.F.R. § 42.104(b)(4).
`
`The Board should reject the Petition because Petitioner fails to meet this burden for
`
`any of the grounds.
`
`The Petition presents the following ground of purported obviousness:
`
`Ground
`
`References
`
`Challenged
`Claims
`
`1
`
`Olkin (Ex. 1003) in view of Kim (Ex. 1004)
`
`1-15
`
`
`
`A. Claim Construction Standard
`
`As of the filing date of the Petition, the standard for claim construction in Inter
`
`11
`
`

`

`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`Partes Review is the standard of “ordinary and customary meaning of such claim as
`
`understood by one of ordinary skill in the art and the prosecution history pertaining
`
`to the patent.” 37 C.F.R. §42.100(b) (effective November 13, 2018). For all claim
`
`terms, Uniloc requests that the Board adopt the ordinary and customary meaning of
`
`the claim term as understood by one of ordinary skill in the art.
`
`
`B. Overview of Olkin (Ex. 1003) and Kim (Ex. 1004).
`
`1. Overview of Olkin (Ex. 1003).
`
`Olkin is directed to a communication system for sending and receiving e-mail
`
`messages via transactions with a security server. (Olkin, column 8, lines 44-56). In
`
`particular, the system of Olkin provides a means for securely sending e-mail
`
`messages by authenticating the e-mail message transactions in a manner such that
`
`the transaction cannot be repudiated. (Id, column 5, lines 44-53). Fig. 1 of Olkin,
`
`which shows the basic stages (steps) of a process performed by the system of Olkin,
`
`is reproduced herein below:
`
`12
`
`

`

`
`
`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`Here, the system of Olkin generally includes a sender 12 (first user) who
`
`sends, via a sending unit 18 (sending computing device), a secure e-mail message
`
`14 to one or more receivers 16 (receiving users) via one or more receiving units 20
`
`(receiving computing devices). (Id, column 6, lines 44-47). An e-mail server 22 is
`
`included for conveying the e-mail message 14 from the sending unit 18 to the
`
`receiving units 20, while a security server 24 is included for managing the secure e-
`
`mail transaction as will be described in detail herein below. (Id, column 8, lines 51-
`
`56).
`
`Referring now to the process shown in Fig. 1, a user 12 decides to send a
`
`secure e-mail message 14 at stage 32. (Id, column 9, lines 33-43). At stage 34, the
`
`system sends a transmission request to the security server 24. (Id, column 9, lines
`
`37-44). That is, the system does not send the e-mail message directly to the receiving
`
`13
`
`

`

`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`units 20; rather, it initially sends a request to the security server 24 that manages the
`
`e-mail transaction. (Id). Thereafter at stage 36, the security server 24 determines
`
`whether the receivers 16 are registered (e.g., if the receiving users have an active
`
`account with the security server). (Id, column 9, lines 52-53). If not, the security
`
`server 24 issues a solicitation to any un-registered user to do so in order that they
`
`can decrypt the forthcoming encrypted e-mail message. At stage 38, the sending
`
`unit 18 then encrypts the subject and/or body portion of a standard e-mail message
`
`14 using a message key provided by the security server 24, and transmits the
`
`encrypted e-mail message via the e-mail server 22. (Id, column 10, lines 12-24).
`
`At stage 40, the encrypted e-mail message 14 arrives at the inbox of each
`
`receiving unit 20. Thereafter at stage 42, a software module 14 installed each
`
`receiving unit 20 identifies that the e-mail message has been encrypted and therefore,
`
`communicates with the security server 24 to obtain the same message key that was
`
`sent to the sending unit 18. (Id, column 10, lines 33-43). Thus, each receiving unit
`
`20 is able to decrypt the encrypted message because the same message key that was
`
`sent to the sending unit 18 for encrypting the e-mail message is also sent to each
`
`receiving unit 20. (Id).
`
`
`
`2. Overview of Kim (Ex. 1004).
`
`Kim is directed to a method and apparatus for sharing secret information
`
`between devices in a home network. (Kim, paragraph [0011], Abstract). That is,
`
`the teachings of Kim are directed to use in a home network. Additionally, Kim
`
`14
`
`

`

`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`describes several protocol standards that have been developed for use in a home
`
`network setting. (Kim, p. 5). Kim provides examples of how the method and
`
`apparatus may be used, but these are all in the context of a home environment. One
`
`particular example provided by Kim is a home shopping service that is provided only
`
`through a remote user interface (RUI) supporting settop box (a home-based item),
`
`and a RUI supporting television (TV) (another home-based item). (Kim, p. 7). Kim
`
`further describes how the communication between these two home-based items may
`
`be secured using the teachings of the method and apparatus as taught within. (Id).
`
`Fig. 4 of Kim, which illustrates several operations that are performed for the method
`
`and apparatus of sharing secret information, is reproduced herein below:
`
`
`
`15
`
`

`

`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`As shown, the method and apparatus of Kim involves a first device and a
`
`second device. Kim further teaches that the first device may be a RUI server (e.g.,
`
`a settop box), while the second device may be a RUI client (e.g., a RUI supporting
`
`TV). (Kim, p. 30). The sharing of secret information between the first and second
`
`device is facilitated by the generation of keys using seed information and/or inputted
`
`personal information according to an identity based encryption (IBE) scheme, or
`
`universal plug-n-play (UPnP) scheme. (Id, paragraphs [0023] and [0029]). Kim
`
`does not discuss the IBE scheme in detail, but refers to another document about the
`
`IBE scheme. (Id, p. 25).
`
`The process is initiated by sending seed information by the first device to the
`
`second device at operation 401. Kim teaches that the seed information collectively
`
`refers to information that the second device uses to generate the public key of the
`
`first device. (Kim, p. 28). Kim further teaches that the seed information may include
`
`the master key of the first device, IBE parameters, identification information of the
`
`first device, and the like used in the IBE scheme. (Id). At operation 403, the second
`
`device calculates a public key based on the received seed information along with
`
`user's personal information obtained at operation 402. Kim teaches that the user's
`
`personal information is a password inputted by the user (e.g., credential). (Kim, p.
`
`33).
`
`Thereafter, at operation 405, secret information is encrypted using the
`
`calculated public key, and transmitted to the first device at operation 406. The first
`
`device may then calculate its secret key based on the seed information that was sent
`
`16
`
`

`

`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`to the second device at operation 401, and on the user's personal information that
`
`was also inputted by the user at operation 402. Because the seed information and
`
`user's personal information used to calculate the keys at operations 403 and 408 are
`
`the same, the encrypted secret information may be successfully decrypted at
`
`operation 409.
`
`
`
`C. No proof that sufficient motivation exists to combine the teachings
`of Olkin (Ex. 1003) with those of Kim (Ex. 1004).
`
`The Petition fails to establish prima facie obviousness of Claims 1-15 over
`
`Olkin in view of Kim. In particular, the Patent Owner respectfully submits that there
`
`exists no motivation to combine Olkin and Kim because, among other things, the
`
`system taught by Kim, while being ideally suited for use in a home network
`
`environment where most or all nodes of the network are managed by one or a few
`
`individuals, would not function in an environment as taught by Olkin where e-mail
`
`messaging is used. In addition, combining the teachings of Olkin with those of Kim
`
`would render the system of Olkin inoperable for its intended purpose. In re Gordon,
`
`733 F.2d 900, 221 USPQ 1125 (Fed. Cir. 1984) (holding that if proposed
`
`modification would render the prior art invention being modified unsatisfactory for
`
`its intended purpose, then there is no suggestion or motivation to make the proposed
`
`modification); Plas–Pak Indus., Inc. v. Sulzer Mixpac AG, 600 Fed. Appx. 755, 759
`
`(Fed. Cir 2015) (combinations that change the basic principles under which the prior
`
`art was designed to operate may fail to support a conclusion of obviousness).
`
`As discussed previously (supra), Olkin is directed to a system and method for
`
`17
`
`

`

`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`securely sending and receiving e-mail messages using a security server. But one of
`
`ordinary skill in the art would not have been motivated to modify Olkin’s security
`
`server to derive an encryption key from a device identifier associated with the first
`
`computing device because, among other things, the device identifiers taught by Kim,
`
`such as those conforming to the IBE or UPnP standards, would not possess sufficient
`
`uniqueness or tamper resistance to be deployed in a publicly accessible network
`
`environment (e.g., the Internet) where e-mail messaging is used. (Olkin, column 1,
`
`lines 23-32, and column 1, line 64 – column 2, line 5). For example, the '359 Patent
`
`specifically teaches that the device identifier has a very high probability of being
`
`unique to the target computing device. ('359 Patent, column 4, lines 13-23). The
`
`'359 Patent also teaches that the device identifier has a very high probability of
`
`remaining unchanged during normal operation. (Id). Thus, the device identifier,
`
`which would be used by two separate entities (e.g., the gateway server and first
`
`computing device of the '359 Patent, or the security server 24 and receiving unit 20
`
`of Olkin) to derive a similar encryption key would necessarily need to have a very
`
`high degree of uniqueness and permanence, particularly when used in a publicly
`
`accessible network environment, such as one where e-mail communications are
`
`conducted.
`
`One of ordinary skill in the art considering Olkin would not have considered
`
`the system of Kim to be a viable option for modification because the protocols used
`
`to generate the device identifiers (e.g., the IBE protocol and the UPnP protocol)
`
`taught by Kim would not provide sufficient uniqueness when used in a publicly
`
`18
`
`

`

`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`accessible network environment. For example, Kim teaches that, in the IBE Scheme,
`
`a message transmitter can transmit a message encrypted with arbitrary information
`
`representing an identity of a message receiver. For example, the transmitter can use
`
`an e-mail address of the receiver as a public key. (Kim, paragraph [0024]). But it
`
`has been well known to any PHOSITA that mere 'arbitrary information' and/or a
`
`user-provided e-mail address is grossly insufficient for uniquely identifying or even
`
`providing any suitable level of permanence of one computing device from among
`
`the myriad of other computing devices that may communicate over a publicly
`
`accessible network environment, which is the de-facto communications medium for
`
`e-mail messaging as taught by Olkin.
`
`Regarding the UPnP protocol, although suited for use in a small network
`
`environment, such as one often found in a home, it is known to be ill-suited for use
`
`in a large network environment, such as in a publicly accessible network
`
`environment. In particular, UPnP is generally regarded as unsuitable for deployment
`
`in business settings for reasons of economy, complexity, and consistency: the
`
`multicast foundation makes it chatty, consuming too many network resources on
`
`networks with a large population of devices; the simplified access controls don't map
`
`well to complex environments; and it does not provide a uniform configuration
`
`syntax such as the CLI environments of other configuration protocols, such as Cisco
`
`IOS or JUNOS. (http://en.wikipedia.org/wiki/upnp). Thus, Olkin would not have
`
`looked to the UPnP configuration protocol as a means of deriving encryption keys
`
`due to, among other things, its inherent problems with being used in a publicly
`
`19
`
`

`

`IPR2020-00101
`U.S. Patent No. 8,495,359
`
`
`
`accessible network where a large population of computing devices often co-exist.
`
`Indeed, Kim specifically teaches a system that is particularly well suited for
`
`use in home network devices. (Kim, paragraph [0023]). But it is well known to any
`
`PHOSITA that the challenges of maintaining security in a home network
`
`environment are entirely different than those posed in a publicly accessible network
`
`environment. For example, those devices implemented in a home network
`
`environment are often commonly owned and managed by only one or several
`
`individuals. Moreover, even if managed by multiple individuals in the home, those
`
`individuals would most likely share common interests and thus, would rarely have
`
`reason to maliciously attack (e.g., hack) another device configured within the home
`
`network environment. This is clearly not the case when dealing with computing
`
`devices configured in a publicly accessible network, which is the de-facto medium
`
`used for e-mail communications as t