`__________________________
`
`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 -
`
`