throbber

`
`
`Paper 10
`Date: October 1, 2020
`
`Trials@uspto.gov
`571-272-7822
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`EARLY WARNING SERVICES, LLC,
`Petitioner,
`
`v.
`
`WILLIAM GRECIA,
`Patent Owner.
`____________
`
`IPR2020-00763
`Patent 8,887,308 B2
`____________
`
`
`
`Before MICHAEL W. KIM, Vice Chief Administrative Patent Judge,
`JAMESON LEE, and MICHELLE N. WORMMEESTER,
`Administrative Patent Judges.
`
`WORMMEESTER, Administrative Patent Judge.
`
`
`
`
`DECISION
`Denying Institution of Inter Partes Review
`35 U.S.C. § 314
`
`
`
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`
`INTRODUCTION
`I.
`Early Warning Services, LLC (“Petitioner”) filed a Petition (Paper 1,
`“Pet.”) requesting inter partes review of claim 1 of U.S. Patent
`No. 8,887,308 B2 (Ex. 1001, “the ’308 patent”). William Grecia (“Patent
`Owner”) filed a Preliminary Response (Paper 6, “Prelim. Resp.”).1 With our
`authorization, Petitioner filed a Reply (Paper 8) to Patent Owner’s
`Preliminary Response, and Patent Owner filed a Sur-Reply (Paper 9) to
`Petitioner’s Reply. See Paper 7. We have jurisdiction under 35 U.S.C.
`§ 314 and 37 C.F.R. § 42.4(a). Under 35 U.S.C. § 314(a), an inter partes
`review may not be instituted “unless . . . there is a reasonable likelihood that
`the petitioner would prevail with respect to at least 1 of the claims
`challenged in the petition.” For the reasons that follow, we decline to
`institute an inter partes review of the challenged claim.
`
`
`II. BACKGROUND
`A. Related Proceedings
`The parties identify several federal district court cases relating to the
`’308 patent. Pet. 1–2; Paper 5, 2. The parties also identify several other
`petitions for inter partes review relating to the ’308 patent. Pet. 2–3;
`Paper 5, 2.
`
`
`
`1 We note that Patent Owner captioned Paper 6 as “Mandatory Notices.”
`This appears to be a typographical error. Accordingly, we treat Paper 6 as
`Patent Owner’s Preliminary Response.
`
`2
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`
`B. The ’308 Patent
`The ’308 patent describes a digital rights management system, that
`manages access rights across a plurality of devices via digital media
`personalization, to protect digital media subject to illegal copying. Ex. 1001,
`1:20–27, 4:48–49. To illustrate, Figure 3 of the ’308 patent is reproduced
`below.
`
`
`Figure 3 is a flow chart of a digital media personalization process. Id. at
`4:23–25. A user wishing to access certain digital media (e.g., videos,
`audios, games) posts a branding request via Kodekey GUI 301, which
`prompts the user to enter a token and press the redeem button. Id. at 6:19–
`
`3
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`21, 6:66–7:4. The branding request is a request to read or write metadata
`associated with the digital media and includes a membership verification
`token corresponding to the digital media. Id. at 5:48–51. The token may be
`a unique serial number assigned to the digital media. Id. at 6:38–40. It
`represents the digital media provider’s permission to grant access rights. Id.
`at 9:21–23. Kodekey GUI 301 is connected to token database 305, which
`reads, writes, and store tokens. Id. at 7:7–11. Token database 305 is used to
`authenticate the token entered at Kodekey GUI 301. Id. at 8:20–22; see also
`id. at 8:53–56 (“According to an embodiment of the present invention, an
`identifier for the digital media is stored in a database with another database
`of a list of associated tokens for cross-reference identification for
`verification.”).
`After authentication, the user is redirected to APIwebsite.com
`GUI 307, which prompts the user to enter a login ID and password to access
`the digital media from database 309. Id. at 7:11–12, 15–18. The
`APIwebsite.com GUI interfaces to a web service membership (e.g.,
`Facebook), where an electronic identification for the user is collected and
`sent to Kodekey GUI 301. Id. at 7:11–15, 10:41–46. Kodekey GUI 301
`also is connected to product metadata 302, which is readable and writable
`metadata associated with the digital media to be acquired. Id. at 7:4–5.
`Product metadata 302 is branded by writing the token and the user’s
`electronic identification reference into the metadata. Id. at 8:28–31.
`For a subsequent access request, the user’s electronic identification
`reference is compared against the electronic identification reference in
`metadata 302. Id. at 13:52–56. If there is a match, access rights are granted
`to the user. Id. at 13:56–61.
`
`4
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`
`C. Challenged Claim
`Petitioner challenges claim 1 of the ’308 patent:
`1. A process for transforming a user access request for cloud
`digital content into a computer readable authorization object, the
`process for transforming comprising:
`a) receiving an access request for cloud digital content
`through an apparatus in process with at least one CPU, the
`access request being a write request to a data store,
`wherein the data store is at least one of:
`a memory connected to the at least one CPU;
`a storage connected to the at least one CPU; and
`a database connected to the at least one CPU through
`the Internet; wherein
`the access request further comprises verification data
`provided by at least one user, wherein the
`verification data is recognized by the apparatus as a
`verification token; then
`b) authenticating the verification token of (a) using a
`database recognized by the apparatus of (a) as a
`verification token database; then
`c) establishing an API communication between the apparatus
`of (a) and a database apparatus, the database apparatus
`being a different database from the verification token
`database of (b) wherein the API is related to a verified web
`service, wherein the verified web service is a part of the
`database apparatus, wherein establishing
`the API
`communication requires a credential assigned to the
`apparatus of (a), wherein the apparatus assigned credential
`is recognized as a permission to conduct a data exchange
`session between the apparatus of (a) and the database
`apparatus to complete the verification process, wherein the
`data exchange session is also capable of an exchange of
`query data, wherein the query data comprises at least one
`verified web service account identifier; then
`
`5
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`
`d) requesting the query data, from the apparatus of (a), from
`the API communication data exchange session of (c),
`wherein the query data request is a request for the at least
`one verified web service identifier; then
`e) receiving the query data requested in (d) from the API
`communication data exchange session of (c); and
`f) creating a computer readable authorization object by
`writing into the data store of (a) at least one of:
`the received verification data of (a); and
`the received query data of (e); wherein
`the created computer readable authorization object is
`recognized by the apparatus of (a) as user access
`rights associated to the cloud digital content,
`wherein the computer readable authorization object
`is processed by the apparatus of (a) using a cross-
`referencing action during subsequent user access
`requests to determine one or more of a user access
`permission for the cloud digital content.
`
`
`
`D. Asserted Grounds of Unpatentability
`Petitioner challenges claim 1 of the ’308 patent on the following
`grounds. Pet. 6, 21–73.
`Claim Challenged
`
`References/Basis
`35 U.S.C. §
`Lynch2
`102(e)
`1
`the ’868 Publication3
`102(b)
`1
`In support of its arguments, Petitioner relies on a Declaration of Dr. Michael
`Shamos (Ex. 1012) and a Declaration of Warren Johnson (Ex. 1060).
`
`
`
`2 Lynch, U.S. Patent No. 7,769,998 B2, issued Aug. 3, 2010 (Ex. 1011).
`3 Grecia, U.S. Publ’n No. 2010/0185868 A1, published July 22, 2010
`(Ex. 1005).
`
`6
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`
`III. DISCUSSION
`A. Claim Construction
`In an inter partes review proceeding, we construe a claim of a patent
`“using the same claim construction standard that would be used to construe
`the claim in a civil action under 35 U.S.C. 282(b).” See 37 C.F.R.
`§ 42.100(b) (2019). That standard involves construing claims in accordance
`with the ordinary and customary meaning of such claims as would have been
`understood by one of ordinary skill in the art and the prosecution history
`pertaining to the patent. See id.; Phillips v. AWH Corp., 415 F.3d 1303,
`1312–14 (Fed. Cir. 2005) (en banc).
`Petitioner proposes constructions for various limitations of claim 1.
`Pet. 14–21. Patent Owner does not respond. See generally Prelim. Resp.
`For purposes of this Decision, we conclude that no claim term requires
`express interpretation at this time to resolve any controversy in this
`proceeding. See Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795,
`803 (Fed. Cir. 1999).
`
`
`B. Anticipation by Lynch
`Petitioner asserts that Lynch anticipates claim 1 of the ’308 patent.
`Pet. 6, 21–56. For the reasons explained below, we determine that Petitioner
`has not demonstrated a reasonable likelihood of prevailing on this asserted
`ground.
`We start with an overview of Lynch.
`
`
`7
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`
`1. Lynch
`Lynch describes systems and methods for authenticating and
`authorizing user access to a system. Ex. 1011, 1:13–16. Figure 5, which is
`reproduced below, illustrates an example of a system according to Lynch.
`
`
`
`
`In particular, Figure 5 of Lynch illustrates authentication and authorization
`mechanism 500, which is used to authenticate and authorize user 502
`wishing to access primary site 506 via secondary site 504 in order to perform
`various tasks on primary site 506. Id. at 10:4–15, 10:21–24.
`When user 502 tries to access primary site 506 via secondary site 504,
`secondary site 504 determines whether it has a token that corresponds to
`user 502. Id. at 10:24–28. If secondary site 504 has the token, secondary
`site 504 contacts primary site 506 by accessing Application Program
`
`8
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`Interface (API) 508 at primary site 506. Id. at 10:28–32. Primary site 506
`authenticates and authorizes user 502 by returning the API call. Id.
`User 502 may then access primary site 506 via secondary site 504. Id. at
`10:32–33, Figs. 5, 6.
`If secondary site 504 does not have the token, however, user 502 is
`redirected to primary site 506 for sign-in (if already registered) or
`registration (and then sign-in). Id. at 10:36–38, 11:15–20, 14:6–7. After
`sign-in, primary site 506 generates a token for user 502. Id. at 14:14–16.
`The entire token may then be sent to secondary site 504 for a single use. Id.
`at 14:17–18.
`Alternatively, the token may be divided into portions, where, for
`example, one half of the token is sent to secondary site 504 and the other
`half of the token is stored at primary site 506. Id. at 11:23–28, 11:47–49,
`14:18–20. Partial tokens are used for future user access authentication and
`authorization. Id. at 14:20–21. Thus, when user 502 tries to access primary
`site 506 via secondary site 504, secondary site 504 contacts primary site 506
`by accessing API 508 and provides the partial token to primary site 506 for
`matching with the other portion of the token stored at primary site 506. Id.
`at 13:49–54. If the partial tokens match, primary site 506 authenticates and
`authorizes user 502 by returning the API call. Id. at 13:61–66.
`
`
`2. Analysis
`Claim 1 is directed to “[a] process for transforming a user access
`request for cloud digital content into a computer readable authorization
`object,” and recites six steps. These steps include “a) receiving an access
`request,” “b) authenticating [a] verification token,” “c) establishing an API
`
`9
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`communication,” “d) requesting . . . query data,” “e) receiving the query
`data,” and “f) creating a computer readable authorization object.” We
`address certain aspects of the first two steps, namely, steps a) and b), in
`detail.
`
`
`a. “a) receiving an access request . . .”
`Claim 1 recites “a) receiving an access request for cloud digital
`content through an apparatus in process with at least one CPU, the access
`request being a write request to a data store, . . . wherein the access request
`further comprises verification data provided by at least one user, wherein the
`verification data is recognized by the apparatus as a verification token.”
`For this “receiving” step, Petitioner directs us to where Lynch teaches
`that “the user 502 uses the secondary site 504 to access the primary site 506
`to perform various tasks . . . on the primary site 506,” and that “[w]hen the
`user 502 attempts to access the primary site 506, via the secondary site 504,
`the secondary site 504 determines whether there is a token (e.g., partial
`token, half token, split token) at the secondary site 504 that corresponds to
`the user 502.” Pet. 27, 33 (quoting Ex. 1011, 10:21–28) (emphases by
`Petitioner omitted). Petitioner also directs us to where Lynch teaches that
`“[i]n the absence of such a token, the secondary site 504 may redirect 514
`the user 502 to the primary site 506 for sign-in 516 and/or registration 520,
`so the token can be generated by and obtained from the primary site 506.”
`Id. at 28 (quoting Ex. 1011, 11:15–31). In this regard, Petitioner further
`directs us to Lynch’s description of “a federated mechanism (e.g., system or
`subsystem) 806 in communication with the primary site’s community site
`(e.g., www.website.com), which also functions as the sign-in site 802, for
`
`10
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`the user to sign-in and/or register to start the process of authentication and
`authorization,” where federated mechanism 806 uses “credentials 808
`includ[ing] user information (e.g., user identification, password, preferences,
`name, address, billing information, etc.) . . . to authenticate and authorize the
`user.” Id. at 34–35 (quoting Ex. 1011, 16:9–27). Petitioner additionally
`points to Lynch’s teaching that “[a] token is generated by the primary
`site 506 for the user 502 and a segment or portion of the token (e.g., half
`token, partial token) is then transmitted to the secondary site.” Id. at 28
`(quoting Ex. 1011, 11:15–31) (emphasis by Petitioner omitted).
`Petitioner identifies Lynch’s secondary site 504 as the recited
`“apparatus” of step a). Id. at 29. This is key to our analysis. As discussed
`in further detail below, Petitioner describes how verification data is
`recognized by this “apparatus” as a verification token, but incorrectly
`discusses Lynch’s sign-in site 802 as though it were secondary site 504. Id.
`at 34–35. Petitioner points to nothing in Lynch that indicates that sign-in
`site 802 is the same as secondary site 504, or is a secondary site by another
`reference number. Sign-in site 802, instead, is described as a community
`site of the primary site and, as such, is a part of the primary site. Ex. 1011,
`16:9–27. Indeed, Lynch states that “[b]oth the federated mechanism 806 and
`the sign-in site 802 are based on the transaction platform of the primary site,
`which includes an API/platform 804.” Id. at 16:15–17.
`Specifically, Petitioner contends that “Lynch discloses this limitation
`as a request to access content on the primary site . . . to write a token into the
`data store of the primary site and/or store a partial token at the secondary
`site.” Pet. 29. Petitioner further contends that to determine whether there is
`a token at secondary site 504, “the secondary site must authenticate the user,
`
`11
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`i.e., the verification data (e.g., user name) is recognized . . . by the secondary
`site as a verification token.” Id. at 33–34. According to Petitioner, “Lynch
`discloses that the access request contains at least a user name and password,
`which is recognized by the secondary site (sign-in site 802, apparatus of (a))
`as a verification token.” Id. at 34. Although Lynch also specifically
`describes a “token,” Petitioner notes that it is identifying the “user name”
`and “password” of Lynch as the “verification token of Claim 1 of the
`’308 Patent[, which] is different from the ‘token’ described in Lynch.” Id. at
`35.
`
`On the record before us, we are not persuaded that Petitioner has
`sufficiently shown that Lynch discloses step a) of claim 1. In particular, we
`are not persuaded that Lynch discloses claim 1’s requirement that “the
`verification data is recognized by the apparatus as a verification token.”
`Petitioner contends that “Lynch discloses that the access request contains at
`least a user name and password, which is recognized by the secondary site
`(sign-in site 802, apparatus of (a)) as a verification token.” Pet. 34. This
`contention is based on the position that Lynch’s sign-in site 802 corresponds
`to the secondary site, which Petitioner identifies as the recited “apparatus.”
`Petitioner further identifies Lynch’s user name and password as the recited
`“verification data.” Lynch, however, teaches that its “federated model 800
`includes a federated mechanism (e.g., system or subsystem) 806 in
`communication with the primary site’s community site (e.g.,
`www.website.com), which also functions as the sign-in site 802, for the user
`to sign-in and/or register.” Ex. 1011, 16:9–14 (emphases added). This
`teaching indicates that Lynch’s sign-in site 802 corresponds to the primary
`site, not the secondary site. See also id. at 11:17–20 (“[T]he secondary
`
`12
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`site 504 may redirect 514 the user 502 to the primary site 506 for sign-in.”
`(emphasis added)); id. at 14:35–42 (describing “an embodiment of an
`authentication and authorization architecture 700 having a transaction
`platform 702 with a federated mechanism 704,” where “the transaction
`platform 702 is based at a primary site 734 (e.g., eBay)” and “includes a
`registration and sign-in site (e.g., eBay Community site) 706 for the user 708
`to use when registering or signing-in” (emphases added)); id. at Fig. 7
`(showing sign-in site 706 as a part of primary site 734). Accordingly,
`contrary to Petitioner’s position, Lynch’s user name and password are not
`recognized by the secondary site as a verification token, as Petitioner asserts.
`
`
`b. “b) authenticating the verification token . . .”
`We also are unpersuaded that Petitioner has sufficiently shown that
`Lynch discloses step b) of claim 1. This step requires “then b)
`authenticating the verification token of (a) using a database recognized by
`the apparatus of (a) as a verification token database.” For this
`“authenticating” step, Petitioner contends that it is Lynch’s secondary site
`that “uses a database to authenticate the user identification and password.”
`Pet. 35.
`As support, Petitioner directs us to where Lynch teaches that “a
`request for authentication and authorization of a user is received from a
`secondary site on behalf of the user who is seeking to access a primary site
`via the secondary site,” where “[t]he request includes information relating to
`the user” that “is then verified for authenticity.” Id. at 35–36 (quoting
`Ex. 1011, 1:49–57). This teaching does not support Petitioner’s contention.
`The request for authentication and authorization in Lynch is received from
`
`13
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`the secondary site, which indicates that it is the entity receiving the request,
`not the secondary site, that performs the authentication and authorization.
`Thus, Petitioner incorrectly asserts that Lynch’s secondary site uses a
`database to authenticate the user identification and password.
`Petitioner further directs us to where Lynch describes “a federated
`mechanism (e.g., system or subsystem) 806 in communication with the
`primary site’s community site (e.g., www.website.com), which also
`functions as the sign-in site 802, for the user to sign-in and/or register to start
`the process of authentication and authorization.” Id. at 36 (quoting
`Ex. 1011, 16:7–27). Lynch teaches that “[b]oth the federated
`mechanism 806 and the sign-in site 802 are based on the transaction
`platform of the primary site,” and that “[t]he federated mechanism 806
`serves as an authenticator.” Ex. 1011, 16:15–20 (quoted by Pet. 36). Lynch
`also teaches that federated mechanism 806 uses “credentials 808 includ[ing]
`user information (e.g., user identification, password, preferences, name,
`address, billing information, etc.) that the federated mechanism 806 uses . . .
`to authenticate and authorize the user.” Id. at 16:20–27 (quoted by Pet. 36).
`According to Petitioner, an ordinarily skilled artisan “would have
`understood that the verification to ‘authenticate and authorize the user’
`requires a lookup in a database of authorized users, otherwise there would be
`no way for the secondary site to verify the user’s identification and
`password.” Id. at 37. Even if this were true, Lynch’s teachings indicate that
`federated mechanism 806 is at the primary site, not the secondary site. See
`also Ex. 1011, 14:35–47 (describing “an embodiment of an authentication
`and authorization architecture 700 having a transaction platform 702 with a
`federated mechanism 704,” where “[t]he federated mechanism 704 is to
`
`14
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`provide a mechanism for authentication and authorization of users 708 by
`the primary site 734”); id. at Fig. 7 (showing federated mechanism 704 as a
`part of primary site 734). That is, Lynch’s teachings indicate that the
`primary site (not the secondary site) performs the authentication and
`authorization.
`Petitioner additionally asserts that “[t]he same type of verification
`occurs at the primary site.” Pet. 37–39. Petitioner’s assertion, however,
`does not show that Lynch’s secondary site authenticates the user name and
`password. Nor does it show that any database that the primary site uses for
`verification purposes is recognized by the secondary site at all, let alone as a
`verification token database.
`
`
`3. Summary
`In view of the foregoing, we are not sufficiently persuaded that Lynch
`discloses steps a) and b) of claim 1. Accordingly, we determine that
`Petitioner has not demonstrated a reasonable likelihood of showing that
`Lynch anticipates claim 1.
`
`
`C. Anticipation by the ’868 Publication
`Petitioner asserts that the ’868 publication anticipates claim 1 of the
`’308 patent. Pet. 6, 56–73. Through a chain of continuation applications,
`the application for the ’308 patent claims priority to U.S. Application
`No. 12/728,218, which was published as the ’868 publication. Ex. 1001,
`code (63); Ex. 1005, codes (10), (21). Specifically, the application for the
`’308 patent claims priority to U.S. Application No. 13/740,086 (“the
`’086 application”), which was filed on January 11, 2013, and issued as U.S.
`
`15
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`Patent No. 8,533,860. Ex. 1001, code (63), 1:6–15. The ’086 application
`claims priority to U.S. Application No. 13,397,517, which was filed on
`February 15, 2012, and issued as U.S. Patent No. 8,402,555. Id. U.S.
`Application No. 13/397,517 claims priority to U.S. Application
`No. 12/985,351, which was filed on January 6, 2011, and eventually
`abandoned. Id. Finally, U.S. Application No. 12/985,351 claims priority to
`U.S. Application No. 12/728,218, which was filed on March 21, 2010,
`published as the ’868 publication, and eventually abandoned. Id. To
`illustrate, we provide a chart showing the ’308 patent’s claimed priority
`chain.
`
`
`Application 12/728,218
`(The ’868 Publication)
`Filed: March 21, 2010
`
`Application 12/985,351
`(abandoned)
`Filed: January 6, 2011
`
`Application 13,397,517
`(Patent 8,402,555)
`Filed: February 15, 2012
`
`The ’086 Application
`(Patent 8,533,860)
`Filed: January 11, 2013
`
`Application 12/728,218
`(The ’308 Patent)
`Filed: January 11, 2013
`
`
`
`16
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`
`Petitioner’s reliance on the ’868 publication (publication of the
`earliest priority application) as an anticipatory reference is based on
`Petitioner’s position that the ’086 application (intermediate priority
`application) failed to comply with provisions governing priority claims,
`thereby breaking the claimed priority chain. Pet. 56–67. For the reasons
`explained below, we determine that Petitioner has not demonstrated a
`reasonable likelihood of prevailing on its asserted anticipation ground.
`We start with an overview of the relevant prosecution history for the
`’086 application.
`
`
`1. Relevant Prosecution History for the ’086 Application
`On January 11, 2013, a pro se applicant (“Applicant”) filed the
`’086 application (to which the application for the ’308 patent directly claims
`priority). Ex. 1007, 3937–3990. The first lines following the title of the
`’086 application’s original specification claim priority to a chain of
`continuation applications, including U.S. Application No. 12/728,218
`(earliest filed priority application), filed March 21, 2010. Id. at 3956. As
`discussed above, U.S. Application No. 12/728,218 was published as the
`’868 publication. The ’086 application did not include an Application Data
`Sheet (“ADS”) claiming priority to the chain of continuation applications
`referenced in the specification. Id. at 3931 (Utility Patent Application
`Transmittal). On May 31, 2013, the Patent Office issued a Notice of
`Allowance. Id. at 3762–3766.
`After issuing the Notice of Allowance, the Patent Office mailed a
`Notice to File Corrected Application Papers on August 1, 2013, indicating
`that “[t]he 37 CFR 1.78(a)(2) reference to the prior U.S. nonprovisional
`
`17
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`application or international application designating the U.S. is not present on
`an application data sheet.” Id. at 3754. The Notice states that “[a] proper
`response to this notice would include any one of: (1) a corrected Application
`Data Sheet (ADS) pursuant to 37 CFR 1.76(c) which provides benefit
`information that complies with 37 CFR 1.78(a)(2) . . . or (2) a petition filed
`pursuant to the provisions of 37 CFR 1.78(a)(3) . . . .” Id. Applicant
`responded to the Notice that same day by filing an ADS including
`information on the ’086 application’s claimed priority chain. Id. at 3755–
`3761.
`
`The ’086 application issued as U.S. Patent No. 8,533,860 on
`September 10, 2013, without any reference to the claimed priority chain on
`the face of the patent. Ex. 1002, codes (10), (21), (45); see also Ex. 1007,
`3735 (Issue Notification). Applicant subsequently filed four Requests for
`Certificate of Correction within approximately one month of the issue date.
`Ex. 1007, 3706–3734. These Requests for Certificate of Correction sought
`various changes to the issued patent. See id. One Request for Certificate of
`Correction in particular, filed September 13, 2013, sought to add a reference
`to the claimed priority chain on the face of the patent. Id. at 3720.
`Specifically, it sought to add the language “(63) Continuation of application
`No. 13/397,517, filed on Feb. 15, 2012, which is a continuation of
`application No. 12/985,351, filed on Jan. 6, 2011, which is a continuation of
`application No. 12,728,218, filed on Mar. 21, 2010, now abandoned.” Id.
`Applicant filed this Request for Certificate of Correction pursuant to 37
`C.F.R. § 1.322, which authorizes certificates of correction for mistakes
`incurred through the fault of the Patent Office. Id. at 3722. The Patent
`Office issued two Certificates of Correction reflecting all the changes sought
`
`18
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`in Applicant’s four Requests for Certificates of Correction, including a
`reference to the claimed priority chain on the face of the patent. Id. at 3692,
`3698.
`
`
`
`2. Analysis
`Petitioner argues that “the priority claims relied on in the ’308 Patent
`are defective for a number of reasons, and therefore, the challenged claim is
`not entitled to an effective filing date earlier than the January 11, 2013 filing
`date of the ’086 Application.” Pet. 56. More specifically, Petitioner argues
`that there is a break in the ’308 patent’s claimed priority chain between the
`’086 application and earlier filed applications, and, therefore, the
`’868 publication may be used as prior art against the challenged claim. See
`id. at 56–67. To determine whether the ’868 publication qualifies as prior
`art, we address whether there is a break in the ’308 patent’s claimed priority
`chain.
`Priority claims are governed by statute. For domestic priority claims,
`35 U.S.C. § 120 requires that the patent application “contains or is amended
`to contain a specific reference to the earlier filed application.” Thus, each
`application in a chain of priority must refer to all prior applications.
`Encyclopaedia Britannica, Inc. v. Alpine Elecs. of Am., Inc., 609 F.3d 1345,
`1352 (Fed. Cir. 2010).
`The Patent Office has issued a regulation implementing 35 U.S.C.
`§ 120, namely, 37 C.F.R. § 1.78. Under the provisions of 37 C.F.R. § 1.78
`in effect at the time of the ’086 application filing, “any nonprovisional
`application . . . claiming the benefit of one or more prior-filed copending
`nonprovisional applications . . . must contain or be amended to contain a
`
`19
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`reference to each such prior-filed application,” where “the reference . . .
`must be included in an application data sheet” and “submitted within the
`later of four months from the actual filing date of the later-filed application
`or sixteen months from the filing date of the prior-filed application.”
`Manual of Patent Examining Procedure, App. R, 37 C.F.R. § 1.78(a)(2)(i)–
`(iii) (2012-09-16 thru 2013-03-15) (9th ed. 2014). Section 1.78 further
`provides that “[i]f the reference required . . . is presented after the time
`period . . . , the claim . . . for benefit . . . may be accepted if the reference . . .
`was unintentionally delayed,” and that “[a] petition to accept an
`unintentionally delayed claim . . . for the benefit of a prior-filed application
`must be accompanied by: (i) [t]he reference required . . . ; (ii) [a] surcharge
`. . . ; and (iii) [a] statement that the entire delay between the date the claim
`was due . . . and the date the claim was filed was unintentional.” Id.
`§ 1.78(a)(3).
`Petitioner contends that “the priority chain of the ’308 Patent via the
`’086 Application fails to meet the specific reference requirement.” Pet. 58.
`Petitioner asserts that “the ’086 Application was filed without an ADS at
`all.” Id. at 59. As to Applicant’s filing of an ADS in response to the Patent
`Office’s Notice to File Corrected Application Papers, Petitioner further
`asserts that “th[e] ADS was faulty because Applicant filled out the priority
`claim information incorrectly.” Id. at 60 (citing Ex. 1007, 3759). In
`addition, Petitioner asserts that Applicant’s “faulty ADS in the
`’086 Application is outside . . . [the required timeframes]” for submitting an
`ADS. Id. at 61 n.4. According to Petitioner, therefore, “even if Applicant
`had filled out the ADS correctly, the ADS still was not effective because the
`following items were not filed along with the ADS: (i) mandatory petition
`
`20
`
`

`

`IPR2020-00763
`Patent 8,887,308 B2
`
`asserting that the entire delay was unintentional and (ii) an associated fee.”
`Id. at 61. Petitioner also points out that “the [Patent Office] did not issue a
`corrected filing receipt showing the priority claim, and the ’086 Application
`issued on September 10, 2013 as the ’860 Patent without a priority claim on
`its face.” Id. at 62.
`We disagree with Petitioner. As discussed above, the Patent Office’s
`Notice to File Corrected Application Papers instructed that a proper response
`to the Notice would include a corrected ADS or a petition pursuant to 37
`C.F.R. § 1.78(a)(3). Ex. 1007, 3754. In response to the Notice, Applicant
`followed the Patent Office’s explicit instruction and promptly filed an ADS.
`Id. at 3755–3761. Although Applicant might have completed the ADS
`incorrectly, as Petitioner alleges, all the required information was
`nonetheless included in the appropriate section. Compare id. at 3759, with
`Ex. 1002, 1:7–14 (Cross-Reference to Related Applications), Certificate of
`Correction (signed Nov. 12, 2013). Moreover, independent of whether the
`priority informa

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket