throbber
liliiilililliiil
`07/0313};
`
`‘7 '70 WV
`
`fie
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`7/3/97
`
`Applicant:
`Serial N0.:
`Filed:
`For:
`
`Docket N0.:
`
`Thomas Yohe eta].
`08/
`
`-
`APPARATUS AND METHOD FOR INCREASED DATA ACCESS IN A
`NETWORK FILE ORIENTED CACHING SYSTEM
`8-00014-003
`
`Box Patent Appiicati on
`Commissioner of Patents and Trademarks
`Washin on, DC 2023]
`
`Sir:
`
`Enclosed are the following papers:
`
`Specification, abstract and claims,_ pages total;
`Drawings :_ sheet(S), A formal, _ informal
`Declaration and Power of Attorney _X_ executed
`_ unexecuted
`_ A claim for priority under 35 U.S.C_ 119 is hereby made
`with respect to
`Application No‘ _
`filed
`. A certified copy of that
`application _ is enclosed]_ will be filed
`laterr
`
`|><|><|><
`
`
`_)_I_
`
`A claim for priority under 35 U.S.C. 120 is hereby made
`
`with respect to Q Application No. 08/565 393
`filed Ill/30195,
`Statement by inventor as to small entity status
`1 Enclosed herewith is a check in the amount offi 770 .
`which is calculated as follows.
`Preliminary amendment
`Information Disclosure Statement
`
`2&—
`
`{,1'1"
`E
`7“
`
`L The inventorship for all the claims in this application are:
`
`L The same
`
`or
`
`_ Are not the same. An explanation, including the
`ownership of the various claims at the time the last
`claimed invention was made
`_ is submitted.
`
`
`
`MICROSOFT
`MICROSOFT
`
`EXHIBIT 1007
`
`EXHIBIT 1006
`
`Page 1 of 49
`Page 1 of 49
`
`

`

`_ will be submitted.
`
`L An assignment of the invention to
`11s attached
`_ will follow; enclosed herewith is a check in the
`amount of 40.00
`
`A tenninal disclaimer is filed herewith and fee $55.00
`
`CLAIMS AS FILED
`
`Number filed
`
`Number Extra Rate
`J
`
`Basic Fee 37 CFR l.16(a)
`
`Total
`Claims 37
`.
`-20= -— X 22.00 —
`
`
`770.00
`
`Independent
`Claims :37 CFR 1.16011)
`
`- 3=
`
`X $ 80.00 -
`
`0.00
`
`Multiple dependent claim(s), if any
`37 CFR 1.16 (1
`
`260.00 -
`
`0.00
`
`
`
`Filing Fee Calculation
`
`Large Entity
`Small Entity
`
`7 7O ‘ (3‘0
`)x .5
`
`(
`
`Respectfully submitted,
`
`By
`
`R. William Graham
`Reg. No. @321.
`
`Page 2 of 49
`Page 2 of 49
`
`

`

`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`Applicant:
`Serial No.:
`Filed:
`For:
`
`Docket No:
`
`Thomas Patrick Yohe et a].
`08/
`
`APPARATUS AND METHOD FOR INCREASED DATAACCESS IN A
`NETWORK FILE ORIENTED CACHlNG SYSTEM
`8-00014-003
`
`COMMISSIONER OF PATENTS AND TRADEMARKS
`Washington, D.C. 20231
`
`EXPRESS MAIL CERTIFICATE
`
`6m 2/ 3 tZJ ‘/ 37
`"Express Mail" label number
`Date of Deposit
`7 / 3 /9 7
`
`
`
`I hereby certify that the following attached:
`transmittal letter
`
`new application
`continuation
`divisional
`
`continuation-impart
`declaration and power of attorney
`amendment
`_
`preliminary amendment
`__
`L information disclosure statement
`_
`response
`_
`notice of appeal
`L assignment
`petition for extension
`notification of continuation
`affidavit
`
`L
`
`verified statement of small entity
`filing fees
`terminal disclaimer and fee
`__
`is being deposited with the United States Postal Service
`service under 37 CFR 1.10 on the date indicated a I
`Patents and Trademarks, Washington, D.C. 2023
`
`"Ex: ess Mail Post Office to Addressee"
`-
`
`missioner of
`
`R4 William Graham
`
`Reg- Not m
`
`Page 3 of 49
`Page 3 0f 49
`
`

`

`Abstract of the Disclosure
`
`An apparatus for increased data access in a network includes a file server computer having
`
`a permanent storage memory, a cache verifying computer operably connected to the file server
`
`computer in a manner to form a network for rapidly transferring data, the cache verifying
`
`5
`
`computer having an operating system, a first memory and a processor with means for performing
`
`an operation on data stored in the permanent storage memory of the file server computer to
`
`produce a signature of the data characteristic of one of a file and directory, a remote client
`
`computer having an operating system, a first memory, a cache memory and a processor with
`
`means for performing an operation on data stored in the cache memory to produce a signature of
`
`the data, a communication server operably connected to the remote client computer to the cache
`
`verifying computer and the file server computer and comparators operably associated with the
`
`cache verifying computer and remote client computer for comparing the signatures of data with
`
`one another to determine whether the signature of data of the remote client is valid.
`
`
`
`
`
`32
`
`Page 4 of 49
`Page 4 of 49
`
`

`

`APPARATUS AND METHOD FOR INCREASED DATA ACCESS IN A NETWORK FILE
`
`\
`
`OK
`
`ORIENTED CACHING SYSTEM
`This is a continuation-in-part ofU.S. Serial No. 08/565,393 filed rum/w _
`‘
`-
`(L ‘
`Background of the Invention
`
`5
`
`Field of the Invention
`
`The present invention relates to data access in a file oriented network system. More
`
`particularly, the present invention is directed to a client-agent-server utility which increases the
`
`speed in which data in the form of files and directories are accessed across slow link
`
`communications via remote node caching and verifying.
`
`Related Art
`
`
` (e.g., x + y bytes). Thus, when the application requests the bytes, it already exists in its readily
`
`Many operating systems are equipped to handle caching and verifying of data,
`
`Traditionally, in a remote client's caching system, optimization in retrieving data is limited to
`
`prefetching. In other words, an application program in a remote client requests fiom a file server
`
`transmission of a predetermined number of bytes of information (eg, x bytes) and the operating
`
`system on the client prefetches the requested data plus another number ofbytes ofinformation
`
`accessible memory (cache)
`
`In addition, there also exist problems with verification of directories in existing systems.
`
`It
`
`has been found, for example, that two remote clients concurrently accessing data and attempting
`
`20
`
`to verify a directory will not necessarily obtain the same data due to the fact that the data from the
`
`file server computer will not necessarily send out the data in the same order to each ofthe remote
`
`clients. Thus, there is no clear indication whether the directory data is current.
`
`Page 5 of 49
`Page 5 0f 49
`
`

`

`In a desktop caching system, a high speed memory is used to cache data that is stored on a
`
`hard disk. While a desk-top cache program, such as Microsoft's SmartDrive is a usefiil tool to
`
`increase performance from the random access memory (RAM), this type of caching technique is
`
`not applicable to remote environments because of its inability to correctly handle multiple remote
`clients accessing the same data files concurrently, i.e., it is likely to corrupt the data.
`
`File servers have employed caching techniques which parallel techniques of the desktop.
`
`Here, the file server deviates in protecting against multiple common data user access by
`
`implementing or providing a file locking service to clients.
`
`As shown in FIG. 1, the related art includes a remote client computer having an operating
`
`system (OS) with a file system interface (FSI). Operatively connected to the F81 is a local file
`
`system (LFS) which in turn is operatively connected to a RAM based disk cacher (RBDC), disk
`
`driver (DD) and permanent storage disk (PSD). Also, operatively connected to the PSI is a
`
`network file redirector (NFR) with prefetch capability, and a network transport layer (NTL)
`
`connected to a WAN driver. Aside from the OS, there exist application programs (AP) which
`
`employs the OS via the FSI. A communication server (CS) connects to the remote client
`
`computer and includes a WAN driver, routing layer and LAN driver.
`
`. The CS connects through a LAN link to a file server computer having an OS. The file
`
`server computer OS includes an NTL connected to a LAN driver and an FSI connected to LFS
`
`which in turn is connected to an RBDC, a DD and a PSD. Aside from the OS, there exists a file
`
`server application which employs the OS via the FSI.
`
`The problem associated with these prior systems is their inability to provide a remote
`
`client user with greater speed of access to file server data and/or file server directories. This is
`
`
`
`20
`
`Page 6 of 49
`Page 6 of 49
`
`

`

`especially so because of the type of link in which the remote client may be accessing the data
`
`through, such as a modem phone link. In the context of the present invention, "remote client" is
`
`defined as a user, accessing data over a relatively slow link, such as a modern phone link. A
`
`typical modern phone link provides a transfer rate of about 28.8 kilobits of information per
`
`second. This is contrasted with a link in a LAN connection which can transfer at about 10
`
`Megabits per second, These remote clients are thus greatly limited in speed of access.
`
`' Summary of the Invention
`
`The present invention overcomes the above described deficiencies which exist with remote
`
`clients accessing and verifying data in files and directories from a file oriented network
`
`environment.
`
`It is an object to increase the speed in which a remote client can access data and
`
`directories.
`
`It is another object to maintain integrity of the accessed data and directory while
`
`increasing the speed in which the data is accessed.
`
`A further object is to implement an agent to act as a caching verifier between a remote
`
`client and a file server computer.
`
`Still, another object is to add intelligence to a remote client in order to reduce the overall
`
`time in which a remote client accesses data.
`
`Another object is to overcome the deficiencies of data transfer for a remote client.
`
`Other objects and advantages will be readily apparent from reading the following
`
`description and viewing the drawings.
`
`Accordingly, the present invention is directed to an apparatus for increased data access in
`
`
`
`
`
`20
`
`Page 7 of 49
`Page 7 of 49
`
`

`

`r
`
`a network, which includes a file server computer having a permanent storage memory, a cache
`
`verifying computer operably cemented to the file server computer in a manner to form a network
`
`for rapidly transferring data, the cache verifying computer having an operating system, a first
`
`memory and a processor with means for performing an operation on data stored in the permanent
`
`storage memory ofthe file server computer to produce a signature of the data characteristic of
`
`one ofa fiie and directory, a remote client computer having an operating system, a first memory, a
`
`cache memory and a processor with means for performing an operation on data stored in the
`
`cache memory to produce a signature ofthe data, a communication server operably connected to
`
`the remote client computer to the cache veriiying computer and the file server computer and
`
`
`
`comparators operably associated with the cache verifying computer and remote client computer
`
`for comparing the signatures of data with one another to determine whether the signature of data
`
`ofthe remote client is valid. The remote client computer includes means responsive to each
`
`comparison performed by the comparator on the data for generating and storing a validation ratio
`
`for'the data in the first memory and for removing the data from the cache memory when the
`
`validation ratio drops below a predetermined value, Also, the cache verifying computer includes
`
`means for recognizing a LOCK request from the remote client computer and for obtaining a lock
`
`on the data from the file server computer in response to the LOCK request,
`
`Terminology
`
`"Permanent storage memory," as used herein, includes, but is not limited to, disk drive,
`
`20
`
`flash RAM or bubble memory, for example.
`
`”File oriented distributed network," as used in the present invention, will include a
`
`network wherein the file server computer data is accessed via the following set offile system
`
`Page 8 of 49
`Page 8 0f 49
`
`

`

`primitives: OPEN, CREATE, READ, WRITE, SEEK, LOCK, UNLOCK, CLOSE and
`
`DIRECTORY REQUEST.
`
`"Caching" is the function of retrieving an object fi'om a relatively high speed storage
`
`device from a list of most-recently—used objects.
`
`"Cache" is a file which resides in permanent storage and contains the most~recently-used
`
`blocks of data read flour a remote file server.
`
`“Object” is a sequence of.data of variable length.
`
`“Sub-object” is a portion of an Object.
`
`
`
`20
`
`"File server computer" is a computer which includes a processor with its associated
`
`memory, an operating system, and a permanent storage memory.
`
`“Reverse channel” is the means by which a response message is sent over the same
`
`network layer interface in which a request was received
`
`Brief Description of the Drawings
`
`FIG. I illustrates the block diagram configuration of the related art,
`
`FIG. 2 illustrates the block diagram configuration of the present invention»
`
`FIG. 3 illustrates a flow chart of the operations of the present invention corresponding to the
`
`requests within a remote client.
`
`FIG. 4 illustrates a flow chart of the operations of the present invention corresponding to
`
`OPEN/CREATE requests on remote client computer.
`
`FIG. 5 illustrates a flow chart of the operations ofthe present invention corresponding to
`
`OPEN/CREATE requests on cache verifying computer.
`
`FIG. 6 illustrates a flow chart of the operations of the present invention corresponding to READ
`
`Page 9 of 49
`Page 9 Of 49
`
`

`

`requests on remote client computer.
`
`FIG. 7 illustrates a 'flow chart of the operations ofthe present invention corresponding to READ
`
`requests on cache verifying computer.
`
`FIG. 8 illustrates a flow chart of additional operations of the present invention corresponding to
`
`S
`
`READ requests in the cache verifying computer.
`
`FIG. 9 illustrates a flow chart of the operations ofthe present invention corresponding to WRITE
`
`requests on remote client computer.
`
`FIG. 10 illustrates a flow chart of the operations of the present invention corresponding to
`
`WRITE requests on cache verifying computer.
`
`FIG» 11 illustrates a flow chart of the operations ofthe present invention corresponding to LOCK
`
`requests on remote client computer.
`
`FIG. 12 illustrates a flow chart ofthe operations of the present invention corresponding to LOCK
`
`requests on cache verifying computer.
`
`FIG. 13 illustrates a flow chart ofthe operations of the present invention corresponding to
`
`CLOSE requests on remote client computer.
`
`FIG. 14 illustrates a flow chart of the operations of the present invention corresponding to
`
`CLOSE requests on cache verifying computer.
`
`FIG. 15 illustrates a flow chart of the operations of the present invention corresponding to
`
`DIRECTORY REQUEST on cache verifidng computer.
`
`
`
`20
`
`FIG. 16 illustrates a flow chart of the operations of the present invention corresponding to a part
`
`of the operations in FIG. 15,
`
`Detailed Description of a Preferred Embodiment
`
`Page 10 of 49
`Page 10 of 49
`
`

`

`In the description which follows, the representation of the present invention is in part
`
`presented in terms of program operations executed on a file oriented distributed network of
`
`computers, but may as well be applicable to distributed file oriented network systems. The
`
`operations are steps leading to a certain result. Typically, these steps take the form of electrical
`
`5
`
`signals which are manipulated, stored, transmitted, combined, compared or otherwise operated
`
`upon by a particular computer in the network. For simplicity, these signals may be referred to
`
`herein as bits, bytes or data.
`
`
`
`The following description describes solutions to the problems associated with a remote
`
`client computer’s ability to access specified data from a file or directory of a file server computer
`
`located on a network or world wide web, An apparatus and method are disclosed which permit
`
`the remote client computer to reduce the time for accessing such data using a cache verifying
`
`computer coupled with a caching technique,
`
`The performance gains realized by the present invention are derived from the fact that
`
`remote clients tend to repetitively access the same data by performing file reads. [fa copy of the
`
`data can be stored in the permanent storage memory ofthe remote client computer and also
`
`verified to be current when it is subsequently retrieved, this will improve performance
`
`significantly. This is because it requires much less bandwidth to verify a block of data than it
`
`would to actually transfer a block of data.
`
`Referring now to the figures 2-15, the present invention is a network computer system 10
`
`20
`
`having at least one remote client computer 12, cache verifying computer 14, communication
`
`server 16 and file server computer 18. The cache verifying computer 14 and file server computer
`
`18 are connected via a local area network (LAN) link 20. The communication server 16 links the
`
`Page 11 of 49
`Page 11 of 49
`
`

`

`remote client computer 12 to the LAN 20, which in turn permits communication with the cache
`
`verifying computer 14 and the file server computer 18.
`
`The remote client computer 12 communicates via communication link 22 to the
`
`communication server 16. The communication server 16 can be of a type such as that provided
`
`5
`
`by Cisco, 3Com, Shiva, etc.= which will act as a router of traffic between the LAN 20 and
`
`communication link 22 and convert data through the LAN 20. The LAN 20 can be Ethernet or
`
`Token Ring, for example,
`
`
`
`The remote client computer 12 has an operating system (OS) 24 with a file system
`
`interface (F8!) 26. Operatively connected to the F8126 is a local file system (LFS) 28 which in
`
`turn is operatively connected to a RAM based disk cacher (RBDC) 30, disk driver (DD) 32 and
`
`permanent storage disk (PSD) 34, A network file redirector (NFR) 36 with prefetch data 37,
`
`operatively connects to a network transport layer (NTL) 38 which in turn is connected to a WAN
`
`driver 40. Additionally, the invention includes a network file cacher (NFC) 42 which is operably
`
`disposed between and interconnects the PSI 26 and NPR 36. The NFC 42 has operatively
`
`associated therewith a directory cacher (DC) 43 and directory signature comparator (DSC) 46.
`
`The NTL 38 operatively connects to the NFC 42. Also, the NFC 42 operatively connects
`
`to the LFS 28. The NFC 42 includes a block signature generator (B56) 44 and hit ratio analyzer
`
`(HRA) 45, which wiil be more fully described hereinafter. Aside from the OS, there exists on the
`
`computer 12 application programs (AP) 46 which employ the OS 24 via PSI 26.
`
`20
`
`The communication server (CS) 16 includes a WAN driver 48, a LAN driver 50 and
`
`roofing layer (EL) 52 operatively interconnecting the WAN driver 48 and the LAN 50 driver.
`
`The cache verifying computer 14 includes a cache verifyiné agent (CVA) 54 having a BSG
`
`Page 12 of 49
`Page 12 of 49
`
`

`

`
`
`56 (of the type described herein), a directory signature generator (D56) 57 and a comparator 58.
`
`Also, included is an OS 60 having an FSI 62 operatively connected to OVA 54, an NPR 64
`
`operatively connected to the PSI 62, an NTL 66 operatively connected to the NFR 64 and CVA
`
`S4, and a LAN driver 68 operatively connected to the NTL 66.
`
`5
`
`The file server computer 18 includes an OS 70 having an F8] 72 which is operatively
`
`connected to an LFS 74 which in turn is connected to an RBDC 76, a DD 78 and a PSD 80.
`
`Also, the OS 70 includes an NTL 82 operatively connected to a LAN driver 84, A fiie server
`
`application (FSA) 86 exists on the computer 18 which is operably connected to both the NTL 82
`
`and F81 72.
`
`
`
`
`LL;
`
`It should be noted that one skilled in the art can modify the basic network computer to
`
`accomplish the objects set forth herein and that such modifications are believed to fall within the
`
`scope ofthe claims appended hereto. Alternatively, for example, the cache verifying agent 54
`
`could reside as part of the communication server 16 or as a stand alone processor with its own
`
`memory and operating system. Stiil, other persons skilled in the art will appreciate the verifying
`
`agent can be implemented in other manners to accomplish the goals set forth herein.
`
`The operation of the system is as follows and as represented in FIGS. 3-15. The
`
`operations discussed hereafter assumes connections have been made among all computers 12, 14
`
`and 18 and communication server 16,
`
`On the remote client computer, AP 46 makes requests from a file server wherein the NFC
`
`20
`
`I 42 will intercept a file system call 100 from the AP 46 and query whether the object to be acted
`
`upon is "remotely located?" 102. If the answer is no, the NFC 42 Tins-tracts" 104 the LFS 28 to
`
`handle the object request. If yes, the type of request is ascertained and handled accordingly as
`
`Page 13 of 49
`Page 13 of 49
`
`

`

`follows.
`
`In the case of OPEN or CREATE 106 requests, the NFC 42 follows the operation under
`
`200. The NFC 42 "invokes" 202 the NPR 36 to process the request. The NFR 36 asks "Whether
`
`there is a good status" 204 for the request. If no, NFR 36 "returns" 205 the results ofthe
`
`5
`
`operation to AP 46. Ifyes, the NPR 36 assigns a handle thereto and the NFC 42 "builds and
`
`sends" 206 an OPEN/CREATE request to CVA 54 via NTL 38 which triggers operation 250.
`
`CVA 54 "opens" 252 a file specified in OPEN/CREATE request via FSI 62, NFR 62 and
`
`NTL 66. The CVA 54 asks "whether there is a good status on the file?“ 254. If the answer is no,
`
`CVA 54 "sends" 256 the bad response back to NFC 42 in a reverse channel, If the answer is yes,
`
`CVA 54 "assigns a handle to the objec " 258 and “sends" 260 a good response via a reverse
`
`channel.
`
`NFC 42 via NTL 38 ”receives the response" 208 fiom CVA 54 and "asks for a good
`
`status?" 210. Ifthe answer is no, the NFC 42 "returns the results ofthe original OPEN/CREATE
`
`request" 216 to AP 46. Ifthe answer is yes, then the NFC 42 "associates 212 the handle assigned
`
`by the CVA 54 with the handle returned by the NFR 36 in operation 202. The NFC 42 "updates"
`
`214 the network file cache via LFS 28 and "returns the results obtained by NFR 36" 216 to AP 46
`
`via FSI 26.
`
`
`
`In the case of a READ 108 requests, the computer 12 follows the operation 300. Via the
`
`FSI 26 and LFS 28, the NFC 42 "determines if the requested data is in cache?" 302. If the
`
`20
`
`answer is no, a subquery becomes "is the data locked?" 304. To this subquery, if the answer is
`
`no, the NFC 42 "retrieves" 306 the data via NTL 38 from the file server computer 18 and the
`
`NFC 42 "updates" 308 the network file cache via LFS 28. If the answer to the subquery is yes,
`
`10
`
`i
`
`i
`
`Page 14 of 49
`Page 14 of 49
`
`

`

`
`
`the NFC 42 via the NFL 38 "sends" 310 a READ request to CVA 54 which triggers 380. CVA
`
`54 via the F81 62 "reads" 382 the data from the file server computer 18, The CVA 54 "sends"
`
`384 a response back to NBC 42, wherein the data is "received" 312 and "updated" 308 as
`
`described above. The retrieved data is "returned" 314 by the NFC 42 to AP 46.
`
`5
`
`If the data is in cache, NFC 42 is triggered to “invoke" 316 the BSG 44 to generate a
`
`signature of data. NFC 42 via NPR 36 and NTL 38 "sends" 320 a VERIFY request having the
`
`first signature of data therein to CVA 54 which triggers 350.
`
`CVA 54 via PSI 62 "reads" 352 data from the file server computer 18. CVA 54 "invokes"
`
`354 BSG 56 to generate a second signature of data. CVA 54 "invokes" 356 comparator 58 to
`
`compare the first and second signatures of data and "asks whether there is a match?" 358. Ifthe
`
`answer is no, CVA 54 "asks if data is locked?" 360. If no, the CVA 54 "sends" 362 back a bad
`
`response to NFC 42 via a reverse channel. If yes, CVA 54 "sends" 364 back a bad response to
`
`NFC 42 along with read data via a reverse channel. If there is a match of the signatures, CVA 54
`
`"sends" 366 a good response back to NFC 42 viaNTL 66.
`
`The NFC 42 receives 322 the response fi'om CVA 54 and asks "is the data valid?" 324. If
`
`no, NFC 42 asks "is the data locked?" 326. Ifnot locked, the NFC 42 retrieves data 306 as
`
`described above, If locked, data will have been "returned" 328 for updating per 308. Ifthe data
`
`was valid, NFC 42 returns the data to AP 46.
`
`
`
`In the case of a WRITE 110 request, the computer 12 follows the operation 400. The
`
`20
`
`NFC 42 “asks is the data locked?" 402. If no, the NPR 36 is invoked to "write“ 404 to the file
`
`server computer 18. If the data is locked, NFC 42 via NTL 38 "sends" 406 a WRITE request to
`
`CVA 54 which triggers 450. CVA 54 ‘fivrites” 452 data to file server computer 18 via FSI 62.
`
`11
`
`Page 15 of 49
`Page 15 of 49
`
`

`

`CVA 54 "sends" 454 back a response to NFC 42 which "receives" 408 the response. The NFC
`
`42 "asks is the data in cache?" 410. If no, LFS 28 "reports status" 412 to AP 46. If yes, NFC 42
`
`"updates" 414 network cache via LFS 28 and "reports status" 412 to AP 46.
`
`In the case ofLOCK/UNLOCK 112 request, operation 500 is employed. The NFC 42
`
`5
`
`‘huilds" 502 an LOCK/UNLOCK request. The NFC 42 via NTL 38 ”sends" 504 the
`
`LOCK/UNLOCK request to CVA 54 which triggers operation 550. CVA 54 "sends" 552 an
`
`LOCK/”UNLOCK request to the fiie server computer 18 via PSI 62. CVA 54 "sends" 554 a
`
`response back to NFC 42 via a reverse channel. The NFC 42 "receives" 506 the response and
`
`"returns" 508 the results to AP 46.
`
`
`
`In the case of a CLOSE 114 request, operation 600 is employed. The NFC 42 "builds"
`
`602 a CLOSE request. The NFC 42 via NTL 38 “sends" 604 the CLOSE request to CVA 54
`
`which triggers operation 650. CVA 54 "performs" 652 internal processing of the request. CVA
`
`54 “sends" 654 a response back to NFC 42. The NFC 42 “receives” 606 the response and
`
`invokes the NFR 36 to "close" 608 the file and "return” 610 the results to AP 46.
`
`In the case of a DIRECTORY REQUEST 115, operation 700 is employed. Here, the
`
`NFC 42 “processes” 701 a first directory sub-object request.
`
`If the sub-object is not a first, NFC 42 “retrieves” 703 the next directory sub-object from
`
`cache via LFS 28. NFC 42 “asks” 704 whether this is the last sub-object from cache via LFS 28?
`
`If no, NFC “returns” 705 a sub-object to AP 46. Ifyes and it is the last sub-object, NFC 42
`
`20
`
`“returns” 706 a “no more objects.” status to AP 46.
`
`If the sub-object is the first directory sub-object, the NFC 42 “determines” if the requested
`
`object is in cache 702. 7 If no, the NFC 42 “sends” 710 a directory verify request to CVA 54 via
`
`12
`
`Page 16 of 49
`Page 16 of 49
`
`

`

`NTL 38. This triggers the steps 750 and NFC 42 waits to “receive” 711 signature from CVA 54.
`
`As seen in FIG. 16, the steps 750 are performed by the CVA 54. Particularly, the DSG 57
`
`“initializes” 751 signature of a directory. The DSG 57 “retrieves” 752 the first directory sub-
`
`object from the FS 18 via NTL 66. The DSG 57 “asks” 753 is this the last sub»object‘? If no,
`
`5
`
`DSG 57 “factors” 754 the signature of this sub-object into the overall signature of the directory.
`
`The DSG 57 then “retrieves” 755 the next sub-object fi'om FS 18 and returns to step 753. Ifthe
`
`last sub-object, CVA 54 “sends” 756 back signature of directory to NFC 42 at block 724 and
`
`proceeds therefrom.
`
`
`
`If yes and in cache, the NFCV42 “retrieves” 719 signature associated with this directory
`
`request fiom cache via LFS 28, NFC 42 “sends” 720 directory verify request to CVA 54 via
`
`NFL 38. This triggers the steps 750 wherein NFC 42 waits and “receives” 721 signature from
`
`CVA 54. NFC 42 “invokes" 722 DSC 46 to compare whether signature matches the retrieved
`
`signature in 719? Ifyes and the signatures match, NFC 42 “returns” 723 the first subuobject from
`
`cache via LFS 28 and returns it to AP 46. If no and the signature does not match, NFC 42
`
`“invokes” 724 NFR 36 to retrieve the first directory sub-object. NFC 42 “stores” 725 the sub-
`
`object into cache via LFS 28. NFC 42 “asks” 726 whether this is the last sub-object? If no and it
`
`is not the last sub-object, NFC 42 invokes NFR 36 to “retrieve” the next directory sub-object and
`
`returns to step 725. If yes and it is the last sub-object, NFC 42 “stores” 728 the signature
`
`obtained via 721 or 711 into cache via LFS 28. NFC 42 “returns” 729 first sub-object from cache
`
`20
`
`via LFS 28 and returns the same to AP 46.
`
`By way of example, the following packet formats define this client server protocol:
`
`1/
`
`13
`
`Page 17 of 49
`Page 17 0f 49
`
`

`

`// TYPE DEFINITIONS
`
`fl
`
`BYTE =>an 8 bit value (octet) unsigned
`
`DWORD => a 16 bit value in which network byte ordering is not important
`
`5
`
`WORD => 32 bit value in which network byte ordering is not important
`
`MDWORD=> 32 bit value in which network byte ordering is important and represented
`
`
`
`using “motorola” or “big endian“ format
`
`// START CONNECTION REQUEST
`
`typedef struct {
`
`BYTE bFunctionCode; ll aiways 0x00
`
`BYTE bResv; //
`
`WORD wSequenceValue; //
`
`}CVP_START_CONNECTION_REQ, *pCVP_ START_CONNECTION_REQ;
`
`// START CONNECTION RESPONSE
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`// always 0x80
`
`BYTE bStatus;
`
`fl
`
`WORD wSequenceValue ll Same value as in request
`
`DWORD dConnectionHandie; //
`
`20
`
`}CVP* START_CONNECTION_RSP, ‘pCVP_START_CONNECTION_ RSP;
`
`// END CONNECTION REQUEST
`
`typedef struct }
`
`14
`
`Page 18 of 49
`Page 18 of 49
`
`

`

