www.uspto.gov
`
`UNITED STATES DEPARTMENT OF COMMERCE
`United States Patent and TrademarkOffice
`Address; COMMISSIONER FOR PATENTS
`P.O. Box 1450
`Alexandria, Virginia 22313-1450
`
`90/014,876
`
`10/05/2021
`
`10484510
`
`HOLA-005-US10-EPR
`
`2574
`
`MayPatents Ltd. c/o Dorit Shem-Tov
`P oO B 7230
`Ramat-Gan, 5217102
`ISRAEL
`
`WOOD, WILLIAM H
`
`3992
`
`03/23/2022
`
`PAPER
`
`Please find below and/or attached an Office communication concerning this application or proceeding.
`
`The time period for reply, if any, is set in the attached communication.
`
`PTOL-90A (Rev. 04/07)
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 1 of 25
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 1 of 25
`
`

`

`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`Commissionerfor Patents
`United States Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`www.uspto.gov
`
`DO NOT USE IN PALM PRINTER
`
`(THIRD PARTY REQUESTER'S CORRESPONDENCE ADDRESS)
`
`
`
`Charhon Callahan Robson & Garza, PLLC
`3333 Lee Parkway, Suite 460
`Dallas, TX 75219
`
`EX PARTE REEXAMINATION COMMUNICATION TRANSMITTAL FORM
`
`REEXAMINATION CONTROL NO. 90/014,876 .
`
`PATENT UNDER REEXAMINATION 10484570 .
`
`ART UNIT 3992.
`
`Enclosed is a copy of the latest communication from the United States Patent and Trademark
`Office in the aboveidentified exparte reexamination proceeding (87 CFR 1.550(f)).
`
`Wherethis copy is supplied after the reply by requester, 37 CFR 1.535, or the timefor filing a
`reply has passed, no submission on behalf of the evparfe reexamination requester will be
`acknowledged or considered (37 CFR 1.550(g)).
`
`PTOL-465 (Rev.07-04)
`
`i
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 2 of 25
`
`i
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 2 of 25
`
`

`

`10. [) Other: cc: Requester (if third
`
`SUMMARY OF ACTION
`
`Claims 1-2,6-11,13 and 15-24 are subject to reexamination.
`
`Claims 3-5,12 and 14 are not subject to reexamination.
`
`Claims ___ have been canceledin the present reexamination proceeding.
`
`OOSNO8D088 Acknowledgment is made ofthe priority claim under 35 U.S.C. 119(a)-(d) or (f).
`
`Office Action in Ex Parte Reexamination
`
`Control No.
`90/014,876
`
`Patent Under Reexamination
`10484510
`
`Examiner
`WILLIAM H WOOD
`
`Art Unit
`3992
`
`AIA (FITF) Status
`No
`
`-- The MAILING DATEof this communication appears on the cover sheet with the correspondence address --
`
`a. L) Responsiveto the communication(s)filed on
`( A declaration(s)affidavit(s) under 37 CFR 1.130(b) was/werefiled on
`
`.
`
`b. (J This action is made FINAL.
`
`Cc.
`
`A statement under 37 CFR 1.530 has not been received from the patent owner.
`
`A shortenedstatutory period for responseto this action is set to expire 2 month(s) from the mailing date ofthis letter.
`Failure to respond within the period for response will result in termination of the proceeding and issuanceof an eygarfe reexamination
`certificate in accordance with this action. 37 CFR 1.550(d). EXTENSIONS OF TIME ARE GOVERNED BY 37 CFR 1.550(c).
`If the period for response specified aboveis less than thirty (30) days, a response within the statutory minimum ofthirty (30) days
`will be consideredtimely.
`
`THE FOLLOWING ATTACHMENT(S) ARE PART OF THIS ACTION:
`Part!
`Interview Summary, PTO-474.
`1. (J Notice of References Cited by Examiner, PTO-892.
`3.{1
`2.
`Information Disclosure Statement, PTO/SB/08.
`40.
`
`Part Il
`
`ta.
`
`1b.
`
`2.
`
`Claims __ are patentable and/or confirmed.
`
`Claims 1-2,6-11,13 and 15-24 are rejected.
`
`Claims _ are objectedto.
`
`The drawings, filed on 05 October 2021 are acceptable.
`The proposed drawing correction, filedon___—_—shass been (7a)
`
`( approved (7b)
`
`() disapproved.
`
`a) CJ All
`
`b)
`
`() Some* c)
`
`(CJNone
`
`of the certified copies have
`
`1 ©) been received.
`
`2 ( not been received.
`
`3 ( been filed in Application No.
`
`4 (] been filed in reexamination Control No.
`
`5 (] been received by the International Bureau in PCT application No.
`
`* See the attached detailed Office action for a list of the certified copies not received.
`
`9.
`
`(J Since the proceeding appears to be in condition for issuance of an exparte reexamination certificate except for formal
`matters, prosecution as to the merits is closed in accordancewith the practice under Exparfe Quayle, 1935 C.D.
`11, 453 O.G. 213.
`
`U.S. Patent and Trademark Office
`PTOL-466 (Rev. 08-13)
`
`Office Action in Ex Parte Reexamination
`
`PartofPaperNo.
`
`20220314
`
`Page 1
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 3 of 25
`
`Page 1
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 3 of 25
`
`

`

`Application/Control Number: 90/014,876
`Art Unit: 3992
`
`Page 2
`
`The present application is being examined under the pre-AlA first to invent provisions.
`
`DECISION ON REQUEST FOR REEXAMINATION
`
`Reexamination (Fx Parte) has been requested bya third party for claims 1, 2, 6, 7, 8, 9, 10, 11,
`
`13, 15, 16, 17, 18, 19, 20, 21, 22, 23, and 24 of US 10,484,510 B2 to Shribman et al. which issued on
`
`11/19/2019 and was filed on 02/17/2019 (herein Shribman or ‘510 patent). A Request for Ex Parte
`
`Reexamination (herein Request) was received on 10/05/2021.
`
`A substantial new question of patentability affecting claims 1, 2, 6, 7, 8, 9, 10, 11, 13, 15, 16, 17,
`
`18, 19, 20, 21, 22, 23, and 24 of US 10,484,510 B2 to Shribmanis raised by the request for Ex Parte
`
`reexamination filed 10/05/2021. As such the filed request for reexamination is granted.
`
`Information Disclosure Statement
`
`The 14 information disclosure statements (IDS) submitted on 12/20/2021 and the IDS submitted
`
`on 02/14/2022 are considered by the examiner in accordance with 37 CFR 1.97, 37 CFR 1.98, MPEP 609,
`
`and MPEP 1406,to the fullest extent of the items presented including any concise explanation.
`
`Documents not meeting a particular criteria are lined through and not considered.
`
`The submitted English translation of CN 110071980 was blank.
`
`Claim Rejections - 35 USC § 102
`
`In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102
`
`and 103 (or as subject to pre-AlA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory
`
`basis for the rejection will not be considered a new ground ofrejection if the prior art relied upon, and
`
`the rationale supporting the rejection, would be the same under either status.
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 4 of 25
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 4 of 25
`
`

`

`Application/Control Number: 90/014,876
`Art Unit: 3992
`
`Page 3
`
`The following is a quotation of the appropriate paragraphs of pre-AlA 35 U.S.C. 102 that form
`
`the basis for the rejections under this section made in this Office action:
`
`A person shall be entitled to a patent unless —
`
`(b) the invention was patented or described in a printed publication in this or a foreign countryor in
`public use or on sale in this country, more than one year prior to the date of application for patent in
`the United States.
`
`Claim(s) 1, 6-8, 10, and 15-24 is/are rejected under pre-AlA 35 U.S.C. 102(b) as being anticipated
`
`by US 6,795,848 B1 (herein Border).
`
`Consistent with the Request for Reexamination of 10/05/2021, the claim languageis viewed
`
`using the broadest reasonable interpretation. In the case of a “client device”, the broadest reasonable
`
`interpretation is a device that acts, at least at some point, as a client. And in the case of a “server”, the
`
`broadest reasonable interpretation is a device that acts, at least at some point, as a server.
`
`A methodfor use with a web
`
`Border shows “a web server” (Border: figure 1, element 109), “first
`
`server that responds to
`
`content” (Border: column 3, lines 34-46, at least “web content”
`
`Hypertext Transfer Protocol
`
`and/or “URL content”), “a first content identifier” (Border: at least
`
`(HTTP) requests and stores a
`
`requested “URL”), and “a first client device” (Border: figure 1,
`
`comprising:
`
`first content identified by a
`
`element 107, “upstream server”).
`
`first content identifier, the
`
`method byafirst client device
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 5 of 25
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 5 of 25
`
`

`

`Application/Control Number: 90/014,876
`Art Unit: 3992
`
`
`Page 4
`
`FAQ. t
`
`
`
`(Border: figure 1)
`
`“The present invention provides a communication system for
`
`retrieving web content. A downstream proxyserver receives a URL
`
`request message from a web browser, in which the URL request
`
`messagespecifies a URL content that has an embedded object. An
`
`upstream proxy server receives the URL request message from the
`
`downstream proxy server. The upstream proxy server selectively
`
`forwards the URL request message to a web server and receives the
`
`URL contentfrom the web server. The upstream proxy server
`
`forwards the URL content to the downstream proxy server and
`
`parses the URL content to obtain the embeddedobject prior to
`
`receiving a corresponding embedded object request message
`
`initiated by the web browser.” (Border: column 3, lines 34-46,
`
`showing webserverstoring content, identified by a content
`
`identifier)
`
`“HTTP proxy server 105 and 107 acts as an intermediary between
`
`one or more browsers and many web servers(e.g., server 109). A
`
`web browser 103 requests a URL from the proxy server(e.g., 105)
`
`which in turn "gets" the URL from the addressed web server 109.
`
`An HTTPproxy 105 itself may be configured to either access URLs
`
`directly from a web server 109 or from another HTTP proxy server
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 6 of 25
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 6 of 25
`
`

`

`Application/Control Number: 90/014,876
`Art Unit: 3992
`
`
`Page 5
`
`107.” (Border: column4, lines 30-36, showing web server 109, and
`
`proxy servers 105 and 107 respond to HTTP requests)
`
`(see also Border: figure 2; column 2, lines 6-30; column 10, lines 6-
`
`24; and figure 7)
`
`establishing a Transmission
`
`Border shows “a second server” (Border: figure 1, element 105,
`
`Control Protocol (TCP)
`
`“downstream server”).
`
`connection with a second
`
`server;
`
`TCP connection to be reused for multiple requests of the embedded
`
`(Border: figure 2, showing “browser 103” sending a request to
`
`“downstream server 105” which then sends a request to “upstream
`
`server 107” which then sends a request to “web server 109”, and
`
`the content is then returned back through the same path; element
`
`105 is a server to browser/computer 103/101; and element 107is a
`
`client to web server 109)
`
`“Proxy servers 105 and 107, according to an embodimentof the
`
`present invention, are Hypertext Transfer Protocol (HTTP) proxy
`
`servers with HTTP caches 115 and 117, respectively. These servers
`
`105 and 107 communicate using persistent connections (whichis a
`
`feature of HTTP 1.1). Use of persistent connections enables a single
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page7 of 25
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 7 of 25
`
`

`

`Application/Control Number: 90/014,876
`Art Unit: 3992
`
`
`Page 6
`
`objects within a web pageassociated with web server 109. Further,
`
`TCP Transaction Multiplexing Protocol (TTMP) may beutilized.
`
`TTMP and persistent-TCP are morefully described with respect to
`
`FIG. 3.” (Border: column 4, lines 8-18, showing TCP connection)
`
`
`
`(Border: figure 1, note TCP connection between element 107,
`
`mappedto the claimed “first client device” and element 105,
`
`mappedto the claimed “second server”)
`
`sending, to the web server
`
`(Border: figure 2, showing “browser 103” sending a request to
`
`overan Internet, the first
`
`“downstream server 105” which then sends a request to “upstream
`
`contentidentifier;
`
`server 107” which then sends a request to “web server 109”, and
`
`the content is then returned back through the same path; element
`
`105 is a server to browser/computer 103/101; and element 107is a
`
`client to web server 109)
`
`client to web server 109)
`
`receiving, the first content
`
`(Border: figure 2, showing “browser 103” sending a request to
`
`from the web server over the
`
`“downstream server 105” which then sends a request to “upstream
`
`Internet in response to the
`
`server 107” which then sends a request to “web server 109”, and
`
`sending ofthe first content
`
`the content is then returned back through the same path; element
`
`identifier; and
`
`105 is a server to browser/computer 103/101; and element 107is a
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 8 of 25
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 8 of 25
`
`

`

`Page 7
`
`sending the receivedfirst
`
`(Border: figure 2, showing “browser 103” sending a request to
`
`content, to the second server
`
`“downstream server 105” which then sends a request to “upstream
`
`over the established TCP
`
`server 107” which then sends a request to “web server 109”, and
`
`connection, in responseto the
`
`the content is then returned back through the same path; element
`
`receiving of the first content
`
`105 is a server to browser/computer 103/101; and element 107is a
`
`Application/Control Number: 90/014,876
`Art Unit: 3992
`
`
`“third server that comprises a web server”)
`
`identifier.
`
`client to web server 109)
`
`The method according to claim
`
`“HTTP proxy server 105 and 107 acts as an intermediary between
`
`1, for use with a third server
`
`one or more browsers and many web servers(e.g., server 109).”
`
`that comprises a web server
`
`(Border: column 4, lines 30-32, many web servers showsat least a
`
`that is Hypertext Transfer
`
`Protocol (HTTP) server, the
`
`third server responds to HTTP
`
`requests and stores a second
`
`content identified by a second
`
`content identifier, the method
`
`by the first client device further
`
`comprising: receiving the
`
`second content identifier;
`
`sending,to the third server
`
`overthe Internet in response
`
`to the receiving, the second
`
`content identifier; and
`
`receiving the second content
`
`from the third server over the
`
`Internet in response to the
`
`sending.
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 9 of 25
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 9 of 25
`
`

`

`Application/Control Number: 90/014,876
`Art Unit: 3992
`
`
`Page 8
`
`The method according to claim|To the extent HTTPis an application enabling web browser
`
`6, further comprising
`
`functionality, under the broadest reasonable interpretation, Border
`
`executing, by thefirst client
`
`showsthe server 107, mapped to the claim as the client device,
`
`device, a web browser
`
`executing a web browser application.
`
`application or an email
`
`application.
`
`“FIG. 3 shows a block diagram of the protocols utilized in the
`
`system of FIG. 1. The servers 105, 107, and 109 and PC 101 employ,
`
`according to one embodimentof the present invention, a layered
`
`protocol stack 300. The protocol stack 300 includes a network
`
`interface layer 301, an Internet layer 303, a transport layer 305, and
`
`an application layer 307.” (Border: column 7, lines 20-25)
`
`“HTTPis an application level protocol that is employed for
`
`information transfer over the Web. RFC (Request for Comment)
`
`2616 specifies this protocol and is incorporated herein in its
`
`entirety. In addition, a more detailed definition of URL can be found
`
`in RFC 1737, whichis incorporated herein in its entirety.” (Border:
`
`column 7, lines 26-31)
`
`The method according to claim|(Border: figure 1, element “P-TCP”)
`
`1, further comprising
`
`periodically communicating
`
`over the TCP connection
`
`between the second server and
`
`the first client device.
`
`determining, by thefirst client
`
`The method according to claim|Border shows an upstream server mapped to the claimed “client
`
`1, further comprising
`
`device” whether the contentis stale or “not valid”.
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 10 of 25
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 10 of 25
`
`

`

`Application/Control Number: 90/014,876
`Art Unit: 3992
`
`
`Page 9
`
`device, that the received first
`
`“The HTTP protocol also supports a GET IF MODIFIED SINCE request
`
`content,is valid.
`
`wherein a web server (or a proxy server) either responds with a
`
`status code indicating that the URL has not changed or with the URL
`
`contentif the URL has changedsince the requested date and time.
`
`This mechanism updates cache 115 of proxy server 105 only if the
`
`contents have changed, thereby saving unnecessary processing
`
`costs.” (Border: column 5, lines 25-30)
`
`“Next, in step 2, the web server 109 transmits the requested HTML
`
`page to the upstream server 117, which stores the received HTML
`
`page in cache 117.” (Border: column 5, lines 36-38)
`
`“To avoid stale information, the web browser 103 needs to
`
`determine whether the information stored at URL HTML has been
`
`updatedsince the time it was last requested. As a result, the
`
`browser 103 issues a GET HTML IF MODIFIED SINCE the last time
`
`HTML was obtained.” (Border: column 6, lines 55-60)
`
`“If not, the upstream proxy server 107 issues a GET HTML IF
`
`MODIFIED SINCE command to the web server 109. If URL HTML has
`
`not changed since Sep. 22, 2000 at 11:30 a.m., web server 109
`
`issues a NO CHANGE responseto the upstream proxy server 107.”
`
`(Border: column 7, lines 5-10)
`
`“However, in the event that the web browser 103 has requested
`
`this HTML in the past or the downstream server 401 has stored this
`
`HTML previously, the latest time stamp is passed to the upstream
`
`server as a conditional GET request (e.g., GET IF MODIFIED SINCE
`
`Sep. 22, 2000).” (Border: column 9, lines 10-16)
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 11 of 25
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 11 of 25
`
`

`

`Application/Control Number: 90/014,876
`Art Unit: 3992
`
`
`Page 10
`
`The method according to claim
`
`(Border: figure 2, showing “browser 103” sending a request to
`
`1, further comprising receiving,
`
`“downstream server 105” which then sends a request to “upstream
`
`by the first client device from
`
`server 107” which then sends a request to “web server 109”, and
`
`the second server over the
`
`the content is then returned back through the same path; element
`
`established TCP connection,
`
`105 is a server to browser/computer 103/101; and element 107is a
`
`the first content identifier.
`
`client to web server 109)
`
`The method according to claim
`
`(Border: figure 2, showing “browser 103” sending a request to
`
`1, wherein the sending of the
`
`“downstream server 105” which then sends a request to “upstream
`
`first content identifier to the
`
`server 107” which then sends a request to “web server 109”, and
`
`web server over the Internet
`
`the content is then returned back through the same path; element
`
`comprises sending a Hypertext
`
`105 is a server to browser/computer 103/101; and element 107is a
`
`Transfer Protocol (HTTP)
`
`client to web server 109)
`
`request that comprisesthe first
`
`content identifier.
`
`(see also Border: column5, line 13 — column 7, line 19)
`
`servers with HTTP caches 115 and 117, respectively. These servers
`
`The method according to claim
`
`(Border: figure 2, showing “browser 103” sending a request to
`
`1, further comprising storing,
`
`“downstream server 105” which then sends a request to “upstream
`
`by the first client device in
`
`server 107” which then sends a request to “web server 109”, and
`
`response to the receiving from
`
`the content is then returned back through the same path; element
`
`the web server,the first
`
`105 is a server to browser/computer 103/101; and element 107is a
`
`content.
`
`client to web server 109)
`
`(see also Border: column5, line 13 — column7, line 19)
`
`The method according to claim
`
`“Proxy servers 105 and 107, according to an embodimentof the
`
`1, wherein the second server is
`
`present invention, are Hypertext Transfer Protocol (HTTP) proxy
`
`a Transmission Control
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 12 of 25
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 12 of 25
`
`

`

`Application/Control Number: 90/014,876
`Art Unit: 3992
`
`
`Page 11
`
`Protocol/Internet Protocol
`
`105 and 107 communicate using persistent connections (whichis a
`
`(TCP/IP) server that
`
`feature of HTTP 1.1). Use of persistent connections enables a single
`
`communicates over the
`
`TCP connection to be reused for multiple requests of the embedded
`
`Internet based on, or according
`
`objects within a web pageassociated with web server 109. Further,
`
`to, using TCP/IP protocol or
`
`TCP Transaction Multiplexing Protocol (TTMP) may beutilized.
`
`connection, and wherein the
`
`TTMP and persistent-TCP are morefully described with respect to
`
`first client device is a
`
`Transmission Control
`
`FIG. 3.” (Border: column 4, lines 8-18, showing TCP connection)
`
`Protocol/Internet Protocol
`
`“According to one embodimentof the present invention, the proxy
`
`(TCP/IP) client that
`
`servers 105 and 107 may support multicast delivery. IP multicasting
`
`communicates with the second
`
`can be used to transmit information from upstream server 107 to
`
`server over the Internet based
`
`multiple downstream servers (of which only one downstream
`
`on, or according to, TCP/IP
`
`server 105 is shown).” (Border: column 4, lines 37-41)
`
`protocol.
`
`“The Internet layer 303 may be the Internet Protocol (IP) version 4
`
`or 6, for instance. The transport layer 305 may include the TCP
`
`(Transmission Control Protocol) and the UDP (User Datagram
`
`Protocol). According to one embodiment of the present invention,
`
`at the transport layer, persistent TCP connections are utilized in the
`
`system 100; in addition, TCP Transaction Multiplexing Protocol
`
`(TTMP) may be used.” (Border: column 7, lines 32-40)
`
`The method according to claim
`
`“Proxy servers 105 and 107, according to an embodimentof the
`
`1, wherein the first client
`
`present invention, are Hypertext Transfer Protocol (HTTP) proxy
`
`device communicates over the
`
`servers with HTTP caches 115 and 117, respectively. These servers
`
`TCP Transaction Multiplexing Protocol (TTMP) may beutilized.
`
`Internet based on, or according
`
`105 and 107 communicate using persistent connections (whichis a
`
`to, one out of UDP, DNS, TCP,
`
`feature of HTTP 1.1). Use of persistent connections enables a single
`
`FTP, POP#, SMTP, or SQL
`
`TCP connection to be reused for multiple requests of the embedded
`
`standards.
`
`objects within a web pageassociated with web server 109. Further,
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 13 of 25
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 13 of 25
`
`

`

`Application/Control Number: 90/014,876
`Art Unit: 3992
`
`
`Page 12
`
`TTMP and persistent-TCP are morefully described with respect to
`
`FIG. 3.” (Border: column 4, lines 8-18, showing TCP connection)
`
`“Alternatively, downstream proxyserver 105, for efficiency, may
`
`use the User Datagram Protocol (UDP) to transmit HTTP GET and
`
`GET IF MODIFIED SINCE requests to the upstream proxy server 107.
`
`This is done by placing the HTTP request headerinto the UDP
`
`payload. The use of UDP is very efficient as the overhead of
`
`establishing, maintaining and clearing TCP connectionsis not
`
`incurred. It is "best effort" in that there is no guarantee that the
`
`UDP packets will be delivered.” (Border: column 8, lines 38-46)
`
`The method according to claim
`
`“The present invention relates to a communication system, and is
`
`1, wherein the first content
`
`more particularly related to retrieving web content using proxy
`
`comprises web-page, audio, or
`
`servers.” (Border: column 1, lines 16-18)
`
`video content, and wherein the
`
`first content identifier
`
`“Web pages are formatted according to the Hypertext Markup
`
`comprises a Uniform Resource
`
`Language (HTML) standard which providesfor the display of high-
`
`Locator (URL).
`
`quality text (including control over the location, size, color and font
`
`for the text), the display of graphics within the page and the
`
`"linking" from one page to another, possibly stored onadifferent
`
`refers to the URL itself while the terms “web content", "URL
`
`web server. Each HTML document, graphic image, video clip or
`
`other individual piece of contentis identified, that is, addressed, by
`
`an Internet address, referred to as a Uniform Resource Locator
`
`(URL). As used herein, a "URL" may refer to an address of an
`
`individual piece of web content (HTML document, image, sound-
`
`clip, video-clip, etc.) or the individual piece of content addressed by
`
`the URL. Whenadistinction is required, the term "URL address"
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 14 of 25
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 14 of 25
`
`

`

`Application/Control Number: 90/014,876
`Art Unit: 3992
`
`
`Page 13
`
`content"or "URL object" refers to the content addressed by the
`
`URL.” (Border: column 1, line 57 — column2, line 5)
`
`The method according to claim
`
`To the extent HTTPis an application enabling web browser
`
`1, further comprising
`
`functionality, under the broadest reasonable interpretation, Border
`
`executing, by thefirst client
`
`showsthe server 107, mapped to the claim as the client device,
`
`device, a web browser
`
`executing a web browser application.
`
`application or an email
`
`application.
`
`“FIG. 3 shows a block diagram of the protocols utilized in the
`
`system of FIG. 1. The servers 105, 107, and 109 and PC 101 employ,
`
`according to one embodimentof the present invention, a layered
`
`protocol stack 300. The protocol stack 300 includes a network
`
`interface layer 301, an Internet layer 303, a transport layer 305, and
`
`an application layer 307.” (Border: column 7, lines 20-25)
`
`“HTTPis an application level protocol that is employed for
`
`information transfer over the Web. RFC (Request for Comment)
`
`2616 specifies this protocol and is incorporated herein in its
`
`entirety. In addition, a more detailed definition of URL can be found
`
`in RFC 1737, whichis incorporated herein in its entirety.” (Border:
`
`column 7, lines 26-31)
`
`“operating, or using, a client operating system”.
`
`operating under instructions (Border: column 10, line 6 — column 11,
`
`The method according to claim
`
`As Border’s server 107, mapped to the claimed client device,is
`
`1, further comprising storing,
`
`acting as a client (discussed above) and is a computer system
`
`operating, or using, a client
`
`operating system.
`
`line 23), Border shows the broadest reasonable interpretation of
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 15 of 25
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 15 of 25
`
`

`

`Application/Control Number: 90/014,876
`Art Unit: 3992
`
`
`Page 14
`
`The method according to claim|(Border: figure 2)
`
`1, wherein the steps are
`
`sequentially executed.
`
`(see also Border: column5, line 13 — column 7, line 19)
`
`A non-transitory computer
`
`“FIG. 7 is a diagram of a computer system that can be configured as
`
`readable medium containing
`
`a proxy server, in accordance with an embodimentof the present
`
`computer instructions that,
`
`invention.” (Border: column 10, lines 6-8)
`
`when executed by a computer
`
`according to claim 1.
`
`processor, cause the processor|(see also Border: figure 7; and column 7, line 9— column 12,line 3)
`
`to perform the method
`
`Claim Rejections - 35 USC § 103
`
`In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102
`
`and 103 (or as subject to pre-AlA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory
`
`basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and
`
`the rationale supporting the rejection, would be the same under eitherstatus.
`
`The following is a quotation of pre-AlA 35 U.S.C. 103(a) which forms the basis for all obviousness
`
`rejections set forth in this Office action:
`
`(a) A patent may not be obtained though the invention is not identically disclosed or described as set
`forth in section 102, if the differences between the subject matter sought to be patented and the
`prior art are such that the subject matter as a whole would have been obvious at the time the
`invention was made to a person having ordinaryskill in the art to which said subject matter pertains.
`Patentability shall not be negatived by the manner in which the invention was made.
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 16 of 25
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 16 of 25
`
`

`

`Application/Control Number: 90/014,876
`Art Unit: 3992
`
`Page 15
`
`Claims 9 and 11 is/are rejected under pre-AlA 35 U.S.C. 103(a) as being unpatentable over US
`
`6,795,848 B1 (herein Border) in view of “Hypertext Transfer Protocol — HTTP/1.1”, RFC 2616, by Fielding
`
`et al. (herein RFC 2616).
`
`The method according to claim 8, wherein the
`
`To the extent Border does not explicitly state
`
`periodically communicating comprises
`
`“periodically communicating comprises
`
`exchanging ‘keep alive’ messages.
`
`exchanging ‘keep alive’ messages”, RFC 2616
`
`Border and RFC 2616
`
`demonstrates that it was known at the time of
`
`invention to use an idle timer for keeping alive a
`
`connection, such that messages are, under the
`
`broadest reasonable interpretation, ‘keep alive’
`
`when received within that timer’s period (RFC
`
`2616: page 31, section 8.1.4). Border specifically
`
`cites to HTTP/1.1 (Border: column 4, lines 11-12)
`
`and RFC 2616 (Border: column 7, lines 26-31). It
`
`would have been obvious to one ofordinaryskill
`
`in the art at the time of invention to implement
`
`the HTTP of Border with HTTP, including ‘keep
`
`alive’ as defined in RFC 2616 as suggested by the
`
`teachings of both RFC 2616 and Border. This
`
`implementation would have been obvious
`
`because one of ordinaryskill in the art would
`
`have found: the implementation ofis a
`
`substitution and application of one known
`
`element and technique for another yielding a
`
`predictable result using an acceptable piece of
`
`prior art.
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 17 of 25
`
`Claim 11
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 17 of 25
`
`

`

`Application/Control Number: 90/014,876
`Art Unit: 3992
`
`
`Page 16
`
`The method according to claim 10, wherein the
`
`To the extent Border does not explicitly state
`
`determining is based on the received HTTP
`
`“wherein the determining is based on the
`
`header according to, or based on, IETF RFC 2616.
`
`received HTTP header accordingto, or based on,
`
`IETF RFC 2616”, RFC 2616 demonstrates that it
`
`was known at the time of invention to determine
`
`as in claim 10 based on the received HTTP header
`
`according to IETF RFC 2616 (RFC 2616: page 80,
`
`section 14.25, “if-modified-since”, which as
`
`discussed aboveis explicitly referenced in Border).
`
`Borderspecifically cites to HTTP/1.1 (Border:
`
`column 4, lines 11-12) and Borderspecifically
`
`cites to HTTP/1.1 (Border: column 4, lines 11-12)
`
`and RFC 2616 (Border: column 7, lines 26-31). It
`
`would have been obvious to one ofordinaryskill
`
`in the art at the time of invention to implement
`
`the HTTP of Border with HTTP, including headers,
`
`as defined in RFC 2616 as suggested by the
`
`teachings of both RFC 2616 and Border. This
`
`implementation would have been obvious
`
`because one of ordinaryskill in the art would
`
`have found: the implementation ofis a
`
`substitution and application of one known
`
`element and technique for another yielding a
`
`predictable result using an acceptable piece of
`
`prior art.
`
`Claims 2 and 13 is/are rejected under pre-AlA 35 U.S.C. 103(a) as being unpatentable over US
`
`6,795,848 B1 (herein Border) in view of “MorphMix — A Peer-to-Peer-based System for Anonymous
`
`Internet Access”, by Marc Rennhard (herein MorphMix).
`
`Exhibit 1127
`Code 200, UAB, etal. v. Bright Data
`IPR2021-01492
`Page 18 of 25
`
`Exhibit 1127
`Code 200, UAB, et al. v. Bright Data
`IPR2021-01492
`Page 18 of 25
`
`

`

`Page 17
`
`The method according to claim 1, wherein the
`
`“For now, we assume all nodeshave public static
`
`first client device is identified by a Media Access
`
`IP addresses; we will discuss other cases in
`
`Control (MAC) address or a hostname, and
`
`Section 5.8.2. To be contacted by other nodes, a
`
`wherein the method further comprising sending,
`
`node listens on TCP port pmm,, which is 28080
`
`by the first client device, during, as part of, or in
`
`per default, but which can be changed by the
`
`responseto, a start-up or power-up ofthe first
`
`node operator. In addition, each node has a key
`
`client device, a first message to the second
`
`pair consisting of a secret (or private) key SK; and
`
`server, and wherein the first messages comprises
`
`a public key PK;. This key pair is generated locally
`
`the first client IP address, the MAC address, or
`
`when a node is started for the first time. At any
`
`the hostname.
`
`time, MorphMix consists of a set of participating
`
`Application/Control Number: 90/014,876
`Art Unit: 3992
`
`t