throbber
55912 U.S. PTO
`111~111~~I\I~~II'~\\l1\I~11
`07/03L9J.-'
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`Date:
`
`Thomas Yohe et al.
`08/
`
`APPARATUS AND METHOD FOR INCREASED DATA ACCESS IN A
`NETWORK FILE ORIENTED CACHING SYSTEM
`S-OOO14-003
`
`Applicant:
`Serial No.:
`Filed:
`For:
`
`Docket No.:
`
`Box Patent Application
`Commissioner of Patents and Trademarks
`Washington, D.C. 20231
`
`Sir:
`
`.2L
`.2L
`.2L
`
`.lL
`
`X
`
`K-
`.2L
`
`Enclosed are the following papers:
`
`Specification, abstract and c1aims,_ pages total.
`Drawings:_ sheet(s),.x.
`formal, _ informal
`Declaration and Power of Attorney X executed
`unexecuted
`A claim for priority under 35 U.S.c. 119 is hereby made
`Application No. _
`with respect to
`filed
`. A certified copy of that
`application_
`is enclosedl_ will be filed
`later.
`A claim for priority under 35 U.S.C. 120is hereby made
`with respect to u.s. Application No. 08J565 393
`filed IlJ30/95.
`Statement by inventor as to small entity status
`Enclosed herewith is a check in the amount of$ 770.
`which is calculated as follows.
`Preliminary amendment
`Information Disclosure Statement
`The inventorship for all the claims in this application are:
`
`X 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
`
`EXHIBIT 1006
`
`Page 1 of 49
`
`

`