`BYTE bFunctioncode; 1' /always 0x01
`
`BYTE bResv;
`
`/'/'
`
`WORD wSequencevalue; //
`
`DWORD dConnectionHandle; //
`
`5
`
`fl as returned on start connection
`
`}CVP_ENDHCONNECTION_REQ, *CV'P_END_CONNECTION_REQ;
`
`”END CONNECTION RESPONSE
`
`typedef stmct {
`
`BYTE bFunctlonCode; ”always 0x81
`
`BYTE bStatus;
`
`If
`
`WORD wSequencevalue; // Same value as in request
`
`}CVP_END~CONNECTION_RSP, *pcvp_ END_CONNECTION_ RSP;
`
`// OPEN OR CREATE FILE REQUEST
`
`typedef struct {
`
`BYTE bfimctiuncode; fl always 0x02
`
`BYTE bResv; //
`
`WORD wSequenceValue; //
`
`
`
`
`ire
`
`DWORD dConnectlonHandle‘, // As returned on STARTwCONNECT
`
`MDWORD dFileAttributesMask; //
`
`20
`
`BYTE zFilePath[5]2];
`
`//null terminated file name
`
`}CVP_OPEN_ORHCREATE_FILE.REQ, *pCVP_OPEN_OR_‘ ,CREATEMFILE_REQ;
`
`”OPEN OR OR CREATE FILE RESPONSE
`
`15
`
`Page 19 of 49
`Page 19 0f 49
`
`

`

