throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`APPLE INC.
`
`Petitioner
`
`v.
`
`UNILOC 2017 LLC
`
`Patent Owner
`
`
`
`IPR2019-00702
`
`Patent 7,969,925
`
`
`
`
`
`PATENT OWNER SUR-REPLY
`
`
`
`

`

`IPR2019-00702
`U.S. Patent No. 7,969,925
`
`
`I.
`
`II.
`
`Table of Contents
`
`INTRODUCTION ....................................................................................... 1
`
`PETITIONER DOES NOT PROVE A REASONABLE LIKELIHOOD OF
`UNPATENTABILITY FOR ANY CHALLENGED CLAIM ...................... 1
`
`A.
`
`B.
`
`C.
`
`The Reply's Assertions Are Incorrect Because Opening A Listening
`Port for a Target Device Can Be Implemented Using TCP/IP ............ 2
`
`The Reply's Assertions Are Incorrect Because Uniloc’s Claims
`Construction Is Supported by the Plain Meaning ............................... 4
`
`The Reply Mischaracterizes the Claim Construction in Asserting That
`the "listening software port" Only Needs To Be Opened Once .......... 6
`
`D. Opening a Listening Software Port Cannot Be Construed To Mean
`Associating a Port Identifier With a Process ...................................... 7
`
`E.
`
`Petitioner's Declarant Adds Nothing of Substance ............................11
`
`III. CONCLUSION ..........................................................................................11
`
`
`
`ii
`
`

