throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`SAMSUNG ELECTRONICS CO., LTD.,
`SAMSUNG ELECTRONICS AMERICA, INC., AND APPLE INC.,
`
`Petitioner
`
`v.
`
`IXI IP, LLC
`
`Patent Owner
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2015-01444
`Patent 7,039,033
`
`
`
`
`
`
`
`
`
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`
`
`TABLE OF CONTENTS
`
`Introduction ......................................................................................................... 1
`
`I.
`
`II. Marchand’s disclosure of the claimed “service repository software
`
`component”–Location of Marchand’s LUS .................................................... 1
`
`A.
`
`IXI’s sub-piconet theory fails ........................................................................ 1
`
`A.1. IXI’s sub-piconet theory is factually unsupported. ....................................... 2
`
`A.2. IXI’s sub-piconet theory is inconsistent with express disclosure in
`
`Marchand. ............................................................................................................... 3
`
`A.3. IXI’s sub-piconet theory is inconsistent with disclosure within the ’033
`
`Patent. ..................................................................................................................... 5
`
`B.
`
`IXI’s contention that the LUS must be on a master device is unsupported
`
`and incorrect. .......................................................................................................... 6
`
`C. Marchand’s LUS is implemented in the GMP 33. ........................................ 8
`
`C1. A POSITA would have found it obvious to implement the LUS on the GMP
`
`33. 8
`
`C2. Marchand describes the LUS on its GMP 33. ............................................. 10
`
`C3. Marchand’s FIG. 4 does not limit the location of the LUS to laptop 31. ... 11
`
`III. Marchand discloses a network address translator software component that is
`
`included in GMP 33. ...................................................................................... 13
`i
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`IV. Marchand, Nurmann, and Vilander disclose “a first Internet Protocol (‘IP’)
`
`address provided to the first wireless device from the cellular network and a
`
`second address for the second wireless device provided by the first wireless
`
`device.” .......................................................................................................... 15
`
`V. Marchand discloses a thin terminal. .................................................................. 18
`
`VI. Marchand, Nurmann, Vilander, and RFC 2543 disclose a DNS Software
`
`Component. .................................................................................................... 20
`
`VII. Marchand, Nurmann, Vilander, and Larsson disclose the claimed security
`
`software component and virtual private network. ......................................... 22
`
`VIII. Marchand, Nurmann, Vilander, and JINI Spec. disclose a plug and play
`
`software component. ...................................................................................... 23
`
`IX. Dr. Kiaei’s Testimony ....................................................................................... 24
`
`
`
`
`
`
`
`ii
`
`

`
`EXHIBIT-1001
`
`EXHIBIT-1002
`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`
`EXHIBIT LIST
`U.S. Patent No. 7,039,033 to Haller et al. (“’033 Patent”)
`
`S. M. Bellovin et al., Network Firewalls, Network
`Firewalls, IEEE Communications Magazine, Vol. 32,
`Issue 9, pp. 50-57, 1999 (“Bellovin”)
`
`EXHIBIT-1003
`
`Declaration of Dr. Sayfe Kiaei
`
`EXHIBIT-1004
`
`Curriculum Vitae of Dr. Sayfe Kiaei
`
`EXHIBIT-1005
`
`PCT. Publication No. WO 01/76154 A2 to Marchand
`(“Marchand PCT”)
`
`EXHIBIT-1006
`
`U.S. Patent Application No. 09/541,529 to Marchand
`(“Marchand Priority”)
`
`EXHIBIT-1007
`
`Handley et al., Request For Comments 2543 SIP: Session
`Initiation Protocol, The Internet Society, March, 1999
`(“RFC 2543”)
`
`EXHIBIT-1008
`
`U.S. Patent No. 6,836,474 to Larsson (“Larsson”)
`
`EXHIBIT-1009
`
`K. Arnold et al., The JINITM Specification, Addison-
`Wesley, June 1, 1999 (“JINI Spec.”)
`
`EXHIBIT-1010
`
`U.S. Patent No. 6,560,642 to Nurmann (“Nurmann”)
`
`EXHIBIT-1011
`
`U.S. Patent No. 6,771,635 to Vilander (“Vilander”)
`
`EXHIBIT-1012
`
`Claim Chart from IXI’s Infringement Contentions of U.S.
`Patent No. 7,039,033 in 14-cv-4428 (April 9, 2015)
`
`EXHIBIT-1013
`
`Claim Chart from IXI’s Infringement Contentions of U.S.
`Patent No. 7,039,033 in 14-cv-4355 (March 27, 2015)
`
`EXHIBIT-1014
`
`R. Droms, Request for Comments 2131 Dynamic Host
`Configuration Protocol, The Internet Society, March,
`1997 (“RFC 2131”)
`
`
`
`iii
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`
`EXHIBIT-1015
`
`U.S. Patent No. 6,622,017 to Hoffman (“Hoffman”)
`
`EXHIBIT-1016
`
`J. Newmarch, A Programmer’s Guide to Jini Technology,
`Apress, 2000 (“Newmarch”)
`
`EXHIBIT-1017
`
`U.S. Patent No. 5,963,908 to Chadha (“Chadha”)
`
`EXHIBIT-1018
`
`EXHIBIT-1019
`
`Deposition Transcript of Dr. Mandayam, IPR2015-01443,
`May 18, 2016
`
`Deposition Transcript of Dr. Mandayam, IPR2015-01444,
`May 19, 2016
`
`
`
`
`
`iv
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`
`I.
`
`Introduction
`In its Patent Owner Response (“POR”), Patent Owner (“IXI”) advanced
`
`arguments related to claims 1, 5-7, 12, and 23. These arguments fail because they
`
`lack support and mischaracterize the applied references. For the other instituted
`
`claims, IXI relies upon these same arguments without additional analysis. See
`
`POR, 52-57. Thus, while applicable to all claims, the following responses address
`
`IXI’s arguments on claims 1, 5-7, 12, and 23.
`
`II. Marchand’s disclosure of the claimed “service repository software
`component”–Location of Marchand’s LUS
`
`
`IXI argues that Marchand’s JINI Look Up Service (LUS) does not
`
`correspond to the service repository software component recited in the ’033 Patent
`
`claims because Marchand’s JINI LUS is purportedly not located on Marchand’s
`
`gateway mobile phone (GMP) 33. POR, 26-37; Ex. 2301, ¶¶ 30, 31, 52-63. IXI’s
`
`argument is deficient because it relies on a sub-piconet theory that is devoid of
`
`support in Marchand and directly contradicts explicit and implicit disclosure in
`
`Marchand.
`
`A.
`
`IXI’s sub-piconet theory fails
`
`IXI advances an interpretation of Marchand that requires creation of
`
`undisclosed sub-piconets for devices to share services within Marchand’s disclosed
`
`piconet. POR, 14; Ex. 2301, 17. IXI illustrates its sub-piconet theory using FIG. 4
`
`of Dr. Mandayam’s declaration. Id. As shown below, IXI’s Fig. 4 labels laptop 31
`
`as the master device MA of piconet 30 (blue circle A), and a slave device SB in a
`
`
`
`1
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`contrived sub-piconet (red circle B), and labels GMP 33 as the master device MB
`
`of sub-piconet B and a slave device SA in piconet A. POR, 14; Ex. 2301, ¶¶ 30, 31.
`
`
`
`
`
`
`
`FIG. 4 from IXI Expert’s
`Declaration
`
`Marchand’s original FIG. 3
`
`
`IXI’s sub-piconet theory, however, is without support and reflects a flawed
`
`understanding of Marchand.
`
`A.1. IXI’s sub-piconet theory is factually unsupported.
`
`IXI’s FIG. 4 is a modified version of Marchand’s original FIG. 3 and
`
`suggests the addition of a sub-piconet B. POR, 14; Ex. 2301, 17 (FIG. 4); Ex.
`
`1005, FIG. 3. However, Marchand provides no support for IXI’s master-slave
`
`designations of laptop 31 and GMP 33, much less the inclusion of sub-piconet B as
`
`illustrated in IXI’s FIG. 4. In fact, Marchand neither mentions the term sub-
`
`piconet, nor describes coupling devices as suggested by IXI.
`
`
`
`2
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`Moreover, IXI provides no evidence to support its contrived sub-piconet
`
`theory, other than expert testimony, which failed to withstand scrutiny under cross
`
`examination, and which should be given little weight. POR, 14, 30. Particularly,
`
`when IXI’s expert, Dr. Mandayam, was asked about his sub-piconet testimony at
`
`deposition, he could not point to any portion of Marchand that discloses a sub-
`
`piconet. Ex. 1018, 112:22-113:9; 129:15-22. Ex. 1019, 7:10-9:21. Rather, Dr.
`
`Mandayam conceded that FIG. 4 shown above does not appear in Marchand. Ex.
`
`1018, 110:7-113:1.
`
`Accordingly, IXI’s sub-piconet theory is unsupported and presents an
`
`inaccurate view of Marchand’s operations.
`
`A.2. IXI’s sub-piconet theory is inconsistent with express
`disclosure in Marchand.
`
`As mentioned, Marchand lacks explicit disclosure of sub-piconets.
`
`Marchand is explicit in disclosure that its GMP 33 is a master. Specifically,
`
`Marchand discloses an example in which “[t]he mobile phone is the master unit,
`
`and the PDA and laptop are slaves to the mobile phone” (emphasis added). Ex.
`
`1005, 3:22-27. When describing piconet 30, Marchand consistently describes the
`
`GMP 33 as a “master” (see, e.g., Ex. 1005, 7:26-31; 8:1-3).
`
`Yet, as illustrated below, contrary to the consistent disclosure in Marchand,
`
`IXI’s sub-piconet theory requires the GMP 33 to be a slave in Marchand’s piconet.
`
`
`
`3
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`
`
`Accordingly, IXI’s sub-piconet theory is inconsistent with Marchand’s
`
`teaching of GMP 33 operating as master of the piconet 30. Ex. 1005, 7:7-7:11;
`
`7:26-8:3.
`
`Further, Marchand never mentions that laptop 31 is a master–another
`
`premise of IXI’s sub-piconet theory. On the contrary, Marchand explicitly
`
`describes laptop 31 as a slave of piconet 30. Ex. 1005, 3:26; 7:26-31. Thus, IXI’s
`
`sub-piconet theory requires disregard of Marchand’s explicit disclosure of the
`
`mobile phone as the “master” within piconet 30 (depicted as A in IXI’s rendering),
`
`and introduces two contrived elements lacking support in Marchand–sub-piconets
`
`
`4
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`and the laptop 31 being the “master.” This interpretation is not supported by
`
`Marchand.
`
`A.3. IXI’s sub-piconet theory is inconsistent with disclosure
`within the ’033 Patent.
`
`Similar to Marchand, the ’033 Patent describes a “wireless gateway device”
`
`that communicates with “terminals” using “BluetoothTM technology” and provides
`
`the “terminals” with a gateway to a “cellular network.” Ex. 1001, 1:41-59; 2:3-35;
`
`3:14-59. As shown in the annotated version of FIG. 8(b) below, the gateway device
`
`(805) in the ’033 Patent communicates directly with terminals (807-809) in a
`
`Bluetooth piconet and uses a telephony service to provide terminals with access to
`
`a cellular network.
`
`’033 Patent FIG. 8(b) (excerpt, annotated)
`5
`
`
`
`
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`With direct Bluetooth connections to each of the terminals (807-809), the
`
`gateway device (805) serves as master of the Bluetooth piconet. Despite this
`
`configuration, IXI contends that Marchand’s similar gateway device (i.e., GMP 33)
`
`cannot serve as master of its Bluetooth piconet. To justify this inconsistent
`
`position, IXI contends that Marchand’s GMP 33 cannot be the master because
`
`master status must be reserved for establishment of a sub-piconet needed to
`
`connect a terminal to the cellular network. IXI, however, offers no explanation for
`
`why the gateway device in Marchand needs a sub-piconet to connect a Bluetooth
`
`terminal to the cellular network—a contention that is particularly unsupportable
`
`when considering that the comparable gateway device in the ’033 Patent does not
`
`need a sub-piconet to connect a Bluetooth device to its cellular network. As such,
`
`the ’033 Patent confirms that Marchand’s GMP 33 can be the master of its piconet
`
`and that IXI’s sub-piconet is incorrect.
`
`IXI’s contention that the LUS must be on a master device is
`B.
`unsupported and incorrect.
`
`IXI also contends that a LUS must be located on a master device of a
`
`Bluetooth piconet. POR, 28, 34. Like its sub-piconet theory, IXI offers no support
`
`for this contention, other than uncorroborated testimony. POR, 28, 34; Ex. 2301, ¶
`
`55.
`
`In contrast to IXI’s assertions, Marchand describes laptop 31 as a slave that,
`
`at least in some implementations, also has a LUS. Ex. 1005, 3:22-27; 7:26-31; 8:1-
`
`
`
`6
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`3; FIG. 4. Marchand therefore directly discloses that a LUS may be implemented in
`
`a slave device. Further, record evidence shows that a network may have more than
`
`one LUS. Ex. 1016, 23. Network LUS redundancy necessarily indicates that even
`
`if a LUS were included in a piconet master device, such as Marchand’s GMP 33, a
`
`LUS may also be included in a slave device, such as Marchand’s laptop 31.
`
`Record evidence also shows that implementing multiple JINI LUSs is
`
`particularly useful in ad-hoc networks, such as Marchand’s, since the network
`
`topology is variable and the network 30 is heterogeneous with devices expected to
`
`join and leave at various times. Ex. 1016, 23, 24. With this background, the benefit
`
`of multiple LUSs in Marchand’s ad-hoc network 30 is immediately apparent. For
`
`example, if a single device (e.g., laptop 31) included a LUS, service provision for
`
`remaining network devices (e.g., printer 32 and GMP 33) would fail upon the
`
`departure of the single device due to the absence of a network LUS.
`
`Advantageously though, in implementations having multiple network LUSs,
`
`service provision in the network would remain operable should a device (e.g.,
`
`laptop 31, printer 32) with a LUS leave the network because a LUS would still be
`
`available on another device (e.g., GMP 33). Id. Thus, IXI’s requirement that a JINI
`
`LUS must be located on or be limited to a master device is incorrect, and IXI’s
`
`sub-piconet theory does not compel a result in which the GMP 33 is left without a
`
`LUS.
`
`
`
`
`
`7
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`C. Marchand’s LUS is implemented in the GMP 33.
`
`Contrary to IXI’s contentions that a LUS is not implemented in the GMP 33,
`
`a POSITA would have understood Marchand as describing a LUS being located in
`
`the GMP 33. POR, 19, 36.
`
`C1. A POSITA would have found it obvious to implement the
`LUS on the GMP 33.
`
`IXI contends that it would not have been obvious to locate the JINI LUS on
`
`GMP 33, as it offers arguments that the transitory capabilities, memory, processing
`
`power, and battery life of a GMP 33 make the GMP 33 undesirable for the LUS.
`
`POR, 36. However, IXI’s own discussion of Marchand indicates otherwise.
`
`IXI argues that “Marchand makes clear that the use of a Bluetooth piconet
`
`extended into an Internet Protocol (IP) wireless LAN implementing JINI/Java
`
`technology is essential to the operation of the network and devices of Marchand.”
`
`POR, 16 (emphasis added). Yet, as illustrated by the depicted scenarios below,
`
`GMP 33 is the device that enables this “essential” functionality. Without the GMP
`
`33, as shown in Scenario 4, no network 30 device can access IP network 35.
`
`Thus, according to IXI’s admissions, the GMP 33 is the most logical choice
`
`for implementing the LUS because it is the only location that ensures the GMP 33
`
`can offer its “essential” functionality when the GMP 33 is present on the network.
`
`See Ex. 1003, ¶ 40. A POSITA would therefore have found it obvious to
`
`implement a LUS on the GMP 33. Petition, 25-29.
`
`
`
`8
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`
`
`
`
`
`
`
`
`
`
`
`9
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`
`
`
`C2. Marchand describes the LUS on its GMP 33.
`
`As discussed in the Petition, a POSITA would understand that Marchand’s
`
`API corresponds to a JINI proxy object that is stored on a LUS. Petition, 26-29,
`
`39-42; Ex. 1003, ¶ 38. Because, in JINI, proxy objects are downloaded from a LUS
`
`and Marchand describes the API/proxy object as being downloaded from the GMP
`
`33, a POSITA would have understood Marchand as describing an implementation
`
`in which the JINI LUS is located on the GMP 33. Ex. 1003, ¶ 38.
`
`IXI contends that Marchand’s JINI call control API is not a proxy object, but
`
`fails to provide a sufficient explanation. For instance, IXI describes the proxy
`
`object as being “used to identify the service(s) the joining device offers and to
`
`establish an interface with that service.” POR, 19. During deposition, Dr.
`
`Mandayam conceded that a JINI proxy object is “specifically implemented as an
`
`API.” Ex. 1019, 55:5-6. Yet, in describing the call control API, Dr. Mandayam
`
`changed his position—testifying that the call control proxy object in Marchand is
`
`
`
`10
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`not an API, but merely “a data encapsulation that gives instructions on how you
`
`would actually use this call control service, and specifically … asks the device to
`
`behave as a slave to the master.” Ex. 1019, 57:6-24. IXI offers no evidence
`
`supporting Dr. Mandayam’s position that Marchand’s proxy object is merely a data
`
`encapsulation that “makes [a service seeking] device on the Bluetooth network
`
`behave as a slave.” Ex. 1019, 55:5-10; 57:22-24. Marchand provides no description
`
`of a data encapsulation, much less a data encapsulation that makes a device on the
`
`Bluetooth network behave as a slave.
`
`C3. Marchand’s FIG. 4 does not limit the location of the LUS to
`laptop 31.
`
`IXI presses for a narrow interpretation of Marchand’s Fig. 4, suggesting that
`
`only laptop 31 can include a LUS. POR, 53, 54. However, FIG. 4 does not limit the
`
`location of the LUS to laptop 31.
`
`FIG. 4 illustrates that, in some implementations, laptop 31 is one of the
`
`network 30 devices that can include a LUS. FIG. 4, however, does nothing to
`
`preclude implementations in which other devices in Marchand’s Bluetooth network
`
`30 include a LUS.
`
`IXI and Dr. Mandayam concede the same. For example, during deposition,
`
`Dr. Mandayam stated that any network device intrinsic to Marchand’s piconet 30
`
`could include a LUS and could be a master device. Ex. 1019, 16:10-24; 33:5-15.
`
`IXI also alludes to a device other than laptop 31 being the master device when
`
`
`
`11
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`stating “[t]his API is sent to the laptop through the master device” (emphasis
`
`added). POR, 31. IXI’s statements indicate that the location of a LUS is not limited
`
`by the implementation in Marchand’s FIG. 4, and that other devices in Marchand’s
`
`Bluetooth network 30 can include a LUS and be a master of the piconet.
`
`Additionally, FIG. 4 does not disclose all elements that are included on
`
`laptop 31 and GMP 33. For example, IXI concedes that each device in Marchand’s
`
`Bluetooth network 30 includes the protocol stack illustrated in Marchand’s FIG. 2.
`
`POR, 17. FIG. 4 illustrates that laptop 31 includes the protocol stack, but does not
`
`illustrate the protocol stack that is part of the GMP 33. Thus, FIG. 4’s illustration
`
`of a component (e.g., LUS) on the laptop 31 does not indicate that such a
`
`component (e.g., LUS) is lacking on the GMP 33.
`
`As discussed in Section II(B), record evidence confirms that having multiple
`
`LUSs in ad-hoc networks is desirable. Ex. 1016, 23. Because FIG. 4 does not
`
`comprehensively list all elements of the GMP 33 and Marchand’s description
`
`confirms location of the LUS on the GMP 33, FIG. 4 does not preclude the GMP
`
`33 from having a LUS or preclude an implementation in which each of the laptop
`
`31 and GMP 33 have a LUS (see Scenarios 1 and 2 in Section II(C)(C1)). Thus,
`
`Marchand’s FIG. 4 does not require the laptop 31 to be the master of the Bluetooth
`
`network 30 or to be the only device on which a LUS is implemented.
`
`12
`
`
`
`
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`III. Marchand discloses a network address translator software component
`that is included in GMP 33.
`
`IXI argues that a network address translator (NAT) software component is
`
`not included in Marchand’s GMP 33, and that Marchand teaches away from using
`
`NAT. POR, 22, 37-39. IXI’s argument, however, mischaracterizes Marchand and
`
`fails to account for the breadth of a NAT software component, as recognized by the
`
`’033 Patent.
`
`The ’033 Patent describes that a “NAT component 553 translates a private
`
`IP address to and from a real IP address.” Ex. 1001, 8:17-18. Marchand describes a
`
`similar translation of a private IP address to and from a real or public IP address. In
`
`Marchand, the “mobile phone receives IP packets from the GPRS network through
`
`its public IP address, and forwards the received packets to the private IP address of
`
`the destination device in the Piconet.” Ex. 1003, ¶ 27; Ex. 1005, 7:14-17. The
`
`GMP 33 “also translates in the other direction for data going out of the Piconet to
`
`the GPRS network.” Id.
`
`IXI does not dispute that Marchand’s GMP 33 “translate[s] between a public
`
`IP address and a private IP address.” POR, 37. Indeed, Dr. Mandayam admitted
`
`that, in Marchand, “address translation is done at the gateway.” Ex. 1018, 147:5-7;
`
`152:25-153:1.
`
`Despite this recognition, IXI contends that Marchand performs “API
`
`translation” using “the API that is sent from the SIP client in the mobile phone to
`
`the laptop” and that the alleged API translation is distinct from and incompatible
`
`13
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`with using a NAT. POR, 34-39; Ex. 1005, 11:11-12:3. IXI points to Marchand’s
`
`disclosure that, for real-time applications such as VoIP, use of NAT may result in
`
`an IP address mismatch problem. Ex. 1005, 11:17-12:3. Marchand explains that a
`
`mismatch occurs “when the NAT device changes the source IP address in the
`
`header to a temporary public IP address, but the payload still identifies the source
`
`IP address as the private IP address” and addresses this problem using an API to
`
`“ensure[ ] that this mismatch does not occur.” Id.
`
`IXI interprets this section of Marchand as indicating that NAT is not used
`
`and Marchand’s API is performing all of the address translation. See POR, 37-39.
`
`However, this is incorrect. Marchand’s API resolves any IP mismatch problems
`
`created by Marchand’s NAT in handling real-time applications. Ex. 1003, ¶ 27; Ex.
`
`1005, 11:17-12:3. Specifically, for non-real-time applications, Marchand’s NAT
`
`operates without issue. For real-time applications, “the NAT device changes the
`
`source IP address in the header to a temporary public IP address, but the payload
`
`still identifies the source IP address as the private IP address.” Id. An API is used
`
`to resolve any IP address mismatches introduced by NAT. Id. Thus, contrary to
`
`IXI’s API translation theory, Marchand uses the API as a supplement to NAT; not
`
`a substitute for NAT, as IXI contends.
`
`Even assuming that IXI’s API translation theory of Marchand is correct,
`
`which it is not, IXI provides no explanation for why address translation using an
`
`API fails to meet a NAT software component. IXI does not dispute that, in
`
`14
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`Marchand, “address translation is done at the gateway.” Ex. 1018, 147:5-7; 152:25-
`
`153:1. Marchand also describes the API as “a small piece of Java code” (i.e.,
`
`software component). Ex. 1005, 9:15. Accordingly, even assuming that Marchand
`
`discloses “API translation” as IXI argues, the API is a software component that
`
`translates a private IP address to and from a real or public IP address. Nothing in
`
`the ’033 Patent precludes the NAT software component from being implemented
`
`as an API. Accordingly, even under IXI’s interpretation, the API is a software
`
`component that performs NAT.
`
`IV. Marchand, Nurmann, and Vilander disclose “a first Internet Protocol
`(‘IP’) address provided to the first wireless device from the cellular network
`and a second address for the second wireless device provided by the first
`wireless device.”
`IXI contends that “there is no objective teaching or suggestion in Marchand
`
`indicating any need for the cellular network to provide the public IP address, or
`
`any apparent reason based on Vilander’s disclosure to modify Marchand as
`
`suggested by Petitioner.” POR, 40. However, as explained below and in the
`
`Petition, using Vilander’s address allocation in Marchand would have amounted to
`
`nothing more than the use of a known technique to improve similar devices in the
`
`same way or the combination of prior art elements according to known methods to
`
`yield predictable results. See KSR v. Teleflex, 550 U.S. 398, 417 (2007); M.P.E.P. §
`
`2143 I(C). Petition, 16-20.
`
`Marchand discloses a GMP 33 that routes IP packets between a network 30
`
`and an external wireless IP network 35, such as a cellular network that employs
`
`15
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`GPRS. Ex. 1005, 7:12-17. To perform this routing, the GMP 33 has “a public IP
`
`address recognized in the wireless IP network.” Ex. 1005, 4:23-30; Ex. 1006, 7:8–
`
`17. Although the public IP address must be assigned, Marchand does not explicitly
`
`describe how the public IP address is assigned.
`
`Vilander discloses an Internet Access Server (IAS) in a Gateway General
`
`Packet Radio Service (GPRS) cellular network that allocates an IP address to a
`
`mobile terminal that wants to access the Internet through the cellular network. Ex.
`
`1011, 1:33-60. The mobile terminal receives a Radio Network Terminal Identity
`
`(RNTI) from a mobile network and stores the RNTI as an IP address for itself. Ex.
`
`1003, ¶ 45. Ex. 1011, Abstract; FIG. 3; 2:41-45; 5:2-10. Accordingly, a POSITA
`
`would have found it obvious to use Vilander’s technique in Marchand such that,
`
`when Marchand’s GMP 33 requests Internet access, a device on the cellular
`
`network 35, such as a GPRS network, would allocate the public IP address to the
`
`GMP 33 in a known and predictable manner. Ex. 1011, 1:48-52, 1:57-59; Ex.
`
`1003, ¶ 46.
`
`IXI also argues against the combination of Marchand and Nurmann under
`
`the assumption that the GMP 33 is a slave device. In making this assumption, IXI
`
`relies on its sub-piconet theory, which, as noted above, is incorrect at least because
`
`Marchand’s GMP 33 is a master device. Thus, IXI’s argument relies on an
`
`incorrect premise and Marchand’s GMP 33 purportedly being a slave device is not
`
`a reason why Marchand’s GMP 33 cannot assign private IP addresses.
`
`16
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`As described in the Petition, Nurmann teaches that an IP gateway can be
`
`
`
`activated as a DHCP server and then allocate IP addresses to IP hosts (e.g.,
`
`devices) in a local IP network, such as Marchand’s Bluetooth network 30. Petition,
`
`16-20; Ex. 1010, 1:9-12; 2:54-60; 3:26-46; 4:37-48; FIG. 4. Nurmann discloses
`
`that the IP gateway that provides Internet access is the device that assigns IP
`
`addresses. Ex. 1010, Abstract, 3:14-63.
`
`In Marchand, such an IP gateway device is the GMP 33. The GMP 33
`
`receives IP packets from a GPRS network through its public IP address, and
`
`forwards the received packets to the private IP address of the destination device in
`
`the Bluetooth network 30. Ex. 1005, 7:14-16. Accordingly, a POSITA would have
`
`combined Marchand and Nurmann’s teachings at least because IP address
`
`allocation by a DHCP server in a GMP 33 protects against disturbances due to
`
`errors while assigning IP addresses. Ex. 1010, 2:37-48; 4:1-5; Ex. 1003, ¶ 51.
`
`Additionally, because the GMP 33 performs address translation, as taught by
`
`Marchand and conceded by Dr. Mandayam (see Ex. 1018, 147:5-7; 152:25-153:1),
`
`the GMP 33 needs real time information on the allocated addresses of devices. Ex.
`
`1003, ¶ 51. If an entity other than the GMP 33 performs address allocation, there
`
`could be a mismatch between the entity and the GMP 33 for an allocated address
`
`of a device and data packets could be incorrectly routed. Ex. 1003, ¶ 51.
`
`17
`
`
`
`
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`
`V. Marchand discloses a thin terminal.
`IXI contends that Marchand does not teach or suggest that “the second
`
`wireless device is a thin terminal” because Marchand’s printer 32 does not
`
`correspond to a thin terminal. POR, 42, 43. As explained below, IXI’s contentions
`
`rely on a narrow interpretation of thin terminal and are inconsistent with IXI’s own
`
`allegations of infringement.
`
`The ’033 Patent describes thin terminals as mainly being “used as
`
`peripherals to an Application server in a PAN and their main task is user
`
`interaction, rendering output for a user and providing an Application server with a
`
`user's input.” Ex. 1001, 5:4-7. Because Marchand’s printer 32 allows devices in the
`
`piconet to provide printed output, Marchand’s printer 32 is a peripheral to the other
`
`devices in the piconet and performs user interaction. Ex. 1005, 10:6-7. Thus,
`
`Marchand’s printer 32 provides functionality similar to the ’033 Patent discussion
`
`of thin terminal.
`
`The ’033 Patent also describes thin terminals as having “a relatively low
`
`power central processor and operating system” and contrasts thin terminals with
`
`smart terminals, such as a laptop computer or a PDA. Ex. 1001, 5:1-8. The ’033
`
`Patent does not, however, specify a type, range, quantity, or level of power
`
`considered to be of “relatively low power.” As discussed in the Petition, a printer,
`
`at least, has a “low power central processor and operating system” relative to a
`
`laptop computer or PDA. Ex. 1003, ¶ 25.
`
`
`
`18
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`Instead of addressing these arguments, IXI advances a narrow interpretation
`
`of thin terminal, focusing on the ’033 Patent’s disclosure that “a thin terminal . . .
`
`has no embedded application code or data,” despite that language being absent
`
`from the claims. POR, 42, 43. As support, IXI points to col. 10 of the ’033 Patent
`
`specification (see Ex. 1001, 10:12-25):
`
`
`
`This portion of the ’033 Patent, however, does not describe a thin terminal as being
`
`devoid of application code or data —if it did, even a messaging terminal would not
`
`be considered a thin terminal after it locates and downloads appropriate software.
`
`Rather, the ’033 Patent refers to software that “needs to be located, downloaded
`
`and executed” for a thin terminal to be supported in a PAN. Ex. 1001, 10:13-25.
`
`This description does not preclude a printer from being a thin terminal, and, in fact,
`
`is consistent with Marchand’s printer 32, which can locate, download, and execute
`
`
`
`19
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`software (e.g., APIs). Ex. 1005, 7:7-11; 7:27-8:17. Thus, IXI’s argument requires a
`
`narrow interpretation of a “thin terminal” as a device with no embedded
`
`application code or data that is incompatible with the broadest reasonable
`
`interpretation standard.
`
`This point is reinforced when considering IXI’s infringement contentions
`
`that “[a] WLAN Device may be a thin terminal such as a printer.” Ex. 1001, 5:1-8;
`
`Ex. 1012, 20, 45; Ex. 1013, 35, 70. Id. IXI’s infringement contentions negate its’
`
`current argument for the broadest reasonable interpretation of “thin terminal.”
`
`VI. Marchand, Nurmann, Vilander, and RFC 2543 disclose a DNS Software
`Component.
`
`IXI contends that the Marchand, Nurmann, Vilander, RFC 2543
`
`combination does not render obvious that “the software component includes a
`
`domain naming service (‘DNS’) software component to translate between a human
`
`readable name and a second Internet Protocol (‘IP’) address.” IXI argues that there
`
`is no need for a DNS server to allow a device to query a human-readable name and
`
`obtain an IP address corresponding to that human-readable name in Marchand.
`
`POR, 45. However, IXI’s assertions are contrary to Marchand’s disclosure.
`
`Marchand’s GMP 33 includes a “second interface/API [that] is a SIP client
`
`42 which enables the use of the full SIP client capabilities. The SIP client
`
`interfaces via SIP signaling with a SIP proxy server 43 in the 3G wireless IP
`
`network” to establish a cellular call. Ex. 1003, ¶ 54; Ex. 1005, 8:5-7; 9:20-30. The
`
`full client capabilities include implementing SIP capabilities, such as the DNS
`
`20
`
`

`
`Case IPR2015-01444
`Attorney Docket No: 00035-0004IP1
`resolver in RFC 2543, which allow Marchand’s SIP client 42 to perform address
`
`resolution to complete SIP calls. Ex. 1003, ¶ 57; Ex. 1007, pp. 1, 13, 146. Dr.
`
`Mandayam also concedes that a SIP client can be used to complete a call. Ex.
`
`1019, 55:11-15. RFC 2543 tea

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