`typedef struct {
`
`BYTE bFunctionCode;
`
`// always 0x82
`
`BYTE bStatus;
`
`1/
`
`WORD wSequenceValue; ll Same value as in request
`
`5
`
`DWORD dVerifiersFileHandle; //
`
`} CVP_OPENmOR_CREATE_FILE_RSP, *pCVP_OPEN_OR_CREATEiFILE_ RSP;
`
`ll CLOSE FILE REQUEST
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`fl aiways 0x03
`
`BYTE bResv;
`
`//
`
`WORD wSequenceValue;
`
`//
`
`DWORD dConnectionHandle; If As returned on START_CONNECT
`
`DWORD dVerifiersFileI-Iandle; I! As returned on OPEN_OR_CREATE
`
`}CVP_CLOSE_FILE_REQ, *pCVP_CLOSE_FILE_REQ;
`
`// CLOSE FEE RESPONSE
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`// always 0x83
`
`BYTE bStatus; fl
`
`
`
`WORD wSequenceValue;
`
`// Same value as in request
`
`20
`
`} CVP_CLOSE_FILE_RSP, *pCVP_CLOSE_FILE_RSP;
`
`// LOCK REGION REQUEST
`
`typedef strum {
`
`16
`
`Page 20 of 49
`Page 20 0f 49
`
`

