throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`__________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________________________
`
`SAMSUNG ELECTRONICS CO., LTD. And
`GOOGLE LLC
`Petitioner,
`
`v.
`
`IRON OAK TECHNOLOGIES, LLC,
`Patent Owner.
`
`___________________________
`
`IPR2018-015531
`U.S. Patent No. 5,699,275
`___________________________
`
`PATENT OWNER SUR-REPLY
`
`1 Google LLC, who filed a petition in IPR 2019-00111, has joined as a petitioner in this proceeding.
`
`

`

`TABLE OF CONTENTS
`
`I.
`
`II.
`
`INTRODUCTION........................................................................................2
`
`THE PETITION FAILED TO PROVE THAT HAPKA OR
`PARRILLO DISCLOSES SELECTIVE UPDATING OF FIRST
`AND SECOND MOBILE UNITS WHEN BOTH ARE CAPABLE
`OF BEING UPDATED BY THE SAME PATCH ......................................6
`
`III. CONCLUSION..........................................................................................10
`
`CERTIFICATE OF COMPLIANCE ...................................................................11
`
`CERTIFICATE OF SERVICE.............................................................................12
`
`i
`
`

`

`Petitioner’s burden was to file a Petition that “specif[ied] where each element
`
`of [Claim 1] is found in the prior art patents or printed publications relied upon;” and
`
`“the exhibit number of the supporting evidence relied upon to support the challenge
`
`and the relevance of the evidence to the challenge raised, including identifying
`
`specific portions of the evidence that support the challenge.” 37 C.F.R. § 42.104 at
`
`(4). As held in Intelligent Bio-Sys, Inc. v. Illumina Cambridge Ltd, 821 F.3d 1359,
`
`1369 (Fed. Cir. 2016), “[i]t is of the utmost importance that petitioners in the IPR
`
`proceedings adhere to the requirement
`
`that
`
`the initial petition identify ‘with
`
`particularity’ the ‘evidence that support the grounds for the challenge to each
`
`claim.’”
`
`As shown below, among other things, the Petition fails to give effect to all
`
`limitations in the challenged claim and correspondingly fails to reasonably
`
`demonstrate how the prior art discloses the invention as actually claimed.
`
`Specifically, the Petition did not adequately identify where the proposed Hapka-
`
`Parrillo combination disclosed a Manager Host operable to decide not to initiate
`
`transmission of the at least one patch message to a second mobile unit, which second
`
`mobile unit is operable to create patched operating code by merging the at least one
`
`patch with the current operating code. Because the Petition did not adequately
`
`specify where each claim limitation is found in the prior art, the Petition must be
`
`denied.
`
`- 1 -
`
`

`

`I.
`
`INTRODUCTION
`
`Petitioner’s Reply highlights construction disputes for two claim elements in
`
`dispute: the “Second Mobile Unit” claim element and the “wherein” claim element,
`
`reprinted below with the Board’s constructions and with emphasis.
`
`a second mobile unit operable to receive the at least one discrete patch
`message, the second mobile unit further operable to create patched
`operating code by incorporating the at least one patch into the
`current operating code, without replacing the current operating code,
`located in the second mobile unit and to switch execution to the
`patched operating code; and
`
`wherein the manager host is further operable to decide which specific
`mobile unit to send the at least one discrete patch message before
`beginning transmission such that the at least one discrete patch
`message is transmitted to the first mobile unit but not to the second
`mobile unit.
`
`Reading claim 1 as a whole, and giving meaning to each word or phrase in the
`
`claim, demonstrates that the claim requires at least a single patch message, which is
`
`introduced in the first claim element and carried throughout the claim with the
`
`antecedent signal “the.” See Wag Acquisition, LLC v. Webpower, Inc., Slip Op. No.
`
`2018-1617(Fed. Cir. August 26, 2019) (identifying antecedent basis for “said
`
`requests”).
`
`- 2 -
`
`

