UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`
`
`APPLE INC.
`Petitioner
`
`v.
`
`VOIP-PAL.COM, INC.
`Patent Owner
`
`
`
`
`
`
`Case No. IPR2016-01201
`Patent 8,542,815
`
`
`
`
`
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`PURSUANT TO 37 C.F.R. § 42.120
`
`
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`
`
`APPLE INC.
`Petitioner
`
`v.
`
`VOIP-PAL.COM, INC.
`Patent Owner
`
`
`
`
`
`
`Case No. IPR2016-01201
`Patent 8,542,815
`
`
`
`
`
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`PURSUANT TO 37 C.F.R. § 42.120
`
`
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`TABLE OF CONTENTS
`
`
`
`
`I.
`
`INTRODUCTION
`
`II. ARGUMENT
`
`1
`
`3
`
`3
`
`4
`
`A) CHU ‘366 AND CHEN ARE PRIOR ART—PATENT OWNER
`FAILED TO PROVE A JUNE 2005 ACTUAL REDUCTION TO
`PRACTICE
`
`I) PATENT OWNER HAS FAILED TO ESTABLISH THE
`PROFFERED DIGIFONICA SOURCE CODE WAS
`OPERATIONAL IN JUNE 2005.
`
`II) PATENT OWNER HAS FAILED TO ESTABLISH THE
`DIGIFONICA SYSTEM WAS OPERATIONAL FOR THE
`FEATURES REQUIRED BY CHALLENGED CLAIMS
`
`10
`
`III) PATENT OWNER HAS FAILED TO ESTABLISH THE
`PROFFERED DIGIFONICA SOURCE CODE PRACTICED THE
`CHALLENGED CLAIMS.
`12
`
`B) PETITIONER’S PRIOR ART COMBINATIONS RENDER
`OBVIOUS EACH OF THE CHALLENGED CLAIMS.
`
`15
`
`I) PATENT OWNER’S SUGGESTION THAT CHU ‘684 REQUIRES
`SPECIAL DIALING CONVENTIONS FINDS NO SUPPORT IN
`THE RECORD
`16
`
`(1) PSTN CALLS IN CHU ‘684 DO NOT REQUIRE A PREFIX
`DIGIT
`17
`
`(2) IP CALLS IN CHU ‘684 DO NOT REQUIRE PRIVATE
`NUMBERS
`
`21
`
`(3) PATENT OWNER’S SECONDARY CRITIQUE—THAT THE
`
`
`
`i
`
`
`
`
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`DIALING PLAN OF CHU ‘684 IS NOT USER-SPECIFIC—
`IGNORES PETITIONER’S PROPOSED COMBINATIONS
`ENTIRELY
`23
`
`III. CONCLUSION
`
`
`
`
`
`
`
`
`
`24
`
`ii
`
`
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`TABLE OF AUTHORITIES
`
`
`
`
`Cases
`
`Cooper v. Goldfarb, 154 F.3d 1321, 1327 (Fed. Cir. 1998) ..................................... 7
`
`Newkirk v. Lulejian, 825 F.2d 1581, 1582 (Fed. Cir. 1987) ..................................... 7
`
`Senju Pharmaceutical Co. v. Lupin Ltd., 780 F.3d 1337, 1347 (Fed. Cir. 2015) ... 27
`
`UMC Elecs. Co. v. United States, 816 F.2d 647, 652 (Fed. Cir. 1987). ................... 7
`
`
`
`Rules
`
`37 C.F.R. § 42.120 .................................................................................................... 1
`
`37 C.F.R. §§ 42.24(c).............................................................................................. 34
`
`
`
`
`
`
`
`
`
`iii
`
`
`
`
`I. INTRODUCTION
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`Voip-Pal focuses its opposition almost exclusively on establishing an actual
`
`reduction to practice that it alleges occurred on June 6, 2005, nearly 17 months
`
`before the provisional patent application was actually filed. Voip-Pal’s swear-
`
`behind effort suffers from a common deficiency—it relies on witness testimony
`
`that Voip-Pal could not corroborate. Voip-Pal points to Exhibit 2014 as the source
`
`code that embodied its reduction to practice. Presenting source code is not enough,
`
`however. Voip-Pal must demonstrate that the source code (a) worked for its
`
`intended purpose and (b) was coextensive with the Challenged Claims. Voip-Pal
`
`has done neither. With respect to the first point, Voip-Pal relies exclusively on
`
`witness testimony that it cannot corroborate and that is extremely biased with
`
`witnesses with enormous personal stakes in this proceeding. Voip-Pal did not
`
`compile and execute the code, despite having the code in its possession. Voip-Pal
`
`did not present a single test log or other record of testing, despite having such
`
`records in its possession. Voip-Pal did not provide a single detail as to any call that
`
`was successfully connected using the source code version in Exhibit 2014. In fact,
`
`the documentary record shows only that the source code in Exhibit 2014 was an
`
`incomplete work as of June 6, 2005, a work that continued to be edited, modified,
`
`and added to for a lengthy period thereafter.
`
`Similarly, Voip-Pal relies heavily on the Smart421 Report (Exhibit 2003) to
`
`
`
`1
`
`
`
`
`demonstrate the alleged functionality of the source code in Exhibit 2014. Its
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`reliance on this report is baffling because the report concluded that the code was
`
`only a little over half complete and that “it was not easy to ascertain which features
`
`were already implemented in the live service, as opposed to those that were able to
`
`be added in a future release.” Ex. 2003 at 12. Voip-Pal’s other exhibits fare no
`
`better and include no actual description or verification of the features that allegedly
`
`were in operation in June 2005. Voip-Pal went to great lengths to stitch together a
`
`narrative that ultimately does not appear accurate. The more plausible narrative
`
`based on the evidence is that whatever Patent Owner had on June 6, 2005, it was
`
`not nearly complete and there is no evidence that it was operational for any of the
`
`purposes described and claimed in the Challenged Patent.
`
`Voip-Pal’s two substantive criticisms of Petitioner’s proposed rejections also
`
`fail to withstand scrutiny. Its first critique relies on its own expert’s opinion that
`
`Chu ’684 would require specific dialing conventions because it’s a PBX system.
`
`But Voip-Pal’s expert has no telephony expertise, never worked on a PBX system,
`
`and his conclusion is directly opposed to the express teachings of Chu ’684. Voip-
`
`Pal’s second critique—that Chu ‘684’s enterprise-wide dial plans fail to teach the
`
`claimed calling profile—simply mischaracterizes Petitioner’s proposed rejections.
`
`The proposed combinations rely on the calling profiles taught by its secondary
`
`references (Chu ’366 and Chen), not the dial plans in Chu ‘684.
`
`
`
`2
`
`
`
`
`II. ARGUMENT
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`a) Chu ‘366 and Chen are Prior Art—Patent Owner Failed to Prove a
`June 2005 Actual Reduction to Practice
`
`Attempting to swear behind Chu ‘366 and Chen, Patent Owner shouldered
`
`
`
`the burden of establishing that the Digifonica system was actually reduced to
`
`practice in June 2005. Thus, Patent Owner must establish that (1) Digifonica
`
`constructed an embodiment that met every claim limitation of the Challenged
`
`Claims; and (2) the Digifonica system actually worked for its intended purpose
`
`coextensive with said claim limitations. Cooper v. Goldfarb, 154 F.3d 1321, 1327
`
`(Fed. Cir. 1998). It is well settled that “[t]here cannot be a reduction to practice . .
`
`. without a physical embodiment which
`
`includes all
`
`limitations of
`
`the
`
`claim.” UMC Elecs. Co. v. United States, 816 F.2d 647, 652 (Fed. Cir. 1987). “It
`
`is equally well established that every limitation of the [claim] must exist in the
`
`embodiment and be shown to have performed as intended.” Newkirk v. Lulejian,
`
`825 F.2d 1581, 1582 (Fed. Cir. 1987).
`
`
`
`Patent Owner has failed on all accounts. Specifically, Patent Owner has not
`
`demonstrated that the proffered RBR source code was operational for all pertinent
`
`functionalities in June 2005; Patent Owner has not demonstrated that the
`
`Digifonica system worked for its intended purposes in June 2005; and Patent
`
`Owner has not demonstrated that the proffered RBR source code embodied every
`
`
`
`3
`
`
`
`
`
`limitation of the Challenged Claims.
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`
`
`With respect to the final point and to focus the Board’s analysis, each
`
`Challenged Claim is directed to generating routing messages for routing
`
`communications between a caller and a callee. Ex. 1001, ‘815 Patent at
`
`Preambles for Independent Claims 1, 27, 28, 54, 74, and 93. Each requires
`
`“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.”1 Id. at Claim 1. These limitations require generating a
`
`routing message that includes a network address associated with the callee. As
`
`detailed further in section iii below, Patent Owner has failed to establish that the
`
`RBR code generated such a message.
`
`i) Patent Owner Has Failed To Establish the Proffered Digifonica Source
`Code Was Operational in June 2005.
`
`As purported evidence of an actual reduction to practice in June 2005, Patent
`
`
`
`Owner relies on Digifonica RBR server source code (specifically, Version 361),
`
`Exhibit 2014. Exhibit 2014 is a document created by Dr. Mangione-Smith from an
`
`undislcosed source code repository. It is not the original source code file from
`
`2005. Instead, it is snippets of code that were purportedly cut-and-pasted by Dr.
`
`
`1 Although the Claim language differs slightly between claims, Patent Owner has
`mapped them identically to its Digifonica system evidence.
`
`
`
`4
`
`
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`Mangione-Smith. While the printouts are dated June 6, 2005, that date was
`
`actually added as a header by Patent Owner’s counsel, not by Dr. Mangione-
`
`Smith or natively by the source code repository software. Ex. 1007, Mangione-
`
`Smith Trans., 45:8-21.
`
`
`
`Dr. Mangione-Smith never confirmed the proffered code actually worked at
`
`all, much less for its intended purposes. He did not run the software or test it in
`
`any way to confirm that the proffered code was actually operational. Id. at 47:25-
`
`49:14. Furthermore, the evidence shows that the Digifonica source code within
`
`the source code archive continued to be modified through August of 2009.
`
`Exhibit 2011, Purita Declaration (showing “last written” date for source code
`
`repository). Exhibit 2015 confirms that dozens upon dozens of revisions were
`
`made to the code in very near proximity to Version 361, suggesting a heavy
`
`amount of editing for at least the next year and a half (which was the only time
`
`frame provided in Exhibit 2015). Exhibit 2015, RBR Log Messages at 1 (showing
`
`revision history through October 2006). Indeed, six versions of code were saved
`
`within 24 hours of Version 361. The code was unquestionably a work in progress.
`
`In fact, independent 3rd party analysis of the Digifonica system in July 2005
`
`indicated that the overall system was only 56% “complete” with a 63% “surety”
`
`(which indicated how “sure” the 3rd party was that Digifonica’s system would
`
`5
`
`
`
`
`
`
`
`
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`work for its intended purpose).2 Ex. 1008, Rutter Trans. at 23:1-22. This same
`
`third party also admitted that it had no idea how the system operated with regard
`
`to the features in the code, such as formatting of phone numbers or call routing.
`
`Id. at 31:14-32:4. Critically, Patent Owner has not presented a single piece of
`
`evidence to confirm that proffered Version 361 was fully operational as opposed
`
`to in some preliminary development phase. For purposes of its swear behind, not a
`
`single witness simply compiled the code, nor did any witness run the code to
`
`determine its operability and/or functionality. In short, there is no evidence that
`
`Patent Owner “executed the [proffered] code and that the code actually worked”
`
`with respect to the relevant claimed functionalities. IPR2015-00325, Paper 62 –
`
`Final Decision at 32.
`
`
`
`Patent Owner’s witness testimony does not cure this fundamental deficiency.
`
`Patent Owner relies on the testimony of three fact witnesses in support of its
`
`swear behind effort—David Terry, Johan Emil Viktor Bjorsell, and Clay Perrault.
`
`Most prominent in Patent Owner’s Response is its reliance on the testimony of
`
`Mr. Terry. Paper 17, Response at 35-36. Mr. Terry did not write the code and was
`
`not personally familiar with the code in 2005. Ex. 1009, Terry Trans. at 24:23-
`
`25:18. He did not test the system to confirm operation of the code in 2005. Id. at
`
`2 The same third party—Smart421—also admitted that “there was work to be
`done” with the Digifonica system and that the code “was still a work in progress.”
`Ex. 1008, Rutter Trans., 24:15-19; 25:1-5.
`
`
`
`6
`
`
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`39:21-41:7. He was not responsible for defining the relevant functionalities
`
`performed by the code. Id. at 59:19-22. In fact, his description of the system
`
`appears to be based on nothing more than hindsight knowledge coupled with his
`
`having been at Digifonica in 2005. Id. at 60:19-61:17. Mr. Terry’s declaration
`
`(Exhibit 2018) also references emails in Exhibit 2026 and 2027 (and a number of
`
`emails directed to other code versions) that indicate Version 361 had been
`
`deployed for testing. Neither of these emails indicates the system was complete,
`
`operational, or that the testing was successful for any particular functionalities.
`
`Mr. Terry did not testify as to any particular call for which the system was
`
`functional, as would be required to indicate whether the system was functional for
`
`the claimed functionalities. Mr. Terry lacks first hand knowledge of the
`
`Digifonica source code as it existed in 2005, his uncorroborated recollections are
`
`non-specific, and accordingly, he lacks a proper foundation for his conclusions.
`
`
`
`Patent Owner also relies on the testimony of Digifonica’s former CTO, Clay
`
`Perreault. Like Mr. Terry, Mr. Perreault did not write or test the Digifonica code,
`
`and did not have first hand knowledge of the code in June 2005. Ex. 1010,
`
`Perreault Trans. at 59:3-23. Further, he did not analyze the RBR source code
`
`even contemporaneously with preparing his declaration. Id. at 66:19-22. Instead,
`
`Mr. Perreault relied primarily on the Challenged Patent itself to form his
`
`understanding of how the Digifonica system allegedly operated as of June 2005.
`
`7
`
`
`
`
`
`
`
`
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`Id. at 79:25-81:21 (confirming Challenged Patent was the “primary resource” to
`
`confirm his current understanding). Obviously, the Challenged Patent, which
`
`claims priority to a provisional application filed 17 months after the alleged actual
`
`reduction to practice, is not a reliable guide to what allegedly existed in June
`
`2005. Mr. Perreault’s recollections are polluted with after-the-fact review of the
`
`Challenged Patent and are further polluted by his incentive to generate his
`
`“recollection.” Mr. Perreault has a considerable stake in the outcome of the
`
`litigation against Petitioner, which Patent Owner has baselessly (but publicly)
`
`“valued” at $2.8 Billion.3 Ex. 1011, Complaint at 6. Specifically, Mr. Perrault has
`
`received two separate allotments of shares in Patent Owner—a first allotment of
`
`500,000 shares and a second allotment of 200,000 shares. Ex. 1010, Perreault
`
`Trans. at 34:18-23 and 37:14-17. Mr. Perrault’s testimony lacks foundation in
`
`personal knowledge and is heavily biased.
`
`
`
`Finally, Patent Owner relies on the testimony of Johan Emil Viktor Bjorsell.
`
`As with the other witnesses, Mr. Bjorsell could not confirm that any particular
`
`functionalities were tested and operational as of June 2005 and was not aware of
`
`any documentation detailing the same. Ex. 1012, Bjorsell Trans. at 83:15-86:5
`
`(confirming that test call details are required to determine whether certain
`
`
`3 Voip-Pal also recently announced plans to increase its damages demand to more
`than $25 Billion. https://www.voip-pal.com/voip-pal-plans-to-increase-damages.
`
`
`
`8
`
`
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`functionalities were invoked and operational and confirming that he has not
`
`identified any specific test call details from June 2005). In addition to this
`
`substantive deficiency, Mr. Bjorsell has more to gain from Voip-Pal’s lawsuit
`
`than any other declarant, and his testimony should be measured accordingly. Mr.
`
`Bjorsell was given one million shares in Voip-Pal and has “hopes and dreams”
`
`about a significant recovery. Id. at 25:5-28:6; 29:2-8. Any weight given to Mr.
`
`Bjorsell’s testimony must account for this significant bias.
`
`
`
`While Patent Owner’s witnesses each speak in terms of conclusive
`
`recollections, there is no evidence to connect Version 361 with any successful
`
`testing or successful operation that would corroborate such testimony. Emails
`
`indicating that Version 361 was sent to a staging node for testing are not
`
`indicative of the outcome of said testing or any specific functionalities that were
`
`tested. Nor are these emails indicative of the features within the code actually
`
`working for their intended purposes.
`
`
`
`One individual who potentially could answer these questions is the original
`
`author of the RBR source code, Fuad Arafa. Ex. 1013, 4-21-2017 Ltr from Kerry
`
`Taylor. Mr. Arafa was the original author of the RBR code on which Patent
`
`Owner relies for its attempted swear behind. See Ex. 2014, RBR Code at 1:23
`
`(indicating Fuad A. authored the RBR code); Ex. 1010, Perreault Trans. at 66:23-
`
`67:13 (confirming Mr. Arafa was “absolutely” responsible for writing the RBR
`
`9
`
`
`
`
`
`
`
`
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`code). Despite representing Mr. Arafa, Patent Owner did not rely on any
`
`testimony from him. In fact, Patent Owner created numerous unreasonable
`
`impediments to Petitioner’s efforts to investigate Mr. Arafa’s knowledge,
`
`including a motion to compel simply to obtain his contact information. Ex. 1014,
`
`5-1-2017 Email from Kerry Taylor (demanding, among other requirements, a sur-
`
`reply in exchange for producing Mr. Arafa for deposition and a strict limitation on
`
`what Petitioner was allowed to discuss in any deposition of Mr. Arafa). Given the
`
`evidentiary gaps described above and the lack of first hand knowledge from its
`
`proffered witnesses, Patent Owner’s decision not to present testimony from Mr.
`
`Arafa is particularly suspicious.
`
`ii) Patent Owner Has Failed to Establish the Digifonica System Was
`Operational For the Features Required by Challenged Claims
`
`Unable to directly establish what source code and/or what features of the
`
`code were operational as of June 2005, Patent Owner attempts to create inferences
`
`based on witnesses’ recollection of system testing. Of course, not a single witness
`
`could recall any specific call that was placed on the Digifonica system in June
`
`2005 and there is no documentation of calls placed that would have invoked the
`
`claimed dialed digit reformatting that is central to the Challenged Claims. Such call
`
`details are absolutely necessary to establish a baseline of relevance for the
`
`proffered testing recollections. Similar to a case previously considered by the
`
`
`
`10
`
`
`
`
`Board, Patent Owner here has not “proffer[ed] any meaningful test results, test
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`input or output files, simulation run logs, or input test parameters, which a person
`
`with ordinary skill in the art would have expected to see for testing.” IPR2015-
`
`00325, Paper 62 – Final Decision at 33.
`
`Patent Owner’s witnesses confirmed that it would be necessary to know the
`
`specific calls (e.g., caller and callee) placed on the Digifonica system to know
`
`whether certain functionality on the RBR server existed and was operational at the
`
`time of the testing. Ex. 1012, Bjorsell Trans. at 85:24-86:5. Interestingly, Mr.
`
`Perreault did suggest that he reviewed call records as part of preparing his
`
`declaration for this proceeding. Ex. 1010, Perreault Trans. at 57:18-20. However,
`
`none were produced. Because specific call details are necessary to confirm that the
`
`claimed functionality was invoked and operational, the absence of such call
`
`records renders Patent Owner’s evidence of generic calls entirely meaningless.
`
`Evidence that basic system operation had been secured in no way establishes that
`
`the system was fully operational for all functionality in the Challenged Claims.
`
`Similarly, Patent Owner’s heavy reliance on the Smart 421 Report is
`
`misplaced. That report establishes nothing about the actual operation of the code
`
`and merely confirms that some basic system operation was in place by June 2005,
`
`while simultaneously establishing that development work was ongoing. Paper 17,
`
`Response at 32-35. As the author of the Smart 421 Report confirmed, Smart 421
`
`
`
`11
`
`
`
`
`analyzed only Digifonica’s general “approach” to software coding, not the
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`functionality of the software, and Smart 421 did not confirm any specific features
`
`existed in the code. Ex. 1008, Rutter Trans. at 16:14-21:2. Notably, the Smart 421
`
`Report concluded that “it was not easy to ascertain which features were already
`
`implemented in the live service, as opposed to those that were able to be added in a
`
`future release.” Ex. 2003 at 12. The Smart 421 witness even confirmed that he had
`
`no idea which version of code was in operation when they viewed the Digifonica
`
`system. Ex. 1008, Rutter Trans. at 16:17-24. The Smart 421 Report sheds no light
`
`whatsoever on which versions or portions of the Digifonica RBR Source code were
`
`in existence and operational as of June 2005.
`
`In sum, Patent Owner relies entirely on Version 361 of the RBR code, but
`
`Patent Owner did not compile and run Version 361 to confirm operational features.
`
`Instead, Patent Owner relies on emails indicating that Version 361 had been sent
`
`for testing, but Patent Owner presents no details about any such testing. Patent
`
`Owner has not established what particular features were complete as of June 2005,
`
`and importantly, it has not established that the features required by the Challenged
`
`Claims were complete at that time. Patent Owner’s swear behind should fail for
`
`this lack of evidence.
`
`iii) Patent Owner Has Failed To Establish the Proffered Digifonica Source
`Code Practiced the Challenged Claims.
`
`
`
`12
`
`
`
`
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`
`Even assuming the proffered Digifonica RBR source code was complete by
`
`June 2005, Patent Owner has not established that the source code disclosed every
`
`limitation of the Challenged Claims. Specifically, the RBR source code does not
`
`disclose the key limitation, present in each Challenged Claim, requiring
`
`“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.” Ex. 1001, ’815 Patent at Claim 1.
`
`In its attempt to map the Challenged Claims to the Digifonica system, Patent
`
`Owner relies solely on Version 361 of the RBR server source code. For example,
`
`Patent Owner’s Response states the following for this limitation:
`
`The RBR server produces a private network routing message in the
`case of a private network call classification.
`
`
`Paper 17, Response at 16. The remainder of the chart analyses the RBR code
`
`allegedly responsible for generating said routing message. But, critically, the RBR
`
`server does not generate any routing message that includes a network address
`
`associated with the callee. After several fact depositions in this proceeding, Patent
`
`Owner had apparently recognized this deficiency. Thus, during the deposition of
`
`Patent Owner’s expert, Dr. Mangione-Smith argued that the non-routable
`
`Digifonica ID could satisfy the claimed “address, on the private network,
`
`
`
`13
`
`
`
`
`associated with the callee.” Ex. 1007, Mangione-Smith Trans. at 100:18-101:24.
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`But this position is not tenable. Multiple witnesses confirmed that the Digifonica
`
`ID populated by the RBR server is just a unique user identifier and that the RBR
`
`server does not know the network address associated with the callee. Ex. 1010,
`
`Perreault Trans. at 45:8-46:9 (confirming the routing message from the RBR
`
`includes a 12-digit “Digifonica username”); id. at 48:22-24 (confirming the RBR
`
`did not know the “network address associated with a Digifonica subscriber”); Ex.
`
`1012, Bjorsell Trans. at 120:12-121:6 (“Q. So there is no IP address of the callee
`
`IP phone in that routing message; is there?…A. That's correct. The IP address of
`
`the phone is not in that.”) (emphasis added).
`
`The record is entirely unclear as to which component was in fact responsible
`
`for obtaining the network address associated with the callee. Dr. Mangione-Smith
`
`failed to analyze any functionality outside the RBR server, including which
`
`component was responsible for obtaining an actual network address associated
`
`with the callee. Ex. 1007, Mangione-Smith Trans. at 117:15-19 (confirming he has
`
`no knowledge of what happens after the RBR transmits its routing message). And
`
`the Patent Owner’s witnesses were of no help in clarifying this key functionality.
`
`Messrs. Perreault and Bjorsell contradicted each other, identifying different
`
`components that allegedly obtained the callee’s network address. Compare Ex.
`
`1010, Perreault Trans at 48:25-50:12 (tesifying that a network address associated
`
`
`
`14
`
`
`
`
`with the callee is obtained by the B2BUA through the RADius server from a
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`database) with Ex. 1012, Bjorsell Trans. at 120:24-122:1 (contradicting Mr.
`
`Perreault, testifying that the SER maintained the network address of the callee).
`
`Patent Owner has simply failed to identify any source code in the Digifonica
`
`system that meets this crucial claim limitation. Patent Owner’s swear behind
`
`attempt cannot succeed in the absence of such evidence.
`
`b) Petitioner’s Prior Art Combinations Render Obvious Each of the
`Challenged Claims.
`
`Patent Owner’s
`
`in
`
`large part, on
`
`substantive arguments
`
`rely,
`
`mischaracterizations of Petitioner’s two proposed obviousness combinations. To
`
`reiterate the nature of the proposed combinations, both rely on Chu ‘684 as a base
`
`reference for its infrastructure, call classifying, and call routing disclosures. The
`
`proposed combinations then rely on their respective secondary references, Chu
`
`‘366 and Chen (referred to below as the “Secondary References”), for their caller
`
`profile and dialed digit reformatting disclosures. The specific combinations operate
`
`as follows:
`
`1)
`
`First, a caller’s profile is accessed, which includes caller attributes
`(e.g., IDD, NDD, area code, etc.). The Secondary References teach
`accessing a caller profile. See, e.g., Paper 1, Petition at 22-23
`(describing use of calling attributes from Secondary References);
`see also, Ex. 2043, Houh Trans. at 18:5-22:24 (explaining that the
`
`
`
`15
`
`
`
`
`
`2)
`
`3)
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`Chu ‘366 “call origin profile” includes calling attributes and that
`Chu ‘684 includes the user-specific infrastructure to support
`accessing the user-specific profile from Chu ‘366); 33:24-35:3
`(same explanation regarding Chen).
`Next, dialed digits are received by the caller pursuant to standard
`public dialing conventions, e.g., 123-4567 for a local call. The
`number reformatting taught by the Secondary References is
`performed, which results in an E.164-compliant callee identifier,
`e.g., 1-202-123-4567. See, e.g., Paper 1, Petition at 22-23.
`Finally, Chu ‘684 uses the reformatted E.164 number to determine
`whether the callee is on the private IP network or the public PSTN
`and generates routing messages accordingly. See, e.g., id. at 23-24.
`
`Patent Owner’s arguments against Petitioner’s obviousness combinations
`
`fall into two buckets—(1) that Chu ‘684 requires specific dialing conventions that
`
`are incompatible with the Secondary References and (2) that Chu ‘684 teaches an
`
`enterprise-wide, rather than user-specific, calling profiles. As detailed next, both
`
`arguments rely on mischaracterizations of the proposed combinations.
`
`i) Patent Owner’s Suggestion That Chu ‘684 Requires Special Dialing
`Conventions Finds no Support in the Record
`
`Starting with the first bucket of criticisms, Patent Owner’s critiques focus
`
`on two overriding misconceptions First, Patent Owner argues that Chu ‘684
`
`requires private dialing conventions to reach IP-based callees. Paper 17,
`
`Response at 50-57 (concluding that Chu ‘684 requires a “private number” such as
`
`
`
`16
`
`
`
`
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`a “4-digit” extension to call other subscribers on the IP network). Second, Patent
`
`Owner argues that Chu ‘684 requires a prefix digit to reach a callee on the PSTN.
`
`Id. at 46-50 (concluding that Chu ‘684 would not be combined with Chu ‘366 or
`
`Chen because a user on the Chu ‘684 system would simply dial a “PSTN access
`
`code (e.g., a prefix of “9”) . . . to call the PSTN.”). Both criticisms are factually
`
`incorrect.
`
`(1) PSTN Calls In Chu ‘684 Do Not Require a Prefix Digit
`
`Turning first to the use of a prefix digit for PSTN callees, Patent Owner and
`
`its expert appear to have entirely manufactured this requirement. Asked where in
`
`Chu ‘684 such a requirement is discussed, Dr. Mangione-Smith admitted he was
`
`unaware of any such express requirement:
`
`Q. Can you point me to any specific teaching in Chu '684 that says a
`prefix digit must be dialled (sic) to reach a destination callee on the
`PSTN?
`
`…
`
`THE WITNESS: Off the top of my head, no. It's possibly that I have
`referenced something in my declaration.
`
`…
`
`Q. Do you know if you relied on such a teaching[?]
`
`…
`
`
`
`17
`
`
`
`
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`THE WITNESS: I don't recall if I relied upon it. If I did recall
`relying upon it I would search in my report for the citation and
`probably point you back to Chu '684.
`
`Ex. 2007, Mangione-Smith Trans. at 143:17-144:11. After repeated unfulfilled
`
`requests for Dr. Mangione-Smith to review his declaration to confirm that no such
`
`teaching from Chu ‘684 was referenced in his declaration, Dr. Mangione-Smith
`
`finally confirmed that he could not find any such references in his declaration and
`
`did not recall relying on such a teaching to form his opinion. Id. at 150:21-154:1.
`
`
`
`There is no teaching in Chu ‘684 that a prefix digit must be dialed to reach a
`
`callee on the PSTN. In fact, Chu ‘684 expressly teaches that only the telephone
`
`number of a callee PSTN phone is dialed, not a prefix digit:
`
`For connectivity to the PSTN, gateways 1302 are deployed in the
`network 200. For an outgoing call from an originating point phone (IP
`phone 101 in FIG. 13), the operation is very similar to that of an intra-
`net call. From the dialed digits (of a destination phone that is
`being
`called, PSTN phone 1301),
`soft-switch 220,
`ingress
`determines that this call is for the PSTN. From the same dialed
`digits,
`the
`soft-switch
`also determines
`the
`egress PSTN
`gateway 1302 and its controlling soft-switch 1304.
`
`Ex. 1003, Chu ‘684 at 13:12-20 (emphasis added). Accordingly, Patent Owner’s
`
`argument that prefix digits would be required by Chu ‘684 is at odds with the
`
`reference’s express teachings.
`
`
`
`18
`
`
`
`Before leaving this point, Petitioner also notes that Patent Owner’s repeated
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`
`
`reliance on ¶¶ 30-47 and 72 from Dr. Mangione-Smith’s declaration is highly
`
`flawed. See Paper 17, Response at 48-49. In each of these paragraphs, Dr.
`
`Mangione-Smith discusses patents and publications (unrelated to Chu ‘684) that
`
`describe PBX systems with a prefix digit feature. From these references, Dr.
`
`Mangione-Smith concludes that “a person of ordinary skill in the art would
`
`understand Chu ‘684 to be referring to the almost universally used process of
`
`dialing a “9” to indicate the following number is an outside PSTN telephone
`
`number, based in part on the disclosures referenced here.” Ex. 2016, Mangione-
`
`Smith Decl. at ¶ 72. In other words, Dr. Mangione-Smith concludes that because
`
`other PBX systems used “9” to dial out to the PSTN, one of skill in the art would
`
`find that Chu ‘684 also requires a prefix digit to call the PSTN.
`
`There are two primary flaws with this conclusion. First, Dr. Mangione-Smith
`
`is not a person of ordinary skill in the relevant art. Here, the entire focus of the
`
`‘005 Patent is telephony technology. The written description, figures, claims, and
`
`nearly all cited art are all directed to setting up telephony communications in
`
`packet and circuit-switched (e.g., PSTN) networks.
`
`Recognizing this dynamic, Petitioner’s expert, Dr. Henry Houh, opines that
`
`the hypothetical person of ordinary skill in the art would need “(i) a Bachelor
`
`degree (or higher degree) in an academic area emphasizing electrical engineering
`
`
`
`19
`
`
`
`
`and (ii) 2-4 years of industry experience in designing or developing packet-based
`
`IPR2016-01201
`U.S. Patent No. 8,542,815
`
`and circuit-switched telecommunication systems.” Ex. 1006, Houh Decl. at ¶ 19.
`
`In stark contrast, Dr. Mangione-Smith opines that one of ordinary skill in the
`
`art would have “an undergraduate degree in either Computer Science, Compute
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
