Case IPR2017-01977
`Patent No. 8,755,376
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`TELESIGN CORPORATION
`Petitioner
`
`v.
`
`TWILIO INC.
`Patent Owner
`
`Case No. IPR2017-01977
`Patent: 8,755,376
`
`
`
`
`
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`
`
`
`
`
`
`
`
`
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`
`LIST OF EXHIBITS
`
`
`
`Exhibit
`2003
`
`2004
`
`2005
`
`2006
`
`2007
`
`2008
`
`2009
`
`
`
`
`
`
`Description
`Defendant TeleSign Corporation’s Responsive Claim Construction
`Brief, from Twilio Inc. v. TeleSign Corporation, Case No. 5:16-cv-
`06925-LHK-SVK, ECF No. 110
`Transcript of Claim Construction Hearing, from Twilio Inc. v.
`TeleSign Corporation, Case No. 5:16-cv-06925-LHK-SVK
`Order Construing Claim Terms of U.S. Patent Nos. 8,306,021;
`8,837,465; and 8,755,376, from Twilio Inc. v. TeleSign Corporation,
`Case No. 5:16-cv-06925-LHK-SVK, ECF No. 137
`Deposition Transcript of Dr. Seth Nielson, from Twilio Inc. v.
`TeleSign Corporation, Case No. 5:16-cv-06925-LHK-SVK
`Declaration of Seth Nielson, Ph.D., from Twilio Inc. v. TeleSign
`Corporation, Case No. 5:16-cv-06925-LHK-SVK
`TeleSign’s Patent Local Rule 4-2 Preliminary Claim Constructions,
`from Twilio Inc. v. TeleSign Corporation, Case No. 5:16-cv-06925-
`LHK-SVK
`Information Disclosure Statement for Application No. 13/743,078,
`January 16, 2013
`
`i
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`
`TABLE OF CONTENTS
`
`INTRODUCTION ......................................................................................... 1 
`
`THE LEVEL OF ORDINARY SKILL IN THE ART ............................... 3 
`
`
`I. 
`
`II. 
`
`III.  PETITIONER FAILED TO PROPERLY ADDRESS CLAIM
`CONSTRUCTION ......................................................................................... 3 
`
`IV.  PETITIONER HAS NOT SHOWN A REASONABLE LIKELIHOOD
`THAT AT LEAST ONE CLAIM OF THE ’376 PATENT IS
`UNPATENTABLE ........................................................................................ 8 
`
`A. 
`
`B. 
`
`Legal Standard for Obviousness ........................................................... 9 
`
`Ground 1: The Petition Fails to Demonstrate that the Challenged
`Claims Would Have Been Obvious Over Maes in View of Ransom . 10 
`
`1. 
`
`Petitioner Fails to Show, Individually or in Combination, that
`Maes and Ransom Disclose the “exposing the plurality of API
`resources through a representation state transfer (REST) API”
`Limitation .................................................................................. 11 
`
`a.  Maes Fails to Disclose the “exposing the plurality of API
`resources through a representation state transfer (REST)
`API” Limitation .............................................................. 11 
`
`b. 
`
`c. 
`
`Ransom Fails to Disclose the “exposing the plurality of
`API resources through a representation state transfer
`(REST) API” Limitation ................................................. 14 
`
`Petitioner Does Not Explain the Motivation to Combine
`Maes and Ransom ........................................................... 14 
`
`2. 
`
`Petitioner Fails to Show, Individually or in Combination, that
`Maes and Ransom Disclose the “receiving a REST API request
`that specifies and API resource URI” Limitation ..................... 20 
`
`a.  Maes Fails to Disclose the “receiving a REST API
`request that specifies and API resource URI” Limitation
` ........................................................................................ 20 
`
`ii
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`
`b. 
`
`Ransom Fails to Disclose the “receiving a REST API
`request that specifies and API resource URI” Limitation
` ........................................................................................ 23 
`
`c. 
`
`Petitioner Does Not Explain the Motivation to Combine
`Maes and Ransom ........................................................... 24 
`
`3. 
`
`Petitioner Fails to Show that Maes Discloses the “responding to
`the API request according to the request and the specified
`resource URI” Limitation ......................................................... 28 
`
`a.  Maes Fails to Disclose the “responding to the API
`request according to the request and the specified
`resource URI” Limitation ............................................... 28 
`
`b. 
`
`Petitioner Fails to Address the “responding to the API
`request according to the request and the specified
`resource URI” Limitation ............................................... 28 
`
`C. 
`
`Ground 3: The Petition Fails to Demonstrate that the Challenged
`Claims Would Have Been Obvious Over ETSI-202-391-4 in View of
`Ransom ................................................................................................ 29 
`
`1. 
`
`Petitioner Fails to Show, Individually or in Combination, that
`ETSI and Ransom Disclose the “exposing the plurality of API
`resources through a representation state transfer (REST) API”
`Limitation .................................................................................. 30 
`
`a. 
`
`b. 
`
`c. 
`
`ETSI-202-391-4 Fails to Disclose the “exposing the
`plurality of API resources through a representation state
`transfer (REST) API” Limitation ................................... 30 
`
`Ransom Fails to Disclose the “exposing the plurality of
`API resources through a representation state transfer
`(REST) API” Limitation ................................................. 33 
`
`Petitioner Does Not Explain the Motivation to Combine
`ETSI-202-391-4 and Ransom ......................................... 33 
`
`2. 
`
`Petitioner Fails to Show, Individually or in Combination, that
`ETSI or Ransom Disclose the “receiving a REST API request
`that specifies an API resource URI” Limitation ....................... 38 
`
`iii
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`
`a. 
`
`ETSI-202-391-4 Fails to Disclose the “receiving a REST
`API request that specifies an API resource URI”
`Limitation ....................................................................... 38 
`
`b. 
`
`c. 
`
`Ransom Fails to Disclose the “receiving a REST API
`request that specifies an API resource URI” Limitation 41 
`
`Petitioner Does Not Explain the Motivation to Combine
`ETSI and Ransom ........................................................... 41 
`
`3. 
`
`Petitioner Fails to Show that ETSI Discloses the “responding to
`the API request according to the request and the specified
`resource URI” Limitation ......................................................... 45 
`
`a. 
`
`b. 
`
`ETSI Fails to Disclose the “responding to the API request
`according to the request and the specified resource URI”
`Limitation ....................................................................... 46 
`
`Petitioner Fails to Address the “responding to the API
`request according to the request and the specified
`resource URI” Limitation ............................................... 46 
`
`V.  CONCLUSION ............................................................................................ 47 
`
`
`
`iv
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`I.
`
`INTRODUCTION
`
`The Board should not institute inter partes review (IPR) on claims 1-3, 5,
`
`14, 16, 17, and 19 (“the challenged claims”) because Petitioner has not shown a
`
`reasonable likelihood of prevailing on any proposed ground. Grounds 1 and 3 are
`
`the only grounds that address the sole-challenged independent claim, claim 1. By
`
`failing on these two grounds, all of Petitioner’s grounds fail.
`
`First, Petitioner carries the burden to demonstrate invalidity. As part of its
`
`burden, Petitioner must explain its claim construction positions. However, in an
`
`apparent attempt to preserve the ability to make different arguments in the co-
`
`pending District Court litigation, Petitioner has obscured its claim constructions in
`
`this proceeding. In the co-pending District Court litigation, Petitioner urged the
`
`Court to adopt specific definitions for “URI” and “REST,” among many other
`
`terms. Petitioner briefed its specific claim-construction positions and argued them
`
`live to the District Court. Yet knowing that these terms were disputed, Petitioner
`
`offers a two-sentence claim construction section in its petition based exclusively on
`
`BRI boilerplate. The Board has consistently rejected petitions with similar claim-
`
`construction strategies, and it should do so in this proceeding also.
`
`Second, Petitioner has failed to show that any of the references, taken alone
`
`or in combination, teach all the claim limitations. As for Ground 1, Petitioner fails
`
`to demonstrate that either reference (Maes or Ransom) teaches (1) the “exposing
`
`1
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`the plurality of API resources through a representational state transfer (REST)
`
`API” limitation, (2) the “receiving a REST API request that specifies an API
`
`resource URI” limitation, and (3) the “responding to the API request according to
`
`the request and the specified resource URI”—especially when the proper claim
`
`constructions of REST and URI are applied. As for Ground 3, Petitioner similarly
`
`fails to show that any of applied references, individually or in combination, teaches
`
`(1) “exposing the plurality of API resources through a REST API,” (2) “receiving a
`
`REST API request that specifies an API resource URI” limitation, and (3)
`
`“responding to the API request according to the request and the specified resource
`
`URI.” And for both grounds, Petitioner wholly ignored the “responding to the API
`
`request according to…the specified resource URI” portion of the “responding”
`
`limitation. These flaws are fatal to the Petition, and the Board need not even look
`
`at combinability. Petitioner failed on the first step of proving obviousness.
`
`Third, even if one of the references taught the “exposing,” “receiving,” and
`
`“responding” limitations, which none do, Petitioner fails to show the motivation
`
`for combining the references. Instead, Petitioner argues that someone of skill in
`
`the art would have the skill set to combine the references. The law, however,
`
`requires that Petitioner also explain why a person of ordinary skill would have
`
`combined elements from the references in the way the claimed invention does.
`
`Kinetic Tech., Inc. v. Skyworks Solutions, Inc., IPR2014-00529, Paper 8 at *15
`
`2
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`(P.T.A.B. Sept. 23, 2014) (Petitioner “does not explain the ‘how,’ ‘what,’ and
`
`‘why’ of the proposed combination of references”). Petitioner skipped the “why”
`
`in both Grounds 1 and 3. This is another fatal oversight in proving an obviousness
`
`combination.
`II. THE LEVEL OF ORDINARY SKILL IN THE ART
`
`Petitioner asserts that a POSA would have “a bachelor’s degree in computer
`
`science with at least two years of experience in application development.”
`
`(Petition at 8.) Petitioner does not explain why someone at this level of skill would
`
`have the ability to modify the primary references or why someone of this skill
`
`would be motivated to modify the primary references in the way described by
`
`Petitioner.
`
`As explained below, using the Petitioner’s definition of a POSA, Petitioner
`
`has failed to show that the POSA would have any motivation to combine the
`
`references.
`III. PETITIONER FAILED TO PROPERLY ADDRESS CLAIM
`CONSTRUCTION
`
`Petitioner’s “Claim Construction” section of its Petition is two sentences.
`
`(Petition at 8.) One sentence describes the law. The second sentence says simply
`
`that the BRI should be applied to all claim terms. (Petition at 9.)
`
`Petitioner and Patent Owner are involved in co-pending District Court
`
`litigation and the parties have already briefed and argued claim construction,
`
`3
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`including for the terms “URI” and “REST.” (EX2003 at 5 and 6; EX2004 at
`
`15:12-17.)1 The Court has even issued a claim construction order. (See, generally
`
`EX2005.) Petitioner, however, explains none of these facts to the Board, including
`
`that the parties had already taken claim construction positions and were briefing
`
`claim construction at the time Petitioner filed its petition.
`
`Petitioner failed to address claim construction issues as required by Rule
`
`42.104(b)(3). That failure is an independent reason for the Board to deny
`
`institution. Jiawei Tech. Ltd. v. Simon Nicholas Richmond, IPR2014-00937, Paper
`
`24, at 1 (P.T.A.B. Feb. 6, 2014) (“Our denial of review these claims was premised
`
`on Petitioner’s failure to offer a construction”).
`
`If the Petitioner is aware that the Patent Owner may dispute the breadth of
`
`the claim construction of a term in the challenged claims, the Petitioner should
`
`explain the reasons for its proposed construction and, further, a Petitioner should
`
`do more than merely state that the BRI standard applies. Synopsys, Inc. v. Mentor
`
`Graphics Corp., IPR2012-00041, Paper 16 (P.T.A.B. Feb. 22, 2013); see also
`
`
`1 Patent Owner and Petitioner exchanged terms and constructions on June 6, 2017.
`Expert declarations were submitted in July of 2017 and deposed in August. Patent
`Owner and Petitioner’s Claim Construction briefs were filed in August of 2017.
`The claim construction hearing was held on October 5, 2017 and the Order issued
`on October 13, 2017.
`
`4
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`Wowza Media Sys., LLC v. Adobe Systems Inc., IPR2013-00054, Paper 12
`
`(P.T.A.B. Apr. 8, 2013); see also Research in Motion Corp. v. Wi-LAN USA Inc.,
`
`IPR2013-00125, Paper 8 (P.T.A.B. July 29, 2013) (noting that while the Petitioner
`
`did propose a construction, it was “too broad and inconsistent with [p]etitioner’s
`
`argument made in the parallel litigation.”). Petitioner knew that the terms “URI,”
`
`and “REST” were important in both the District Court and in this proceeding.
`
`(EX2003 at 5 and 6; see also EX2008.) By obscuring its positions in this
`
`proceeding, Petitioner is trying to avoid preclusion issues in the District Court,
`
`where it is advocating invalidity based on 102(g) system art not in front of the
`
`Board. The Board should continue to reject Petitioner’s type of gamesmanship.
`
`The rules and case law are clear. Jiawei Tech. Ltd., IPR2014-00937, Paper 24 at 1
`
`(“Our denial of review these claims was premised on Petitioner’s failure to offer a
`
`construction and analysis of a term critical to understanding the scope of
`
`independent claims”). Petitioner was obligated to raise any construction that it
`
`knew could be an issue, and Petitioner’s failure to do so justifies the Board
`
`refusing to institute.
`
`The following three terms are important. Petitioner’s failure to address is an
`
`independent reason for denying institution.
`
`URI: After hotly contested briefing and oral argument, Petitioner agreed
`
`that the term URI is defined by the standard, RFC 3986, a term first raised in May
`
`5
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`of 2017. (EX2003 at 5; see also EX2004 at 15:12-17.) Petitioner also ultimately
`
`agreed that URI should be construed as “a compact sequence of characters that
`
`identifies an abstract or physical resource.” (EX2004 at 15:12-17.) In its Petition,
`
`Petitioner does not explain whether or not it is applying this District Court
`
`construction. Does RFC 3986, the standard, define the BRI? Is BRI broader than
`
`the industry-standard definition set forth in RFC 3986? And if Petitioner is
`
`advocating for a different construction, it does not explain what that construction is
`
`or why the District Court construction is not the BRI. Further, Petitioner does not
`
`offer any analysis of the “compact sequence” or “abstract or physical resource”
`
`terms in the District Court construction. By refusing to address the construction of
`
`this term, Petitioner has violated C.F.R §42.104(b)(3) and the Board’s case-law
`
`guidance. And by hiding its positions, Petitioner has put both the Patent Owner
`
`and the Board at a disadvantage. We are all left to guess at Petitioner’s true
`
`arguments.
`
`REST: Petitioner also ignores the term REST. Throughout the District
`
`Court’s claim construction Petitioner took the position that the term REST is
`
`indefinite. (EX2003 at 6.) This term was the focus of briefing and oral argument.
`
`(See EX2004 at 15:22-41:8.) Yet after telling a Federal Court that Petitioner could
`
`not understand the term “REST,” Petitioner does not even offer the Board a
`
`construction of the term. Petitioner knew that the “REST” term was disputed but
`
`6
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`chose to ignore it in the petition. (See e.g., EX2003 at 6 (arguing that the term
`
`REST is “indefinite” or alternatively should be construed as “a programmatic
`
`communication interface using a varying level of statelessness.”).) Once again,
`
`Petitioner is forcing Patent Owner to guess as to Petitioner’s construction and
`
`invalidity positions.
`
`Petitioner seems to be flipping its position from the District Court
`
`litigation—although it is hard to tell from the ambiguous language in the Petition
`
`and the conflict between the Petition and the Petitioner’s expert. In the District
`
`Court proceedings, Petitioner’s expert told the District Court that “REST” was
`
`indefinite. Petitioner’s expert even testified under oath that he did not understand
`
`the term “REST.” (EX2006 at 40:23-41:3 (“I’m saying the term is indefinite.”);
`
`see also EX2007 at ¶32.) Now, Petitioner’s same expert is telling the Board that
`
`he understands the “REST” term and that he can analyze obviousness using that
`
`term applying Patent Owner’s proposed District Court construction. Petitioner’s
`
`expert does not explain the sudden change in position. Further, while Petitioner
`
`states that it seeks BRI for all terms, its expert states that he applied Twilio’s
`
`proposed District Court construction for REST API: “For purposes of my analysis,
`
`I have used Twilio’s proposed construction and any references to REST, REST
`
`API’s, RESTful, etc. within this report are based on that construction.” (E.g., Ex.
`
`7
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`1009 at [0060].) But Petitioner does not explain what construction of REST
`
`Petitioner is using to support its Petition grounds.
`
`The District Court construed REST API as “an application programming
`
`interface that complies with Representational State Transfer (REST) interface
`
`constraints, which are: identification of resources; manipulation of resources
`
`though representations; self-descriptive messages; and, hypermedia as the engine
`
`of application state.” (EX2005 at 42.) It is unclear whether Petitioner is using this
`
`construction as the BRI or some different construction.
`
`Again, by failing to explain its constructions, Petitioner has violated C.F.R
`
`42 §42.104(b)(3) and this Board’s case-law guidance. The Board should refuse to
`
`institute.
`IV. PETITIONER HAS NOT SHOWN A REASONABLE LIKELIHOOD
`THAT AT LEAST ONE CLAIM OF THE ’376 PATENT IS
`UNPATENTABLE
`
`Petitioner fails on three elements in the only challenged independent claim.
`
`Failing on any single element is fatal to the Petition and justifies denying
`
`institution.
`
`First, Petitioner fails to show that any reference teaches the element:
`
`exposing the plurality of API resources through a Representation State Transfer
`
`(REST) API.
`
`8
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`
`Second, Petitioner fails to show that any reference teaches the element:
`
`receiving a REST API request that specifies an API resource URI.
`
`Third Petitioner fails to show that any reference teaches the element:
`
`responding to the API request according to the request and the specified resource.
`
`Fourth, even if one of the prior-art references taught the missing elements,
`
`which they do not, Petitioner still failed to show the required motivation to
`
`combine the prior art. Petitioner explains that combination is possible but fails to
`
`explain why the POSA (which is a person with a bachelor’s degree and two-years’
`
`experience according to Petitioner) would be motivated to make the combination
`
`for the addressable URI element or the mapping element.
`
`A. Legal Standard for Obviousness
`Obviousness requires (1) the prior art to teach all of the elements of the
`
`claimed invention; (2) a suggestion to those of ordinary skill in the art that they
`
`should make the claimed device; and (3) a reasonable expectation of success in
`
`combining the prior art. See, e.g., Par Pharma, Inc. v. TWI Pharma, Inc., 773 F.3d
`
`1186, 1197 (Fed. Cir. 2014). Petitioner must “explain why a person of ordinary
`
`skill in the art would have combined elements from specific references in the way
`
`the claimed invention does.” Kinetic Tech., Inc., IPR2014-00529, Paper 8 at *15;
`
`see also In re Magnum Oil Tools Int'l, Ltd., 829 F.3d 1364, 1381 (Fed. Cir. 2016).
`
`Explaining only that the POSA could combine the references to create the claimed
`
`9
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`invention is not sufficient to demonstrate obviousness. Kinetic Tech., Inc.,
`
`IPR2014-00529, Paper 8 at *15; see also Duo Sec. Inc., IPR2017-01041, 2017 WL
`
`4677235, at *9 (Oct. 16, 2017) (“Petitioner's arguments and evidence are
`
`insufficient to explain and demonstrate why an ordinarily skilled artisan would
`
`have combined” the references).
`
`B. Ground 1: The Petition Fails to Demonstrate that the Challenged
`Claims Would Have Been Obvious Over Maes in View of Ransom
`
`Ground 1 should be denied first because neither Maes nor Ransom disclose
`
`(at least) three elements: (i) exposing the plurality of API resources through a
`
`Representation State Transfer (REST) API, (ii) receiving a REST API request that
`
`specifies an API resource URI, and (iii) responding to the REST API request and
`
`according to the request and the specified resource URI. Ground 1 can be
`
`alternatively denied because Petitioner failed to demonstrate why a POSA would
`
`combine Maes and Ransom.
`
`10
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`
`1.
`
`Petitioner Fails to Show, Individually or in Combination,
`that Maes2 and Ransom Disclose the “exposing the plurality
`of API resources through a representation state transfer
`(REST) API” Limitation
`a. Maes Fails to Disclose the “exposing the plurality of
`API resources through a representation state transfer
`(REST) API” Limitation
`While Petitioner suggests
`
`that Maes’ “MakeCall,” “DropCall,” or
`
`“TransferCall,” could be accessed through a REST API, Petitioner does not point
`
`to any portion of Maes as disclosing “REST.” (See Petition at 20-24.) Maes
`
`makes no mention of “REST.” (See EX1003.) Instead, the cited disclosure
`
`discusses SOAP. (Id.) “MakeCall,” “DropCall,” and “TransferCall” are SOAP
`
`enumeration values. (Petition at 21; see also EX1003 at 34:20-67.) Petitioner
`
`offers no cites or support for any contention that the values are somehow exposed
`
`via a REST API. (Petition at 20-24.)
`
`Petitioner does not explain what construction of “REST API” it is using or
`
`why it and its expert are using different constructions. (Id.; see Section III.) The
`
`expert it relies on in the Petition is the same expert who opined to the District
`
`
`2 Maes, a SOAP reference, was cited during prosecution of the ’376 Patent. (See
`EX2009.) The Patent Office was therefore aware of Maes and its SOAP based
`teachings and was aware of REST from the ’376 Patent’s disclosure. Petitioner’s
`SOAP to REST arguments are simply rehashing what the Patent Office has already
`reviewed.
`
`11
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`Court that “REST” was indefinite and he did not understand the term. (EX2006 at
`
`26:14-18 (I do remember thinking it [REST] was unclear”); 40:23-41:3 (“I’m
`
`saying the term is indefinite.”); see also EX2007 at ¶32.) Did Petitioner and its
`
`expert change their position? Also, the District Court ultimately construed “REST
`
`API” as “an application programming
`
`interface
`
`that complies with
`
`Representational State Transfer (REST)
`
`interface constraints, which are:
`
`identification of resources; manipulation of resources though representations; self-
`
`descriptive messages; and, hypermedia as the engine of application state.”
`
`(EX2005 at 42.) Petitioner should have pointed out how the cited material in Maes
`
`matches the requirement that a REST API comply with Representational State
`
`Transfer (REST) interface constraints. Alternatively, Petitioner should have stated
`
`that it was using a different construction and explained why. See Synopsys, Inc.,
`
`IPR2012-00041, Paper 16 at 13-14; see also Wowza Media Sys., LLC, IPR2013-
`
`00054, Paper 12 at 6. Petitioner also should have shown how the cited material
`
`shows
`
`the
`
`identification of resources, manipulation of resources
`
`though
`
`representations, self-descriptive messages, and, hypermedia as the engine of
`
`application state constraints. Considering that Petitioner knew Patent Owner
`
`disputed the construction of REST API, Petitioner should have stated the applied
`
`construction for this term if it was applying some specific meaning. Jiawei Tech.
`
`12
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`Ltd., IPR2014-00937, Paper 24 at 1 (“Our denial of review these claims was
`
`premised on Petitioner’s failure to offer a construction”).
`
`Further, Petitioner does not attempt to explain how Maes’ “MakeCall,”
`
`“DropCall,” and “TransferCall” are exposed through a REST API. (Petition at 20-
`
`24.) Even assuming that one of Maes taught a REST API, which it does not,
`
`Petitioner does not explain how the reference teaches “exposing” API resources
`
`through a REST API. (Petition at 20-21.) Petitioner fails to identify the particular
`
`disclosure that links the alleged plurality of API resources of Maes to a REST API.
`
`(Petition at 20-24.) How are API resources exposed through a REST API? It is
`
`Petitioner’s burden to identify the disclosure in the references that it contends
`
`teaches the claim language. In re Magnum Oil Tools Int’l, Ltd., 829 F.3d at, 1377-
`
`81. As a result, Petitioner has not met its burden. Id.
`
`If Petitioner is applying some specific construction of “exposing” to draw
`
`the link between Maes and the “exposing” element, Petitioner has not revealed that
`
`construction and the construction is not obvious from Petitioner’s arguments.
`
`Again, Petitioner is obligated to raise its claim construction positions. Jiawei Tech.
`
`Ltd., IPR2014-00937, Paper 24 at 1.
`
`13
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`
`b.
`
`Ransom Fails to Disclose the “exposing the plurality
`of API resources through a representation state
`transfer (REST) API” Limitation
`
`Petitioner does not cite to any Ransom disclosure to support its claim that
`
`Ransom teaches a REST API. (Petition at 21-24.) In fact, the term “API” appears
`
`nowhere in Ransom. (See, generally EX1004.) The cited portions of Ransom also
`
`make no reference to exposing API resources through a REST API—let alone
`
`exposing a plurality of SOAP API resources (as relied upon by Petitioner) through
`
`a REST API. (Petition at 20-24.) As a result, Petitioner has not met its burden to
`
`identify the disclosure in the references that support its contentions. In re Magnum
`
`Oil Tools Int’l, Ltd., 829 F.3dat 1377-81.
`
`c.
`
`Petitioner Does Not Explain the Motivation to
`Combine Maes and Ransom
`
`Assuming that either Maes or Ransom teaches the “exposing” element—
`
`neither do—Petitioner is obligated to explain why someone of skill in the art
`
`would combine Maes and Ransom to come up with the claimed invention. Kinetic
`
`Tech., Inc., IPR2014-00529, Paper 8 at *15; see also In re Magnum Oil Tools Int'l,
`
`Ltd., 829 F.3d at 1381; see also TRW Automotive US LLC, IPR2014-00259, Paper
`
`19 at *14 (P.T.A.B. June 26, 2014). In this case, Petitioner must show why
`
`someone with a bachelor’s degree and two years’ experience would be motivated
`
`to combine Maes and Ransom. Merely showing that the references could be
`
`14
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`combined is not sufficient. Kinetic Tech., Inc., IPR2014-00529, Paper 8 at *15;
`
`see also Duo Sec. Inc., IPR2017-01041at *9 (“Petitioner's arguments and evidence
`
`are insufficient to explain and demonstrate why an ordinarily skilled artisan would
`
`have combined” the references). Here, Petition and its expert offer no evidence of
`
`why a POSA would be motivated to combine Ransom’s REST disclosure with the
`
`relied-upon Maes’ SOAP message. (Petition at 20-24.) Considering that
`
`Petitioner’s expert testified recently that he could not understand the claimed
`
`“REST” term and now apparently applies a different construction than Petitioner,
`
`his unsupported Petitioner assertions should be given little weight.
`
`Petitioner’s relevant motivation-to-combine evidence is set forth on page 22
`
`through 24 of the Petition. Petitioner merely asserts that Ransom’s REST-based
`
`teachings could be combined with Mae’s SOAP-based message teachings such that
`
`Maes’ alleged telephony resource were accessible via a REST API and that it
`
`would have been “obvious matter of design choice” to use REST over SOAP.
`
`(Petition at 22-23.) Parroting the claim language, however, is not sufficient to
`
`explain why someone would be motivated to combine the two references. Kinetic
`
`Tech., Inc., IPR2014-00529, Paper 8 at *15. Yet Petitioner simply parrots the
`
`claim language. (Petition at 23.) Petitioner fails to explain why someone would be
`
`motivated to modify Maes’s SOAP messages with the Ransom’s mentions of
`
`REST. (Petition at 22-24.)
`
`15
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`
`As Petitioner acknowledges, SOAP and REST are different: REST
`
`emphasizes “the URI” while “SOAP requires an XML wrapper.” (See EX1041.)
`
`Maes even goes to great lengths to explain why its system should be used with a
`
`SOAP-based system. (See EX1003 at 24:19-23; 28:12-16; 28:22-36.) Petitioner,
`
`however, does not explain why a POSA would be motivated to add Ransom’s
`
`REST disclosure to Maes’ SOAP model when the SOAP model has its own API.
`
`(Petition at 20-24.) Similarly, Petitioner does not explain why a POSA would
`
`swap out parts of Maes’ SOAP disclosure for Ransom’s REST disclosure. (Id.)
`
`Petitioner fails to explain what advantage the combination would allegedly provide
`
`or what drawback the combination would allegedly fix. (Id.)
`
`The only support from Ransom Petitioner cites to for its motivation to
`
`combine argument is from paragraph 163, which states that Rest and SOAP “are
`
`two common web services models wherein HTTP is the underlying application
`
`protocol.” (Petition at 21 (citing EX1004 at [0163]).) Notably, what is missing
`
`from Petitioner’s analysis is why a POSA would have been motivated to modify
`
`Maes with the teachings of Ransom. Ransom does not state either SOAP or REST
`
`could be used. In fact, “SOAP” is used in Ransom over 60 times, while “REST” is
`
`used twice. (See, generally EX1004.) Further, Ransom states that “[o]ther transfer
`
`protocols, such a file transfer protocols (‘FTP’), Simple Object Access Protocol
`
`(‘SOAP’), HTTP, XML, or other protocols known the art may be used.” (EX1004
`
`16
`
`

`

`Case IPR2017-01977
`Patent No. 8,755,376
`
`at [0074]; see also EX1004 at [0167] (“may include SOAP, XML, HTTP, TCP/IP,
`
`ION, Modbus and DNP V3.0 and other protocols well known in the art”).) REST
`
`is missing from this list. Ransom goes on to explain how the system may be
`
`implemented through using a SOAP protocol. (Id. at [0157], [0158], and [0184] –
`
`[0187].) Ransom does not explain why or how REST can be used with the system
`
`and says nothing about mixing SOAP with REST or otherwise blending the
`
`approaches. (Ex. 1004.)
`
`In addition to citing to Ransom’s disclosure for the proposition that REST
`
`and SOAP existed, Petitioner cites to the ‘376 Patent’s disclosure showing that
`
`REST was well known in the art (Petition at 22), and that the invention’s call
`
`router may alternatively use a SOAP API (id. at 23). Simply because REST and
`
`SOAP existed does not mean that it would have been “an obvious matter of design
`
`choice” as Petitioner states. (Petition at 23.) For one, the claims explicitly require
`
`a REST API. And secondly, the Petitioner must provide some reason or
`
`explanation why it would have been an obvious design choice to use either SOAP
`
`or REST. Kinetic Techs., IPR2014-00529, Paper 8 at *15 (PTAB Sept. 23, 2014).
`
`The Petition fails to provide this analysis and instead ba