`

`This patch message is what the Manager Host must be operable to transmit to
`
`the First Mobile Unit but not the Second Mobile Unit. And, this same patch message
`
`is what the Second Mobile Unit must be operable to create “patched operating code”
`
`from. If the alleged Second Mobile Unit cannot create patched operating code from
`
`that patch message (such as because the operating code is already patched) that unit
`
`cannot be the “Second Mobile Unit” of claim 1 for purposes of that patch message.
`
`Figure 5 of the ’275 Patent and associated text discloses that if the “version”
`
`of the patch message does not match the current operating code, an error message is
`
`transmitted because the mobile unit (e.g., second mobile unit) is not operable to
`
`create patched operating code from that patch message. It should be understood that
`
`the Second Mobile Unit of claim 1 is determined not solely by whether the Manager
`
`Host is capable to transmit a message to it, or even whether the Second Mobile Unit
`
`is capable to receive the message. Rather, the Second Mobile Unit also has to be
`
`capable to create patched operating code from the same patch message sent to the
`
`first mobile unit.
`
`Petitioner cites to 4:9-17 of the ’275 Patent to support its argument that ’275
`
`Patent discloses not sending the patch to a mobile unit that is capable of updating
`
`current operating code. Reply at 7. However, that portion of the ’275 Patent
`
`discussing Figure 1 explains that the mobile units not receiving the patch “have
`
`different version of operating code than mobile units 26, 28 and 30” and therefore
`
`- 3 -
`
`

`

`would not be capable of creating patched operating code from the different version
`
`patch.
`
`Petitioner’s Reply argues that the “operable to” claim phrasing (i.e., “operable
`
`to” create patched operating code”) means that any prior art that discloses a
`
`reasonable capability of updating software discloses this claim element. Petitioner
`
`relies on ParkerVision v. Qualcomm Inc., 9903 F.3d 1354, 1361 (Fed. Cir. 2018),
`
`which held
`
`Similarly, a prior art reference may anticipate or render obvious an
`apparatus claim — depending on the claim language — if the
`reference discloses an apparatus that is reasonably capable of operating
`so as to meet the claim limitations, even if it does not meet the claim
`limitations in all modes of operation.
`
`ParkerVision, 993 F.3d at 1361 (emphasis added). In this regard, ParkerVision’s
`
`discussion of Ball Aerosol & Specialty Container, Inc. v. Limited Brands, Inc., 555
`
`F.3d 984 (Fed. Cir. 2009) is instructive. See ParkerVision, 903 F.3d at 1361-1362.
`
`As the ParkerVision court noted (emphasis added)
`
`“[a]nd, unlike in Ball Aerosol, the claims here recite no structural
`limitations that would preclude a prior art reference that discloses a
`different structure from performing the claimed function.”
`
`Here, and unlike in ParkerVision, both the “second mobile unit” claim element and
`
`the “wherein” claim element, recite additional limitations on the “operable to” claim
`
`- 4 -
`
`

`

`language. Specifically, the second mobile unit’s “operable to create” capability is
`
`further limited by the requirement of “incorporating the at least one patch with
`
`current operating code located in the second mobile unit, without replacing the
`
`current operating code.” A prior art reference that discloses a reasonable capability
`
`to create patched operating code without also disclosing that the patched operating
`
`code is created by merging the at least one patch with current operating code,
`
`without replacing the current operating code cannot disclose that it is “reasonably
`
`capable of operating so as to meet the claim limitations”
`
`Further, the “operable to address” requirement of the wherein clause is further
`
`limited by the requirement that “the at least one discrete patch message is transmitted
`
`to the first mobile unit but not the second mobile unit.”
`
`Petitioner’s reliance on Hewlett-Packard Co. v. Bausch & Lomb Inc. 909 F.2d
`
`1464, 1468 (Fed. Cir. 1990) is misplaced as well.
`
`In Hewlett-Packard, the Federal
`
`Circuit affirmed the finding of no obviousness because the subject claim language
`
`requiring “grit” was different than the prior art “knurled wheel.” The full quote,
`
`only part of which was cited by Petitioner, puts this in context.
`
`apparatus claims cover what a device is, not what a device does. An
`invention need not operate differently than the prior art
`to be
`patentable, but need only be different.”
`
`Hewlett-Packard, 909 F.2d at 1468 (emphasis in original).
`
`- 5 -
`
`

`