`

`IPR2019-00702
`U.S. Patent No. 7,969,925
`
`
`I.
`
`INTRODUCTION
`
`Uniloc 2017 LLC (“Uniloc” or “Patent Owner”) submits this Sur-Reply to
`
`the Petition for Inter Partes Review (“Pet.” or “Petition”) of United States Patent
`
`No. 7,969,925 (“the '925 patent” or “Ex. 1001”) filed by Apple Inc. (“Petitioner”).
`
`For the reasons given in Patent Owner’s Response and herein, Petitioner
`
`fails to carry its burden of proving the challenged claims of the '925 patent
`
`unpatentable on the challenged grounds.
`
`II.
`
`PETITIONER DOES NOT PROVE A REASONABLE LIKELIHOOD
`OF UNPATENTABILITY FOR ANY CHALLENGED CLAIM
`
`Patent Owner’s Response (POR) explains that Petitioner’s assertion of
`
`RFC793 relies upon an incorrect claim construction and fails to cure conceded
`
`deficiencies of the primary references for the limitations directed to “opening a
`
`listening software port” of all challenged claims (Grounds 1‒6). (POR, pp. 5-9,
`
`11-18). Petitioner alters the claim to mean “associating a port identifier with a
`
`process,” rather than open the port to a specific target device. See id. Petitioner’s
`
`Reply asserting improper claim construction arguments (Reply, pp. 1-8) is
`
`unavailing, as Petitioner fails to show any error in Uniloc’s argument in light of all
`
`of the limitations of each of the independent claims, namely Claims 1, 8, and 15, or
`
`how RFC793 teaches “opening a listening port” as properly construed. Moreover,
`
`the Petitioner fails to cite any portion of Alos (Ex. 1005), Cordenier (Ex. 1007),
`
`Lee (Ex. 1006), or RFC793 (Ex. 1010) that teaches this limitation of the
`
`independent claims. Accordingly, the Patent Owner respectfully submits that the
`
`Petition be denied in its entirety for the reasons discussed in detail below.
`
`1
`
`

`

`IPR2019-00702
`U.S. Patent No. 7,969,925
`
`
`A. The Reply's Assertions Are Incorrect Because Opening A
`Listening Port for a Target Device Can Be Implemented Using
`TCP/IP
`
`The Reply asserts that it is impossible to implement the aforecited limitation
`
`using a TCP connection. (Reply, p. 6). To support this assertion, the Reply
`
`explains that opening a TCP port is accomplished using an OPEN call that is either
`
`active or passive. (Reply, p. 7). The Reply further asserts that an active OPEN
`
`call must specify a foreign host address. (Id). In the context of the independent
`
`claims, the foreign host address would be the target mobile device. The Reply also
`
`explains that a passive OPEN call with zeroes for each of the foreign IP address
`
`and port arguments (i.e., port number) results in entry into the LISTEN state and
`
`allows for a connection with any foreign process. (Id, citing Ex. 1010, p. 11). The
`
`Patent Owner respectfully submits, however, that the Reply is saliently ignoring
`
`the fact that a passive OPEN call is not required to use all zeroes for the port
`
`number in order to open a passive TCP port. In fact, it is this mis-characterization
`
`of the RFC793 standard that the Reply is required to ignore in order to support its
`
`assertion that the aforecited limitation cannot be implemented using TCP/IP.
`
`RFC793 provides
`
`for well-known
`
`sockets
`
`(i.e.,
`
`IP address/port
`
`combinations) that are a convenient mechanism for a priori associating a socket
`
`address with a standard service (e.g., file transfer protocol (FTP), dynamic naming
`
`service (DNS), hypertext transfer protocol (HTTP), etc.). (Ex. 1010, p. 20).
`
`RFC793 also provides for ephemeral ports that are temporary in nature and, as
`
`2
`
`

`

`IPR2019-00702
`U.S. Patent No. 7,969,925
`
`
`opposed to their well-known port counterparts, known only by those nodes
`
`involved in a connection using the ephemeral port. (Ex. 1015, pp. 15-16, and 19).
`
`A TCP port can be opened with a passive OPEN call in which an ephemeral
`
`port number is used. In fact, this is how a telnet session is established. (Ex. 1015,
`
`p. 94, 99). When a client port of a first device is opened, it is assigned with an
`
`ephemeral port number that is transmitted to a telnet server port of a second device.
`
`(Id). Only the second device knows what that ephemeral port number is, and
`
`therefore, only the second device can access the newly opened client port of the
`
`first device. That is, the first device opens a telnet client port (i.e., passive OPEN
`
`call) for a specific target device.
`
`Most TCP/IP implementations allocate ephemeral port numbers between
`
`1024 and 5000. (Ex. 1015, pp. 16, 50). As such, a typical TCP implementation
`
`would allow use of any one of 3,976 different ephemeral port numbers. Thus, any
`
`TCP port of a first device that is opened with the passive OPEN call and an
`
`ephemeral port number can be dedicated to (e.g., tightly coupled to) another target
`
`device to which an invitation message may be sent. Owing to the temporary nature
`
`of an ephemeral port-based session, such as a data transfer session as recited in the
`
`independent claims, it is highly unlikely that an arbitrary third party device could
`
`accidentally or even purposefully (i.e., maliciously) identify what the ephemeral
`
`port number is, much less identify an IP address that is associated with the
`
`ephemeral port number during the relatively short time that the opened port may be
`
`active.
`
`3
`
`

`

`IPR2019-00702
`U.S. Patent No. 7,969,925
`
`
`Such is the case with an example implementation involving the recitations of
`
`the claims of the '925 Patent. In this example implementation, the initiating mobile
`
`device opens a listening software port with an ephemeral port number. The
`
`ephemeral port number is transmitted to the target mobile device in the invitation
`
`message so that only the initiating mobile device and the target mobile device
`
`knows what that ephemeral port number is. Stated differently, the initiating mobile
`
`device open[s] a listening software port for a specific target mobile device as per
`
`the aforecited recitation. The target mobile device, knowing the ephemeral port
`
`number that it has received, can then transmit a response to the listening software
`
`port to establish a data transfer session with the opened ephemeral listening
`
`software port.
`
`Accordingly, once a POSITA becomes aware of the novel and non-obvious
`
`features recited in the independent claims of the '925 Patent, the aforecited
`
`recitation can be implemented using TCP.
`
`B.
`
`The Reply's Assertions Are Incorrect Because Uniloc’s Claims
`Construction Is Supported by the Plain Meaning
`
`The Reply asserts that the Patent Owner's claim construction is contrary to
`
`the plain language of the claims. (Reply, p. 2). In particular, the Reply asserts that
`
`there is nothing in the “opening a listening software port” limitation requiring that
`
`the software listening port be opened in such a way that it can receive
`
`communications from only a specific target mobile device. (Id). The Patent
`
`Owner respectfully submits, however, that when all of the elements of the claim
`
`4
`
`

`

`IPR2019-00702
`U.S. Patent No. 7,969,925
`
`
`are considered in their entirety, the plain meaning clearly supports opening a
`
`listening software port for a specific target mobile device, rather than merely
`
`“associating a port identifier with a process.”
`
`“All words in a claim must be considered in judging the patentability of that
`
`claim against the prior art.” In re Wilson, 424 F.2d 1382, 1385, 165 USPQ 494,
`
`496 (CCPA 1970). In the present case, Claim 1 recites “opening a listening
`
`software port on an initiating mobile device to receive communications through the
`
`data packet-based communications service.” But this recitation of Claim 1 recites
`
`a term “the data packet-based communications service” that finds its antecedent
`
`basis in the preamble of the claim. The preamble of Claim 1 is reproduced herein
`
`below for further discussion:
`
`A method of establishing a direct data transfer session between mobile
`
`devices that support a data packet-based communications service over
`
`a digital mobile network system, the method comprising: [Claim 1,
`
`preamble (annotated)].
`
`As shown,
`
`the preamble affirmatively recites "a data packet-based
`
`communications service" that, as shown above, is the object of the act of "opening
`
`a listening software port" term shown above. Further, the preamble recites that this
`
`data packet-based communications service is supported by multiple mobile devices
`
`to establish a direct data transfer session. Thus, the claim language must be
`
`interpreted in the light of not only "opening a listening software port on an
`
`initiating mobile device" by itself; rather, it must be interpreted based on all terms.
`
`The other independent claims, namely Claims 8 and 15, recite similar recitations
`
`5
`
`

`

`IPR2019-00702
`U.S. Patent No. 7,969,925
`
`
`and, therefore, all of the independent claims should be construed to include the
`
`aforecited claim construction.
`
`For at least these reasons, including those reasons set forth in the Patent
`
`Owner Response, it is Petitioner’s broadening construction that is untethered from
`
`the plain meaning of the independent claims.
`
`C. The Reply Mischaracterizes the Claim Construction in Asserting
`That the "listening software port" Only Needs To Be Opened
`Once
`
`The Reply asserts that the Patent Owner argues that the claim language
`
`requires opening a listening software port every time the initiating mobile device
`
`desires to establish communications with a particular target mobile device. (Reply,
`
`p. 8). This assertion is incorrect. The Patent Owner did not assert that the claim
`
`language requires opening a listening software port every time the initiating mobile
`
`device desires to establish communications; rather, the Patent Owner merely re-
`
`stated an argument that was previously presented during prosecution of a parent
`
`patent application. (Patent Owner Response, p. 8-9 (citing Ex. 1004, p. 316)).
`
`What the Patent Owner did assert was that the previously presented
`
`argument shows that its intent was to unambiguously distinguish the claim
`
`language from, for example, (1) opening a port that indiscriminately “serves any
`
`and all mobile terminals that desire setting up a connection” and (2) “leav[ing]
`
`open one known connection to allow any number of devices to communicate with
`
`it.” (Id, p. 9).
`
`6
`
`

`

`IPR2019-00702
`U.S. Patent No. 7,969,925
`
`
`Nevertheless, the Reply attacks this relevant argument by asserting that the
`
`"listening software port" only needs to opened once for multiple communications.
`
`(Reply, pp. 8-9). Once again, the Reply mischaracterizes the plain meaning of the
`
`language of the claims. For example, the Reply asserts that the claims recite a port
`
`is open[ed] to receive plural "communications." (Id). But the claims do not recite
`
`"plural communications." Rather, the term "communications", when taken within
`
`the context and meaning of the entirety of all the recitations of the claims, simply
`
`means an ongoing transferal of data from one point to another, such as that which
`
`may be accomplished via a single communications session. Indeed, the claims
`
`explicitly recite that a singular "data transfer session" is established (from which
`
`ongoing communications may be accomplished) as a result of the software port
`
`being opened.
`
`D. Opening a Listening Software Port Cannot Be Construed To
`Mean Associating a Port Identifier With a Process
`
`The Reply asserts that the Patent Owner mischaracterizes Petitioner's
`
`construction as "replac[ing] the word 'opening' with 'associating.' (Reply, p. 9
`
`(citing Patent Owner Response, p. 6)). This assertion is incorrect because the
`
`Petition did indeed attempt to re-construct the recitation "opening a listening
`
`software port" to mean "associating a port identifier with a process." (Id). What
`
`the Patent Owner Response explained is that replacing, among other things, the
`
`term 'opening' with 'associating' causes the meaningful and limiting term chosen by
`
`the patentee (in this case 'opening') to fail in its effect. (Patent Owner Response, p.
`
`7
`
`

`

`IPR2019-00702
`U.S. Patent No. 7,969,925
`
`
`6). That is, the patentee specifically chose 'opening' to describe an action that
`
`occurs to a listening software port, not 'associating' as asserted by the Petition.
`
`By indiscriminately replacing the patentee's chosen term 'opening' with the
`
`term 'associating,' the effect of the overall recitation "opening a listening software
`
`port" has inappropriately been changed. For example, the term 'associating' does
`
`not necessarily mean instantiating or establishing an entity, which in this particular
`
`context is a listening software port; rather, it would reasonably be construed to
`
`form a binding or association between two or more entities, whether or not those
`
`entities are explicitly instantiated or established. This is certainly not the case with
`
`the term 'opening,' which necessarily means instantiating or establishing an entity
`
`that has not previously been done. Therefore, as the Patent Owner Response
`
`correctly explains, the Petitioner's attempt to replace the word 'opening' with
`
`'associating' causes the resulting construction to mean something other than what
`
`was intended by the patentee. That is, it fails to give effect to the meaningful and
`
`limiting term chosen by the patentee as correctly pointed out by the Patent Owner
`
`Response.
`
`The Reply asserts that the Petition attempts to replace the phrase "opening a
`
`listening software port” with the phrase “associating a port identifier with a
`
`process.” (Reply, p. 9). Aside from Petitioner’s plain attempt to broaden the
`
`claims, rather then aid in their understanding, Patent Owner notes that "associating
`
`a port identifier with a process" includes the term 'process,' but there exists no such
`
`term within either of the independent claims. To support this flawed phrase
`
`8
`
`

`

`IPR2019-00702
`U.S. Patent No. 7,969,925
`
`
`replacement attempt, the Petition asserts that associating a port identifier with a
`
`process is what enables the device to receive messages at that port and route them
`
`to the correct process. (Petition, p. 21). But the Petition never provides any
`
`disclosure about what the 'correct process' would be, much less how it is relevant
`
`to the language of the claims.
`
`The Reply asserts that the Patent Owner formulates a second attack by
`
`asserting that it (the Petition's proposed claim construction) "is inconsistent with
`
`the remainder of the limitation and the surrounding context.” (Reply, pp. 10-11
`
`(citing Patent Owner Response, pp. 6-7). The Reply argues that Patent Owner
`
`never identifies any “surrounding context” and never explains how Petitioner’s
`
`construction is inconsistent with the remainder of the limitation or any
`
`“surrounding context.” (Id). The Patent Owner respectfully submits, however,
`
`that this assertion is demonstrably false as the Patent Owner provides a clear
`
`explanation immediately thereafter in stating the following:
`
`As recited in claim 1, for example, the “opening” of the listening
`
`software port is at least expressly tied to “receiv[ing] communications
`
`through the data packet-based communications service” (i.e., the data
`
`packet-based communications service introduced in the preamble of
`
`the claim). This is distinguishable on its face from merely associating
`
`a port identifier with an unspecified “process.” (Patent Owner
`
`Response, p. 7).
`
`As clearly shown, when the proper claim construction (opening of the
`
`listening software port) is applied, it is directly tied to other elements of the claims,
`
`such
`
`as
`
`“receiv[ing]
`
`communications
`
`through
`
`the data packet-based
`
`9
`
`

`

`IPR2019-00702
`U.S. Patent No. 7,969,925
`
`
`communications service."
`
` However, were
`
`the Petition's proposed claim
`
`construction ("associating a port identifier with a process") to be applied, no other
`
`portion of the claim could reasonably be tied to a "process." This is the
`
`"surrounding context" that the Patent Owner Response specifically addressed, and
`
`was explained to be lacking in the Petition's flawed arguments. As such, the Board
`
`should deny the flawed claim construction proposed by the Reply, because, among
`
`other things, the Patent Owner Response clearly lays out how and why the
`
`proposed claim construction is clearly shown to be inconsistent with the remainder
`
`of the limitations or any “surrounding context.”
`
`The Reply further asserts that the Patent Owner formulates a third attack by
`
`asserting that Petitioner’s construction is incorrect because it does not require
`
`opening the port only for the target device. (Reply, p. 11). But the Patent Owner
`
`Response clearly describes why the listening software port is opened only for the
`
`target device. (See Patent Owner Response, pp. 5-9). Additionally, the Patent
`
`Owner provides further explanation as to how and why the listening software port
`
`is opened only for the target device in sections II.A, and II.B above.
`
`Given the facts presented herein above, the Petitioner's proposed claim
`
`construction is clearly flawed, and, therefore, should be rejected by the Board.
`
`Accordingly, the Patent Owner respectfully requests that the Petition be denied in
`
`its entirety.
`
`10
`
`

`

`IPR2019-00702
`U.S. Patent No. 7,969,925
`
`
`E.
`
`Petitioner's Declarant Adds Nothing of Substance
`
`The Reply asserts that the Patent Owner argues that the testimony in Dr.
`
`Houh’s Declaration (Ex. 1002) should be given little weight because that testimony
`
`is repetitive of the arguments in the Petition and is unsupported. (Reply, pp. 18-19,
`
`See also Patent Owner Response, pp. 20-21). The Patent Owner respectfully
`
`submits, however, that both the Declaration AND Petition appear to mimic an
`
`inordinately large amount of the same language about opening a passive port. Yet
`
`neither the declaration nor Petition describes how the references, either alone or in
`
`combination, can be shown to teach how that passive port may be opened to only a
`
`target device as described above with reference to section II.A.
`
`III. CONCLUSION
`
`For the foregoing reasons, Uniloc respectfully requests that the Petition be
`
`denied in its entirety.1
`
`Date: March 11, 2020
`
`
`
`
`
`
`
`
`
`Respectfully submitted,
`
`By: /Brett A. Mangrum/
`Brett A. Mangrum
`Attorney for Patent Owner
`Reg. No. 64,783
`
`
`
`
`1
`
`Patent Owner does not concede, and specifically denies, that there is any
`
`legitimacy to any arguments in the Petition that are not specifically addressed
`
`herein.
`
`11
`
`

`

`IPR2019-00702
`U.S. Patent No. 7,969,925
`
`
`
`
`CERTIFICATE OF COMPLIANCE
`
`Pursuant to 37 C.F.R. § 42.24(d), I certify that this Preliminary Response to
`
`Petition complies with the type-volume limitation of 37 C.F.R. § 42.24(c)(1)
`
`because it contains fewer than the limit of 5,600 words, as determined by the word-
`
`processing program used to prepare the brief, excluding the parts of the brief
`
`exempted by 37 C.F.R. § 42.24(c).
`
`Date: March 11, 2020
`
`
`
`
`
`
`
`
`
`Respectfully submitted,
`
`By: /Brett A. Mangrum/
`Brett A. Mangrum
`Attorney for Patent Owner
`Reg. No. 64,783
`
`
`
`
`
`
`i
`
`

`

`IPR2019-00702
`
`US. Patent No. 7,969,925
`
`CERTIFICATE OF SERVICE
`
`Pursuant to 37 CPR. §§ 42.6(e), the undersigned certifies that an electronic
`
`copy of the foregoing was served, along with any accompanying exhibits not
`
`previously served, via email to Petitioner’s counsel at the following addresses
`
`identified in the Petition’s consent to electronic service:
`
`Lead Counsel
`
`Brian Erickson Reg.
`
`brian.crickson@dlapiper.com
`
`BaCk Up
`Counsel
`
`No. 48,895
`
`James M'
`Helntz, Reg.
`No. 41,828
`
`jim.heintz@dlapiper.com
`
`Date: March ll, 2020
`
`Respectfully submitted,
`
`By: / Brett A. Mangrum/
`Brett A. Mangrum; Reg. No. 64,783
`Attorney for Patent Owner
`
`ii
`
`

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