`_ will be submitted .
`
`.K-
`
`An assignment
`.x, is attached
`enclosed
`_ will
`follow;
`amount of -±Q..OO
`
`of the invention
`
`to
`
`herewith
`
`is a check in the
`
`A terminal
`
`disclaimer
`
`is filed herewith
`
`and fee $55.00
`
`CLAIMS AS FILED
`
`Number
`
`filed
`
`Number Extra
`
`Rate
`I
`
`Total
`Claims
`
`(37 CPR 1.l6(cl)
`
`-20= -- X $ 22.00
`
`Independent
`(37 CFR LJ6(bl)
`Claims
`
`- 3=
`
`X $ 80.00 -
`
`dependent
`Multiple
`(37 CFR U6(dl)
`
`c1aim(s),
`
`if any
`
`$26000-
`
`Filing Fee Calculation
`
`Large Entity
`Small Entity
`
`'/70, CN
`) x.5
`
`(
`
`BasicFee
`
`37CFRI.l6(a)
`
`$770.00
`
`000
`
`000
`
`Respectfully
`
`submitted,
`
`BY~----'
`R William Graham
`Reg. No. 33,891
`
`2
`
`Page 2 of 49
`
`

`

`IN THE UNITED STATES PATENT AND TRADEMARK OF.F.ICE
`
`Thomas Patrick Yohe et al.
`08/
`
`APPARATUS AND METHOD FOR INCREASED DATAACCESS
`NETWORK FILE ORIENTED CACHING SYSTEM
`8-00014-003
`
`IN A
`
`Applicant:
`Serial No.:
`Filed:
`For:
`
`Docket No.:
`
`COMMISSIONER OF PATENTS AND TRADEMARKS
`Washington, D.C. 20231
`
`eM II tJ 'f ~/ L(.J r
`"Express Mail" label number
`7 I "3 /9 7
`Date of Deposit
`
`EXPRESS MAIL CERTIFICATE
`
`JL
`JL
`
`JL
`
`Ihereby certify that the following attached:
`transmittal letter
`X-
`new application
`JL
`continuation
`divisional
`continuation-in-part
`declaration and power of attorney
`amendment
`preliminary amendment
`information disclosure statement
`response
`notice of appeal
`assignment
`petition for extension
`notification of continuation
`affidavit
`verified statement of small entity
`filing fees
`terminal disclaimer and fee
`is being deposited with the United States Postal Service "Ex
`ve
`service under 37 CFR 1.10 on the date indicated a
`Patents and Trademarks, Washington, D.C. 2023
`
`JL
`
`JL
`
`s
`
`R. William Graham
`Reg. No. 33 891
`
`Page 3 of 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 ofthe
`
`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
`
`:;::.;'10
`
`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
`
`

`

`APPARATUS AND METHOD FOR INCREASED DATA ACCESS IN A NETWORK FILE
`
`ORIENTED CACHING SYSTEM
`
`of U.S. Serial No. 08/565,393
`
`filed 11130/95':
`
`/'--t:~{
`.<.
`
`This is a continuation-in-part
`i
`
`Background
`
`of the Invention
`
`5
`
`Field of the Invention
`
`i:•.•••,
`
`f:~0
`~Ji~~I'd
`
`If-..?1""
`
`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
`
`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
`
`from a file server
`
`transmission of a predetermined
`
`number of bytes of information (e.g. x bytes) and the operating
`
`system on the client prefetches
`
`the requested data plus another number of bytes of information
`
`(e.g. x + y bytes). Thus, when the application requests the bytes,
`
`it already exists in its readily
`
`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 s,ame order to each of the remote
`
`clients, Thus,
`
`there is no clear indication whether
`
`the directory data is current
`
`Page 5 of 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 useful
`
`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
`
`5
`
`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.
`
`I, the related art includes a remote client computer having an operating
`
`system (OS) with a file system interface (FSI). Operatively connected to the FSI is a local file
`
`system (LFS) which in turn is operatively connected to a RAM based disk cacher (RBDC), disk
`
`lAc;
`
`driver (DD) and permanent
`
`storage disk (PSD). Also, operatively connected to the FSI 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
`
`".j
`
`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 tum is connected to an RBDC, a DD and a PSD. Aside from the OS, there exists a file
`
`20
`
`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
`
`2
`
`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 ofthe present
`
`invention,
`
`"remote client" is
`
`defined as a user, accessing data over a relatively slow link, such as a modem phone link:. A
`
`typical modem phone link provides a transfer
`
`rate of about 28.8 kilobits ofinforrnation
`
`per
`
`5
`
`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
`
`:3.0
`
`~~:::,..~
`;~
`
`20
`
`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
`
`3
`
`Page 7 of 49
`
`

`

`a network, which 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 computer having an operating system, a first
`
`memory and a processor with means for performing an operation on data stored in the permanent
`
`5
`
`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
`
`iie
`
`'
`
`of the 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 of file system
`
`4
`
`Page 8 of 49
`
`

`

`primitives: OPEN, CREATE, READ, WRITE, SEEK, LOCK, UNLOCK, CLOSE and
`
`DIRECTORY REQUEST.
`
`"Caching" is the function of retrieving an object from a relatively high speed storage
`
`device from a list of most- recently-used
`
`objects.
`
`5
`
`"Cache" is a file which resides in permanent
`
`storage and contains the most-recently-used
`
`blocks of data read from a remote file server.
`
`"Object"
`
`is a sequence of data of variable length.
`
`"Sub-object"
`
`is a portion of an Object.
`
`"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.
`
`20
`
`FIG. 5 illustrates a flow chart of the operations of the 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
`
`5
`
`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
`
`5
`
`READ requests
`
`in the cache verifying computer.
`
`FIG. 9 illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to WRITE
`
`requests on remote client computer.
`
`FIG.
`
`IO illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to
`
`WRITE requests on cache verifying computer.
`
`':;10
`
`FIG. 11 illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to LOCK
`
`requests on remote client computer.
`
`i#.,
`
`FIG. 12 illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to LOCK
`
`requests on cache verifying computer.
`
`FIG.
`
`I3 illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to
`
`CLOSE requests on remote client computer.
`
`"'.j
`
`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 verifying 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
`
`6
`
`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 pennit
`
`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.
`
`If a copy of the
`
`data can be stored in the permanent storage memory of the remote client computer and also
`
`>;1
`
`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
`
`7
`
`Page 11 of 49
`
`

`

`remote client computer 12 to the LAN 20, which in tum 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 (FSI) 26. Operatively connected to the FSI 26 is a local file system (LFS) 28 which in
`
`tum 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 tum 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 FSI 26 and NFR 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 (BSG) 44 and hit ratio analyzer
`(HRA) 45, which will be more fully described hereinafter. Aside from the as, there exists on the
`computer 12 application programs CAP) 46 which employ the as 24 via FSI 26.
`
`20
`
`The communication server (CS) 16 includes a WAN driver 48, a LAN driver 50 and
`
`routing layer (RL) 52 operatively interconnecting the WAN driver 48 and the LAN 50 driver.
`
`The cache verifying computer 14 includes a cache verifying agent (CVA) 54 having a BSG
`
`8
`
`Page 12 of 49
`
`

`

`56 (of the type described herein), a directory signature generator
`
`(DSG) 57 and a comparator
`
`58.
`
`Also, included is an OS 60 having an FSI 62 operatively connected to CVA 54, an NFR 64
`
`operatively connected to the FSI 62, an NTL 66 operatively connected to the NFR 64 and CV A
`
`54, and a LAN driver 68 operatively connected to the NTL 66.
`
`5
`
`The file server computer
`
`18 includes an OS 70 having an FSI 72 which is operatively
`
`connected to an LFS 74 which in tum is connected to an RBDC 76, aDD 78 and a PSD 80.
`
`Also,
`
`the OS 70 includes an NTL 82 operatively connected to a LAN driver 84. A file server
`
`application (FSA) 86 exists on the computer 18 which is operably connected to both the NTL 82
`
`and FSI72.
`
`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
`
`(yj
`
`scope of the claims appended hereto. Alternatively,
`
`for example,
`
`the cache verifying agent 54
`
`could reside as part ofthe communication
`
`server 16 or as a stand alone processor with its own
`
`memory and operating system. Still, other persons
`
`skilled in the art will appreciate the verifying
`
`5
`
`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
`
`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.
`
`lfthe answer
`
`is no, the NFC 42 "instructs" 104 the LFS 2810
`
`handle the object request.
`
`If yes, the type of request
`
`is ascertained and handled accordingly as
`
`9
`
`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 NFR 36 to process the request. The NFR 36 asks "whether
`
`there is a good status" 204 for the request.
`
`Ifno, NFR 36 "returns" 205 the results of the
`
`5
`
`operation to AP 46. If yes, the NFR 36 assigns a handle thereto and the NFC 42 "builds and
`
`sends" 206 an OPEN/CREA TE 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 S4 "assigns a handle to the object" 258 and "sends" 260 a good response via a reverse
`
`channel.
`
`NFC 42 via NTL 38 "receives the response" 208 from CVA 54 and "asks for a good
`
`status?" 210.
`
`If the answer is no, the NFC 42 "returns the results ofthe original OPEN/CREATE
`
`request" 216 to AP 46. If the 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
`
`viaFSI26.
`
`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. Ifthe answer to the subquery is yes,
`
`IO
`
`Page 14 of 49
`
`

`

`theNFC 42 via theNTL 38 "sends" 310 a READ request to CVA 54 which triggers 380. CVA
`
`54 via the FSI 62 "reads" 382 the data from the file server computer 18. The CVA 54 "sends"
`
`384 a response back to NEC 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 NFR 36 and NTL 38 "sends" 320 a VERIFY request having the
`
`first signature of data therein to CVA 54 which triggers 350.
`
`CVA 54 viaFSI 62 "reads" 352 data from the file server computer 18. CVA 54 "invokes"
`
`354 BSG 56 to generate a second signature of data. eVA S4 "invokes" 356 comparator 58 to
`
`;40
`i:G
`~~
`
`compare the first and second signatures of data and "asks whether there is a match?" 358.
`
`If the
`
`answer is no, eVA 54 "asksif data is locked?" 360. Ifno, the eVA 54 "sends" 362 back a bad
`
`response to NFe 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, eVA 54
`
`"sends" 366 a good response back to NFC 42 via NTL 66.
`
`The NFC 42 receives 322 the response from eVA 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. If the 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 NFR 36 is invoked to "write" 404 to the file
`
`server computer 18. Ifthe data is locked, NFC 42 via NTL 38 "sends" 406 a WRITE request to
`
`CVA 54 which triggers 450. CVA 54 "writes" 4S2 data to file server computer 18 via FSI 62.
`
`11
`
`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.
`
`Ifno, 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 ofLOCKlUNLOCK 112 request, operation 500 is employed. The NFC 42
`
`5
`
`''builds'' 502 an LOCKIUNLOCK request. The NFC 42 via NTL 38 "sends" 504 the
`
`LOCKIUNLOCK request to CVA 54 which triggers operation 550. CVA 54 "sends" 552 an
`
`LOCKIUNLOCK request to the file server computer 18 via FSI 62. CVA 54 "sends" 554 a
`
`response back to NFC 42 via a reverse channel. The NFC 42 "receives" 506 the response and
`
`!,\,,'
`
`!''';
`
`",j
`
`"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 S4
`
`which triggers operation 650. CVA 54 "performs" 652 internal processing of the request. CVA
`
`S4 "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 ofa DIRECTORY REQUEST 115, operation 700 is employed. Here, the
`
`NFC 42 "processes" 701 a first directory sub-object request.
`
`Ifthe 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?
`
`Ifno, NFC "returns" 705 a sub-object to AP 46.
`
`If yes 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 NFC42 "determines" if the requested
`
`object is in cache 702.
`
`If no, the NFC 42 "sends" 710 a directory verify request to CVA 54 via
`
`12
`
`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? Ifno,
`
`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 from FS 18 and returns to step 753. If the
`
`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 NFC 42 "retrieves" 719 signature associated with this directory
`
`i~l0
`t't~,
`;r;
`
`request from cache via LFS 28. NFC 42 "sends" 720 directory verify request to CVA 54 via
`
`NTL 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? If yes and the signatures match, NFC 42 "returns" 723 the first sub-object 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-objectand
`
`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:
`
`f(
`
`13
`
`Page 17 of 49
`
`

`

`II TYPE DEFINITIONS
`
`II
`
`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
`
`II START CONNECTION REQUEST
`
`typedef struct {
`
`BYTE bFunctionCode; II always OxOO
`
`BYTE bResv; II
`
`WORD wSequenceValue; 1/
`
`liST ART CONNECTION RESPONSE
`
`typedef struct {
`
`BYlE bFunctionCode;
`
`// always Ox.80
`
`BYTE bStatus;
`
`II
`
`WORD wSequenceValue // Same value as in request
`
`DWORD dConnectionHandle;
`
`II
`
`20
`
`}CVP_ START_CONNECTlON_RSP,
`
`*pCVP_START_CONNECTJON_RSP;
`
`/1 END CONNECTION REQUEST
`
`typedef struct }
`
`14
`
`Page 18 of 49
`
`

`

`BYTE bFunctioncode;
`
`Iialways OxOl
`
`BYTE bResv;
`
`II
`
`WORD wSequencevalue;
`
`II
`
`DWORD dConnectionHandle;
`
`II
`
`5
`
`/I as returned on start connection
`
`}CVP_END_CONNECTION_REQ,
`
`"CVP_END_CONNECTION_REQ;
`
`fIEND CONNECTION RESPONSE
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`Iialways Ox81
`
`BYTE bStatus;
`
`II
`
`WORD wSequencevalue;
`
`II Same value as in request
`
`II OPEN OR CREATE Fll.E REQUEST
`
`typedef
`
`struct {
`
`BYTE bfunctioncode;
`
`II always Ox02
`
`BYTE bResv; II
`
`WORD wSequenceValue;
`
`II
`
`DWORD dConnectionHandle;
`
`II As returned on START_CONNECT
`
`MDWORD dFileAttributesMask;
`
`II
`
`20
`
`BYTE zFilePath[512];
`
`flnull
`
`terminated file name
`
`}CVP_OPEN_OR_CREATE]ll.E_REQ,
`
`·pCVP _OPEN_O~
`
`~REATE]ILE_REQ;
`
`IIOPEN OR OR CREATE FILE RESPONSE
`
`15
`
`Page 19 of 49
`
`

`

`typedef
`
`struct {
`
`BYTE bFunctionCode;
`
`II always Ox82
`
`BYTE bStatus;
`
`II
`
`WORD wSequenceValue;
`
`II Same value as in request
`
`5
`
`DWORD dVerifiersFileHandle;
`
`II
`
`} CVP ~OPEN _ OR_CREATE ]ILE _RSP, *pCVP _OPEN_OR _CREATE ]ILE _ RSP;
`
`1/ CLOSE FILE REQUEST
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`1/ always Ox03
`
`BYTE bResv;
`
`/1
`
`WORD wSequenceValue;
`
`II
`
`DWORD dConnectionHandle;
`
`II As returned on START_CONNECT
`
`DWORD dVerifiersFileHandle;
`
`II As returned on OPEN_ OR_CREATE
`
`}CVP _CLOSE ]lLE _REQ, *pCVP _CLOSE ]ILE _REQ;
`
`II CLOSE FILE RESPONSE
`
`typedef struct {
`
`:~
`
`BYTE bFunctionCode;
`
`// always Ox83
`
`BYTE bStatus;
`
`II
`
`WORD wSequenceValue;
`
`/1 Same value as in request
`
`20
`
`} CVP_CLOSE_FILE_RSP,
`
`*pCVP~CLOSE]ILE_RSP;
`
`II LOCK REGION REQUEST
`
`typedef struct {
`
`16
`
`Page 20 of 49
`
`

`

`BYTE bFunctionCode;
`
`II always Ox04
`
`BYTE bResv; //
`
`WORD wSequenceValue;
`
`II
`
`DWORD dConnectionHandle; /I As returned on START_CONNECT
`
`5
`
`DWORD dVerifiersFileHandle; II As returned on OPEN_DR_CREATE
`
`MDWORD dSeekValue;
`
`Iloffset
`
`into file
`
`MDWORD dLength;
`
`Iinumber of bytes to lock
`
`}CVP_LOCK_REGION_REQ,
`
`*pCVP_LDCK_REGION_REQ;
`
`IILOCK REGION RESPONSE
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`(( always Ox84
`
`BYTE bStatus;
`
`II
`
`WORD wSequence Value; II Same value as in request
`
`DWORD
`
`dVerifiersLockHandle;
`
`} CVP_LOCK_REGION_RSP, *pCVP_LOCK_REGION_RSP;
`
`I!UNLOCK REGION REQUEST
`
`typedef struct {
`
`BYTE bFunctionCode; II always Ox05
`
`BYTE bResv; /1
`
`20
`
`WORD wSequenceValue;
`
`((
`
`DWORD dConnectionHandle; ((As returned on START_CONNECT
`
`DWORD dVerifiersLockHandle;
`
`// As returned LOCK REGION
`
`17
`
`Page 21 of 49
`
`

`

`} CVP_UNLOCK_REGION_REQ,
`
`*pCVP_UNLOCK_REGION_REQ;
`
`II UNLOCK REGION RESPONSE
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`II always Ox85
`
`5
`
`BYTE bStatus;
`
`WORD wSequenceValue;
`
`If Same value as in request
`
`}CVP _UNLOCK_ REGION _RSP. *pCVP _UNLOCK _REGION_RSP;
`
`II VERIFY REGION REQUEST
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`II always Ox06
`
`BYTE bResv;
`
`II if status is not 0xF1
`
`WORD wSequenceValue;
`
`II
`
`DWORD dConnectionHandle;
`
`II As returned on START_CONNECT
`
`DWORD dVerifiersFileHandle;
`
`II As returned on OPEN_OR_CREATE
`
`5
`
`MDWORD dSeekValue;
`
`II offset
`
`into file
`
`MDWORD dLength;
`
`Iinumber of bytes to verify
`
`BYTE Signature[8];
`
`IICRC adaptation
`
`} CVP _VERIFY _RFGION _REQ. *pCVP _ VERIFY_REGION _REQ;
`
`II VERIFY REGION RESPONSE # 1 (not
`
`locked data)
`
`20
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`II always Ox86
`
`BYTE bStatus;
`
`II
`
`18
`
`Page 22 of 49
`
`

`

`WORD wSequenceValue;
`
`IISame value as in request
`
`1/
`
`1/ VERIFY REGION RESPONSE #2
`
`5
`
`1/ (if signatures did not match and region was locked)
`
`II
`
`typedef
`
`struct {
`
`BYTE bFunctionCode;
`
`II always Ox86
`
`BYTE bStatus;
`
`IIstatus = 0xF1 for this case
`
`WORD wSequenceValue;
`
`II Same value as in request
`
`MDWORD dLength;
`
`II # of bytes that follow
`
`char TheData[];
`
`/I
`
`} CVP_VERIFY_REGION_RSP,
`
`*pCVP_VERIFY_REGION_RSP;
`
`II READ REGION REQUEST
`
`II
`
`(sent only when reading from a locked region)
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`II always Ox07
`
`BYTE bResv;
`
`II
`
`WORD wSequenceValue;
`
`II
`
`20
`
`DWORD dConnectionHandle;
`
`II As returned on START_CONNECT
`
`DWORD dVerifiersFileHandle;
`
`II As returned on OPEN_OR_CREATE
`
`MDWORD dSeekValue;
`
`//offset
`
`into file
`
`19
`
`Page 23 of 49
`
`

`

`WDWORD dLength;
`
`II number of bytes to read
`
`} CVP _READ _REGION_ REQ, *pCVP _

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