`Claim 1 is different than the proposed Hapka-Parrillo combination because
`
`the claim language as a whole requires elements not shown to be present in the
`
`combination
`
`Because the Panel is charged with determining whether the Petition—as
`
`filed—proved unpatentability of claim 1 by a preponderance of the evidence, the
`
`Panel must determine whether the Petition adequately specified how the prior art
`
`disclosed all limitations of claim 1.
`
`II.
`
`THE PETITION FAILED TO PROVE THAT HAPKA OR PARRILLO
`DISCLOSES SELECTIVE UPDATING OF FIRST AND SECOND
`MOBILE UNITS WHEN BOTH ARE CAPABLE OF BEING
`UPDATED BY THE SAME PATCH
`
`Hapka (Ex. 1008) is entitled “Remote Control of Engine Idling Time.” A
`
`POSITA reading Hapka would understand that this system allows a truck fleet
`
`manager, for example, to wirelessly and remotely modify the value of a parameter
`
`used by an engine algorithm. See, e.g., Abstract. Hapka’s specification consistently
`
`describes the invention as transmitting “data” over satellite or RF link to a
`
`communications system onboard a vehicle. The “data” is consistently described as
`
`“commands” and “control messages” (See, e.g., Ex. 1008 at 4:28; 6:40, 6:44; 7:11;
`
`7:27). The following passage from Hapka captures the essence of its disclosure
`
`(emphasis supplied):
`
`- 6 -
`
`

`

`[With reference to FIG. 3], [i]n block 302, the remote command
`interface device 8 then analyzes the data on data bus 28 to determine if
`the data is a remote engine control command sent from a remote use to
`modify existing engine parameters to control engine idle time or a
`similar engine function.
`
`Ex. 1008 at 7:54-58.
`
`Notably, Hapka discloses that while the system contains “software” or
`
`“firmware” (e.g., “operating code”), nowhere does Hapka disclose that
`
`this
`
`“software” or “firmware” is modified, let alone “patched” as required by Claim 1.2
`
`Furthermore, remote command interface device 8 is provided with
`software or firmware that implements the functions described herein
`with reference to the flowchart of FIG. 3. The software provided with
`the remote command interface device 8 translates the data on bus 28.
`Engine control system 36 comprises an engine control device 9 which
`includes a microprocessor 33 for storing and, processing, and
`implementing a sequence of data commands received from data bus
`29.
`
`2 The Petition admits that Hapka does not disclose “patching of operating
`
`code” as required by Claim 1 (Decision at 15). Indeed, Hapka discloses enabling or
`
`disabling an engine idle shutdown device. Nowhere does Hapka disclose patching
`
`current operating code.
`
`- 7 -
`
`

`

`Ex. 1008 at 4:21-29 (emphasis added). Hapka’s “parameter” or “data” used by an
`
`engine control algorithm is not “operating code.”
`
`Petitioner argues that because Hapka discloses a fleet of vehicles with each
`
`having a “mobile unit,” Hapka necessarily discloses a first “mobile unit” and a
`
`second “mobile unit.” Reply at 9. Petitioner further argues that because Hapka
`
`discloses a fleet of vehicles, that sending a communication to one vehicle to modify
`
`its engine algorithm necessarily means that a second vehicle was not sent the
`
`communication. Pet. at 55-56.
`
`But what the Petition did not show is that Hapka disclosed that the alleged
`
`“second mobile unit” is operable to receive the same communication (algorithm
`
`modification) as the first mobile unit, and whether the alleged “second mobile unit”
`
`is operable to create patched operating code using the same communication
`
`(algorithm modification) as used by the first mobile unit. Neither Petitioner nor its
`
`expert separately argues how or where Hapka discloses that the alleged “second”
`
`mobile unit was operable to be updated by the same patch (i.e., “the at least one
`
`discrete patch message”) that updated the first mobile unit, as required by claim 1.
`
`See Pet. at 53-55; Ex. 1002 at ¶¶ 244-245.
`
`Petitioner does not argue that Parrillo (Ex. 1009) discloses the “selective
`
`updating” aspect of claim 1.
`
`Instead, Petitioner focusses on Parrillo as allegedly
`
`disclosing the “operable to address” (or “decide which specific mobile unit to send,”
`
`- 8 -
`
`

`

