UNITED STATES PATENT AND TRADEMARK OFFICE
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`___________________________
`
`MICROSOFT CORPORATION,
`Petitioner,
`
`v.
`
`IRON OAK TECHNOLOGIES, LLC,
`Patent Owner.
`
`___________________________
`
`IPR2019-00106
`U.S. Patent No. 5,699,275
`___________________________
`
`PATENT OWNER SUR-REPLY
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`___________________________
`
`MICROSOFT CORPORATION,
`Petitioner,
`
`v.
`
`IRON OAK TECHNOLOGIES, LLC,
`Patent Owner.
`
`___________________________
`
`IPR2019-00106
`U.S. Patent No. 5,699,275
`___________________________
`
`PATENT OWNER SUR-REPLY
`
`
`
`TABLE OF CONTENTS
`
`I.
`
`II.
`
`III.
`
`INTRODUCTION ........................................................................................ 1
`
`PETITIONER’S REPLY HIGHLIGHTS THE INADEQUACY OF THE
`PETITION .................................................................................................... 3
`
`THE PETITION DID NOT ADDRESS ALL OF THE LIMITATIONS
`OF THE SECOND MOBILE UNIT IN THE CLAIMED SYSTEM,
`AND THE PETITION SHOULD BE DENIED IN ALL RESPECTS........ 7
`
`IV. CONCLUSION........................................................................................... 11
`
`CERTIFICATE OF COMPLIANCE.................................................................... 13
`
`CERTIFICATE OF SERVICE ............................................................................. 14
`
`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). Further, “[t]he Board may exclude or give no weight to the evidence where a
`
`party has failed to state its relevance or to identify specific portions of the evidence
`
`that support the challenge.” 37 C.F.R. § 42.104 at (5). See Response at 1-4.
`
`As shown below, among other things, the Petition did not adequately specify
`
`where the Sugita reference 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 from the current
`
`operating code and the at least one patch. Because the Petition did not adequately
`
`specify where each claim element is found in the prior art, the Petition must be
`
`denied.
`
`I.
`
`INTRODUCTION
`
`Petitioner’s Reply highlights why the Petition fails
`
`to demonstrate
`
`unpatentability of Claim 1. Distilled to its essence, the Petition failed to demonstrate
`
`by a preponderance of the evidence how Sugita disclosed a Manager Host that is
`
`operable to decide not to initiate transmission of the at least one patch message to a
`
`- 1 -
`
`
`
`second mobile unit that is operable to create patched operating code from the
`
`current operating code and the at least one patch, a patch that was also able to be
`
`sent to, received by, and merged into the first mobile unit.
`
`In other words, the literal wording and organization of Claim 1, as construed
`
`by the Panel, requires that both the First and Second Mobile Units be
`
`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.
`
`See Ex.1001 at claim 1 & Decision at 5 (incorporating Panels’ construction).
`
`Not only do the First and Second Mobile Units of Claim 1 have to be
`
`“operable to receive the at least one discrete patch message” (which is the patch
`
`message that the Manager Host is operable to transmit), the First and Second Mobile
`
`Units also have to be “further operable to create patched operating code by merging
`
`the at least one patch with current operating code.” See Ex.1001 at Claim 1
`
`(emphasis added).
`
`Thus, the literal wording and organization of claim 1 requires that a First
`
`Mobile Unit and Second Mobile Unit be operable to create patched operating code
`
`from the same “at least one patch,” and that the Manager Host be operable to decide
`
`not to initiate transmission of that “at least one patch” to the Second Mobile Unit,
`
`- 2 -
`
`
`
`even though the Second Mobile Unit is operable to create patched operating code
`
`from the “at least one patch” and the “current operating code.” 1
`
`II.
`
`PETITIONER’S REPLY HIGHLIGHTS THE INADEQUACY OF THE
`PETITION
`In Reply, Petitioner argues that Patent Owner makes a “convoluted argument
`
`based on an overly narrow interpretation of the claim …” Reply at 3.2 To support
`
`1 Claim 12, which depends directly from Claim 1, further limits the system of Claim
`
`1 by requiring that the Manager Host is further operable to address another discrete
`
`patch message to the Second Mobile Unit but not the First Mobile Unit. Further,
`
`Claim 14, which depends directly from Claim 1, further limits the system of Claim
`
`1 by requiring that the Manager Host is further operable to address the discrete patch
`
`message of Claim 1 to the First Mobile Unit and the Second Mobile Unit. Thus, it
`
`is clear from Claims 1, 12 and 14 that the discrete patch message of Claim 1 that is
`
`not sent to the Second Mobile Unit in Claim 1 is clearly the same discrete patch
`
`message that is sent to the First Mobile Unit.
`
`2 Petitioner appears to contend that the argument is “convoluted” because Patent
`
`Owner cited to Petitioner’s certified Sugita translation (i.e., Ex. 1005), and reprinted
`
`portions of the certified Sugita translation filed in IPR2018-01552. One would
`
`- 3 -
`
`
`
`this contention, Petitioner argues that a “temporal limitation” has been improperly
`
`read into Claim 1. But
`
`it was Petitioner that asked the Panel
`
`in multiple
`
`circumstances to the construe Claim 1 as having a temporal or timing aspect.
`
`Although Petitioner now attempts to walk back its prior arguments, the
`
`Petition presented Claim 1 as having “temporal” aspects for both the “addressing”
`
`aspect and the “patching” aspect of Claim 1. First, the Petition requested the Panel
`
`to construe “current operating code” (for both First and Second Mobile Units) as
`
`“operating code currently being executed by the mobile unit.” Pet. at 15 (emphasis
`
`added). Undeniably, both “current” and “currently” impart temporal aspects to this
`
`claim phrase, so system claim 1 as issued has a temporal component.
`
`Second, in construing the “addressing the at least one discrete patch message”
`
`aspect of the Manager Host, Petitioner argued for (and received) the construction
`
`that the
`
`manager host is further operable to decide which specific mobile unit
`
`to send the at least one discrete patch message to before beginning
`
`transmission.
`
`assume that translations of the same document, if accurate, would be the same.
`
`Notably, Petitioner did not
`
`identify any substantive errors in the reprinted
`
`translations. See Petition at 3.
`
`- 4 -
`
`
`
`Pet. at 18; Decision at 6 (emphasis added). This construction plainly interjects a
`
`temporal aspect to the claimed system.
`
`Third, the Petition also argued that the “manager host must determine when
`
`and which device should receive the discrete patch message prior to beginning
`
`transmission.” Pet. at 19 (emphasis added).
`
`Thus, it was Petitioner that argued Claim 1 has a “timing” aspect to the claim
`
`elements, and under the Panel’s construction the Manager Hosts must be operable
`
`to decide not to send the at least one patch message to Second Mobile Unit before
`
`sending the at least one patch message to First Mobile Unit, even though the Second
`
`Mobile must be “operable to create patched operating code by incorporating the at
`
`least one patch [which is not sent to the Second Mobile Unit] into the current
`
`operating code.”
`
`What Petitioner conveniently and strategically ignores in its Reply is the fact
`
`that a Mobile Unit that has created “patched operating code” by “incorporating the
`
`at least one patch into the current operating code” is no longer
`
`further operable to create patched operating code by incorporating the
`
`at least one patch into current operating code without replacing the
`
`current operating code located in the second mobile unit and to switch
`
`execution to the patched operating code.
`
`- 5 -
`
`
`
`This is because once the “current operating code” is patched, the patched operating
`
`code becomes the “current operating code” and the patch can no longer be merged
`
`therein.
`
`Thus, a Mobile Unit
`
`that has created “patched operating code” by
`
`incorporating the “at least one patch” into the current operating code cannot be the
`
`“Second Mobile Unit” required by Claim 1 at least because it is not “further
`
`operable” to create “patched operating code” from “the at least one patch message.”
`
`Petitioner’s arguments in Reply read out these very claim limitations that the
`
`Patent Office noted in its reasons for allowance. See Ex. 1002 at 110 (Prior art does
`
`not disclose “a manager host is operable to address the at least one discrete patch
`
`message such that at least one discrete patch message is transmitted to a first mobile
`
`unit but not to a second mobile unit recited in claim 1;”) (emphasis added).
`
`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 Sugita
`
`disclosed all limitations of the Second Mobile Unit in the claimed system.
`
`- 6 -
`
`
`
`III. THE PETITION DID NOT ADDRESS ALL OF THE LIMITATIONS
`OF THE SECOND MOBILE UNIT IN THE CLAIMED SYSTEM, AND
`THE PETITION SHOULD BE DENIED IN ALL RESPECTS
`
`In the Decision instituting review, the Panel addressed the Manager Host
`
`claim element directed to addressing the patch message to one mobile unit but not
`
`the other. The Panel held that
`
`Claim 1 does not foreclose sending an update to both mobile units,
`followed by sending an update to only one mobile unit. As long as the
`host addresses the at least one discrete patch message such that the
`message is transmitted to one mobile unit but not another mobile unit,
`the claim language is satisfied.
`
`Decision at 14. This holding is true so far as it goes. However, it does not address
`
`whether the Second Mobile Unit (i.e., the “but not another mobile unit”) was
`
`operable to (1) receive the at least one discrete patch message; and (2) further
`
`operable to create patched operating code by incorporating the at least one patch
`
`[from the at least one patch message]
`
`into the current operating code, without
`
`replacing the current operating code.
`
`This explicitly claimed aspect of the Second Mobile Unit of Claim 1 was
`
`never adequately addressed in the Petition, and because of that failing alone, the
`
`Petition must be denied.
`
`The Petition argued that Sugita disclosed
`- 7 -
`
`
`
` “base station creates a ‘list of update target terminals’ containing
`
`mobile terminals that require updates” Pet. at 31, 44 (emphasis added)
`
` “the base station then sends software update information … to those
`
`mobile terminals on the list of update target terminals …” Pet. at 31
`
`(emphasis added).
`
` “The base station then removes those confirmed mobile terminals from
`
`its update target list, and uses the list to track which mobile terminals
`
`remain to be updated.” Pet. at 32 (emphasis added).
`
`Thus, the Petition establishes that the Sugita “list of update target terminals”
`
`is a list of those mobile terminals that are capable of creating patched code from the
`
`base station update.
`
`The Petition argues that Sugita discloses two methods of transmitting the
`
`update information to terminals on the “list of update target terminals:” Individual
`
`ID Addressing and Group ID Addressing.
`
`Concerning Sugita’s “Group ID Addressing,” the Petition argues that Sugita’s
`
`“disclosure of multiple ‘group units’ means that some mobile terminals belong to
`
`different groups” and that “update information sent using the group ID for the first
`
`group unit would not be meant for mobile terminals in the second group unit. Pet.
`
`at 44. This conclusion assumes that the “update information” differs by group ID.
`
`- 8 -
`
`
`
`Otherwise, the update information sent to first ground also would “be meant for
`
`mobile terminals in the second group.” 3
`
`The Petition identifies no support in Sugita for the conclusion that the update
`
`information for the first Sugita group is not the same as or meant for the update
`
`information required by the second Sugita group. Indeed, Sugita is concerned with
`
`updating all terminals that require updates. See Response at 8-9. The Petition
`
`identifies no disclosure in Sugita that suggests the groups of terminals identified on
`
`the “list of update target terminals” receive different update information based on
`
`3 Sugita describes his invention as achieving “updates of multiple mobile
`
`communications terminals using a small number of transmission packets by, in the
`
`initial stage of the update, using a group ID that applies to the group of multiple
`
`mobile communications terminals to transmit update information to each mobile
`
`communications terminal within said group, while in the final stage of the update,
`
`in other words, the stage in which the number of mobile communications terminals
`
`within the above-mentioned group that have not been updated has decreased, by
`
`transmitting update information to each mobile communications terminal using an
`
`individual ID that applies to each mobile communications terminal. The method in
`
`this invention is particularly effective in data communication systems with small
`
`communication capacities.” Ex. 1005 at [0014].
`
`- 9 -
`
`
`
`the groupings. Indeed, Sugita’s Figure 1 and the associated text establish that for
`
`the universe of terminals that require updating (i.e., terminals on the update list)
`
`those terminals receive the update information first by Group ID Addressing, then
`
`for those terminals that did not completed the update, they receive the same update
`
`information by Individual ID Addressing. Sugita never describes a situation where
`
`a mobile terminal is on the “list of update target terminals,” (i.e., capable of being
`
`upgraded) but the base station decides not to send the update information to that
`
`terminal (i.e., mobile unit).
`
`Moreover, even if the Panel agrees that the Petition specifically established
`
`that under Sugita’s Group ID Addressing scheme the base station decided not to
`
`send the update information to a mobile terminal that was on the list, the Petition
`
`also failed to establish that the terminal not sent the update was “operable to receive”
`
`the update information that was sent to the first group terminals (i.e., the at least one
`
`patch message,) but not sent to he second group terminal. In Petitioner’s view, there
`
`is some unspecified reason why the update information “would not be meant for
`
`mobile terminals in the second group unit.” Pet. at 44. If this is so, Claim 1 requires
`
`the Petition to specifically establish where Sugita disclosed the second group
`
`terminals were “capable to receive” the first group update information. The Petition
`
`failed to do this. See Response at 9-15
`
`- 10 -
`
`
`
`Concerning Sugita’s “Individual ID Addressing,” the Petition argues that
`
`Sugita terminal “m1” may not have received the update information using the Group
`
`ID Addressing (m1 was presumably in the first Sugita update group). In that case,
`
`the Petition argues that the base station would then transmit update information
`
`addressed only to terminal “m1” and not to some other mobile terminal, such as
`
`“m2.” Pet. at 47. However, the Petition does not establish that his other Sugita
`
`terminal that is not sent the update information, was (1) operable to receive the
`
`specific update information, and that it was (2) operable to create patched operating
`
`code from the update information (i.e., not already updated and removed from the
`
`“list of update target terminals”).
`
`IV. 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.
`
`- 11 -
`
`
`
`Date: August 23, 2019
`
`Respectfully submitted,
`
`By: /Al Deaver/
`Albert B. Deaver, Jr.
`Reg. No. 34,318
`Lead Counsel for Patent Owner
`
`- 12 -
`
`
`
`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: August 23, 2019
`
`Respectfully submitted,
`
`By: /Al Deaver/
`Albert B. Deaver, Jr.
`Reg. No. 34,318
`Lead Counsel for Patent Owner
`
`- 13 -
`
`
`
`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:
`
`sidley_microsoft_ironoak_ipr@sidley.com
`
`Date: August 23, 2019
`
`Respectfully submitted,
`
`By: /Al Deaver/
`Albert B. Deaver, Jr.
`Reg. No. 34,318
`Lead Counsel for Patent Owner
`
`- 14 -
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
