Paper: 9
`
`Trials@uspto.gov
`Entered: October 8, 2019
`571-272-7822
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`PANASONIC AVIONICS CORP.,
`Petitioner
`v.
`LINKSMART WIRELESS TECHNOLOGY, LLC,
`Patent Owner.
`____________
`
`Case IPR2019-00043
`Patent RE46,459 E
`____________
`
`
`Before JEAN R. HOMERE, BRIAN J. McNAMARA, and
`CHARLES J. BOUDREAU, Administrative Patent Judges.
`
`McNAMARA, Administrative Patent Judge.
`
`
`DECISION
`Denying Petitioner’s Request for Rehearing of
`Decision Denying Institution of Inter Partes Review
`37C.F.R. § 42.71(d)
`
`
`

`

`IPR2019-00043
`Patent RE46,459 E
`
`INTRODUCTION
`On June 12, 2019, Panasonic Avionics Corp. (“Petitioner”) requested
`rehearing of our Decision Denying Institution of inter partes review of U.S. Patent
`RE46,459 (the ’459 patent) entered as Paper 7 (“Decision” or “Dec.”) on May 14,
`2019. See Paper 8 (“Req. Reh’g.”). When rehearing a decision on institution, the
`Board reviews the decision for an abuse of discretion. 37 C.F.R. § 42.71(c). An
`abuse of discretion may arise if the decision is based on an erroneous interpretation
`of law, if a factual finding is not supported by substantial evidence, or if an
`unreasonable judgment is made in weighing relevant factors. Star Fruits S.N.C. v.
`U.S., 393 F.3d 1277, 1281 (Fed. Cir. 2005); Arnold P’ship v. Dudas, 362 F.3d
`1338, 1340 (Fed. Cir. 2004); In re Gartside, 203 F.3d 1305, 1315–16 (Fed. Cir.
`2000).
`The burdens and requirements of a request for rehearing are stated in
`37 C.F.R. § 42.71(d):
`(d) Rehearing. . . . The burden of showing a decision should be
`modified lies with the party challenging the decision. The request must
`specifically identify all matters the party believes the Board
`misapprehended or overlooked, and the place where each matter was
`previously addressed in a motion, an opposition, or a reply.
`We address below the matters Petitioner asserts we overlooked or
`misapprehended.
`For the reasons discussed below, the Request for Rehearing is DENIED.
`ANALYSIS
`Petitioner contends the Decision should be reversed for the following
`reasons:
`
`1. The Decision overlooked Malkin’s disclosure of redirecting a
`user’s request to a different network location.
`
`
`
`
`2
`
`

`

`IPR2019-00043
`Patent RE46,459 E
`2. The Decision overlooked Malkin’s second technique for
`redirecting a packet.
`3. The Decision misapprehended Petitioner’s mapping of the prior
`art to the claimed “redirection server.”
`4. The Decision misapprehended the lack of any limitation
`relating to whether packets enter a network.
`5. The Decision misapprehended Abraham’s user rule set, which
`includes global rules that are modified while correlated to the
`user’s temporarily assigned network address.
`6. The Decision overlooked Petitioner’s design choice argument.
`7. The Decision misconstrued “redirection server” by overlooking
`the ’459 patent’s multiple examples of “redirection.”
`Req. Reh’g. i. Petitioner categorizes reasons 1–4 as concerning (A) the
`“redirection feature” of the “redirection server,” reasons 5 and 6 as concerning
`(B) the “[u]ser’s rule set correlated to a temporarily assigned network address,”
`and reason 7 as concerning (C) an alleged misconstruction of the term “redirection
`server.” Id. As many of Petitioner’s assertions are connected to the construction
`of “redirection server,” we begin with Petitioner’s last assertion (contention (C) or
`7), i.e., that we misconstrued “redirection server.”
`Our Decision declined to adopt Petitioner’s proposed construction that a
`“redirection server” means “a server operable to control network access by
`applying the following actions: block, allow, direct.” Pet. 15. We explained that a
`prior panel of the Board construed “redirection server” as “requiring[ing] some sort
`of redirection functionality” and that “blocking and allowing are ‘further’ functions
`of the redirection server.” Dec. 10. We agreed that “‘redirection’ requires the
`server perform a redirection function as distinguished from merely blocking or
`allowing user access, i.e., there must be some form of redirection of the user’s
`request.” Id. at 11. We phrased the construction of “redirection server” to mean a
`server that “at least must be capable of redirecting a user to a network location that
`is different from the network location in the user’s request.” Dec. 12. Our
`
`
`
`3
`
`

`

`IPR2019-00043
`Patent RE46,459 E
`phraseology was consistent with the ’459 patent’s description that the redirection
`server “controls the user’s access to the network” and that a “user” may be
`“redirected to a location,” e.g., periodically. Ex. 1001, 4:63–65, 5:46–59.
`Petitioner’s contention that by using the term “redirecting a user” we
`overlooked or excluded redirecting a user’s request or a user’s packet (Req. Reh’g.
`12–13) ignores the language in our construction that the user is directed to a
`“network location that is different from the network location in the user’s request”
`(Dec. 12 (emphasis added)). Petitioner also ignores our analysis in the Decision
`that “there must be some form of redirection of the user’s request.” Id. at 11
`(emphasis added).
`Our use of the term “redirecting a user” in our construction encompasses
`requests that are provided in packets or by any other means and explicitly requires
`that the user be redirected to a “network location that is different from the location
`in the user’s request.” Thus, a user’s request in any form is part of the
`construction. Indeed, we discussed a prior art reference cited by Petitioner, i.e.,
`Malkin, in the context of “redirecting a request” and “the user’s packets.” Dec. 17.
`As discussed above, our construction requires the redirection server be capable of
`treating a request differently from allowing it or blocking it—it must be sent to a
`different location on the network.
`We now turn to Petitioner’s (A) contentions (contentions 1–4) concerning
`the redirection feature of the redirection server. Petitioner contends that our
`Decision overlooked that in Malkin the Network Access Server (NAS) handles the
`routing of the user’s request to a server that is different from that specified in the
`user’s request, i.e., to server 14 instead of its intended location. Req. Reh’g. 3.
`Petitioner’s assertion fails to recognize that our Decision states explicitly:
`Petitioner cites Malkin as disclosing how to use an NAS to redirect
`rejected requests to another server that ‘spoofs’ the expected
`
`
`
`4
`
`

`

`IPR2019-00043
`Patent RE46,459 E
`destination and sends the requesting server a denial explanation that
`appears to come from the expected destination.
`Dec. 15 (citing Pet. 23). Thus, we not only recognized the role of the NAS in
`Malkin, we cited Petitioner’s reliance on Malkin for the very proposition Petitioner
`contends we overlooked.
`Petitioner next contends that we overlooked Malkin’s second technique for
`redirecting a packet, i.e., one in which the NAS removes the request for the
`Subscriber’s packet and places it in a new packet to be sent to server 14. Req.
`Reh’g. 5–6 (citing Pet. 71, 78). Petitioner refers to this second technique as an
`address-replacement approach. Id. at 5. According to Petitioner, Malkin’s address
`replacement approach is consistent with our analysis that the ’459 patent requires
`modifying a request to access a destination on the network by changing the
`requested destination. Id. at 5–6 (citing Dec. 18). Petitioner overlooks that our
`analysis of Malkin is independent of how server 14 is accessed. Our Decision
`states, “When the NAS detects a user attempting unauthorized access, Malkin
`routes the user’s request to redirection server 14 within ISP 16.” Dec. 17
`(emphasis added). We also stated that “Malkin either allows network access for
`authorized user requests or blocks network access for unauthorized user requests,
`but it does not redirect a request to another location on the network.” Id.
`(emphasis added). As our construction requires that the claimed redirection server
`perform some function other than allowing or blocking access to a network, i.e.,
`redirecting the user to a network location that is different from the requested
`network location, we concluded that Malkin, which blocks access to the network,
`does not disclose the claimed redirection server. Id. at 17–18.
`Petitioner next contends we misapprehended Petitioner’s mapping of the
`prior art to the claimed redirection server. According to Petitioner, our discussion
`that Malkin’s redirection server 14 does not actually redirect the user’s request to
`
`
`
`5
`
`

`

`IPR2019-00043
`Patent RE46,459 E
`another site on the network demonstrates that we failed to understand that
`Petitioner relied upon Malkin’s NAS, not server 14, as disclosing the claimed
`redirection server. Req. Reh’g. 6–7. As discussed above, however, the Decision at
`15 recognizes Petitioner’s reliance on Malkin to disclose “how to use an NAS to
`redirect requests to another server.” Consistent with our claim construction, our
`analysis distinguished Malkin’s routing of a request to a different server at the ISP
`from a different location on a network.
`Further, Petitioner contends that we misapprehended the lack of any
`limitation relating to whether packets enter a network. Req. Reh’g. 7–8.
`Petitioner’s contention fails to recognize that we were not persuaded Malkin
`discloses the claimed redirection server because Malkin’s NAS and redirection
`server act to block the user’s packets from accessing the network. Dec. 17–18.
`Malkin’s redirection server sends a “spoof” message to make the Subscriber think
`it is communicating with the server at the requested destination, but the
`Subscriber’s request actually did not leave the ISP. Dec. 17. Our analysis does not
`incorporate a new limitation. Instead, our analysis is based on our construction
`that the redirection function is different from blocking access to a network.
`Finally, we turn to Petitioner’s (B) contentions (contentions 5–6) concerning
`the user’s rule set correlated to a temporarily assigned network address. As an
`initial matter, we note that the Petition (i) cites Abraham as disclosing denying or
`allowing transmission of IP packets and (ii) argues it would have been obvious to
`augment the network server’s ability to deny or allow packets, as disclosed by
`Abraham, with Malkin’s packet redirection technique, thereby making Abraham’s
`network server a redirection server. Pet. 30–31. According to Petitioner, “it would
`have been obvious for Abraham’s network server to redirect packets that are
`blocked, as described by Malkin.” Id. at 32. As discussed above, because
`Malkin’s packet redirection technique is a blocking technique that fails to disclose
`6
`
`
`
`

`

`IPR2019-00043
`Patent RE46,459 E
`the claimed redirection server as that term is construed, Petitioner’s analysis of
`Abraham does not alter our decision to deny institution. See also Dec. 18 (“As we
`are persuaded that Petitioner has not demonstrated the references disclose a
`redirection server as that term is properly construed within the meaning of the
`challenged claims, we conclude that Petitioner has not demonstrated a likelihood
`that it will prevail on its challenge to any of the claims.”).
`Claim 91 recites “a redirection server programmed with a user’s rule set
`correlated to a temporarily assigned network address.” Petitioner notes the
`Decision states “the periodic updating of global rules, even while the user is not
`connected, demonstrates that at least a portion of the user rule set is not correlated
`to the temporarily assigned network address.” Req. Reh’g. 8 (quoting Dec. 19).
`Petitioner contends that our analysis “misapprehended the claim language, which
`neither requires nor excludes the updating of a rules set that is not correlated to a
`temporarily assigned network address.” Req. Reh’g. 9. Petitioner argues the
`Decision further misapprehends the claim language by implicitly requiring the
`user’s rule set to contain only user-specific rules. Id. (quoting Dec. 19).
`Petitioner did not propose a construction of “programmed with a user’s rule
`set correlated to a temporarily assigned network address.” Moreover, Petitioner’s
`quote from the Decision in its Request for Rehearing omits the first part of the
`sentence, which reads in its entirety:
`Given that Petitioner cites applying the global rules and user rules as
`applying the user rule set, we are persuaded by Patent Owner’s
`argument that the periodic updating of the global rules, even while the
`user is not connected, demonstrates that at least a portion of the user
`rule set is not correlated to the temporarily assigned network address,
`as required by all the claims.
`Dec. 19 (emphasized portions indicating subject matter from Decision omitted in
`Petitioner’s Request for Rehearing). As discussed further below, our Decision is
`
`
`
`7
`
`

`

`IPR2019-00043
`Patent RE46,459 E
`based in part on Petitioner’s assertion that applying the user rule set includes
`applying both global rules and user rules.
`The Rehearing Request notes (i) the Petition argued that in Abraham the
`global protocol rules are applied to the user’s packets while the user is logged into
`the LAN and (ii) Patent Owner did not dispute Abraham applies global rules to a
`user’s temporarily assigned IP address. Req. Reh’g. 10–11 (quoting Pet. 37)
`(citing Pet. 34; Prelim. Resp. 22–23). Petitioner contends the user’s rule set is
`correlated to the user’s IP address because all the rules are applied when the user is
`logged in. Id.
`The Petition states that Abraham’s network server is programmed with rules
`from its filter executive that include corporate rules, global network protocol rules,
`user rules and time rules to form a user rule set for each user of a computer
`connected to the LAN. Pet. 33–34 (emphasis added). The implication of the
`Petition is that all the rules, including the global rules, are correlated to the
`temporarily assigned IP address. We note, however, the distinction in Abraham
`between user rules and other rules.
`The Rehearing Request notes Patent Owner’s arguments concerning
`Abraham’s behavior when a user does not have a temporarily assigned address.
`Req. Reh’g. 10–11 (citing Prelim. Resp. 22–23). Petitioner does not address Patent
`Owner’s argument that correlation to the temporarily assigned IP address is lacking
`in Abraham because global rules are processed before user rules and only after the
`global rules are applied does the filter engine scan the user mapping rules table
`(user rules mapped to a user’s assigned IP address) to determine if the user rule set
`contains any rules that must be applied. Dec. 18–19 (citing Prelim. Resp. 22–23).
`Thus, we are not persuaded that we overlooked or misapprehended Petitioner’s
`arguments or that Abraham teaches the language of the claims, i.e. the redirection
`
`
`
`8
`
`

`

`IPR2019-00043
`Patent RE46,459 E
`server is “programmed with a user’s rule set correlated to a temporarily assigned
`network address.”
`Finally, Petitioner contends the Decision acknowledged, but overlooked, the
`argument in the Petition that adding user-specific, timer-based rules is merely a
`matter of design choice. Req. Reh’g. 10–11 (citing Pet. 35–36; Dec. 19). The
`Decision did not need to address the timer-based rules separately because we found
`persuasive Patent Owner’s arguments that global rules are not correlated to a
`temporarily assigned network address.
`In consideration of the above, we are not persuaded that Petitioner has
`demonstrated the Decision overlooked or misapprehended subject matter that
`would justify reversing the decision to deny institution. Petitioner’s Request for
`Rehearing is DENIED.
`
`PETITIONER
`David L. McCombs
`david.mccombs.ipr@haynesboone.com
`Theodore M. Foster
`ipr.theo.foster@haynesboone.com
`John R. Emerson
`Russell.emerson.ipr@haynesboone.com
`Adam C. Fowles
`adam.fowles.ipr@haynesboone.com
`
`PATENT OWNER
`Reza Mirzaie
`rmirzaie@raklaw.com
`C. Jay Chung
`jchung@raklaw.com
`
`
`
`
`
`9
`
`