`
`
`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