Filed on behalf of Microsoft Corporation
`
`By: John D. Vandenberg (Reg. No. 31,312)
`
`john.vandenberg@klarquist.com
`Stephen J. Joncus (Reg. No. 44,809)
`stephen.joncus@klarquist.com
`Klarquist Sparkman, LLP
`One World Trade Center, Suite 1600
`121 S.W. Salmon Street
`Portland, Oregon 97204
`Telephone: (503) 595-5300
`Facsimile: (503) 595-5301
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________
`
`MICROSOFT CORPORATION
`Petitioner
`
`v.
`
`PROXYCONN, INC.
`Patent Owner
`
`____________
`
`Case IPR2012-00026 (TLG)
`Case IPR2013-00109 (TLG)
`Patent 6,757,717 B1
`
`____________
`
`MICROSOFT CORPORATION’S OPPOSITION TO PATENT OWNER’S
`CORRECTED MOTION TO AMEND UNDER 37 C.F.R. § 42.121
`
`
`
`
`By: John D. Vandenberg (Reg. No. 31,312)
`
`john.vandenberg@klarquist.com
`Stephen J. Joncus (Reg. No. 44,809)
`stephen.joncus@klarquist.com
`Klarquist Sparkman, LLP
`One World Trade Center, Suite 1600
`121 S.W. Salmon Street
`Portland, Oregon 97204
`Telephone: (503) 595-5300
`Facsimile: (503) 595-5301
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________
`
`MICROSOFT CORPORATION
`Petitioner
`
`v.
`
`PROXYCONN, INC.
`Patent Owner
`
`____________
`
`Case IPR2012-00026 (TLG)
`Case IPR2013-00109 (TLG)
`Patent 6,757,717 B1
`
`____________
`
`MICROSOFT CORPORATION’S OPPOSITION TO PATENT OWNER’S
`CORRECTED MOTION TO AMEND UNDER 37 C.F.R. § 42.121
`
`
`
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`
`TABLE OF CONTENTS
`
`Page
`
`I.
`
`CLAIM 35 ....................................................................................................... 2
`
`II.
`
`CLAIM 36 ....................................................................................................... 4
`
`III. CLAIM 37 ....................................................................................................... 5
`
`IV. CLAIM 38 ....................................................................................................... 6
`
`V.
`
`CLAIM 39 ....................................................................................................... 9
`
`VI. CLAIM 40 .....................................................................................................11
`
`VII. CLAIM 41 .....................................................................................................13
`
`
`
`
`
`
`
`i
`
`
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`
`The Board should deny Patent Owner’s over-length motion to amend. Each
`
`proposed claim enlarges the scope of the claims and/or introduces new matter, in
`
`violation of 35 U.S.C. § 316(d)(3). At least one claim is unpatentable for indefi-
`
`niteness, under 35 U.S.C. § 112(b). Several amendments seek to correct claim de-
`
`fects in ways that do not respond to a ground of unpatentability involved in the tri-
`
`al, in violation of 37 C.F.R. § 42.121(a)(2)(ii). Each claim is anticipated by DRP
`
`and/or Yohe, under 35 U.S.C. § 102. Proxyconn does not even try to meet its bur-
`
`den to show that the proposed claims are patentable over prior art known to it.
`
`Microsoft submits its cross-examination of Dr. Alon Konchitsky (Ex. 1024).
`
`(The parties have agreed to Microsoft filing this transcript, unsigned.) Dr.
`
`Konchitsky is not an expert in this field. Nevertheless, he is a retained agent of
`
`Proxyconn and thus it is proper to treat his cited admissions as admissions of
`
`Proxyconn, if the Board admits his direct testimony in this trial.
`
`Ground
`
`Enlarged
`
`New Matter
`
`Indefinite
`
`Non-responsive
`
`Anticipated by DRP
`
`Anticipated by Yohe
`
`
`
`35
`
`
`
`√
`
`
`
`
`
`√
`
`√
`
`36
`
`√
`
`
`
`
`
`√
`
`√
`
`√
`
`37
`
`38
`
`39
`
`40
`
`41
`
`√
`
`√
`
`√
`
`√
`
`√
`
`√
`
`
`
`√
`
`
`
`
`
`√
`
`
`
`√
`
`√
`
`
`
`
`
`√
`
`√
`
`√
`
`√
`
`
`
`√
`
`√
`
`√
`
`
`
`√
`
`
`
`
`
`√
`
`√
`
`1
`
`
`
`I.
`
`CLAIM 35
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`
`Some Changes from Claim 1: Adds that (1) the receiver is “configured to
`
`initiate a request for data” from the sender; (2) the sender is “configured to trans-
`
`mit a digital digest . . . in response to the request;” and (3) the data includes a range
`
`of octets in a file.
`
`New Matter: Change (1) is new matter. The ’717 patent does not disclose a
`
`receiver being so configured. Admittedly, the patent does refer to the step of be-
`
`ginning a transaction with the receiver sending “a request to the sender/computer.”
`
`(IPR2012-00026, Ex. 1002 (“’717”), e.g., 7:65-67, 8:37-39). But, for Figs. 5-7 and
`
`8-10, it does not say request for data. (Compare id., 9:66 (“a request for data” (for
`
`Fig. 15) with 7:65-67, 8:37-39 (“a request to the sender”)). And, it does not dis-
`
`close the receiver being programmed or otherwise configured to initiate this re-
`
`quest. It may instead, e.g., merely react to a prompt from elsewhere to send a re-
`
`quest. This new “configured to initiate” limitation thus is new matter.
`
`Anticipated by DRP: DRP’s client embodies the claim’s “receiver.” A DRP
`
`client is programmed to (a) request data from the server using a GET or differential
`
`GET request (IPR2013-00109, Ex. 1003 (“DRP”), 5:22-23, 6:43-7:1, 7:20-31,
`
`7:37, 8:11-13, 9:22-32), (b) store data received over the network from the server
`
`into its disk-based cache (id., 5:30-33, 7:2-8), (c) calculate MD5 digests on that
`
`same data it receives and stores in cache (id., 3:24-27, 7:42-45, 8:36-37, 11:5-6),
`
`2
`
`
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`and (d) compare MD5 digests (id., 5:30-33, 7:2-8, 7:42-45, 11:5-6). (See also Ex.
`
`1024 (“Konchitsky TR”1), 91:18-21, 98:5-9, 108:11-109:18). DRP’s server em-
`
`bodies the claim’s “sender.” A DRP server is programmed to (a) calculate MD5
`
`digests on files it stores in its file-system file cache (DRP, 3:24-27, 5:26-28, 8:25-
`
`27, 9:30-31, 10:45-11:2) and (b) transmit MD5 digests of requested data in re-
`
`sponse to the client’s request for data (id., 5:22-23, 7:33-34, 7:37-39, 8:29-31,
`
`9:22-32). (See also Konchitsky TR 93:14-94:7, 106:12-15). The data includes
`
`files and thus a range of octets in a file. (DRP, 2:31-32, 2:44-3:2, 3:13-15, 3:28-
`
`31).
`
`Anticipated by Yohe: The three changes to the claim do not overcome
`
`Yohe’s anticipation of claim 1. (See IPR2012-00026, Ex. 1001, entries for claim
`
`1). (Change 1:) As part of Yohe’s “file system primitives” (IPR2012-00026, Ex.
`
`1005 (“Yohe”), 3:8-12) and “program operations” (id., 4:13-23), Yohe’s client is
`
`programmed to perform the method of Fig. 15. The client is configured to initiate
`
`a request for data from the server, beginning with its directory verify request (id.,
`
`Fig. 15 (720)) to the server. (Change 2:) The server is configured to respond to
`
`this request from the client with an MD5 or CRC signature of the requested direc-
`
`tory (id., Fig. 15 (721)). (Change 3:) As Dr. Konchitsky testified, Yohe’s “directo-
`
`
`1 Dr. Konchitsky is Patent Owner’s retained agent but not an expert in this field.
`
`3
`
`
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`ry” includes one or more “files” as its sub-objects (id., 13:53-57) and thus includes
`
`a plurality of ranges of octets (bytes) in one or more files, which is “data.” (Id.,
`
`16:6-7, 11-12). (Konchitsky TR 119:9-121:19).
`
`II. CLAIM 36
`
`Some Changes from Claim 3: (1) Changes requirement that sender and re-
`
`ceiver be “communicating” to their being “configured to communicate.” (2) Re-
`
`places “means for storing said created digest” in its first or permanent memory
`
`with “means for storing at least one of the digital digests created by the send-
`
`er/computer in its permanent storage memory.” (3) Adds that data includes at least
`
`a range of octets in a file.
`
`Enlarged: Change (1) enlarges the claim. Unlike claim 3, claim 36 newly
`
`covers systems in which the server and receiver are not “communicating.” Change
`
`(2) enlarges the claim. Although claim 3’s “said created digest” is ambiguous, it
`
`might refer to a digest created at the receiver—in which case claim 36 would new-
`
`ly cover systems not covered by claim 3.
`
`Non-responsive: Changes (1) and (2) improperly seek to correct indefinite-
`
`ness defects that Microsoft raised in parallel litigation, not overcome an unpatenta-
`
`bility ground asserted in this trial. “Communicating” renders claim 3 indefinite as
`
`it is an improper method step in a non-method claim. Also, the antecedent for
`
`“said” created digest in claim 3 is unclear.
`
`4
`
`
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`Anticipated by DRP: See discussion of Claim 35. The DRP client (receiv-
`
`er) compares MD5 digests it had calculated to MD5 digests the server had calcu-
`
`lated (DRP, 7:42-45, 8:36-37, 11:5-6) and also receives and stores in its disk cache
`
`MD5 digests the server had calculated (id., 5:30-33, 7:2-8). (See also Konchitsky
`
`TR 91:18-92:6, 98:5-11, 108:11-109:18).
`
`Anticipated by Yohe: The changes to the claim do not overcome Yohe’s an-
`
`ticipation of claim 3. (See IPR2012-00026, Ex. 1001, entries for claim 3).
`
`(Change 1:) Yohe’s client and server are configured to communicate with each
`
`other. (E.g., Yohe, Fig. 15, 4:13-22). (Change 2:) Yohe’s client is programmed to
`
`store “the [e.g., MD5] signature obtained [from the server] into cache via LFS 28
`
`[the client’s local file system]” (e.g., id., Fig. 15 (728), 8:19-21). This Yohe client
`
`“cache” (aka “network file cache” (id., 6:14-15)) “resides in permanent storage”
`
`(id., 3:16-18; see id., 4:35-36, 15:32-33 (“cache memory is disposed on a perma-
`
`nent storage disk of said remote client computer”)). (Change 3:) Yohe’s “directo-
`
`ry” includes one or more “files” as its sub-objects (id., 13:53-57) and thus includes
`
`a plurality of ranges of octets in one or more files. (Konchitsky TR 119:9-120:15).
`
`III. CLAIM 37
`
`Some Changes from Claim 6: Adds that the data “includes a plurality of oc-
`
`tet ranges in a file or files.”
`
`5
`
`
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`New Matter: This new claim limitation is new matter. The specification
`
`mentions “range of octets in a file,” and “RAM-based range of octets,” and other
`
`examples of “data” (’717, 2:5-8), but not a digital digest of plural different ranges
`
`of octets from plural different files. Nothing in the specification shows the appli-
`
`cant had “possession” of this claimed subject matter.
`
`Anticipated by DRP: The change to the claim does not overcome DRP’s an-
`
`ticipation of claim 6. (See IPR2013-00109, Ex. 1001, entries for claim 6). The da-
`
`ta processed in DRP includes plural files and thus includes a plurality of ranges of
`
`octets in plural files. (DRP, 2:31-32, 2:44-3:2, 3:14-16, 3:28-31). The “data that is
`
`distributed . . . can consist of any kind of code or content.” (Id., 2:31-32).
`
`Anticipated by Yohe: The change to the claim does not overcome Yohe’s
`
`anticipation of claim 6. (See IPR2013-00109, Ex. 1001, entries for claim 6).
`
`Yohe’s “directory” includes one or more “files” as its sub-objects (Yohe, 13:53-
`
`57) and thus includes a plurality of ranges of octets in one or more files. (See also
`
`Konchitsky TR 119:9-120:15).
`
`IV. CLAIM 38
`
`Some Changes from Claim 10: (1) Changes the function of the “means for
`
`storing” from “storing a digital digest received from said network” to “storing at
`
`least one of said digital digest [sic] received from said network.” (2) Replaces
`
`“means for comparison between digital digests” with “configured to search for a
`
`6
`
`
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`digital digest received from the sender/computer, in response to receiving the digi-
`
`tal digest.” (3) Adds that data includes a range of octets in a file.
`
`Enlarged: Change (2) (omitting “means for comparison between digital di-
`
`gests”) enlarges the claim. By eliminating “means for,” the element’s scope may
`
`no longer be restricted by 35 U.S.C. § 112(f). The proposed claim may no longer
`
`require that the receiver include a “means for comparison between digital digests.”
`
`For example, the receiver might check for a given digest by comparing hashes (or
`
`other identifiers) of digital digests not the digital digests themselves.
`
`New Matter: Change (2) is new matter. The patent does not disclose a re-
`
`ceiver configured to “search for a digital digest received from the sender/computer,
`
`in response to receiving the digital digest.” The patent instead says that the receiv-
`
`er “searches for data with the same digest.” (’717, 4:7-8, 4:18-19, 7:55-57).
`
`Indefinite: Change (1) renders the claim indefinite. There is no antecedent
`
`for “said digital digest received from said network.” This is not a method claim.
`
`There is no prior step recited in this claim of the receiver receiving a digital digest
`
`from the network.
`
`Non-responsive: Change (2) is not responsive to a ground for unpantability
`
`asserted here. Claim 10’s “means for comparison” has no linked structural coun-
`
`terpart in the patent and thus renders claim 10 indefinite. Omitting this defective
`
`element to attempt to avoid that indefiniteness, is an improper use of this trial.
`
`7
`
`
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`Anticipated by DRP: See discussion of claims 35-36. Before something can
`
`be compared, it must be found. In DRP, in response to receiving a digital digest
`
`over the network (e.g., in a newly received index file), the client searches its disk
`
`cache for that same digital digest value (e.g., previously received in an index file
`
`from the server). (DRP, 5:30-33, 7:2-8).
`
`The claim term “search” here requires no more than this. (Konchitsky TR
`
`43:14-45:4, 47:9- 49:7). The ’717 patent does not disclose a particular search algo-
`
`rithm beyond comparing a single pair of digest values. (Id., 41:23-43:7, 54:4-12,
`
`67:7-12). In Fig. 5, it equates the “search” (’717, 7:56) with “check for digest in
`
`cache.” As Dr. Konchitsky testified, this search may require no more than having
`
`one digest value in RAM (copied from cache) and comparing it to another digest
`
`value (received over the network) to check for a match. (Konchitsky TR 41:23-
`
`43:7, 54:4-12, 67:7-12). The patent does not disclose checking multiple digest
`
`values for a match. On the contrary, the problem the patent addresses is that a par-
`
`ticular locally stored file (or data object) may or may not have been changed at its
`
`remote source. (’717, 1:18-55). Thus, when the receiver checks for a matching
`
`data digest in the ’717 patent, it already has that data’s file name. Therefore, it
`
`need only find that file’s digest and check only that single digest for that single
`
`file. The ’717 patent does not disclose the same content having multiple file
`
`8
`
`
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`names, nor comparing to a digest value for one file to multiple digest values of
`
`multiple files.
`
`Anticipated by Yohe: The changes to the claim do not overcome Yohe’s an-
`
`ticipation of claim 10. (See IPR2013-00109, Ex. 1001, entries for claim 10). See
`
`discussion of claim 36 (re (Change 1:) means for storing and (Change 3:) range of
`
`octets). (Change 2:) In response to receiving an MD5 signature from the server,
`
`each Yohe receiver searches for data from its cache that has the same signature as
`
`that received from the sender, using a “directory signature comparator (DSC) 46”
`
`(Yohe, 5:1-3) “for comparing the signatures of data with one another to determine
`
`whether the signature of data of the remote client is valid” (id., 2:41-61), i.e., to
`
`“determine[] whether the signature of data match” (id., 13:34-35). (See id., 8:9-11,
`
`8:13-21, 14:40-15:3, Abstract, Fig. 15 (719), claims 1, 8). Again, the ’717 patent
`
`requires no more than this type of search.
`
`V. CLAIM 39
`
`Some Changes from Claim 11: Adds a new step (between claim 11’s steps
`
`of creating and transmitting a digital digest on data) of the sender (1) receiving
`
`from the receiver “a request for said data.” Also, (2) limits claim 11’s “transmit-
`
`ting” step to being in response to that request for data.
`
`New Matter: The combination of changes (1) and (2) is new matter. The
`
`patent does not disclose the sender creating a digest on data followed by the sender
`
`9
`
`
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`receiving a request for said data. This claim purportedly relates to Figs. 5-7. The
`
`patent says that the “transaction” of Figs. 5-7 “begins” with the receiver “sending a
`
`request to the sender” (’717, 7:65-67) but does not say a request for what. (See al-
`
`so id., 8:38-39). It does not say a request for particular data. (Konchitsky TR
`
`36:11-16, 39:6-17). And, although the patent says that digest values may be stored
`
`in the sender’s memory (’717, 8:5-7), it does not say that the sender created that
`
`digest on requested data before it is requested. If anything, by saying that the
`
`“transaction begins with” the request (id., 7:65-67), and by including sender calcu-
`
`lation of the digest as part of the “transaction” (id., 7:52-53), the patent may imply
`
`the opposite.
`
`Anticipated by DRP: The changes to the claim do not overcome DRP’s an-
`
`ticipation of claim 11. (See IPR2013-00109, Ex. 1001, entries for claim 11). The
`
`DRP server creates MD5 digests on the content (including files) on its site. (DRP,
`
`11:1-2). It necessarily performs this step before sending an index with those di-
`
`gests to the client and thus before the client first downloads particular data. Once a
`
`client has initially downloaded files from the server, “a client can update the con-
`
`tent” (id., 5:30-31) in a two-part data-request operation. The first part is sending a
`
`GET request or differential GET request for that content’s current associated index
`
`file. (Id., 5:22-23, 9:22-32). The server responds to an index GET request with an
`
`index file including the current digest for the request content. (Id., 5:22-32). After
`
`10
`
`
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`checking its cache for that digest, the client responds with a GET request (negative
`
`indication signal), or differential GET request (partial indication signal), or (when
`
`there is “no change since the last request” (id., 9:24)), no request for the corre-
`
`sponding data (positive indication signal). (Id., 6:43-7:1, 7:20-31, 7:37-38, 8:8-13,
`
`9:22-25, 9:26-28). If the server receives a negative indication, it responds with the
`
`requested content. (DRP, 7:30-34).
`
`VI. CLAIM 40
`
`Some Changes from Claim 22: (1) Adds a new step before the method of
`
`claim 22, namely the receiver “sending a request for data.” (2) Restricts the digital
`
`digest received from the network to be “for the requested data” (this change was
`
`not underlined). (3) Replaces the object of the “searching” step from “data with
`
`the same digital digest” to “each received digital digest.” (4) Changes the condi-
`
`tion for forming a negative indication from uncovering “data having the same digi-
`
`tal digest” to uncovering “the same digital digest” as the digital digest received.
`
`(5) Replaces creating a digest for data received “from said network cache memory”
`
`to data received “from the sender/computer and stored in” the network cache
`
`memory.
`
`Enlarged: Changes (3) and (4) enlarge the claim. Claim 40 newly covers
`
`methods that look only for matching digests but not for data having those digests.
`
`Claim 22 does not cover such a method.
`
`11
`
`
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`New Matter: Changes (1) and (2) are new matter. Proxyconn cites ’717,
`
`7:65-67 and 8:37-39 but neither says a request “for data.” (The discussion of Fig.
`
`15 does say “request[s] for data” (’717, 5:5, 9:66, 10:12-13), but the Fig. 15 em-
`
`bodiment does not support this claim). Changes (3) and (4) are new matter. Ra-
`
`ther than support searching “for each received digital digest,” the specification in-
`
`stead repeatedly says that the receiver “searches” “for data with the same digest.”
`
`(Id., 4:7-8, 4:18-19, 7:55-57). The patent likewise fails to disclose searching for
`
`digests in the receiver’s network cache memory, and a step (as distinct from the
`
`capability) of storing digests in the receiver’s network cache. Change (5) is new
`
`matter. Although the patent says that the receiver can calculate digests on data in
`
`its cache and says that it can store in its cache data received from the server, the
`
`patent does not disclose the step of the receiver creating a digital digest on data re-
`
`ceived from the sender, particularly not in combination with the other steps of this
`
`method.
`
`Anticipated by DRP: See discussion of claims 35, 38 and 39. When the
`
`DRP client receives from the DRP sender the index file for the client-requested da-
`
`ta, the client searches its cache for the same content identifier included in that in-
`
`dex file for that data. (DRP, 5:30-33, 7:2-8). (Konchitsky TR 106:12-15). The
`
`client also calculates MD5 digests on the data it receives from the sender and
`
`12
`
`
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`stores in its cache (DRP, 3:24-27, 7:42-45, 8:36-37, 11:5-6). (Konchitsky TR
`
`93:14- 94:7).
`
`Anticipated by Yohe: The changes to the claim do not overcome Yohe’s an-
`
`ticipation of claim 22. (See IPR201200026, Ex. 1001, entries for claim 22).
`
`(Changes 1 and 2:) Yohe’s client requests a particular directory and receives an
`
`MD5 signature of that directory from the server in response. (Yohe, Fig. 15 (720,
`
`721, 724-27)). (Change 3:) See discussion of claim 38. (Change 4:) If Yohe’s re-
`
`ceiver does not find a matching digest, it requests the directory from the server.
`
`(Id., Fig. 15 (722, 724)). (Change 5:) Yohe’s client stores in its disk cache data re-
`
`trieved from the server (e.g., id., Fig. 6 (308)) and when that data is next requested,
`
`invokes its “BSG [block signature generator] 44 to generate a signature of [that]
`
`data.” (Id., 6:8-23, Fig. 6 (316), claim 8).
`
`VII. CLAIM 41
`
`Some Changes from Claim 23 (in addition to claim 40’s changes to claim
`
`22): (1) Eliminates the second searching step in claim 23 (following “further com-
`
`prising”) and substitutes for it a further limitation of the independent claim’s
`
`searching step. (2) Changes “substantially identical” to “identical.”
`
`Enlarged: Change (1) enlarges the claim. See discussion of claim 40.
`
`Claim 23 required two different searching steps (one for data with the same digest
`
`(as received from the network) in the network cache memory, the other more
`
`13
`
`
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`broadly for data with a digest substantially identical to the received digest in per-
`
`manent storage). Proposed claim 41 more broadly covers a method with only one
`
`searching step, and does not require searching for a substantially identical digest.
`
`New Matter: Change (1) is new matter. See discussion of claim 40. There
`
`is no disclosure in the patent of searching “in network cache memory” (claim 40)
`
`“wherein [such] searching . . . includes searching in predetermined locations in
`
`said permanent storage memory.” “Predetermined locations in permanent storage
`
`memory” is broader than network cache memory, and thus includes searching out-
`
`side network cache memory. (See ’717, 8:50-53).
`
`Non-responsive: Changes (1) and (2) do not respond to a ground of un-
`
`patentability asserted here. Eliminating “substantially” attempts to remedy a Sec.
`
`112(a), (b) defect noted by Microsoft in the litigation: there is no such thing as two
`
`MD5 digests being “substantially identical.” Eliminating the second searching step
`
`also attempts to remedy a disconnect between claim 23 and the patent’s disclosure.
`
`Anticipated by DRP: See discussion of claim 40. The DRP client searches
`
`in the previous version of the index file and elsewhere in its disk cache “accessed
`
`using content identifiers” to find the identical file (even if previously sent from a
`
`different host). (DRP, 5:30-33, 7:2-8). (Konchitsky TR 106:12-15).
`
`Anticipated by Yohe: The changes to the claim do not overcome Yohe’s an-
`
`ticipation of claim 23. (See IPR2012-00026, Ex. 1001, entries for claim 23). See
`
`14
`
`
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`discussion of claim 40. Yohe’s client looks in its cache at the location(s) storing
`
`the digital digest associated with the particular directory it seeks to verify, “‘re-
`
`trieves’ 719 signature associated with this directory request from cache” and then
`
`compares that digest to the one received from the sender (Yohe, 8:5-11).
`
`VIII. PROXYCONN FAILS TO MEET ITS BURDEN
`
`Proxyconn fails to identify the closest prior art known to it, or show patenta-
`
`bility of any proposed claim over that prior art, or even argue patentability of
`
`claims 35, 36, 38, 40, or 41 over DRP. It submits no expert declaration or other
`
`evidence showing either the significance of the added features to a skilled artisan,
`
`or any objective indicia of non-obviousness. Thus, it has not even come close to
`
`meeting its burden on this motion to amend. See 37 C.F.R. § 42.20(c); Idle Free
`
`Systems Inc. v. Bergstrom Inc., IPR2012-00027, Paper 26 (USPTO PTAB June 11,
`
`2013).
`
`Dated: August 21, 2013
`
`
`
`Respectfully submitted,
`
`
`
`
`
`
`
`/John D. Vandenberg/
`John D. Vandenberg
`Registration No. 31,312
`Stephen J. Joncus
`Registration No. 44,809
`Klarquist Sparkman, LLP
`One World Trade Center, Suite 1600
`121 S.W. Salmon Street
`Portland, Oregon 97204
`Telephone: (503) 595-5300
`Facsimile: (503) 595-5301
`
`15
`
`
`
`Case IPR2012-00026; IPR2013-00109
`Patent 6,757,717
`
`
`Certificate of Service in Compliance With 37 C.F.R. § 42.6(e)(4)
`
`The undersigned certifies that a complete copy of Microsoft Corporation’s
`
`Opposition to Patent Owner’s Corrected Motion to Amend Under 37 C.F.R. §
`
`42.121 was served on the attorneys of record for Patent Owner in this proceeding:
`
`
`
`MATTHEW L. CUTLER
`BRYAN K. WHEELOCK
`DOUGLAS A. ROBINSON
`HARNESS, DICKEY & PIERCE, PLC
`7700 BONHOMME, SUITE 400
`ST. LOUIS, MO 63105
`
`
`via EXPRESS MAIL, on August 21, 2013
`
`
`
`
`
`
`
`By /John D. Vandenberg/
`John D. Vandenberg
`Reg. No. 31,312
`One World Trade Center, Suite 1600
`121 S.W. Salmon Street
`Portland, Oregon 97204
`Telephone: (503) 595-5300
`Facsimile: (503) 595-5301
`
`CERTIFICATE OF SERVICE
`
`
`
`Page 1
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
