`
`
`Paper 8
`Entered: July 26, 2017
`
`Trials@uspto.gov
`571-272-7822
`
`
`
`
`
`
` UNITED STATES PATENT AND
`TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`NOKIA SOLUTIONS AND NETWORKS US LLC and
`NOKIA SOLUTIONS AND NETWORKS OY,
`Petitioner,
`
`v.
`
`HUAWEI TECHNOLOGIES CO. LTD.,
`Patent Owner.
`____________
`
`Case IPR2017-00593
`Patent 8,798,575 B2
`____________
`
`
`
`Before JENNIFER MEYER CHAGNON,
`MICHELLE N. WORMMEESTER, and CHRISTA P. ZADO,
`Administrative Patent Judges.
`
`WORMMEESTER, Administrative Patent Judge.
`
`
`
`
`DECISION
`Denying Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`
`I. INTRODUCTION
`Nokia Solutions and Networks US LLC as well as Nokia Solutions
`and Networks Oy (collectively, “Petitioner”) filed a Petition (Paper 2,
`“Pet.”) requesting inter partes review of claims 1–3, 5, 8, 9, 11, 16, 17, and
`19 of U.S. Patent No. 8,798,575 B2 (Ex. 1001, “the ’575 patent”). Huawei
`Technologies Co. Ltd. (“Patent Owner”) filed a Preliminary Response
`(Paper 7, “Prelim. Resp.”). We have jurisdiction under 35 U.S.C. § 314 and
`37 C.F.R. § 42.4(a). Under 35 U.S.C. § 314(a), an inter partes review may
`not be instituted “unless . . . there is a reasonable likelihood that the
`petitioner would prevail with respect to at least 1 of the claims challenged in
`the petition.” For the reasons that follow, we decline to institute an inter
`partes review.
`
`
`II. BACKGROUND
`A. Related Proceedings
`The parties identify the following federal district court case involving
`the ’575 patent: Huawei Technologies Co. v. T-Mobile US, Inc., Case No.
`2:16-cv-0055 (E.D. Tex.). Pet. 1; Paper 6, 2. The parties also identify
`several other related petitions for inter partes review. Pet. 1; Paper 6, 2.
`
`
`B. The ’575 patent
`According to the ’575 patent, there is a wide range of available packet
`data services, including e-mail services, browsing services, and file
`transmission services. Ex. 1001, 1:19, 2:51–57. A user may access multiple
`services based on one activated Packet Data Protocol Context (PDP
`Context). Id. at 2:51–60.
`
`2
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`
`The ’575 patent notes that different charging policies may apply to
`different services. Id. at 2:61–62. For example, an e-mail service provider
`may charge a user according to the times of the receiving-sending events; a
`browsing service provider may charge the user according to the data flow
`using one charging rate; and a file transmission service provider may charge
`the user also according to the data flow but using another charging rate. Id.
`at 2:62–3:1. The ’575 patent further notes that the 3rd Generation
`Partnership Project (3GPP) “is now discussing how to implement Flow
`Based Charging (FBC),” which provides for a charging system that can
`apply different charging policies to different services using the same PDP
`Context as the bearer. Id. at 3:1–26. According to the ’575 patent,
`FBC can be regarded to be implemented by filtering the IP
`flows for different services borne in the same PDP context
`through different sieve-like “filters” and then charging for
`different services according to the corresponding “filters”.
`Therefore, the “pore size” of the charging “filter” based on IP
`flows is much less than that based on one PDP Context. The
`“pore size” of the charging “filter” can be regarded as to indicate
`the size of a sieve hole. If the charging is based on one PDP
`Context, one PDP Context corresponds to one sieve hole; while
`if the charging is based on IP flows, one IP flow corresponds to
`one sieve hole and thus one PDP Context corresponds to multiple
`sieve holes in the FBC mode. Therefore, compared with the
`charging based on one PDP Context, the FBC provides more
`abundant charging means for operators or service providers.
`Id. at 3:12–26.
`Figures 2A and 2B of the ’575 patent, which are reproduced below,
`show systematic configurations of FBC. Id. at 8:9–12.
`
`3
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`
`
`In particular, Figure 2A shows the FBC systematic configuration for online
`charging, while Figure 2B shows the FBC systematic configuration for
`offline charging. Id. Traffic Plane Function (TPF) 205 bears IP flow and
`sends a Charging Rules Request to Charging Rule Function (CRF) 203 when
`an IP flow bearer is established. Id. at 3:55–58. CRF 203 selects
`appropriate charging rules according to the input information provided by
`TPF 205 and returns to TPF 205 the selected charging rules, including the
`charging mechanism. Id. at 4:6–11. The charging mechanism may be
`online charging (where the user is provided with a prepaid service) or offline
`charging (where the user is provided with a post-paid service). Id. at 4:11–
`13, 9:9–20. CRF 203 may select the charging rules according to input from
`Application Function (AF) 204 or Online Charging System (OCS) 206, as
`well. Id. at 4:33–35. Credit Control Function (CCF) 202 manages and
`controls the user’s credit and provides the related information used to
`determine the charging rules to CRF 203. Id. at 4:43–46. When the user
`uses a certain packet data service, CCF 202 also authenticates the user’s
`
`4
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`credit and provides TPF 205 with the available credit upon request. Id. at
`4:48–56, 5:16–18. TPF 205 charges for IP flows according to the charging
`rules. Id. at 4:17–20.
`Thus, when the bearer is established according to the 3GPP standard,
`the TPF requests the user’s credit from the OCS, and the OCS returns the
`credit to the TPF. Id. at 7:1–6. According to the ’575 patent, however, the
`means by which the TPF may address the correct OCS is not described in
`the 3GPP standard. Id. at 7:6–9. To address this problem, the invention of
`the ’575 patent provides a system for improving service data flow based
`charging where the CRF provides the TPF with the address information of
`the charging system. Id. at 7:33–36. In particular, the CRF may provide the
`TPF with the address information of an OCS or Offline Charging System
`(OFCS), so that the TPF can address the appropriate OCS and request the
`user’s credit information, or so that it can address the appropriate OFCS and
`send collected charging data information to the OFCS. Id. at 7:60–8:1. In
`this way, “the charging implementation procedure based on the FBC
`mechanism may be more complete and more reasonable.” Id. at 8:1–3.
`
`
`C. Challenged Claims
`Petitioner challenges claims 1–3, 5, 8, 9, 11, 16, 17, and 19 of the
`’575 patent. Claim 1 is independent and illustrative of the claims under
`challenge:
`1. A method for improving service data flow based charging in
`a communications network, comprising:
`a Charging Rules Function (CRF) determining a charging
`method and charging rules in response to a service request
`or other trigger event, and
`
`5
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`
`the CRF providing a Traffic Plane Function (TPF) with the
`charging rules and address information of a charging
`system.
`
`
`
`D. Asserted Grounds of Unpatentability
`Petitioner challenges claims 1–3, 5, 8, 9, 11, 16, 17, and 19 of the
`’575 patent on the following grounds. Pet. 3, 30–78.
`References
`Basis
`Claims Challenged
`TS 23.125,1 TS 32.200,2 and
`§ 103
`1–3, 5, 8, 9, 11, 16, 17,
`TS 32.2153
`and 19
`TS 23.125, TS 32.225,4 and
`1–3, 5, 8, 9, 11, 16, 17,
`Tdoc ’5015
`and 19
`TS 23.125, Tdoc ’501, and
`1–3, 5, 8, 9, 11, 16, 17,
`Tdoc ’1066
`and 19
`
`§ 103
`
`§ 103
`
`
`1 Overall High Level Functionality and Architecture Impacts of Flow Based
`Charging; Stage 2 (Release 6) (3GPP TS 23.125 V6.0.0), Technical
`Specification (3rd Generation P’ship Project), Mar. 2004 (Ex. 1006,
`“TS 23.125”).
`2 Telecommunication Management; Charging Management; Charging
`Principles (Release 5) (3GPP TS 32.200 V5.6.0), Technical Specification
`(3rd Generation P’ship Project), Mar. 2004 (Ex. 1007, “TS 32.200”).
`3 Telecommunication Management; Charging Management; Charging Data
`Description for the Packet Switched (PS) Domain (Release 5) (3GPP
`TS 32.215 V5.5.0), Technical Specification (3rd Generation P’ship Project),
`Dec. 2003 (Ex. 1008, “TS 32.215”).
`4 Telecommunication Management; Charging Management; Charging Data
`Description for the IP Multimedia Subsystem (IMS) (Release 5) (3GPP
`TS 32.225 V5.5.0), Technical Specification (3rd Generation P’ship Project),
`Mar. 2004 (Ex. 1009, “TS 32.225”).
`5 3GPP TSG-SA WG2 Meeting #33, Tdoc S2-032501, Temporary Document
`(3rd Generation P’ship Project), July 7–11, 2003 (Ex. 1011, “Tdoc ’501”).
`6 3GPP TSG-SA5 Meeting #21, S5B0100106, Temporary Document (3rd
`Generation P’ship Project), July 16–20, 2001 (Ex. 1010, “Tdoc ’106”).
`
`6
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`In support of its arguments, Petitioner proffers the declarations of Balazs
`Bertenyi (Ex. 1004) and Paul S. Min, Ph.D. (Ex. 1005). See id.
`
`
`E. Claim Construction
`We construe claims in an unexpired patent by applying the broadest
`reasonable interpretation in light of the specification of the patent in which
`they appear. See 37 C.F.R. § 42.100(b); Cuozzo Speed Techs. LLC v. Lee,
`136 S. Ct. 2131, 2144–46 (2016) (upholding the use of the broadest
`reasonable interpretation standard). Under this standard, claim terms
`generally are given their ordinary and customary meaning, as would be
`understood by one of ordinary skill in the art in the context of the entire
`disclosure. See In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir.
`2007). A “claim term will not receive its ordinary meaning if the patentee
`acted as his own lexicographer,” however, and clearly set forth a definition
`of the claim term in the specification. CCS Fitness, Inc. v. Brunswick Corp.,
`288 F.3d 1359, 1366 (Fed. Cir. 2002).
`Petitioner provides proposed interpretations for various limitations of
`the claims. Pet. 21–24. Patent Owner responds. Prelim. Resp. 13–16. For
`purposes of this Decision, we conclude that no term requires express
`construction to resolve a controversy in this proceeding. See Vivid Techs.,
`Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999) (“[O]nly
`those terms need be construed that are in controversy, and only to the extent
`necessary to resolve the controversy.”).
`
`
`7
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`
`III. DISCUSSION
`A. Obviousness over TS 23.125, TS 32.200, and TS 32.215
`Petitioner argues that claims 1–3, 5, 8, 9, 11, 16, 17, and 19 of the
`’575 patent would have been obvious over TS 23.125, TS 32.200, and
`TS 32.215. Pet. 30–62. For the reasons explained below, we are not
`persuaded that Petitioner has demonstrated a reasonable likelihood of
`prevailing on this asserted ground.
`
`
`1. TS 23.125
`TS 23.125 is a 3GPP technical specification that describes flow based
`charging. Ex. 1006, 1, 7. According to TS 23.125, there are many different
`services that can be used within a network, and data flows from these
`services can be charged in many different ways. Id. at 10. Charging rules
`are used for defining how a service data flow is to be charged. Id. at 11. For
`example, a charging rule may contain information on whether a particular
`service data flow, such a web service data flow, is to be charged online or
`offline. Id. at 10 (describing a web service), 12 (describing information
`included in charging rules). Figures 6.1 and 6.2 of TS 23.125, which are
`reproduced below, show the overall architectures for online and offline
`service data flow based charging.
`
`
`8
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`
`
`
`
`
`
`
`
`Figure 6.1 in particular shows the architecture for online service data flow
`based charging, while Figure 6.2 shows the architecture for offline service
`data flow based charging. Id. at 14–15. As shown in the figures, each
`system includes a Traffic Plane Function (TPF), a Service Data Flow Based
`Charging Rules Function (CRF), and a charging system that is either online
`(see id. at Fig. 6.1) or offline (see id. at Fig. 6.2).
`Figure 7.1 of TS 23.125, which is reproduced below, shows how
`information flows between the different system components.
`
`
`9
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`
`
`Figure 7.1 shows how information flows between system components
`specifically in the context of bearer service establishment. Id. at 21. At step
`1, the user sends to the TPF a request to establish a bearer service. Id. At
`step 2, the TPF sends to the CRF a request for the applicable charging rules
`and provides relevant input information for the charging rule decision. Id.
`The CRF determines the charging rules based on information from the TPF
`at step 3, and then sends to the TPF the charging rules at step 4. Id. The
`TPF installs the charging rules as indicated at step 5. Id. Finally, at step 6,
`the TPF continues with the bearer service establishment procedure. Id.
`
`
`2. TS 32.200
`TS 32.200 is a 3GPP technical specification that “describes the
`principles of charging and billing for the provision of service and services by
`a 3G-system.” Ex. 1007, 7.
`
`
`3. TS 32.215
`TS 32.215 is 3GPP technical specification that “is part of a series of
`documents specifying charging functionality in UMTS networks,” where
`
`10
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`“UMTS” refers to “Universal Mobile Telecommunications System.”
`Ex. 1008, 7. The UMTS charging architecture and principles are specified
`in TS 32.200 (Ex. 1007). Id.
`
`
`4. Analysis
`Independent claim 1 recites “the CRF providing a Traffic Plane
`Function (TPF) with . . . address information of a charging system.”
`Independent claim 16 similarly recites “wherein the CRF is configured . . .
`to provide the TPF with the . . . address information of the charging system.”
`For these limitations, Petitioner points out that TS 23.125 “discloses
`that the TPF should use the Gy and Gz interfaces to report charging
`information to the charging systems.” Pet. 42 (citing Ex. 1006, 11); see also
`Ex. 1006, Figs. 6.1, 6.2. Relying on the declaration testimony of Dr. Min,
`Petitioner explains that, “‘[i]n order to report information to the charging
`system, a POSITA would understand that the TPF would need to know the
`address information of the charging system.’” Pet. 43 (quoting Ex. 1005 ¶
`157). According to Dr. Min, “[a] POSITA would have further known that
`the address information could either be pre-configured in the TPF or
`provided by another node.” Ex. 1005 ¶ 166; see also Pet. 45. Petitioner
`argues that, “[i]f provided by another node, TS 23.125 [] renders it obvious
`that the address information should come from the CRF.” Pet. 45. In
`support of this argument, Petitioner explains that “[a] CRF could provide
`any information that would ‘define[] how [a] service data flow is to be
`charged.’” Id. (citing Ex. 1006, 11). Relying again on the declaration
`testimony of Dr. Min, Petitioner further explains that “‘[a] POSITA would
`understand that by providing the address information of a charging system, a
`
`11
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`charging rule could define whether the subscriber would be charged to, for
`example, Online Charging System #1 or Online Charging System #2,” and,
`therefore, “‘would consider the address information of a charging system to
`be information that would define how a service data flow is to be charged.’”
`Id. (citing Ex. 1005 ¶ 159).
`We are not persuaded by Petitioner’s argument. Petitioner directs us
`to where TS 23.125 teaches that “[c]harging rules contain information that
`. . . allow for defining how the service data flow is to be charged.” Pet. 45;
`Ex. 1006, 11 (emphasis added). We note that TS 23.125 further teaches that
`“[c]harging rules contain information on . . . [h]ow a particular service data
`flow is to be charged: online/offline.” Ex. 1006, 12. Thus, in the context of
`TS 23.125, “defining how the service data flow is to be charged” refers
`specifically to defining whether the service data flow is to be charged online
`or offline. See Ex. 1006, 11–12. This does not encompass defining whether
`the subscriber would be charged to Online Charging System #1 or to Online
`Charging System #2, as Petitioner argues. See Pet. 45. In view of the
`teachings in TS 23.125, neither Petitioner nor Dr. Min explains sufficiently
`why it would have been “obvious that the address information [of a charging
`system] should come from the CRF.” See id. Accordingly, based on the
`record before us, we are not persuaded that a CRF providing a TPF with
`address information of a charging system would have been obvious in the
`context of TS 23.125.
`
`12
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`
`We note Petitioner’s additional argument that “[t]he ’575 APA
`[(admitted prior art7)] also discloses a CRF providing a TPF with the
`charging rules and address information of a charging system.” Pet. 45. For
`instance, Petitioner points out that the ’575 APA teaches that, “when the
`charging method is ‘online,’ the TPF’s first step after receiving the charging
`rules is to send a message to the online charging system.” Id. at 47 (citing
`Ex. 1001, 5:12–24). Relying on the declaration testimony of Dr. Min,
`Petitioner explains that “‘a POSITA would have understood that the only
`way for a network element to contact a remote network element was with
`some sort of address information,’” which “‘could either be pre-configured
`in the TPF or provided by another node.’” Id. (quoting Ex. 1005 ¶ 1578).
`As to the latter case, Petitioner notes that the CRF “was the only node
`connected to the TPF . . . other than the [charging system].” Id. at 47–48
`(citing Ex. 1001, Figs. 2A, 2B); see also Ex. 1005 ¶ 167. Petitioner further
`explains that, according to Dr. Min, the TPF would not have received
`address information from the charging system because “‘the flow-based
`charging architecture placed the burden on the TPF to send the first message
`to a charging system,’” and “‘the TPF could send this first message only if it
`had address information of a charging system.’” Pet. 48 (quoting Ex. 1005
`
`
`7 With respect to the admitted prior art, Petitioner states: “The Grounds for
`invalidity do not directly rely on the ’575 APA. But because Patent Owner
`was describing the disclosure of TS 23.125 [], each Ground notes where
`Patent Owner admitted that certain aspects of its purported invention were
`already known and described in existing 3GPP specification documents.”
`Pet. 25.
`8 Although Petitioner cites Ex. 1005 ¶ 157, we believe Petitioner intended to
`cite Ex. 1005 ¶ 166, which includes the language quoted in the Petition.
`
`13
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`¶ 1599). Therefore, Petitioner concludes, “‘it would have been obvious to a
`POSITA that the address information [of a charging system] could either be
`pre-configured or dynamically allocated [“provided”] by the CRF.’” Id.
`(quoting Ex. 1005 ¶ 15910).
`In light of Petitioner’s arguments and evidence, including Dr. Min’s
`declaration testimony, we are persuaded that one of ordinary skill in the art
`would have known that the address information of a charging system could
`have been provided by the CRF to the TPF. See Pet. 47–48; Ex. 1005 ¶ 166.
`We note that both TS 23.125 and the ’575 APA show that the CRF is indeed
`connected to the TPF. Ex. 1006, Fig. 6.1; Ex. 1001, Figs. 2A, 2B.
`It is not sufficient, however, for Petitioner to demonstrate that each of
`the claim elements is known. See KSR Int’l Co. v. Teleflex Inc., 550 U.S.
`398, 418 (2007). Petitioner must also provide “some articulated reasoning
`with some rational underpinning to support the legal conclusion of
`obviousness.” In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006). In that
`regard, Petitioner does not provide persuasive argument as to why one of
`ordinary skill in the art would have considered modifying the system in
`TS 23.125 to arrive at the claimed invention, namely a CRF providing a TPF
`with address information of a charging system.
`As to the case where the address information is provided to the TPF
`by another node (as opposed to being preconfigured in the TPF), we note
`Petitioner’s explanation that the CRF is the only node that would have
`
`
`9 Although Petitioner cites Ex. 1005 ¶ 159, we believe Petitioner intended to
`cite Ex. 1005 ¶ 168, which includes the language quoted in the Petition.
`10 Although Petitioner cites Ex. 1005 ¶ 159, we believe Petitioner intended
`to cite Ex. 1005 ¶ 168, which includes the language quoted in the Petition.
`
`14
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`provided the TPF with address information because the CRF and the
`charging system are the only nodes connected to the TPF, and the charging
`system would not have provided its own address to the TPF. See Pet. 47–48;
`Ex. 1005 ¶¶ 167–68. However, we find this explanation to be inconsistent
`with the teachings in both TS 23.125 and the ’575 APA.
`For example, TS 23.125 teaches that “[a] TPF may be served by one
`or more CRF nodes,” and that “[t]he appropriate CRF is contacted based on
`UE identity information,” where “UE” refers to “User Equipment.”
`Ex. 1006, at 8, 16; see also id. at Fig. 7.1 (showing the UE communicating
`with the TPF). Similarly, the ’575 APA teaches that “the UE sends an
`Establish Bearer Service Request to the TPF.” Ex. 1001, 4:65–66. These
`teachings indicate that at least another node, namely the UE, is connected to
`the TPF. Accordingly, we find that these teachings also indicate that the
`address information of a charging system could have been provided by the
`CRF or the UE in the case where the address information is provided to the
`TPF by another node.
`As Patent Owner points out, neither Petitioner nor Dr. Min explains
`why a person of ordinary skill in the art would have modified the system in
`TS 23.125 to arrive specifically at a CRF providing a TPF with address
`information of a charging system, rather than to arrive at a UE providing a
`TPF with the address information or at a TPF that is already preconfigured
`with the address information. See Prelim. Resp. 44 (“However, Petitioner
`does not provide any analysis or evidence to explain why a POSITA would
`have chosen another node providing the address information over the
`traditional option of having the TPF pre-configured with the address
`information.”). Accordingly, on this record, we are not persuaded that
`
`15
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`Petitioner has provided adequately articulated reasoning with some rational
`underpinning to support the legal conclusion of obviousness. See Kahn, 441
`F.3d at 988.
`Alternatively, Petitioner argues that, “[i]f additional disclosure is
`needed, TS 32.200 [] and TS 32.215 [] disclose or render obvious a CRF
`providing a TPF with the charging rules and address information of a
`charging system.” Pet. 48. As support, Petitioner directs us to an annotated
`version of Fig. 6.1 of TS 32.200, which is reproduced below. Id. at 52.
`
`
`Figure 6.1 shows an outgoing packet-switched context from a public land
`mobile network (PLMN) packet-switched service subscriber “A” to a
`mainframe “B” via a packet data network (PDN). Ex. 1007, 67. As the
`annotated figure shows, the charging gateway function (CGF) is part of an
`offline charging system (OFCS). Pet. 49 (citing Ex. 1001, Fig. 2B;
`Ex. 1006, 15). Petitioner explains that, when establishing a new packet data
`protocol (PDP) context, the serving GPRS service node (SGSN), where
`
`16
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`GPRS refers to general packet radio service, retrieves subscriber information
`that could include a charging characteristics value. Id. at 50 (citing
`Ex. 1007, 60, 63). The SGSN forwards the charging characteristics value to
`the gateway GPRS service node (GGSN). Id. (citing Ex. 1007, 63;
`Ex. 1008, 24). According to TS 32.215, the charging characteristics value
`could contain the address information for a CGF (which is part of a charging
`system, as discussed above). Id. at 50–51 (citing Ex. 1008, 64–65). Thus, as
`Petitioner points out, “TS 32.200 [] and TS 32.215 [] disclose a SGSN
`providing address information of a charging system to a GGSN.” Id. at 52.
`We note that the ’575 patent teaches that, “[i]n a GPRS network, the TPF []
`is in the GGSN.” Ex. 1001, 4:57.
`Relying on the declaration testimony of Dr. Min, Petitioner further
`explains that a CRF providing a TPF with address information of a charging
`system, as required by claims 1 and 16, would have been obvious based on
`“‘a simple substitution of a known element—the SGSN—for another—the
`CRF—to obtain predictable results.” Pet. 52.
`We are not persuaded by Petitioner’s argument. In particular, we do
`not find that substituting the SGSN of TS 32.200 for the CRF of TS 23.125
`would have provided a CRF providing a TPF with address information of a
`charging system; rather, such substitution would have provided a SGSN
`providing a GGSN (where the TPF is) with address information of a
`charging system. As Patent Owner points out, Petitioner does not direct us
`to any evidence showing that the SGSN in TS 32.200 and the CRF in
`TS 23.125 perform the same functions. See Prelim. Resp. 53 (“the CRF
`provides charging rules to the TPF,” but “none of the evidence in the present
`
`17
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`record provides any indication that the SGSN is capable of determining
`charging rules and providing them to the TPF”).
`Moreover, the ’575 patent teaches that, “[i]n a GPRS network, . . . the
`CRF [] is an added logic entity.” Ex. 1001, 4:57–59 (emphasis added);
`compare with id. at 4:57–59 (“[i]n a GPRS network, the TPF [] is in the
`GGSN”). According to Patent Owner, “‘the prior GPRS charging system’
`shown in FIG. 1 [of the ’575 patent] including the SGSN ‘is unable to apply
`different charging policies to different services using the same PDP Context
`as the bearer,’ which is the exact functionality enabled by the charging rules
`managed by the CRF.” Prelim. Resp. 53 (citing Ex. 1001, 3:1–41).
`Even if we were to assume Petitioner intended to propose instead
`modifying the GPRS system in TS 32.200 by adding the CRF of TS 23.125,
`we still would not find that such modification would have provided a CRF
`providing a TPF with address information of a charging system; or, if it
`would have, we note that neither Petitioner nor Dr. Min explains sufficiently
`why one of ordinary skill in the art would have combined TS 23.125 with
`TS 32.200 and TS 32.215 to arrive at a CRF providing a TPF with address
`information of a charging system. See Kahn, 441 F.3d at 988. For example,
`neither Petitioner nor Dr. Min addresses why one of ordinary skill in the art
`would have modified the GPRS system in TS 32.200 to provide a CRF
`providing address information of a charging system to a TPF, when the
`SGSN in TS 32.200 already provides such address information to the GGSN
`(where the TPF is).
`Based on the record before us, we are not persuaded that a CRF
`providing address information of a charging system to a TPF would have
`been obvious over TS 23.125, TS 32.200, and TS 32.215. Accordingly, we
`
`18
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`determine that Petitioner has not demonstrated a reasonable likelihood of
`prevailing in showing that claims 1 and 16 would have been obvious over
`TS 23.125, TS 32.200, and TS 32.215. As claims 2, 3, 5, 8, 9, 11, 17, and
`19 depend from claims 1 or 16, and Petitioner has not provided separate
`arguments that would overcome the shortcomings with respect to claims 1
`and 16, we also determine that Petitioner has not demonstrated a reasonable
`likelihood of prevailing in showing that these dependent claims would have
`been obvious over the same references.
`
`
`B. Obviousness over TS 23.125, TS 32.225, and Tdoc ’501
`Petitioner argues that claims 1–3, 5, 8, 9, 11, 16, 17, and 19 of the
`’575 patent would have been obvious over TS 23.125, TS 32.225, and
`Tdoc ’501. Pet. 62–69. For the reasons explained below, we are not
`persuaded that Petitioner has demonstrated a reasonable likelihood of
`prevailing on this asserted ground.
`
`
`1. TS 32.225
`TS 32.225 is a 3GPP technical specification that “covers both online
`and offline charging for the IMS,” where “IMS” refers to “IP Multimedia
`Subsystem.” Ex. 1009, 7. “The IMS charging architecture details,
`requirements, definitions and principles are listed in TS 32.200
`[(Ex. 1007)].” Id.
`
`
`2. Tdoc ’501
`Tdoc ’501 is a 3GPP “temporary document” that “proposes
`introducing a reference point from the application function to the charging
`
`19
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`rules function to support provision of dynamic filter information.” Ex. 1011,
`1.
`
`3. Analysis
`As discussed above, claims 1 and 16 require a CRF providing a TPF
`with address information of a charging system. Referring to its arguments
`discussed above with respect to the first ground that we addressed, Petitioner
`argues that “TS 23.125 [] discloses or renders obvious this limitation.”
`Pet. 64. For the reasons given as to that ground, we are not persuaded by
`Petitioner’s argument here.
`Petitioner relies alternatively on TS 32.225 and Tdoc ’501 for
`teaching the disputed limitation. Id. In particular, Petitioner directs us to
`where TS 32.225 teaches “provisioning of address information of a charging
`system to the IMS,” where “IMS” refers to “IP Multimedia Subsystem.” Id.
`at 65 (citing Ex. 1009, 9); Ex. 1009, 9. According to Petitioner, Tdoc ’501
`“made it obvious to POSITA to add such provisioning functionality to a
`CRF.” Pet. 65. As support, Petitioner explains that Tdoc ’501 teaches that
`charging rule information may be preconfigured (static) or provided to the
`TPF (dynamic). Id. at 66 (citing Ex. 1011, 1–2). Petitioner further explains
`that, “[i]f provided, [Tdoc ’501] made clear that all information ‘must come
`from one location’: the CRF.” Id. (citing Ex. 1011, 1–2). Thus, Petitioner
`concludes, “TS 32.225 [] discloses a logical element receiving the address
`information of a charging system, and [Tdoc ’501] discloses that a CRF
`should provide all charging information.” Id. at 67.
`Relying on the declaration testimony of Dr. Min, Petitioner
`additionally explains that, “[a]t best, a CRF providing [a TPF with] address
`information of a charging system would have been obvious to try based on
`
`20
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`[Tdoc ’501]’s flow-based charging architecture,” or, “at worst, it was mere
`application of a known technique (provisioning address information) to a
`known device (a CRF) ready for improvement to yield predictable results.”
`Id. (citing Ex. 1005 ¶ 213).
`We are not persuaded by Petitioner’s argument. As Patent Owner
`points out, “Tdoc ’501 makes no such universal statement that ‘all
`information must come from the CRF’ and merely states that ‘all applicable
`charging rules must come from the one location.’” Prelim. Resp. 55 (citing
`Ex. 1011, 1). Indeed, Tdoc ’501 teaches that filters are a type of charging
`rule information, and that they “can be predefined (in the charging rules
`function, and also in the traffic plane function),” or “the application function
`can provide filter information.” Ex. 1011, 1 (emphasis added); see also id.
`at 2 (“[t]he application function . . . can supply filters”); id. (“there may
`already exist filter(s) predefined in the traffic plane”). Accordingly, not all
`charging information must come from the CRF, as Petitioner urges. See
`Pet. 66. Based on the record before us, we are not persuaded that TS 32.225
`and Tdoc ’501 teach or suggest a CRF providing a TPF with address
`information of a charging system.
`Even if we were to accept that TS 32.225 and Tdoc ’501 teach or
`suggest a CRF providing a TPF with address information of a charging
`system, we note that neither Petitioner nor Dr. Min explains sufficiently why
`one of ordinary skill in the art would have combined TS 23.125 with
`TS 32.200 and Tdoc ’501 to arrive at a CRF providing a TPF with address
`information of a charging system. See Kahn, 441 F.3d at 988. As discussed
`above with respect to the first ground that we addressed, we find that the
`teachings in TS 23.125 and the ’575 APA indicate that the address
`
`21
`
`
`
`IPR2017-00593
`Patent 8,798,575 B2
`
`information of a charging system could have been prov
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
