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

`

`Case IPR2017-01977
`Patent 8,755,376
`
`
`
`I.
`
`Introduction ..................................................................................................... 1
`
`TABLE OF CONTENTS
`
`II. Maes and ransom render the ’376 Patent obvious. ......................................... 2
`
`A.
`
`Ransom is analogous art. ...................................................................... 2
`
`B.
`
`Skilled artisans would have been motivated to combine Maes with
`Ransom. ................................................................................................ 3
`
`C.
`
`Claim 1 is rendered obvious in view of Maes and Ransom. ................ 6
`
`1. Maes teaches “a plurality of API resources.” ............................ 6
`
`2.
`
`3.
`
`4.
`
`Petitioner relies on the same resources for the operating and
`exposing limitations ................................................................... 7
`
`Ransom teaches REST API. ...................................................... 7
`
`Ransom does not teach away from REST. .............................. 10
`
`D. Maes and Ransom teach “receiving a REST API request that specifies
`an API resource URI.” ....................................................................... 10
`
`E. Maes and Ransom teach “responding to the API request according to
`the request and the specified resource URI.” ..................................... 11
`
`F. Maes and Ransom render the dependent claims obvious. ................. 15
`
`III. ETSI and ransom render the ’376 Patent obvious ........................................ 17
`
`A.
`
`ETSI and Ransom teach “plurality of API resources,” ...................... 17
`
`B.
`
`ETSI and Ransom teach “exposing the plurality of API resources
`through a REST API.” ........................................................................ 17
`
`C.
`
`Skilled artisans would be motivated to combine ETSI with Ransom.18
`
`D.
`
`ETSI and Ransom teach the receiving limitation ............................... 19
`
`E.
`
`F.
`
`ETSI and Ransom teach the responding limitation ........................... 19
`
`ETSI and Ransom render the dependent claims obvious. .................. 20
`
`ii
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`IV. None of the secondary considerations evidence Patent owner advances is
`probative of nonobviousness ........................................................................ 22
`
`A.
`
`B.
`
`Patent Owner does not adequately show that its products embody the
`’376 Patent. ......................................................................................... 22
`
`Patent Owner fails to show that Petitioner copied its patented
`technology. ......................................................................................... 24
`
`C.
`
`Patent Owner’s commercial-success evidence is deficient. ............... 27
`
`D.
`
`Patent Owner fails to show a long-felt, unmet need. ......................... 28
`
`E.
`
`Patent Owner fails does not properly show industry praise. .............. 29
`
`V.
`
`Conclusion .................................................................................................... 29
`
`
`
`
`
`
`
`iii
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`
`
`
`Exhibit
`Number
`
`EXHIBIT LIST
`
`Document
`
`EX1001 U.S. Patent 8,755,376 to Lawson, et al. (‘376 Patent)
`
`EX1002
`
`File History of U.S. Patent 8,755,376 to Lawson, et al. (‘376 Patent
`File History)
`
`Part 1 – pages 1-220
`
`Part 2 – pages 221-440
`
`Part 3 – pages 441-660
`
`Part 4 – pages 661-880
`
`Part 5 – pages 881-1102
`
`EX1003 U.S. Patent 6,801,604 to Maes, et al. (Maes)
`
`EX1004 U.S. Patent Publication 2003/0204756 to Ransom, et al. (Ransom)
`
`EX1005 U.S. Patent 7,092,370 to Jiang, et al. (Jiang)
`
`EX1006 ETSI ES 202 391-4 V1.2.1 (2006-12), “Open Service Access (OSA);
`Parlay X Web Services; Part 4: Short Messaging (Parlay X 2) (ETSI ES
`202 391-4)
`
`EX1007 ETSI ES 202 391-7 V1.2.1 (2006-12), “Open Service Access (OSA);
`Parlay X Web Services; Part 7: Account Management (Parlay X 2)
`(ETSI ES 202 391-7)
`
`EX1008 ETSI ES 202 391-2 V1.2.1 (2006-12), “Open Service Access (OSA);
`Parlay X Web Services; Part 2: Third Party Call (Parlay X 2) (ETSI ES
`202 391-2)
`
`EX1009 Declaration of Dr. Seth Nielson (Nielson Decl.)
`
`EX1010 Twilio’s Opening Claim Construction Brief
`
`EX1011
`
`“Giving SOAP a REST,” DevX.com, by Amit Asaravala, 2002,
`available
`at
`
`iv
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`
`https://web.archive.org/web/20021202002704/www.devx.com/DevX/
`Article/8155
`
`EX1012 W3C Working Draft, “Web Services Description Requirements”,
`October 28, 2002, available at http://www.w3.org/TR/2002/WD-ws-
`desc-reqs-20021028
`
`EX1013
`
`“REST vs. SOAP Web Services,” August 3, 2005, available at
`https://web.archive.org/web/20051018025732/https://www.petefreitag
`.com/item/431.cfm
`
`EX1014 U.S. Pub. App. 2008/0140861 to Kothari, et al. (Kothari)
`
`EX1015 W3C Working Draft, “SOAP Version 1.2,” July 9, 2001
`
`EX1016 Authentication Declaration of TeleSign Employee Marciano Reconnu
`
`EX1017
`
`Feb. 28, 2010, 6:14 PM email re “Twilio Account Activity”
`
`EX1018
`
`Feb. 28 2010, 5:55 PM email re “Twilio Account Activity”
`
`EX1019
`
`Supplemental Declaration of Seth Nielson, Ph.D.
`
`EX1020 Declaration of Patent Owner’s District-Court Claim-Construction
`Expert: Dr. Kevin Almeroth.
`
`
`
`
`v
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`I.
`
`INTRODUCTION
`
`Twilio’s lead argument against obviousness is that implementing a web
`
`service using SOAP or REST was not an obvious matter of design choice at the time
`
`of the ’376 Patent. But Patent Owner’s argument contradicts the specification and
`
`record, which is replete with evidence advanced by both Petitioner and Patent Owner
`
`that, at the time of the ’376 Patent, SOAP and REST were two well-known ways of
`
`implementing a web service to achieve desired functionality. The ’376 Patent itself
`
`admits that REST does not serve any advantage or present any novel or unexpected
`
`results by expressly stating that REST and SOAP are two known ways of
`
`implementing the invention. EX 1001 at 8:12-17 (“The Call Router API is
`
`preferably an application programming interface (API) such as a REST API
`
`(Representational State Transfer) as is known in the art, but the Call Router API may
`
`alternatively be a SOAP (Simple Object Access Protocol) API or any suitable
`
`programmatic communication interface.”); id. at 9:13-18 (“The Call Router API
`
`response may alternatively conform to any suitable programming principle such as
`
`SOAP.”) (emphasis added). The record evidence also shows that it was well known
`
`that REST had advantages that would have motivated a POSA to implement a web
`
`service using REST.
`
`1
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`II. MAES AND RANSOM RENDER THE ’376 PATENT OBVIOUS.
`
`A. Ransom is analogous art.
`
`Patent Owner asserts that only prior art relating to telephony is in the same
`
`field of endeavor of the ’376 Patent. PO Resp. 19-22. But it is well-settled “that the
`
`scope of analogous art is to be construed broadly.” Snap Inc., v. Vaporstream, Inc.,
`
`IPR2018-00439, 2018 WL 3702498, at *8 (Aug. 2, 2018) (citations omitted). The
`
`’376 Patent describes facilitating Internet requests and responses that invoke
`
`functionality or provide information via a web service. Indeed, seven of the sixteen
`
`figures of the ’376 Patent expressly describe the invention as a “web service.”
`
`EX1001 at FIGS 7-12, 15 (denoting the “Voice Mini App Web Service,” “Web
`
`Service API,” “SMS Interfaced Web Service,” “Voice App Web Service,” and
`
`“Voice App Hold Web Service”). Ransom is also directed towards web services,
`
`and as such, is in the same field of endeavor. Critically, the ’376 Patent is not
`
`directed to how Internet requests and response are actually converted into telephony
`
`action.
`
`Moreover, Ransom is reasonably pertinent to the problem of the ’376 Patent
`
`to simplify the interactions between an application and a disparate network by
`
`“us[ing] the familiar web site visitor model to interact with a web developer’s
`
`application.” EX1001 at 2:3-6. Ransom describes using HTTP requests and
`
`responses to invoke functionality addressed with URIs (EX1004 at [0162]-[0165],
`
`2
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`[0185]) just as the ’376 Patent does and as such would have logically commended
`
`itself to the inventor’s attention in considering the problem identified in the ’376
`
`Patent. See, e.g., Samsung Elecs. Co., Ltd. v. IXI IP, LLC, IPR2015-01445, 2016
`
`Pat. App. LEXIS 13293, at *24-25 (PTAB Dec. 21, 2016) (finding prior art directed
`
`to a toy analogous to a cellular patent where the prior art described the same basic
`
`network interactions as the cellular patent).
`
`B.
`
`Skilled artisans would have been motivated to combine Maes with
`Ransom.
`
`Patent Owner argues that there is no motivation to combine Maes with
`
`Ransom because “SOAP was preferred for complex applications like those involving
`
`a telephony network.” PO Resp. 23-24. But the portion of Dr. Negus’s declaration
`
`that Patent Owner relies on in support states only that SOAP “may” have been
`
`preferred for complex applications. EX2010 at ¶287. Nor does Dr. Negus even
`
`opine that Maes’ telephony web service is complex. See id. Nevertheless, even if
`
`SOAP was preferred for a system such as Maes, this does not mean that a POSA
`
`would have understood that SOAP was the only option given REST’s well-known
`
`advantages. See Medichem, S.A. v. Rolabo, S.L., 437 F.3d 1157, 1165 (Fed. Cir.
`
`2006) (“[a] given course of action often has simultaneous advantages and
`
`disadvantages, and this does not necessarily obviate a motivation to combine.”) And
`
`3
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`elsewhere, Patent Owner tacitly concedes that REST APIs were sometimes used in
`
`complex systems by saying that they only “generally” were not. PO Resp. 6.
`
`Dr. Nielson, relying on two illustrative articles, EX2011 and EX1013,
`
`confirms that REST and SOAP were two well-known models of implementing a
`
`web service that offered similar capabilities and functionality. Patent Owner itself
`
`identifies other articles, EX2012-2014, validating Dr. Nielson’s opinion. EX2012
`
`highlights “that both REST and SOAP can be used to implement similar
`
`functionality.” EX2013 states the same:
`
`[SOAP and REST] both have underlying issues around
`
`security, transport layers, and the like, but they both can
`
`get the job done and in many cases, they each bring
`
`something different to the web. So for this argument, the
`
`best rule, is the rule of flexibility, because no matter what
`
`the problem at least in today’s web development world,
`
`web developers have great solutions using either of
`
`these protocols.
`
`EX2014 at 3 (emphasis added). EX2013 identifies additional advantages of REST,
`
`including: Language and platform agnostic; Much simpler to develop than SOAP;
`
`Small learning curve, less reliance on tools; Concise, no need for additional
`
`messaging layer; and Closer in design and philosophy to the Web. EX2013 at 5.
`
`4
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`EX2014 highlights, just like Dr. Nielson, that the choice between SOAP and REST
`
`is developer preference: “Both approaches work, both have advantage and
`
`disadvantages to interfacing to web services, but it is up to the web developer
`
`to make the decision of which approach may be best for each particular case.”
`
`EX2014 at 1 (emphasis added).
`
`Given the well-known advantages of implementing a web service using REST
`
`at the time of the ’376 Patent, a POSA would have been motivated to combine the
`
`teachings of Maes and Ransom. DyStar Textilfarben GmbH & Co. Deutschland KG
`
`v. C.H. Patrick Co., 464 F.3d 1356, 1361 (Fed. Cir. 2006) (citations omitted) (noting
`
`that the motivation to combine prior art references “need not be found in the
`
`references sought to be combined, but may be found in any number of sources,
`
`including common knowledge, the prior art as a whole, or the nature of the problem
`
`itself.”) And contrary to Patent Owner’s assertion (PO Resp. 24-25), Petitioner
`
`“does not need to show that there was a known problem with the prior art system in
`
`order
`
`to articulate
`
`the required rationale underpinning for
`
`the proposed
`
`combination.” Unwired Planet, LLC v. Google Inc., 841 F.3d 995, 1002 (Fed. Cir.
`
`2016).
`
`Furthermore, Dr. Nielson’s motivation-to-combine opinions stand despite his
`
`indefiniteness opinions at the district court. PO Resp. 27-38. Dr. Nielson never
`
`feigned ignorance of the universe of constraints that could be associated with a REST
`
`5
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`API; instead, as the testimony reproduced in Patent Owner’s Response makes clear,
`
`he testified only that it was unclear which of those constraints were applicable to the
`
`term as it is described in the ’376 Patent and the boundaries of REST. See id. And
`
`of course, a finding of invalidity is not precluded by pursuing, or even a finding of,
`
`indefiniteness. See, e.g., Baldwin Graphic Sys. v. Siebert, Inc., No. 03 C 7713, 2008
`
`U.S. Dist. LEXIS 82991, *15 (N.D. Ill. Aug. 27, 2008) (finding claims indefinite
`
`and also obvious in view of the prior art regarding precisely the same term).
`
`C. Claim 1 is rendered obvious in view of Maes and Ransom.
`
`1. Maes teaches “a plurality of API resources.”
`
`Patent Owner’s argument (PO Resp. 15) that Maes does not describe a
`
`plurality of API resources is based on an improper claim construction. The ’376
`
`Patent describes that addressing each API resource with its own URI is not
`
`mandatory, only preferable. EX1001 at 9:30-34 (emphasis added) (“An API
`
`resource is preferably addressed by a persistent URI.”). Moreover, Maes’ resources
`
`are API resources. PO Resp. 15. The ’376 Patent explains that an API resource
`
`“functions to expose information and/or functionality . . . .” EX1001 at 8:4-7. Patent
`
`Owner’s own expert in the district court similarly explained that APIs are
`
`“mechanisms by which a program could access the features of a server.” EX1020
`
`at 9, ¶27. As the Petition highlights, Maes describes just this: an application sending
`
`a request over the Internet to a server TEL 20 to invoke its functionality like making
`
`6
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`a call. Pet. 25. Furthermore, Maes does not disparage the use of APIs in general as
`
`Patent Owner contends (PO Resp. 15), just that some proprietary APIs require
`
`specific programming because they are not portable from vendor to vendor. EX1003
`
`at 2:34-40.
`
`2.
`
`Petitioner relies on the same resources for the operating and
`exposing limitations
`
`Petitioner correctly relies on the same resources of Maes’ TEL20 for the
`
`operating and exposing limitations (PO. Resp. at 16), namely TEL20 functionality,
`
`such as making a call or transferring a call. Compare Pet. 16 discussing operating
`
`limitation (“Maes teaches that TEL 20, includes various functionalities . . . such as
`
`setting up a call, transferring a call . . . .”) with Pet. 20 discussing exposing limitation
`
`(“Maes discloses several resources accessible via an API. . . . such as ‘MakeCall’ . .
`
`. ‘TransferCall’ etc.”).
`
`3.
`
`Ransom teaches REST API.
`
`In the district court, Patent Owner distanced itself from the claim construction
`
`it now tries to use to advance a “gotcha” argument (PO Resp. 17-18) based on a
`
`claim construction that neither party proposed, even in litigation.
`
`7
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`
`EX2004 at 9 (annotated) (Mr. Stacy is Twilio’s counsel).
`
`
`
`Patent Owner did not advance a proposed construction of REST API in its
`
`preliminary response. Moreover, Patent Owner and its claim-construction expert
`
`(Dr. Kevin Almeroth) argued for the construction used in the Petition:
`
`EX1020 (Declaration of Patent Owner’s claim-construction expert) at ¶ 31.
`
`
`
`After IPR institution, the district court rejected Patent Owner’s proposed
`
`construction of REST API and newly included the four interface constraints:
`
`identification of resources; manipulation of resources through representations; self-
`
`descriptive message; and, hypermedia as the engine of application state.” EX2005
`
`at 22. Twilio now changes its position, finds a new expert, and improperly attempts
`
`to use this new construction to fault Petitioner for not expressly addressing, ipsis
`
`verbis, each constraint despite Ransom expressly referring to “REST” by name.
`
`8
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`
`Regardless, contrary to Patent Owner’s assertion (PO Resp. 17-18), Ransom
`
`describes the four REST constraints. Ransom teaches identifying a resource with a
`
`URI. EX1004 at [0162] (“[t]he Uniform Resource Identifier (‘URI’) defines the
`
`resource that is being accessed”); EX1019 at [0004]. Ransom teaches a self-
`
`descriptive message, namely a message that include the information that describes
`
`how to process it. EX1004 at [0162] (“The HTTP POST message type is where the
`
`HTTP request contains data that is sent to a URI on the server for processing of some
`
`kind. As is well known in the art, this could include . . . triggering the execution of
`
`scripts or some other data processing application to parse the posted data.
`
`Alternatively data could be encoded within the URI itself and either a POST or a
`
`GET be executed.”); EX1019 at [0009]-[0012]. Ransom teaches manipulation of
`
`resources through representations via HTTP methods, such as using GET and POST
`
`commands. EX1004 at [0162]; EX1019 at [0005]-[0008]. And Ransom teaches
`
`hypermedia as the engine of application state by including hypermedia links with
`
`responses. EX1009 at [0164] (“the HTTP response message will also contain . . . a
`
`link to a URI that contains a new request.”); EX1019 at [013]-[014].
`
`Patent Owner’s remaining argument that Ransom does not describe how to
`
`implement a SOAP-based system like Maes using REST (PO Resp. 18) incorrectly
`
`implies bodily incorporation is an obviousness requirement. It is not. In re Keller,
`
`642 F.2d 413, 425 (CCPA 1981).
`
`9
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`
`4.
`
`Ransom does not teach away from REST.
`
`Patent Owner argues that Ransom teaches that REST-based messages “will
`
`not work.” PO Resp. 19. While it is true that Ransom describes one firewall that
`
`would limit traffic to SOAP traffic, it also describes a counter-part REST scenario
`
`that—despite being behind a firewall—would clearly not block REST messages.
`
`
`
`EX1004 at [0184]-[0185] (annotated); Pet. 14, 22, 26, 50, 53.
`
`D. Maes and Ransom teach the receiving limitation.
`
`Patent’s Owner’s first and second arguments are solely directed to Maes’s
`
`purported failure to describe resources that are individually addressed with URIs
`
`(see PO Resp. 29-30) but “one cannot show non-obviousness by attacking references
`
`individually where, as here, the rejections are based on combinations of references.”
`
`In re Keller, 642 F.2d 413, 426 (CCPA 1981). Indeed, the Board already and
`
`correctly rejected these arguments, recognizing that Petitioner was relying on the
`
`combination (and Ransom in particular) for teaching the URI aspect. Paper 13 at 6
`
`(“Patent Owner’s argument is not persuasive because it addresses Maes and Ransom
`
`10
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`individually, not the combination of Maes proposed by Petitioner. . . Petitioner
`
`identifies evidence that . . . Ransom teaches accessing resources using a REST
`
`request that specifies the URI of the requested resource.”) Patent Owner’s remaining
`
`argument is that the combination of Maes and Ransom does not render the receiving
`
`limitation obvious because Petitioner supposedly fails to explain how each of Maes’
`
`API resources could be identified by a URI as Ransom describes. PO Resp. 29-33.
`
`But as explained above in Section II.C.3, bodily incorporation is not an obviousness
`
`requirement.
`
`E. Maes and Ransom teach the responding limitation.
`
`Patent Owner argues that Maes does not teach the responding limitation
`
`because the response must be a single telephony action and Maes at 35:25-28
`
`discloses multiple telephony actions. PO Resp. 33-34. But this construction would
`
`read out four of the embodiments described in the ’376 Patent, making it improper.
`
`FIGS. 7, 9, 10, and 11 of the ’376 Patent, partially reproduced below, depict a
`
`response with multiple telephony actions, namely playing a greeting and collecting
`
`digits:
`
`11
`
`

`

`Voice Mini App
`Web Service
`
`K.’
`
`“ L
`
`ookup
`AuloAtlendanl
`by ID & find:
`'Greeling file
`'Digils to expect
`
`CASE 1:
`SMB AutoAttendant
`
`S 110
`
`85
`K‘ HTTP POST:
`
`v
`
`0'
`
`for Regex: [09.1“ ’
`
`_
`
`S5\ HTTP POST:
`
`EX1001, FIG. 7.
`EX1001, FIG. 7.
`
`Case IPR2017-01977
`Case IPR2017-01977
`Patent 8,755,376
`Patent 8,755,376
`
`
`hURL Router
`JavaAGl Handler
`
`INCOMING
`
`S1
`
`lnil
`Interceptor
`(lnit URL
`lockup)
`
`Passes
`to hURLer
`with Init URL
`lwilio.coml
`AuloAllendanll
`A9898900
`
`hURL Router
`JavaAGl Handler
`
`INCOMING
`
`Init
`lnlerceplor
`(Inil URL
`lockup)
`
`Passes
`to hURLer
`with Inil URL
`
`3rdparty.coml
`AuloConf
`
`CASE 3:
`3rd Party AutoConf
`
`8110
`
`35
`k HTTP POST:
`
`HTTP RESPONSE: ‘/-89
`
`One For "Work Conference“
`Two For "Mom & Dad"
`
`NextUrlzlo 3rdparty.comlAuloConfl
`IWM—l
`
`EX1001, FIG. 9.
`EX1001, FIG. 9.
`
`12
`12
`
`
`
`
`
`
`Voice Mini App
`Web Service
`
`3rdparty.com
`
`Lookup by
`incoming caller
`ID, find auto-coral
`customer. There
`are four possible
`AuloConfs for
`this user...
`
`
`
`
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`
`EX1001, FIG. 10.
`
`
`
`
`
`EX1001, FIG. 11.
`
`Even so, Maes does describe responding with a single telephony action. For
`
`example, 35:25-28 of Maes specifically describes “play and/or record” not just play
`
`and record. EX1003 (emphasis added).
`
`13
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`
`Patent Owner argues that Petitioner cannot rely on Ransom’s URI teachings
`
`because the petition does not identify Ransom in the responding limitation. PO
`
`Resp. 34. But the Board correctly rejected this argument given Petitioner’s
`
`arguments collectively for the receiving and responding limitations. Paper 13 at 7
`
`(“Thus, when Petitioner’s arguments and evidence regarding the final two
`
`limitations of claim 1 are considered together, Petitioner sufficiently shows that
`
`the response is according to the REST API request and the specified API resource
`
`URI.” (emphasis added)).
`
`Petitioner’s contention that Maes and Ransom collectively teach “the
`
`specified resource URI” in the responding limitation is clear from its discussion of
`
`the “specifies an API resource URI” in the immediately preceding receiving
`
`limitation. In that discussion, Petitioner states that Ransom supplies the specified
`
`resource URI missing from Maes. Pet. 26-29 (citing EX1004 at [0185]). Indeed,
`
`Figure 20 as described in [0185] of Ransom depicts the well-known REST model of
`
`sending a request to the URI of a resource and responding according to the resource
`
`URI:
`
`14
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`
`EX1004, FIG. 20.
`
`
`
`F. Maes and Ransom render the dependent claims obvious.
`
`As to claim 2, Patent Owner argues that Maes does not teach resources
`
`individually addressed with a URI (PO Resp. 35), but as explained in Section II.C.3.
`
`above, Maes teaches this concept.
`
`As to claim 14, the Petition explains that Maes teaches an informational API
`
`resource, namely information created or used during a call (PO Resp. 36-37). Maes
`
`describes sending a request for text recognized by and context values used by the
`
`automatic speech recognition engine (“ASR”) during a call, and ASR responding
`
`with this information. Pet. 32-34. Moreover, the Petition does explain that Ransom
`
`supplies the REST and URI concepts. Pet. 20-29.
`
`As to claim 16, Petitioner does not argue that the collected digits that TEL20
`
`returns in response to a request for collected digits is both an informational API
`
`resource and data of the informational API resource. See PO Resp. 37-38. Rather,
`
`Petitioner maintains that TEL20’s collecting-digits-functionality is the informational
`
`15
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`API resource and the actual collected digits TEL20 returns are data of the
`
`informational API resource. Pet. 34. Moreover, the Petition does explain that
`
`Ransom supplies the URI concept. Pet. 20-29.
`
`As to claim 19, Petitioner has not violated antecedent basis. PO Resp. at 38-
`
`39. Petitioner identifies data that is both returned data of an informational API
`
`resource, as claim 16 requires, and returned data on an in-progress telephony session,
`
`as claim 19 requires. Maes’s “ASR” server provides an informational API resource
`
`in that it returns data associated with a telephony session, such as recognized text
`
`and its translation. Pet. 35 (citing EX1003 at 8:26-32: 36:34-38). Maes describes
`
`that the ASR server processes commands and data input of a telephony user – this is
`
`information of an in-progress telephony session. Id.
`
`As to claims 5 and 17, Patent Owner does not contest that Jiang is in the same
`
`field of endeavor as the ‘376 Patent as the Petition asserts at page 37. See PO Resp.
`
`39. As such, its argument that Jiang is not directed to the same problem as the ’376
`
`Patent is irrelevant because prior art is analogous where “the art is from the same
`
`field of endeavor, regardless of the problem of addressed.” In re Clay, 966 F.2d 656,
`
`658-59 (Fed. Cir. 1992).
`
`Moreover, Petition does provide an express motivation to combine. As the
`
`Petition and supporting declaration state, a POSA would have recognized the benefit
`
`of adding additional telephony functionality, such as Jiang’s SMS functionality, to
`
`16
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`Maes’ web service of traditional telephony functionality. Pet. 39; EX1009 at [0087].
`
`As Dr. Nielson even notes, one of the goals of Maes is to deploy its web service
`
`across “a wide range of . . . networks . . . .” EX1009 at [0087].
`
`III. ETSI AND RANSOM RENDER THE ’376 PATENT OBVIOUS
`
`A. ETSI and Ransom teach “plurality of API resources,”
`
`For the reasons set forth above in Section II.C.1., Patent Owner’s argument
`
`(PO Resp. 40-42) that ETSI-4 does not teach a plurality of API resources is based
`
`on an improper claim construction and should be rejected. Moreover, the Petition
`
`does explain that an API resource can be information or functionality; accordingly,
`
`the initiating-a-call and sending-an-SMS functionalities of the SMS Web Service
`
`API and Third Party Call Web Service API are API resources. Pet. 49.
`
`B.
`
`ETSI and Ransom teach “exposing the plurality of API resources
`through a REST API.”
`
`Petitioner identifies the SMS Web Service API and the Third Party Call Web
`
`Service API functionalities as the API resources in the operating and exposing
`
`limitations, and as such, does not violate antecedent basis (PO Resp. 41). Compare
`
`Pet. 44-45 discussing operating limitation (“Parlay X Web Services, including the
`
`SMS and Third Party Call Web Services”) with Pet. 50 discussing exposing
`
`limitation (“Parlay X Short Messaging Web Service API . . . To the extent one
`
`might argue that the resources of the Parlay X Third Party Call Web Service API
`
`are not accessible via REST API . . . .”). And as explained above in Section II.C.3.,
`
`17
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`Ransom teaches the four REST constraints and does not teach away from a REST
`
`web service.
`
`C.
`
`Skilled artisans would be motivated to combine ETSI with Ransom.
`
`Patent Owner argues that ETSI-4 cannot be combined with Ransom’s REST
`
`teaching because another document, ETSI-1, states that the Parlay X Web Services
`
`shall send and accept message using SOAP. PO Resp. 45. But even if this statement
`
`was in ETSI-4, it does not teach away from REST because it never even mentions,
`
`let alone criticizes, REST or any of its attributes. Galderma Labs., L.P. v. Tolmar,
`
`Inc., 737 F.3d 731, 739 (Fed. Cir. 2013) (internal quotations omitted) (“A reference
`
`does not teach away . . . if it . . . does not criticize, discredit, or otherwise discourage
`
`investigation into the invention claimed.”).
`
`As described above in Section II.B., at the time of the ’376 Patent there were
`
`well-known advantages associated with implementing a web service using REST,
`
`which would have motivated a POSA when implementing ETSI-4’s Web Service
`
`APIs to look to Ransom’s REST teachings. Moreover, as explained above in Section
`
`II.B., Petitioner does not need to show a known problem with ETSI-4’s Web Service
`
`APIs in order to articulate the required underpinning for the proposed modification
`
`with Ransom. Unwired Planet, LLC, 841 F.3d at 1002. Nor, as described above in
`
`Section II.C.3., is it an obviousness requirement that Petitioner explain how to bodily
`
`18
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`incorporate Ransom’s REST teachings into the SOAP-based ETSI-4 Web Service
`
`APIs (PO Resp. 47-48).
`
`D. ETSI and Ransom teach the receiving limitation.
`
`As described above in Section II.C.3., Ransom describe a REST API (PO
`
`Resp. 49). Petitioner relies on Ransom for an API resource URI not ETSI-4 and
`
`quotes from Ransom that resources are addressed with a URI (PO Resp. 49). Pet.
`
`53-54. As explained above in Section II.C.3., Petitioner was not required to describe
`
`how ETSI-4’s API resources could be identified by a URI as Ransom describes
`
`because bodily incorporation is not an obviousness requirement (PO Resp. 50). And
`
`as the Board highlighted in its institution decision, the Petition provides notice of
`
`Petitioner’s argument regarding the receiving limitation, namely that “ETSI 391-4
`
`teaches receiving a getReceivedSmsRequest that specifies the getReceivedSms
`
`resource, and Ransom teaches accessing resources using a REST request that
`
`specifies the URI of the requested resource.” Paper No. 13 at 11-12.
`
`E.
`
`ETSI and Ransom teach the responding limitation.
`
`Patent Owner argues that Petitioner cannot rely on Ransom for the responding
`
`limitation because the petition does not identify Ransom in discussing this limitation.
`
`PO Resp. 53-54. But the Board already correctly rejected this argument given
`
`Petitioner’s arguments collectively for the receiving and responding limitations.
`
`Paper 13 at 12 (emphasis added) (“Thus, when Petitioner’s arguments and evidence
`
`19
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`regarding the final two limitations of claim 1 are considered together, Petitioner
`
`sufficiently shows that the response is according to the REST API request and the
`
`specified API resource URI.”) Indeed, Petitioner’s contention that ETSI-4 and
`
`Ransom collectively teach a response according to the REST request and the
`
`specified resource URI is clear from its discussion of REST and the “specifies an
`
`API resource URI” in the immediately preceding receiving limitation. In that
`
`discussion, Petitioner describes modifying ETSI-4’s API request that specifies an
`
`API resource based on Ransom’s REST teachings that resources are addressed with
`
`a URI.
`
`F.
`
`ETSI and Ransom render the dependent claims obvious.
`
`As to claim 2, Patent Owner reiterates the same arguments as it does for claim
`
`1 that Ransom does not teach the specified API resource URI. For the reasons set
`
`forth in Section II.D., Patent Owner’s argument should be rejected.
`
`As to claim 5, Petitioner does address claim 5 in its analysis of claim 1 (PO
`
`Resp. 55). As the Petition describes, ETSI-4 describes sending an SMS, which
`
`prompts the initiation of a telephony session. Pet. 45-46, 57-58.
`
`As
`
`to
`
`claim 14, Petitioner does not point
`
`to
`
`the
`
`same
`
`“getReceivedSMSRequest” in arguing that ETSI-4 teaches two different requests
`
`and responses as claim 14 requires (PO Resp. 55-56). ETSI-4 describes sending a
`
`“sendSMS” message to a functional API resource of the SMS Web Service API,
`
`20
`
`

`

`Case IPR2017-01977
`Patent 8,755,376
`
`which responds by sending an SMS message. Pet. 55-57. As described for claim 1,
`
`ETSI-4 also describes sending a “getReceivedSmsRequest” message to an
`
`informational API resource, which responds wi