`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