`

`i 1 \
`
`Page 21 of 49
`Page 21 of 49
`
`BYTE bFunctionCode;
`
`ff always 0x04
`
`BYTE bResv; ll
`
`WORD wSequenceValue;
`
`//
`
`DWORD dConnectionI-Iandle; ll As returned on START_CONNECT
`
`5
`
`DWORD dVen'fiersFileHandle; // As returned on OPEN_OR_CREATE
`
`MDWORD dSeekValue',
`
`f/offset into file
`
`MDWORD dLength;
`
`l/number of bytes to lock
`
`}CVP_LOCK_REGION_REQ, *pCVP_ LOCK_ REGION_RBQ;'
`
`'
`
`”LOCK REGION RESPONSE
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`ll always 0x84
`
`BYTE bSratus;
`
`//
`
`WORD wSequenceVaiue; If Same value as in request
`
`DWORD
`
`dVeriflersLocldJandle;
`
`} CVP_LOCK_REGION_RSP, *pCVP_LOCKflREGIONdRSP;
`
`
`
`l/UNLOCK REGION REQUEST
`
`typedef struct {
`
`BYTE bFunctionCode; // aIways 0x05
`
`BYTE bResv; //
`
`20
`
`‘
`
`WORD wSequenceValue;
`
`ff
`
`DWORD' dConnectionI-Iandle; f/As returned on START_CONNECT
`
`DWORD dVerifiersLockHandle; ll As returned LOCK REGION
`
`17
`
`

`

`} CVP_UNLOCK_REG10N_REQ, *pCVP_UNLOCK_REGION_REQ;
`
`// UNLOCK REGION RESPONSE
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`// always 0x85
`
`5
`
`BYTE bStatus;
`
`WORD wS‘equenceValue;
`
`// Same value as in request
`
`}CVP_UNL0CKMREGION_RSP‘ *pCVP_UNLOCK_REGIONURSP;
`
`fl VERIFY REGION REQUEST
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`// always 0x06
`
`BYTE bResv;
`
`// if status is not OxFl
`
`WORD wSequenceValue;
`
`//
`
`DWORD dConnectionHandle; // As returned on STARTWCONNECT
`
`DWORD dVerifiersFileHandle; ll As returned on 0PEN_OR_CREATE
`
`MDWORD dSeekValue; ff offset into fiEe
`
`MDWORD dLength; ”number of bytes to verify
`
`BYTE Signature[8]‘, l/CRC adaptation
`
`
`
`} CVP_VERIFY_.RFGION_REQ, *pCVP_ VERIFY_REGION_REQ;
`
`// VERIFY REGION RESPONSE # 1 (not locked data)
`
`20
`
`typedef struct {
`
`BYTE bFunctionCode',
`
`II always 0x86
`
`BYTE bStams;
`
`//
`
`18
`
`Page 22 of 49
`Page 22 of 49
`
`

`

`WORD wSequenceValue;
`
`”Same value as in request
`
`} CVP_VERIFY_REGION_RSP,*pCVP_VERIFYfiREGION_RSP;
`
`//
`
`// VERIFY REGION RESPONSE #2
`
`5
`
`// (if signatures did not match and region was locked)
`
`If
`
`typedef struct {
`
`BYTE bFunctionCode; fl always 0x86
`
`BYTE bStatus;
`
`”status = OXF 1 for this case
`
`WORD wSequenceVaJue; If Same value as in request
`
`MDWORD dLength;
`
`// # of bytes that follow
`
`char TheDatafl;
`
`//
`
` // {sent only when reading from a locked regiOn)
`
`} CVP_VER]FY_REGION_RSP, *pCVP_VERIFY_REGION_RSP;
`
`If READ REGION REQUEST
`
`
`
`typedef struct {
`
`BYTE bFunctionCode; ff always 0x07
`
`BYTE bResv;
`
`ll
`
`WORD wSequenceValue; ff
`
`20
`
`DWORD dConnectionHandle', Ill As returned on START_CONNECT
`
`DWORD dVerifiersFileH

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


Or .

Accessing this document will incur an additional charge of $.

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

Accept $ Charge
throbber

Still Working On It

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

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

throbber

A few More Minutes ... Still Working

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

Thank you for your continued patience.

This document could not be displayed.

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

Your account does not support viewing this document.

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

Your account does not support viewing this document.

Set your membership status to view this document.

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

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

Become a Member

One Moment Please

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

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

Your document is on its way!

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

Sealed Document

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

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


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket