Case 5:16-cv-06925-LHK Document 110-4 Filed 08/28/17 Page 1 of 12
`
`
`
`
`
`EXHIBIT C
`
`
`
`TeleSign Corporation, EX1020, Page 1
`TeleSign Corporation v. Twilio Inc.
`IPR2017-01977
`
`

`

`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Case 5:16-cv-06925-LHK Document 110-4 Filed 08/28/17 Page 2 of 12
`
`
`
`TWILIO INC.,
`
`vs.
`
`UNITED STATES DISTRICT COURT
`
`NORTHERN DISTRICT OF CALIFORNIA – SAN JOSE
`
`Case No. 5:16-CV-06925-LHK-SVK
`
`
`
`
`
`Plaintiff,
`
`TELESIGN CORPORATION,
`
`Defendant.
`
`
`DECLARATION OF KEVIN ALMEROTH IN REPLY TO SETH NIELSON’S
`DECLARATION
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Declaration of Kevin Almeroth
`Case: 5:16-cv-06925-LHK-SVK
`
`
`
`
`
`
`
`TeleSign Corporation, EX1020, Page 2
`TeleSign Corporation v. Twilio Inc.
`IPR2017-01977
`
`

`

`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Case 5:16-cv-06925-LHK Document 110-4 Filed 08/28/17 Page 3 of 12
`
`I, Kevin Almeroth, declare that I have personal knowledge of the facts set forth in this
`
`declaration and, if called to testify as a witness, could and would do so competently.
`
`I.
`
`INTRODUCTION
`1.
`
`I have been asked to provide expert opinions on behalf of Twilio in the above-
`
`captioned case.
`2.
`
`This declaration is a statement of my opinions in response to Dr. Nielson’s
`
`declaration on issues related to the meaning and usage of certain claim terms used in the asserted
`
`claims of U.S. Patent 8,306,021 (“the ’021 Patent), U.S. Patent 8,837,465 (“the ’465 Patent), and
`
`U.S. Patent 8,755,376 (“the ’376 Patent”).
`3.
`
`My qualifications are stated more fully in my curriculum vitae and a brief
`
`summary of my qualifications is provided in my opening Declaration.
`
`II. MATERIALS CONSIDERED
`4.
`
`In forming my opinions, I have reviewed or relied upon:
`a. the specifications, asserted claims, and file histories of the asserted Patents;
`b. my background and experiences in the field;
`c. the parties’ joint claim construction statement and the cited evidence with
`
`III.
`
`respect to the claim term “REST API”; and
`d. the Declaration of Seth Nielson and supporting evidence.
`LEGAL CONCEPTS
`5.
`6.
`
`I was not asked to offer any legal opinions in this matter.
`
`I understand that the patent claims and claim terms are to be given the meaning
`
`one of ordinary skill in the art would understand them to have after considering the patent’s
`
`claims, written description, and prosecution history.
`7.
`
`I understand that extrinsic evidence encompasses “all evidence external to the
`
`patent and prosecution history, including expert and inventor testimony, dictionaries, and
`
`learned treatises.” Markman v. Westview Instruments, Inc., 52 F.3d 967, 980, 34 U.S.P.Q.2d
`
`1321 (Fed. Cir. 1995), aff'd, 517 U.S. 370, 116 S. Ct. 1384, 38 U.S.P.Q.2d 1461 (1996).
`
`Declaration of Kevin Almeroth
` Case: 5:16-cv-06925-LHK-SVK 1
`
`
`
`
`
`TeleSign Corporation, EX1020, Page 3
`TeleSign Corporation v. Twilio Inc.
`IPR2017-01977
`
`

`

`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Case 5:16-cv-06925-LHK Document 110-4 Filed 08/28/17 Page 4 of 12
`
`8.
`
`I understand that a patent is invalid for indefiniteness if its claims, read in light of
`
`the patent’s specification and prosecution history, fail to inform, with reasonable certainty, those
`
`skilled in the art about the scope of the invention.
`9.
`
`I understand that, according to the Supreme Court’s Nautilus decision in 2014,
`
`that the definiteness requirement requires clarity to inform those skilled in the art about the
`
`scope of the invention, while recognizing that absolute precision is unattainable.
`
`IV. DISPUTED TERM
`
`A.
`“REST API”
`
`Plaintiff’s Proposed Construction
`An application programming interface that is
`operable with Representational State Transfer
`(REST) conventions.
`
`Defendant’s Proposed Construction
`Indefinite.
`
`Alternatively:
`A programmatic communication
`using a varying level of statelessness.
`I understand that TeleSign’s technical expert opined that “[t]hose skilled in the
`
`interface
`
`10.
`
`art as of April 2, 2009 would not have understood with reasonable certainty the terms ‘REST
`
`API’ (or ‘representational state transfer (REST) API’).” Nielson Dec. at ¶32. I disagree.
`11.
`
`Dr. Nielson states “there has been and continues to be considerable disagreement
`
`among those skilled in the art as to the particular meaning and scope for ‘REST API,’” however,
`
`Dr. Nielson presents no evidence to support this position. Nielson Dec. at ¶33. In fact,
`
`TeleSign’s own website states that there is an industry standard for REST.
`
`(https://developer.telesign.com/v2.0/docs/getting-started-with-the-rest-api). Thus, it appears that
`
`TeleSign, its engineers, and its customers understand the meaning of REST API.
`
`Declaration of Kevin Almeroth
` Case: 5:16-cv-06925-LHK-SVK 2
`
`
`
`
`
`TeleSign Corporation, EX1020, Page 4
`TeleSign Corporation v. Twilio Inc.
`IPR2017-01977
`
`

`

`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Case 5:16-cv-06925-LHK Document 110-4 Filed 08/28/17 Page 5 of 12
`
`12.
`
` In addition, numerous textbooks, web design books, and the like have been
`
`published on how to implement REST APIs, indicating that one of ordinary skill in the art at the
`
`time of the invention would have understood with reasonable certainty the meaning of REST
`
`API. For example, REST API – Design Rulebook by Mark Masse, RESTful Web APIs by
`
`Leonard Richardson and Mike Amundsen, REST in Practice by Jim Webber, RESTful Web
`
`Services by Leonard Richardson and Sam Ruby, and RESTful API Design by Matthias Biehl.
`13.
`
`As an initial matter, Dr. Nielson relies primarily on a dissertation written in 2000
`
`by Dr. Fielding (attached as Exhibit B) in support of his argument that the term “REST API” is
`
`indefinite. As pointed out by Dr. Nielson, Dr. Fielding is one of the principal creators of REST.
`14.
`
`Dr. Nielson suggests that Dr. Fielding explains REST as an “architectural style
`
`that he observed (not defined).” Nielson Dec. at ¶33 (emphasis in original). Dr. Nielson
`
`presents no evidence to support this position. In fact, Dr. Nielson provides no citation for the
`
`quoted term “observed” and no explanation as to why observations would make the term “REST
`
`API” indefinite.
`15.
`
`I have searched Dr. Fielding’s dissertation and find the term “observed” occurs
`
`only once. It appears in a section defining the term “components”:
`
`
`The behavior of each component is part of the architecture insofar as that
`behavior can be observed or discerned from the point of view of another
`component [9]. In other words, a component is defined by its interface and the
`services it provides to other components, rather than by its implementation behind
`the interface.
`
`
`Ex. B at 10 (emphasis added).
`16.
`If anything, this statement demonstrates that definitions can in fact be made based
`
`on observing and characterizing behaviors. More important, however, is that Dr. Nielson fails to
`
`include Dr. Fielding’s definition of what an architectural style is and then also fails to recognize
`
`that Dr. Fielding uses that very definition to compare and contrast the advantages and
`
`disadvantages of different styles. For example, Dr. Fielding defines an architectural style as:
`
`Declaration of Kevin Almeroth
` Case: 5:16-cv-06925-LHK-SVK 3
`
`
`
`
`
`TeleSign Corporation, EX1020, Page 5
`TeleSign Corporation v. Twilio Inc.
`IPR2017-01977
`
`

`

`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Case 5:16-cv-06925-LHK Document 110-4 Filed 08/28/17 Page 6 of 12
`
` Ex. B at 13. Dr. Nielson does not even acknowledge this definition, but instead compares a
`
`“style” to a type of music. Nielson Dec. at ¶33.
`17.
`
`For example, and with respect to “architectural style,” Dr. Nielson attempts to
`
`provide his own definition and relates it to types of music. Nielson Dec. at ¶33. Styles of
`
`music, however, to a person of appropriate skill in that discipline, are certainly well-defined
`
`enough to provide reasonable certainty. Just as person of skill in the art in the “music” field
`
`would understand to a reasonable certainty that Music A is rock-n-roll and Music B is classical,
`
`a person of skill in the art in “API web design” would understand to a reasonable certainty that
`
`Web Design A is SOAP and Web Design B is RPC.
`18. When it comes to API web design there are different types of architectural styles
`
`and API design decisions a developer needs to consider in creating her API. Dr. Fielding notes
`
`there while there are some architectural styles that are that cover multiple forms of software, a
`
`developer should select the a particular architecture based on the problem being solved. Ex. B at
`
`15. For example, Dr. Fielding references multiple different types of architecture in his
`
`dissertation: CERN, CORBRA, and RPC. Ex. B at 138-142.
`19.
`
`In my opinion, a POSA at the time of the invention would have understood with
`
`reasonable certainty the term “REST API” as it appears in the claims. REST is an architectural
`
`style, as Dr. Nielson repeatedly states throughout his declaration, and as such it defines a set of
`
`architectural constraints and conventions. An API which observes the REST constraints is
`
`considered to be RESTful.
`20.
`
`As Fielding describes, REST was designed to make optimal use of HTTP, which
`
`is one of the major advantages of REST. See generally Ex. B. One of the focuses of REST is on
`
`the design of resources (nouns), unlike other architectures which emphasizes methods or
`
`operations (verbs). Ex. B at 86-92. A REST API therefore makes data available as resources
`Declaration of Kevin Almeroth
` Case: 5:16-cv-06925-LHK-SVK 4
`
`
`
`
`
`TeleSign Corporation, EX1020, Page 6
`TeleSign Corporation v. Twilio Inc.
`IPR2017-01977
`
`

`

`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Case 5:16-cv-06925-LHK Document 110-4 Filed 08/28/17 Page 7 of 12
`
`and each REST resource (and their subresources) may be identified by its unique URI (Uniform
`
`Resource Identifier). Ex. B at 76-106, 109-116. Further, REST also emphasizes a stateless
`
`communication between the client and server, caches data, and uses HTTP return codes and
`
`media types. Ex. B at 47-48, 76-106, 143-144.
`21.
`
`Dr. Nielson also quotes to another portion from Dr. Fielding’s dissertation, but
`
`other than emphasizing the last sentence, does not explain how it demonstrates that the term
`
`“REST API” is indefinite. Nielson Dec. at ¶33, Ex. B at 115. Further, Dr. Nielson selectively
`
`cites to that portion of Dr. Fielding’s dissertation. A more complete quote is below:
`
`
`Like most real-world systems, not all components of the deployed Web
`architecture obey every constraint present in its architectural design. REST has
`been used both as a means to define architectural improvements and to identify
`architectural mismatches. Mismatches occur when, due to ignorance or oversight,
`a software implementation is deployed that violates the architectural constraints.
`While mismatches cannot be avoided in general, it is possible to identify them
`before they become standardized.
`
`
`Ex. B at 115.
`22.
`
`In my opinion, this citation demonstrates the ability of persons of skill in the art
`
`to review a system and determine whether it conforms with or violates the conventions of a
`
`REST architecture.
`23.
`
`Dr. Nielson also points to an unauthenticated blog post by Dr. Fielding,
`
`suggesting that it demonstrated frustration by Dr. Fielding over how people had misused the
`
`term “REST.” Nielson Dec. at ¶33. First, this is a blog post. It provides an anecdotal opinion at
`
`best, even if it is from Dr. Fielding. Second, the developer that Dr. Fielding was criticizing in
`
`his blog post “never meant to imply that [his API] is RESTful (and neither did the authors of the
`
`[API]).” See Developer Response at rollerweblogger.org/roller/entry/the_x_rated_socialsite_api.
`
`Regardless, Dr. Fielding’s criticism that the term “REST” is being misused by a developer is
`
`not evidence that the term is indefinite. It is not clear from Dr. Fielding’s blog post (1) the
`
`extent to which people are misusing the term, and (2) whether they are misusing the term for
`
`marketing reasons, for example, or because there is genuine confusion over what the term
`
`Declaration of Kevin Almeroth
` Case: 5:16-cv-06925-LHK-SVK 5
`
`
`
`
`
`TeleSign Corporation, EX1020, Page 7
`TeleSign Corporation v. Twilio Inc.
`IPR2017-01977
`
`

`

`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Case 5:16-cv-06925-LHK Document 110-4 Filed 08/28/17 Page 8 of 12
`
`means. Further and most important, Dr. Nielson ignores the fact that this blog post goes on to
`
`state: “API designers, please note the following rules before calling your creation a REST API.”
`
`Fielding’s Blog at http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven.
`
`What follows is a list of rules that apply to REST APIs that Dr. Fielding views are most often
`
`violated. At the end of his post, Dr. Fielding notes that there might be other rules that he may be
`
`forgetting; however, I would not think that blog posts are typically seen as a place where
`
`standards are defined. In any event, the blog post only further demonstrates that the term REST
`
`API is not indefinite.
`24.
`
`Dr. Nielson also uses a variety of words to attempt to characterize REST as
`
`vague, including “philosophical,” “overly simplistic,” “REST friendly,” and “operating in a
`
`‘RESTful way.’” Nielson Dec. at ¶33. But none of these descriptions demonstrates that “REST
`
`API” is indefinite.
`25.
`
`Dr. Nielson states, “Moreover, as will be described in greater detail below, the
`
`specification’s own description of REST indicates that it was known in the art that REST had
`
`varying ‘levels’ and no hard requirements.” Nielson Dec. at ¶33. First, having varying levels is
`
`not an indication of indefiniteness. Second, Dr. Nielson never comes back to the point of “hard
`
`requirements.” Such a characterization is in direct contradiction to the specification, Dr.
`
`Fielding’s dissertation, and even his blog post. For example, and as described above in
`
`paragraphs 19-20, in the specification, and in Dr. Fielding’s dissertations (and his blog post),
`
`REST is defined by an architectural style and includes a set of architectural constraints and
`
`agreements.
`
` As a further example, the specification repeatedly states using REST
`
`“conventions”, “principles”, and “architectures” “as if familiar to many web developers.” The
`
`specification goes on to provide examples of employing these architectures as discussed in more
`
`detail below.
`26.
`
`Dr. Nielson suggests that “REST API” is indefinite because the specification of
`
`the Asserted Patents does not define the term. Nielson Dec. at ¶34. But the citations he uses
`
`from the specification (listed below) all indicate that the inventors understood a person of
`
`ordinary skill in the art would have known with reasonable certainty what a “REST API” was.
`Declaration of Kevin Almeroth
` Case: 5:16-cv-06925-LHK-SVK 6
`
`
`
`
`
`TeleSign Corporation, EX1020, Page 8
`TeleSign Corporation v. Twilio Inc.
`IPR2017-01977
`
`

`

`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Case 5:16-cv-06925-LHK Document 110-4 Filed 08/28/17 Page 9 of 12
`
`a. “a REST API as is familiar to many web developers” ‘021 Patent at 2:17-18.
`b. “RESTful is understood in this document to describe a Representational State
`
`Transfer architecture as is known in the art” ‘021 Patent at 5:18-20.
`c. “a REST API (Representational State Transfer) as is known in the art” ‘021
`
`Patent at 8:15-17.
`d. “Consistent with the RESTful conventions” ‘021 Patent at 9:42-23.
`e. “as is common in RESTful architectures” ‘021 Patent at 11:60.
`f. “Using RESTful principles” ‘021 Patent at 11:64-65.
`
`I agree with the inventors. Thus, it is clear that the specification and claims use the term “REST
`
`API” consistently with its commonly understood meaning.
`27.
`
`I disagree with Dr. Nielson’s suggestion that those skilled in the art would not
`
`have understood the term “REST API.” One of ordinary skill in the art at the time of the
`
`invention would understand that REST stands for Representational State Transfer. A person of
`
`ordinary skill in the art at the time would also understand that API is an Application
`
`Programming Interface, and used with the modifier “REST,” describes certain mechanisms by
`
`which a program could access the features of a server. Further, one of skill in the art would
`
`understand that REST relies on a stateless, client-server communication protocol, and primarily
`
`uses the HTTP protocol. This would have been well-known to a person of ordinary skill in the
`
`art at the time of the invention. The specification of the Asserted Patents confirms this
`
`understanding.
`28.
`
`For example, despite Dr. Nielson’s request for absolute precision in the
`
`specification (which he acknowledges is never attainable (Nielson Dec. ¶31)), the specification
`
`provides multiple examples indicating that a person of ordinary skill in the art would understand
`
`the term “REST API” as discussed below.
`29.
`
`For example, the specification states “[t]he HTTP request (or any suitable request
`
`communication) to the server preferably observes the principles of a RESTful design. RESTful
`
`is understood in this document to describe a Representational State Transfer architecture as is
`
`known in the art. The RESTful HTTP requests are preferably stateless, thus each message
`Declaration of Kevin Almeroth
` Case: 5:16-cv-06925-LHK-SVK 7
`
`
`
`
`
`TeleSign Corporation, EX1020, Page 9
`TeleSign Corporation v. Twilio Inc.
`IPR2017-01977
`
`

`

`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Case 5:16-cv-06925-LHK Document 110-4 Filed 08/28/17 Page 10 of 12
`
`communicated from the call router to the application server preferably contains all necessary
`
`information for operation of the application server and response generation of the application
`
`server.” ‘021 Patent at 5:14-24. Dr. Nielson attempts to counter this quote by selectively
`
`choosing another statement in the specification. Nielson Dec. ¶36. He only provides the
`
`following portion from the specification: “varying level of a RESTful communication
`
`(statelessness).” Id. The entire quote is as follows: “However, a varying level of a RESTful
`
`communication (statelessness) may be used, such as by using cookies, session tracking, or any
`
`suitable devices to simulate a normal website visitor model.” ‘021 Patent at 5:38-41. Dr.
`
`Nielson’s selective citation is in no way “especially confusing” (as Dr. Neilson claims) when
`
`read in its proper context and in its entirety.
`30.
`
`As another example, the specification states “[c]onsistent with the RESTful
`
`conventions, a GET request of a resource may return the current state of a resource, while PUT
`
`may update the state, PUT or POST may be used to create a new resource, and DELETE may be
`
`used to destroy a resource.” ‘021 Patent at 9:42-46. Dr. Nielson again attempts to confuse the
`
`issues in responding to the above quote from the specification. Dr. Nielson states: “But at least
`
`the figures (e.g., FIG. 4C) show that the use of GET and POST requests that alter state are
`
`interchangeable, which is inconsistent with the principles of REST as view by some in the art,
`
`such as Dr. Fielding.” Nielson Dec. at ¶38. As an initial matter, Dr. Nielson acknowledges that
`
`there are principles associated with REST as understood by a person of ordinary skill in the art.
`
`But even putting that aside, Dr. Nielson’s statement is nonsensical. First, Dr. Nielson provides
`
`no citation for his statement. And second, FIG. 4C is an example of a GET Request as
`
`evidenced by the word “GET.” FIG. 4C does not depict a POST request. Another example
`
`from the specification that indicates that a person of ordinary skill in the art would understand
`
`the term “REST API” is at 11:59-62, which states “[t]he calls resource preferably accepts a
`
`request to create a new call resource, as is common in RESTful architectures, which in the Call
`
`Router API, preferably serves to initiate one or more new calls.” ‘021 Patent at 11:59-62.
`31.
`
`It is my opinion that a POSA would have understood the term “REST API” to
`
`mean an application programming interface that is operable with Representational State Transfer
`Declaration of Kevin Almeroth
` Case: 5:16-cv-06925-LHK-SVK 8
`
`
`
`
`
`TeleSign Corporation, EX1020, Page 10
`TeleSign Corporation v. Twilio Inc.
`IPR2017-01977
`
`

`

`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Case 5:16-cv-06925-LHK Document 110-4 Filed 08/28/17 Page 11 of 12
`
`(REST) conventions. This construction is consistent with the specification and how one of
`
`ordinary skill in the art at the time of the invention would have understood the term.
`32.
`
`It is my opinion that the claims, read in light of the patent’s specification and
`
`prosecution history provide reasonable certainty to a person of ordinary skill in the art as to the
`
`meaning of the term “REST API.”
`33.
`
`Dr. Nielson’s declaration attempts to argue the term is indefinite. However, if
`
`anything, Dr. Nielson’s declaration confirms that the term “REST API” was (and is) a term well
`
`known in the art to a person of ordinary skill in the art. For example, Dr. Nielson explains that:
`a. The specifications of the Asserted Patents provide examples of related
`
`functionality. Nielson Dec. at ¶32.
`b. The term “REST” was coined by Dr. Fielding in his dissertation in which Dr.
`
`Fielding identified REST constraints. Nielson Dec. at ¶33.
`c. Dr. Fielding provided the general guidelines for creating REST APIs in a blog
`
`post. Nielson Dec. at ¶33.
`d. There are different types of architectural styles that may be used in designing
`
`APIs. Dr. Nielson mentions both SOAP and REST APIs. Nielson Dec. at
`
`¶38.
`e. A REST API adheres to certain conventions:
`i. “stateless is one thing that is almost universally acknowledged as a
`
`characteristic of REST.” Nielson Dec. at ¶36.
`ii. If both GET and POST requests alter state that “is inconsistent with
`
`the principles of REST.” Nielson Dec. at ¶38.
`iii. The specification states that “API requests can be consistent with
`
`REST.” Nielson Dec. at ¶38.
`
`34.
`
`It is my understanding that TeleSign has also proposed an alternative construction
`
`for the term “REST API”: “a programmatic communication interface using a varying level of
`
`statelessness.”
`
`Declaration of Kevin Almeroth
` Case: 5:16-cv-06925-LHK-SVK 9
`
`
`
`
`
`TeleSign Corporation, EX1020, Page 11
`TeleSign Corporation v. Twilio Inc.
`IPR2017-01977
`
`

`

`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`27
`
`28
`
`Case 5:16-cv-06925-LHK Document 110-4 Filed 08/28/17 Page 12 of 12
`
`35.
`
`As an initial matter, this construction is in direct contradiction with Dr. Nielson’s
`
`opinions regarding indefiniteness. Dr. Nielson makes clear in his declaration that one of the
`
`universal characteristics of REST is statelessness. Nielson Dec. at ¶36. One of ordinary skill in
`
`the art at the time of the invention would not understand the term REST API to include “varying
`
`levels” of statelessness. As indicated by Dr. Nielson and the specification, a REST API does not
`
`use varying levels of statelessness. ‘021 Patent at 5:20 (“RESTful HTTP requests are preferably
`
`stateless”). Further, TeleSign’s proposed construction only creates uncertainty as to the scope of
`
`the term given that “varying level of statelessness” would provide little to no guidance to a
`
`person of ordinary skill in the art as to the bounds of the term.
`36.
`
` TeleSign’s alternative construction also fails to take into consideration the
`
`multiple constraints of a REST API. Whether the standard allows for multiple levels of
`
`statelessness or not, this is only one factor to consider. TeleSign’s alternative constructions
`
`ignores everything else associated with REST and attempts to read the term out of the claim.
`37.
`
`Additionally, TeleSign’s alternative construction would lead to confusion among
`
`those of ordinary skill in the art. For example, a POSA would not be able to apply the term in
`
`the context of the claim given TeleSign’s ambiguous construction. What does varying levels
`
`mean? What level is sufficient and what level is not?
`38.
`
`TeleSign’s alternative construction
`
`is overbroad.
`
` TeleSign’s proposed
`
`construction essentially encompasses any number of architectural style into the claims when the
`
`claims specifically require a REST API.
`
`I declare under penalty of perjury under the laws of the United States that the foregoing is true
`
`and correct. Executed in Santa Barbara, California on July 27, 2017.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Dr. Kevin Almeroth
`
`
`
`
`
`Declaration of Kevin Almeroth
` Case: 5:16-cv-06925-LHK-SVK 10
`
`
`
`TeleSign Corporation, EX1020, Page 12
`TeleSign Corporation v. Twilio Inc.
`IPR2017-01977
`
`