`as construed by the Board) aspect of claim 1. See Pet. at 56-60. Nowhere does the
`
`Petition address how or where Hapka or Parrillo discloses a manager host that is
`
`operable to send an update communication to a first mobile unit, but not to a second
`
`mobile unit that is operable to create patched operating code using that very same
`
`communication update. Indeed, Petitioner tacitly admits there is no such disclosure
`
`in Hapka or Parrillo by arguing instead that
`
`the Hapka-Parrillo combination
`
`“target[s] individual vehicles … that required a particular software modification,
`
`while not affecting the operating code of vehicles not requiring a modification.”
`
`As established above, a vehicle that does not require the modification (i.e., not
`
`operable to created patched operating code) cannot be the “Second Mobile Unit”
`
`required by claim 1.
`
`Thus, there is no plausible basis given in the petition for the Board to conclude
`
`that Petitioners have carried their burden to demonstrate by a preponderance of the
`
`evidence that a Hapka-Parrillo combination would be operable to transmit update
`
`information to one mobile terminal but not to a second mobile terminal when both
`
`terminals were “operable to create patched operating code by merging the at least
`
`one patch with current operating code located in the [] mobile unit.”
`
`- 9 -
`
`

`

`III. CONCLUSION
`
`Petitioner had the burden to demonstrate in its Petition that each element of
`
`claim 1 of the ’275 patent was disclosed in a legitimate combination of prior art
`
`references. Among other failures, the petition failed to demonstrated that the prior
`
`art disclosed a manager host that “decides” not to send an operating code patch to a
`
`second mobile unit that is both operable to receive the patch and operable to create
`
`patched operating code from the patch, as required by claim 1. For at least this
`
`reason, the Petition should be denied.
`
`Date: September 23, 2019
`
`Respectfully submitted,
`
`By: /Al Deaver/
`Albert B. Deaver, Jr.
`Reg. No. 34,318
`Lead Counsel for Patent Owner
`
`- 10 -
`
`

`

`CERTIFICATE OF COMPLIANCE
`
`Pursuant to 37 C.F.R. § 42.24(d), I certify that this paper 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 document, excluding the parts of the document exempted by 37 C.F.R.
`
`§ 42.24(c).
`
`Date: September 23, 2019
`
`Respectfully submitted,
`
`By: /Al Deaver/
`Albert B. Deaver, Jr.
`Reg. No. 34,318
`Lead Counsel for Patent Owner
`
`- 11 -
`
`

`

`CERTIFICATE OF SERVICE
`
`Pursuant to 37 C.F.R. §42.6(e), I certify that an electronic copy of the foregoing
`
`paper was served along with any accompanying exhibits via the Patent Review
`
`Processing System and via email to Petitioner’s counsel:
`
`PH-Samsung-IronOak-IPR@paulhastings.com
`
`smith@smithbaluch.com
`
`baluch@smithbaluch.com
`
`Date: September 23, 2019
`
`Respectfully submitted,
`
`By: /Al Deaver/
`Albert B. Deaver, Jr.
`Reg. No. 34,318
`Lead Counsel for Patent Owner
`
`- 12 -
`
`

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