Paper 8
`Trials@uspto.gov
`571-272-7822 Entered: November 18, 2016
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`UNIFIED PATENTS INC.,
`Petitioner,
`
`v.
`
`VOIP-PAL.COM INC.,
`Patent Owner.
`____________
`
`Case IPR2016-01082
`Patent 8,542,815 B2
`____________
`
`Before BARBARA A. BENOIT, LYNNE E. PETTIGREW, and
`STACY B. MARGOLIES, Administrative Patent Judges.
`
`MARGOLIES, Administrative Patent Judge.
`
`
`
`
`
`DECISION
`Denying Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`I. INTRODUCTION
`
`
`
`Unified Patents Inc. (“Petitioner”) filed a Petition for inter partes
`review of claims 1, 2, 7, 27–29, 34, 54, 72–74, 92, 93, and 111 of U.S.
`Patent No. 8,542,815 B2 (Ex. 1001, “the ’815 patent”). Paper 1 (“Pet.”).
`Voip-Pal.com, Inc. (“Patent Owner”) filed a Preliminary Response. Paper 6
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`(“Prelim. Resp.”). Institution of an inter partes review is authorized by
`statute when “the information presented in the petition . . . and any
`response . . . shows that there is a reasonable likelihood that the petitioner
`would prevail with respect to at least 1 of the claims challenged in the
`petition.” 35 U.S.C. § 314(a); see 37 C.F.R. § 42.108. Upon consideration
`of the Petition and the Preliminary Response, we conclude that the
`information presented does not show a reasonable likelihood that Petitioner
`would prevail in establishing the unpatentability of any of claims 1, 2, 7, 27–
`29, 34, 54, 72–74, 92, 93, and 111 of the ’815 patent.
`
`A. Related Matters
`The parties identify the following district court proceedings in which
`the ’815 patent has been asserted: Voip-Pal.com, Inc. v. Verizon Wireless
`Services, LLC, Case No. 2-16-cv-00271 (D. Nev.), and Voip-Pal.com, Inc. v.
`Apple, Inc., Case No. 2-16-cv-00260 (D. Nev.). See Pet. 4; Paper 4, 2.
`Another petitioner—Apple Inc.—has filed a petition for inter partes
`review of claims of the ’815 patent in IPR2016-01201, and a petition for
`inter partes review of claims of U.S. Patent No. 9,179,005—a continuation
`of the ’815 patent—in IPR2016-001198.
`
`B. The ’815 Patent
`The ’815 patent is directed to classifying a call as a public network
`call or a private network call and producing a routing message based on that
`classification. Ex. 1001, Abstract. Figure 7 of the ’815 patent, shown
`below, illustrates a routing controller that facilitates communication between
`callers and callees:
`
`2
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`
`Id. at Fig. 7, 14:24–25, 17:16–17. As shown in Figure 7, above, routing
`controller (RC) 16 includes RC processor circuit 200, which in turn includes
`processor 202, program memory 204, table memory 206, buffer memory
`207, and I/O port 208. Id. at 17:17–22. Routing controller 16 queries
`database 18 (shown in Figure 1) to produce a routing message to connect
`caller and callee. Id. at 14:10–17, 14:24–34. Program memory 204 includes
`blocks of code for directing processor 202 to carry out various functions of
`the routing controller. Id. at 17:38–40. Those blocks of code include RC
`request message handler 250, which directs the routing controller to produce
`the routing message. Id. at 17:40–44.
`According to the ’815 patent, in response to a calling subscriber
`initiating a call, the routing controller:
`receiv[es] a callee identifier from the calling subscriber, us[es]
`call classification criteria associated with the calling subscriber
`to classify the call as a public network call or a private network
`call[,] and produc[es] a routing message identifying an address
`
`3
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`on the private network, associated with the callee[,] when the
`call is classified as a private network call and produc[es] a
`routing message identifying a gateway to the public network
`when the call is classified as a public network call.
`Id. at 14:24–34.
`Figures 8A through 8D of the ’815 patent illustrate a flowchart of an
`RC request message handler executed by the RC processor circuit. Id. at
`10:62–63. Figure 8B, shown below, illustrates steps for performing checks
`on the callee identifier:
`
`
`
`
`Id. at Fig. 8B, 19:45–49. Blocks 257, 380, 390, 396, 402 in Figure 8B above
`effectively “establish call classification criteria for classifying the call as a
`public network call or a private network call.” Id. at 22:48–51. For
`example, block 402 “directs the processor 202 of FIG. 7 to classify the call
`as a private network call when the callee identifier complies with a
`
`4
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`predefined format, i.e. is a valid user name and identifies a subscriber to the
`private network . . . .” Id. at 22:51–60. Block 269 also classifies the call as
`public or private, depending on whether the callee is a subscriber to the
`system. Id. at 22:51–23:8, 20:14–24; see also id. at 18:55–19:22.
`
`C. Illustrative Claim
`Among the challenged claims, claims 1, 27, 28, 54, 74, and 93 are
`independent. Claim 1 is illustrative and reads:
`1.
`A process for operating a call routing controller to
`facilitate communication between callers and callees in a system
`comprising a plurality of nodes with which callers and callees are
`associated, the process comprising:
`in response to initiation of a call by a calling subscriber,
`receiving a caller identifier and a callee identifier;
`locating a caller dialing profile comprising a username
`associated with the caller and a plurality of calling attributes
`associated with the caller;
`determining a match when at least one of said calling
`attributes matches at least a portion of said callee identifier;
`classifying the call as a public network call when said
`match meets public network classification criteria and
`classifying the call as a private network call when said match
`meets private network classification criteria;
`when the call is classified as a private network call,
`producing a private network routing message for receipt by a call
`controller, said private network routing message identifying an
`address, on the private network, associated with the callee;
`when the call is classified as a public network call,
`producing a public network routing message for receipt by the
`call controller, said public network routing message identifying
`a gateway to the public network.
`
`Id. at 36:14–38.
`
`5
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`D. Asserted Grounds of Unpatentability
`Petitioner contends that claims 1, 2, 7, 27–29, 34, 54, 72–74, 92, 93,
`and 111 of the ’815 patent are unpatentable based on the following specific
`grounds (Pet. 5, 15–61):
`
`Reference(s)
`
`Basis
`
`Turner1
`Turner and
`Kaczmarczyk2
`
`35 U.S.C. § 102(e)
`
`35 U.S.C. § 103(a)
`
`Challenged Claims
`1, 2, 7, 27–29, 34, 54, 72–74,
`92, 93, and 111
`1, 2, 7, 27–29, 34, 54, 72–74,
`92, 93, and 111
`
`In its analysis, Petitioner relies on the declaration testimony of Dr. Michael
`Caloyannides (Ex. 1002). Pet. 15–20, 34–40.
`
`II. DISCUSSION
`
`A. Claim Construction
`In an inter partes review, we construe claim terms in an unexpired
`patent according to their broadest reasonable construction in light of the
`specification of the patent in which they appear. 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).
`Consistent with the broadest reasonable construction, claim terms are
`presumed to have their ordinary and customary meaning as understood by a
`person of ordinary skill in the art in the context of the entire patent
`disclosure. In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir.
`2007). An inventor may provide a meaning for a term that is different from
`
`
`1 U.S. Patent No. 7,218,722 B1, filed Dec. 18, 2000 (Ex. 1003, “Turner”).
`2 U.S. Patent No. 6,961,334 B1, issued Nov. 1, 2005 (Ex. 1004,
`“Kaczmarczyk”).
`
`6
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`its ordinary meaning by defining the term in the specification with
`reasonable clarity, deliberateness, and precision. In re Paulsen, 30 F.3d
`1475, 1480 (Fed. Cir. 1994).
`Petitioner proposes constructions for various claim terms. Pet. 10–15.
`For purposes of this decision, we determine that no claim terms require
`express construction.
`
`B. Asserted Anticipation by Turner
`Petitioner contends that claims 1, 2, 7, 27–29, 34, 54, 72–74, 92, 93,
`and 111 are unpatentable under 35 U.S.C. § 102(e) as anticipated by Turner.
`Pet. 5, 15–34. Relying on the testimony of Dr. Caloyannides, Petitioner
`purportedly explains how Turner discloses each claim limitation. Id. at 15–
`34 (citing Ex. 1002).
`
`1. Summary of Turner
`Turner discloses a system for providing call management services in a
`Virtual Private Network using Voice or Video over Internet Protocol.
`Ex. 1003, 1:10–12. Turner describes allowing users of the private network
`continued use of a conventional circuit-switched voice transport network,
`such as the Public Switched Telephone Network (PSTN), to guarantee the
`Quality of Service that Virtual Private Network users have come to expect.
`Id. at 2:29–34.
`Figure 1 of Turner, shown below, illustrates a network topology of the
`system:
`
`7
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`
`
`As illustrated in Figure 1 above, Internet Protocol (IP) Gateway X 14
`serves user A 34 and user B 36, and IP Gateway Y 18 serves user C 38. Id.
`at 4:61–63. Turner discloses that an IP signaling protocol such as Session
`Initiation Protocol (SIP) handles communications between call agents 18 and
`26 in gateways 14 and 16, respectively, via managed IP network 22. Id. at
`5:5–8. PSTN 12 is also a call routing option for calls between the users. Id.
`at 4:39–44.
`Figures 4A and 4B of Turner illustrate a flowchart for handling intra-
`gateway calls. Id. at 9:13–15. Figure 4A is shown below:
`
`8
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`
`Id. at 9:13–15. As illustrated in Figure 4A above and according to an
`example described in Turner, user A dials 2002 to reach user B per step 152.
`Id. at 9:15–17. A call agent associated with user A, also known as the
`originating call agent, receives the Customer Address (CA) (e.g., 2002) and
`assigns a Network Address (NA) (e.g., 313-555-2002) in step 160. Id. at
`9:17–22. The Directory Server converts the dialed CA (2002) to the NA
`(313-555-2002) per step 170. Id. at 9:24–28. At step 176, the originating
`call agent recognizes that the called party is within the gateway. Id. at 9:30–
`
`9
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`33. According to Turner, “[t]his is a major decision point, leading either to a
`process that can be completed internally or one that involves interaction with
`a call agent at another gateway.” Id. at 9:33–36. Figure 4B, below,
`illustrates additional steps once it is determined, per step 176, that the call
`can be completed internally:
`
`
`Figure 4B, above, illustrates that, having decided to proceed
`internally, the call agent negotiates the Matching Decision Tree per step 178,
`which involves matching the preferences and privileges of the two parties
`and returning an appropriate NA. Id. at 9:37–43. If the call is approved per
`
`10
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`step 180, the NA should be unchanged from that supplied by the Directory
`Server. However, since the busy/idle status of the terminating station or
`endpoint is known only to the associated call agent, and cannot be
`anticipated by the Directory Server, “the final result might be the NA of a
`voice mailbox, administrative assistant, call attendant or even an external
`PSTN destination such as home telephone number.” Id. at 9:46–52. Thus,
`in step 183, the number provided by the Matching Decision Tree, if different
`from that provided by the Directory Server, is examined to ensure that the
`destination is still internal. Id. at 9:52–55.
`If the destination is not internal, the steps proceed to those illustrated
`in Figure 4C, shown below:
`
`
`
`11
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`Figure 4C, above, illustrates the handling of calls when the Matching
`Decision Tree has identified an external destination, either in the PSTN or in
`another customer’s Virtual Private Network. Id. at 9:57–60. For example,
`step 192 determines whether the destination is a PSTN destination, and if so,
`the call agent instructs the trunk gateway to set up the call, per step 193. Id.
`at 9:60–63.
`Referring again to step 176 of Figure 4A above, Turner discloses that
`if the call is not an intra-gateway call, the steps proceed to those illustrated
`in Figure 5A below:
`
`12
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`
`Figure 5A, above, illustrates steps for handling inter-gateway calls.
`Id. at 10:25–27. Turner describes an example in which user A on IP
`gateway X dials 3001 to reach user C on IP gateway Y. Id. at 10:28–30.
`The call agent associated with user A receives the CA (e.g., 3001) and
`assigns an NA (e.g., 313-555-2001) as the caller’s identity. Id. at 10:30–33.
`The Directory Server converts the CA (3001) to, for example, 709-555-
`3001. Id. at 10:33–35. The originating call agent recognizes that “the called
`party is within the private network, but at a location of gateway ‘X’.” Id. at
`
`13
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`10:36–38. Turner again describes this step (step 176 in Figure 4A) as “a
`major decision point,” in which, in this example, the call agent recognizes
`that “709-5555” is associated with gateway Y. Id. at 10:39–42. The steps
`proceed as illustrated in Figure 5A, including determining—per step 215
`(like step 183 in Figure 4A)—that the destination is still internal—and
`ultimately establishing a VoIP association, per step 221. Id. at 11:42–44,
`Fig. 5A.
`In a section called “External Call Handling,” Turner discloses that
`“CAs cannot begin with digits ‘8’, ‘9’, or ‘0’, these being reserved for
`private trunk network access, escape to the PSTN, and attendant services,
`respectively.” Id. at 12:44–47. According to an example in Turner, user A
`dials a PSTN number, 9-313-555-7860. Id. at 12:53–56. Per step 162 of
`Figure 4A, the Directory Server recognizes the escape code of “9” and
`declines to translate the dialed number. Id. at 12:58–61. The call agent
`ultimately requests trunk gateway X to set up a call to the PSTN. Id. at
`12:64–65; see also id. at Fig. 6D.
`
`2. Analysis
`Petitioner characterizes Turner as disclosing that “[c]alling and called
`parties can be located on private networks such as Internet Protocol
`networks connected to a gateway, or on public networks such as a PSTN.”
`Pet. 15; see also Pet. 16 (labeling portions of Turner Figure 1 as “Public
`Network” and “Private Network”). Petitioner contends, among other things,
`that Turner discloses that based on an analysis of the NA and/or CA of the
`caller and the callee, as well as stored information associated with the NA
`and CA, a call agent determines whether the callee is within the same
`gateway as the caller and can be processed internally, “such as a private
`
`14
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`network call,” and determines whether the call is directed to a callee on
`another gateway, “such as a public network call.” Id. at 18. Thus, according
`to Petitioner, Turner’s call agent classifies the call as a private network call
`or a public network call. Id. Petitioner also argues that Turner’s Directory
`Server analyzes the called address to identify codes or digits “that are
`associated with the caller as being numbers for ‘private trunk network
`access’ or ‘escape to the PSTN.’” Id.
`a. Claim 1: determining a match
`Petitioner contends that Turner discloses the step of claim 1 of
`“determining a match when at least one of said calling attributes matches at
`least a portion of said callee identifier” by disclosing that the call agent
`analyzes a caller address, callee address, and information about the
`addresses such as associated network locations to determine whether the
`caller and callee are connected to the same gateway or in the same location.
`Pet. 24. Petitioner specifically relies on decision step 176 of Figure 4A of
`Turner, which determines whether the caller and callee are located in the
`same gateway. See Pet. 17–18, 24; Ex. 1003, 9:24–36, 10:25–48. Petitioner
`also relies on decision step 366 of Figure 7B of Turner, which is part of the
`Matching Decision Tree process (block 178 of Fig. 4B) and determines
`whether the caller and callee are located in the same business unit (after
`determining in step 176 that the two are in the same gateway). See Pet. 24–
`25; Ex. 1003, 15:33–34, 16:51–57, 17:9–12. For the reasons explained
`below in connection with the classifying step, even if Turner’s step 176 or
`step 366 discloses the claimed “determining a match,” we determine that
`Petitioner does not sufficiently show on the current record that Turner
`discloses the claimed classifying the call as a public network call when “said
`
`15
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`match” meets public network classification criteria, wherein “said match” is
`the match determined by step 176 of Figure 4A or step 366 of Figure 7B.
`Petitioner alternatively contends that Turner discloses the claimed
`determining a match by disclosing that the Directory Server analyzes the
`called address to identify “codes or digits that are associated with the caller”
`as numbers for private trunk network access or escape to the PSTN.
`Pet. 18–19; see also id. at 25–26. Petitioner relies on Turner’s disclosure at
`column 12, lines 44 through 67, describing external call handling, and an
`example illustrated in Figures 4A and 6D below:
`
`
`
`
`
`
`See Pet. 18–19, 25–26; Ex. 1003, 12:44–67. As shown above, at step 164 of
`Figure 4A, if the Directory Server determines that the network address
`contains the prefix 9, the steps proceed to those shown in Figure 6D, above,
`to set up a call to the PSTN. Ex. 1003, 12:51–67.
`
`16
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`Patent Owner argues, among other things, that the predefined prefixes
`in Turner (i.e., “8” for private trunk network access, “9” for escape to the
`PSTN, and “0” for attendant services) are not “calling attributes associated
`with the caller,” as required by claim 1. Prelim. Resp. 43–45.
`We determine that Petitioner fails to show, based on its contention
`involving analysis of the digits indicative of private trunk network access or
`escape to the PSTN, that Turner discloses “determining a match when at
`least one of said calling attributes matches at least a portion of said callee
`identifier.” According to the claim, “said calling attributes” are attributes
`“associated with the caller.” Ex. 1001, 36:20–25. The prefixes in Turner,
`however, are not associated with the caller. We agree with Patent Owner
`that the passage in Turner on which Petitioner relies (column 12, lines 44
`through 67) does not describe the prefix digits as calling attributes associated
`with the caller and that Turner does not disclose that a user profile object
`includes predefined prefix digits. See Prelim. Resp. 43–44; Ex. 1003,
`12:44–67, 7:29–61, Fig. 3. Petitioner thus fails to provide sufficient
`evidence in support of its conclusory statement on page 18 of the Petition
`that the digits are “associated with the caller.”
`b. Claim 1: classifying the call
`Petitioner contends that Turner discloses the step of claim 1 of
`“classifying the call as a public network call when said match meets public
`network classification criteria and classifying the call as a private network
`call when said match meets private network classification criteria” because
`Turner’s call agent determines whether the call is an internal call such as a
`call within an IP network on a single gateway or an external call that uses
`the PSTN. Pet. 26. Petitioner relies on three different decision points in
`
`17
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`Turner in support of its contention: (i) step 176 of Figure 4A (id. at 18, 27
`(citing Ex. 1003, 9:30–36)); (ii) step 192 of Figure 4C (id. at 26 (citing
`Ex. 1003, 9:57–63)); and (iii) external call handling for reserved digits 8, 9,
`and 0 (id. at 26–27 (citing Ex. 1003, 12:44–67)). Based on the information
`presented, Petitioner fails to show sufficiently that Turner discloses the
`classifying limitation under any of these theories.
`First, step 176 of Figure 4A step determines whether a call within a
`private network is intra-gateway or inter-gateway. Ex. 1003, 9:13–15, 9:30–
`36, 10:25–28, 10:36–42. This step does not involve “classifying the call as a
`public network call when said match meets public network classification
`criteria,” as required by the claim.3
`Second, Petitioner fails to show sufficiently that step 192 involves
`classifying the call as a public network call when “said match” meets public
`network classification criteria and as a private network call when “said
`match” meets private network classification criteria. As discussed above in
`connection with the “determining a match” limitation, the claimed match
`must be when at least one of said calling attributes matches at least a portion
`of said callee identifier. Step 192—determining whether a number is a
`PSTN number—is not based on a match between a calling attribute (i.e., an
`attribute associated with the caller) and a portion of the callee identifier.
`
`3 Petitioner does not rely on the other internal match Petitioner identifies in
`connection with the “determining a match” limitation—step 366 of Figure
`4B—in support of the “classifying” limitation. Compare Pet. 24, with
`Pet. 26–27. Even so, step 366—which is directed to determining whether
`the calling and called user are in the same unit (after determining they are
`served by the same gateway in the private network)—does not involve
`classifying a call as a public network call when the match meets public
`network classification criteria. See Ex. 1003, 17:9–12, Figs. 4A, 4B, 7B.
`
`18
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`Third, with respect to the handling of reserved digits, those digits are
`not calling attributes associated with the caller and thus, as explained above,
`under this theory, Petitioner has not shown that Turner discloses the
`“determining a match” limitation of claim 1. For the same reason, Petitioner
`fails to show sufficiently that the “said match” element of the classifying
`step is met.
`For the foregoing reasons, Petitioner fails to show sufficiently that
`Turner discloses the classifying step of claim 1.
`c. Conclusion
`For the above reasons, Petitioner has not shown sufficiently that
`Turner discloses all of the limitations of independent claim 1. Petitioner
`relies on its analysis of claim 1 for similar limitations in the other challenged
`independent claims (claims 27, 28, 54, 74, and 93). Pet. 30–34.
`Accordingly, we determine that the information presented does not show a
`reasonable likelihood that Petitioner would prevail in demonstrating that any
`of claims 1, 2, 7, 27–29, 34, 54, 72–74, 92, 93, and 111 are unpatentable
`under 35 U.S.C. § 102(e) as anticipated by Turner.
`
`C. Asserted Obviousness over Turner and Kaczmarczyk
`Petitioner also contends that claims 1, 2, 7, 27–29, 34, 54, 72–74, 92,
`93, and 111 of the ’815 patent are unpatentable under 35 U.S.C. § 103(a) as
`obvious over Turner and Kaczmarczyk. Pet. 5, 34–56. Relying on the
`testimony of Dr. Caloyannides, Petitioner explains how the references
`allegedly teach or suggest the claim limitations and provides purported
`reasoning for combining the teachings of the references. Id. at 34–56 (citing
`Ex. 1002).
`
`19
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`1. Summary of Kaczmarczyk
`Kaczmarczyk discloses a call routing and signaling system for
`providing connectivity between a PSTN and an IP network. Ex. 1004, 5:56–
`62, Fig. 1. Kaczmarczyk discloses that a call control engine and a route
`intelligence engine “determine the route the call should take. In particular,
`[a] resource manager informs [the] intelligence engine of the available
`trunks over which a call may be routed in response to call processing by [a]
`call control engine, and [the] intelligence engine selects the route
`accordingly.” Id. at 8:35–40 (reference numerals omitted); see also id. at
`7:38–40 (stating that the “[i]ntelligence engine determines what route the
`call will take” (reference numeral omitted)). Figure 4A of Kaczmarczyk
`illustrates a process flow for calls to the PSTN, and Figure 4B illustrates a
`process flow for calls to the IP network. Id. at 4:50–53, 9:53–60, 11:61–63.
`
`2. Analysis
`Petitioner contends that Kaczmarczyk discloses routing calls from a
`private network to a public network, and vice versa. Pet. 37. Petitioner
`argues that Kaczmarczyk is silent regarding routing calls in a private
`network, such as calls between individuals within an IP network. Id.
`Petitioner maintains that Turner cures the deficiencies of Kaczmarczyk
`“because Turner discloses the additional techniques of determining that a
`call is directed to a party within the same (i.e. private) network, and routing
`the call to the private network recipient.” Pet. 37 (emphasis omitted).
`As with its anticipation ground, Petitioner contends that Turner’s call
`agent classifies the call as a private network call or a public network call.
`Pet. 38. Petitioner relies on the same analysis of Turner for the classifying
`step in support of its obviousness ground as it relies on for its anticipation
`
`20
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`ground. Compare Pet. 46–47, with Pet. 26–27. Petitioner also relies on
`Kaczmarczyk for disclosing “determining services available to the caller,
`using the call type and call attributes to select an appropriate route list, and
`sending the call to the intelligence engine.” Pet. 45.
`As explained above, Petitioner has not sufficiently shown that Turner
`discloses the classifying step of claim 1. Petitioner relies on the same
`disclosures in Turner that it relies on in support of the anticipation ground,
`which we find insufficient for the reasons explained above. Pet. 46–47.
`Petitioner also fails to show sufficiently that Kaczmarczyk discloses this
`limitation. Petitioner vaguely states that Kaczmarczyk discloses “selecting
`an appropriate route list,” but Petitioner does not sufficiently explain
`whether, or how, any passage in Kaczmarczyk specifically discloses
`classifying a call as a private network call or classifying a call as a public
`network call based on matching particular criteria as claimed. See Pet. 36–
`37, 45–46. We agree with Patent Owner, based on the information
`presented, that Kaczmarczyk describes choosing routing paths once it is
`already known that the destination is a private network or PSTN. See
`Prelim. Resp. 52–55, 61–66; Ex. 1004, 6:18–20, 6:30–36, 9:53–59, 10:36–
`38, 10:46–49, 11:61–64, Figs. 4A, 4B. Petitioner fails to explain, for
`example, how the cited descriptions in Kaczmarczyk disclose “classifying
`the call as a public network call when said match meets public network
`classification criteria,” as required by claim 1. Petitioner thus fails to show
`sufficiently that the combined teachings of Turner and Kaczmarczyk teach
`the classifying step of claim 1.
`For at least the foregoing reasons, we determine that the information
`presented does not show a reasonable likelihood that Petitioner would
`
`21
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`prevail in establishing that the subject matter of claims 1, 2, 7, 27–29, 34,
`54, 72–74, 92, 93, and 111 would have been obvious over the combination
`of Turner and Kaczmarczyk.
`
`III. CONCLUSION
`For the above reasons, we determine that the information presented
`does not establish a reasonable likelihood that Petitioner would prevail in
`showing that claims 1, 2, 7, 27–29, 34, 54, 72–74, 92, 93, and 111 of the
`’815 patent are unpatentable on the grounds asserted in the Petition.
`
`IV. ORDER
`
`Accordingly, it is:
`
`ORDERED that the Petition is denied as to all challenged claims, and
`
`no trial is instituted.
`
`
`
`
`
`22
`
`

`
`IPR2016-01082
`Patent 8,542,815 B2
`
`FOR PETITIONER:
`P. Andrew Riley
`Kai Rajan
`FINNEGAN, HENDERSON, FARABOW, GARRETT & DUNNER, LLP
`andrew.riley@finnegan.com
`VoIP-Pal-815-IPR@finnegan.com
`
`Jonathan Stroud
`UNIFIED PATENTS INC.
`jonathan@unifiedpatents.com
`
`
`
`FOR PATENT OWNER:
`Kerry Taylor
`John M. Carson
`KNOBBE, MARTENS, OLSON & BEAR, LLP
`2kst@knobbe.com
`2jmc@knobbe.com
`BoxDigifonica@knobbe.com
`
`23