throbber
W0 97/43717
`
`PCT/US97/07834
`
`-41..
`
`included in client programs that wish to contact handle
`servers.
`
`Caches are used by clients to reduce the load on
`
`the other handle servers, particularly the global handle
`
`in
`server, G. Resolution of handles using caches is,
`The
`
`general, faster than resolution without caches.
`
`caching server is a shared cache to be used by a group of
`clients.
`
`The architecture also allows a cache to be
`
`incorporated within an individual client.
`
`The recommended configuration is for any client,
`
`C, to have an assigned cache, C1. This can be integrated
`
`into the client or can be caching server shared by
`
`several clients.
`
`C1,
`
`order caching server,
`
`itself, may be connected to a higher
`C2.
`
`To avoid resolution involving
`
`many steps,
`
`the recommended configuration is to have no
`
`more than two levels of caches, C1 and C2.
`
`A proxy server 1246 has been developed that acts
`
`as a client to the handle system for use with World Wide
`Web browsers and other clients.
`
`The client passes a
`
`handle to the proxy server which attempts to resolve it.
`
`If the handle can be resolved into one or more URLs, a
`
`URL is returned to the client.
`
`The proxy server is configured as a separate
`
`server to be used by a group of clients.
`
`The recommended
`
`configuration is that every organization that wishes to
`
`use the handle system should provide both a caching and
`
`proxy server for its community.
`
`A proxy server has been developed in consultation
`
`with the National Center for Supercomputing Applications,
`
`the developer of Mosaic, but is intended to work with
`
`other clients that support proxies. Mosaic will be
`
`configured to use the proxy when a handle is specified in
`
`place of a URL. The proxy server will be supported by
`
`future releases of Mosaic.
`
`It is also compatible with
`
`the earlier proxy server developed by CERN.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`GOOG-1002-Page 423 of 841
`
`GOOG-1002-Page 423 of 841
`
`

`
`WO 97143717
`
`PCT/US97/07834
`
`-42..
`
`We now describe how a client, C, resolves any
`handle, h.
`Note that (a) each handle server can be
`
`implemented as one or more server computers;
`
`(h) checks
`
`are required to prevent looping through indirect handles;
`
`(c)
`
`the client may not have access permissions for all
`
`local handle servers;
`
`(d)
`
`the client request may ask for
`
`all the data in a handle record or data of specified
`
`types only;
`
`(e) because the local handle servers are
`
`independently managed, the client may encounter
`
`inconsistent data or unacceptably poor response from a
`server .
`
`If the client, C,
`
`is not attached to any caching
`
`server, it uses the following steps to resolve a handle,
`h.
`
`1.
`
`C sends a query to G.
`If the handle record for h is stored in G, G
`resolves h.
`
`Otherwise, G returns the address of P,
`
`the primary
`
`handle server of naming authority, n.
`
`2.
`
`If h is not yet resolved, C sends h to P.
`
`If h is stored in P and C has the correct access
`
`permissions, P resolves h.
`
`Otherwise,
`
`if there is an indirect handle to
`
`another handle server, M, which stores h, P sends the
`
`client the address of M.
`3.
`
`If h is not yet resolved,
`
`h to M.
`
`the client, C, sends
`
`If the client has the correct access permissions,
`
`M resolves_h.
`
`(If C does not have permission, it should
`
`try other handle servers that hold the handle.)
`
`If the client, C,
`
`is connected to a cache, C1,
`
`resolution of h follows these steps:
`
`1.
`
`The client, C, asks C1 to resolve h.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`If the handle record of h is in the cache,
`handle record is returned to C.
`
`the
`
`GOOG-1002-Page 424 of 841
`
`GOOG-1002-Page 424 of 841
`
`

`
`W0 9_7/43717
`
`PCT/US97/07834
`
`-43-
`
`2. Otherwise, if the identity of P,
`
`the primary
`
`handle server of naming authority n,
`
`is stored in C1, C1
`
`resolves the handle following steps 2 and 3 above in the
`
`description of resolution without caching.
`
`3.
`If the handle has not been resolved,
`connected to a higher cache, C2, C1 asks C2 to resolve
`
`and C1 is
`
`both h and P,
`C1's cache.
`
`and pass the results to C1 to be saved in
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`If h and P are not in C2’s cache,
`
`the request is
`
`passed to the next higher cache, until the handle is
`
`resolved until the highest cache is reached.
`
`(The
`
`recommended configuration is to have no more than two
`
`levels of cache.)
`
`4.
`
`If there is no higher cache,
`
`then the cache
`
`sends a request to G asking for the resolution of h and
`
`P.
`
`The resolution algorithm then continues as in the
`
`description of resolution without caching.
`
`The handle server system is intended to be a means
`
`of universal basic access to registered digital objects.
`
`In the worst case, a user can present a handle to a
`
`handle server and be advised of some repository which an
`
`authorized party has asserted contains the digital object
`
`designated by the handle.
`
`The handle server is not meant
`
`to be the only, or even primary, means,
`
`to locate
`
`repositories. Primary access may be provided locally and
`
`also by value-added service providers,
`
`likely in a
`
`variety of different and possibly incompatible ways.
`
`Users interacting with such services may not encounter
`
`handles; and such services may interact with repositories
`
`via RAP or via protocols that do not involve handles.
`
`Handle servers provide a number of services,
`
`three
`
`of which are RESOLVE,
`
`INSERT, and DELETE.
`
`A party that
`
`is authorized to insert, delete and otherwise change
`
`handle entries for a particular naming authority is
`
`called a handle administrator.
`
`A naming authority will
`
`GOOG-1002-Page 425 of 841
`
`GOOG-1002-Page 425 of 841
`
`

`
`W0 9_7/43717
`
`PCT/US97/07834
`
`‘
`
`-44..
`
`generally designate one or more repositories to act as
`
`handle administrators on its behalf. This designation
`
`will be made known by the naming authority to the handle
`
`server system.
`
`5 RE§OLVE
`
`A handle is sent to a handle server to locate
`
`network addresses of repositories containing that object.
`
`The handle is first mapped to locate the handle server
`
`from the handle directory server table but is not
`
`10 otherwise interpreted.
`
`one can also supply a handle to a
`
`separate system, which invokes the above procedures to
`
`find the stated object. Local handle servers may use any
`technique to do the mapping.
`The handle servers
`
`maintained as part of the infrastructure map the handles
`
`15 by hashing them.
`
`To resolve a handle, a handle server receives as
`
`input a handle and returns some or all of the fields of
`
`typed data in the corresponding handle record.
`
`The
`
`client can request that all data fields in the handle
`
`20
`
`record he returned or only those fields that contain data
`
`of a given type.
`
`No guarantee is made that the identified
`
`repositories will provide the designated object. Rather,
`
`the user is assured only that the specified repositories
`
`25 are where authorized maintainers of repository services
`
`have indicated particular digital objects reside.
`
`Since a handle is just a unique string, it can be
`
`mapped to an actual repository by any of several
`
`mechanisms. including a mechanism that attempts to
`
`30
`
`interpret the string. Repository names are not actual
`
`network addresses;
`
`they must first be mapped to network
`
`locations.
`
`The method for accomplishing these mappings
`
`is not specified.
`
`The handle service is one available
`
`means for both kinds of mappings; it would specify at
`
`35
`
`least the location of the interface that supports the RAP
`
`GOOG-1002-Page 426 of 841
`
`GOOG-1002-Page 426 of 841
`
`

`
`W0 9_7/43717
`
`PCT/US97/07834
`
`‘
`
`-45..
`
`protocol for a given repository. There may also be a
`
`need to explicitly provide a country identifier for
`
`repositories, naming authorities and/or originators.
`
`For
`
`the present, however, country identifiers are be omitted.
`
`when a repository is identified by a handle
`
`server,
`
`it will be most efficient to map the handle
`
`directly into the network address (or addresses) of the
`
`repository. This mapping avoids having to do a double
`
`lookup from repository name to repository location.
`
`However, if the location of the repository were to
`
`change,
`
`the handle server would have to be notified so it
`
`could make the corresponding changes.
`
`It is possible
`
`that certain repository names may resolve to broadcast
`
`addresses to locate specific machines.
`
`This might be the
`
`case where a single repository consists of multiple
`The
`
`machines on a local area network at a given site.
`
`handle administrator may determine whether to store IP
`
`addresses or domain names or other information in the
`
`handle server.
`
`The entries are typed and therefore one
`
`or more of the above information types may be provided by
`the administrator for retention in the handle server.
`
`IH§EBEL12ELEIEl
`
`Information associating handles with network
`
`services are inserted into (deleted from)
`
`the handle
`
`server system by the handle administrator or other
`
`parties authorized by it.
`
`Such authorized parties
`
`include repositories of record. The repository of record
`
`is presumed to make known to the handle server system
`
`that it contains (or no longer contains) a particular
`
`digital object some reasonable time after the digital
`
`object is deposited in (withdrawn from) it. Similarly,
`
`the repository of record would make known to the handle
`
`server system the identity of other repositories which it
`The handle
`
`authorizes to store a given digital object.
`
`server system may perform certain administrative
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`GOOG-1002-Page 427 of 841
`
`GOOG-1002-Page 427 of 841
`
`

`
`W0 9,7/43717
`
`PCT/U S97/07834
`
`-45..
`
`functions upon receipt of unauthorized requests. In
`
`addition,
`
`some form of reporting may be desirable to
`
`insure that entities that misbehave can be detected.
`
`The handle server system is intended as a safety
`
`net of information about where digital objects reside.
`
`There will no doubt be other, valuable services that
`
`provide information to users about the location of
`
`digital objects in repositories.
`
`10
`
`15
`
`We do not require repositories to provide a
`
`description of their contents.
`
`Repositories may not
`
`house coherent collections,
`
`and hence, querying or
`
`searching a repository may be a service appropriate only
`not to a user.
`
`to the repository administrator,
`
`Presumably,
`
`such capabilities will exist in the form of
`
`value-added services.
`
`It is such services, rather than
`
`repositories per se, that users would interrogate to
`such
`
`identify digital objects of a certain nature.
`
`services may, of course,
`
`be offered by repositories
`
`20
`
`themselves, especially in the case when one is intended
`to house a coherent collection. However, such a server
`
`is not a requirement of a well-behaved repository.
`
`In one example,
`
`the handle server directory 59
`
`holds a table 149 which associates hash ranges 150 with
`
`25
`
`30
`
`35
`
`domain names of handle servers 58 (Figure 7).
`
`Obtaining Egintgrs from g flanglg
`
`Given a handle,
`
`the following steps, shown in
`
`Figure 8, are followed to obtain a set of pointers
`associated with the handle.
`
`Inia first step 170, a client system downloads the
`
`table that associates hash ranges with handle server
`
`domain names from the handle server directory for future
`use.
`The client also can omit this step if it has
`
`previously stored the
`
`table;
`
`frequent changes in the
`
`table may necessitate
`
`doing this every time.
`
`In a later
`
`step 172,
`
`assume the system obtains a handle for which
`
`GOOG-1002-Page 428 of 841
`
`GOOG-1002-Page 428 of 841
`
`

`
`W0 9_7l437 1 7
`
`PCTIUS97/07834
`
`-47..
`
`pointers are desired.
`
`The system then generates the hash
`
`code for the handle using a predetermined hashing
`
`algorithm (step 174) and consults the hash range/hand1e-
`
`server-domain-name table to determine the domain name of
`
`the appropriate handle server (step 176).
`
`The system
`
`subsequently sends the handle to the handle server as
`
`part of a request pointer information UDP packet (step
`
`178).
`
`10
`
`15
`
`20
`
`The handle server then returns its response to the
`
`requesting system.
`
`If the handle server found the
`
`pointers, a list of pointers is returned (step 180).
`
`This could include pointers to use one or more
`If the handle was
`
`repositories and one or more RMS's.
`
`sent to the wrong handle server,
`
`it returns a not-
`
`responsible-for-handle message (step 182).
`
`In this case,
`
`the client system should download the hash range/handle-
`
`server—domain—name table from the handle server directory
`
`again and attempt the mapping again.
`
`The requester will
`
`determine how many times to try before giving up (and
`
`this same approach is used in other similar situations
`
`described below).
`
`If the request was sent to the correct handle
`
`server ,
`
`but the requested handle could not be found,
`
`the
`
`handle server returns a handle-not-found message (step
`
`25
`
`184).
`
`Overview of Application for Eights gegistratign
`
`There are two mechanisms used to register rights:
`
`an applicant may apply for a rights registration on an
`
`object which is located on his own system 42 or on an
`
`object which has been stored in a repository 36.
`
`In order to submit and process a rights
`
`registration application the following general steps
`
`(described in more detail later) must occur.
`
`First, as seen in Figure 9,
`
`the rights
`
`registration application is created, and the application
`
`30
`
`35
`
`GOOG-1002-Page 429 of 841
`
`GOOG-1002-Page 429 of 841
`
`

`
`W0 97/43717
`
`PCTIUS97/07834
`
`-43-
`
`and the associated object are submitted to the
`
`registration system.
`
`The steps required to perform this
`
`depend on the location of the digital object.
`
`In
`
`registering an object which is located on the applicant's
`
`own system,
`
`the applicant first makes the object
`
`available to his own system (if it was created somewhere
`
`else)
`
`(step 60).
`
`The applicant then runs a rights
`
`registration program in a step 62, and he fills in a
`The
`
`rights registration application template.
`
`application and the associated object are electronically
`
`mailed (as a PEM message)
`
`to the registration system
`
`(step 64), which performs simple syntactic checking on
`
`the application (step 66), and verifies that the
`
`associated object has not been corrupted (step 68).
`
`If the object has not yet been placed in the
`
`repository,
`
`the applicant first places the object in the
`
`repository (step 70).
`
`The applicant then runs the rights
`
`registration program, and he fills in the copyright
`The
`
`registration application template (step 62).
`
`application and
`
`the object's handle are electronically
`
`mailed (PEM)
`
`to
`
`the registration system (step 64), which
`
`performs simple
`
`syntactic checking on the application
`
`(step 66).
`
`The
`
`registration system then retrieves the
`
`object from the
`
`repository in a step 72 and verifies that
`
`the retrieved associated object has not been corrupted
`
`(step 68).
`
`After the registration system has checked the
`
`object, it creates an initial Receipt In Progress (RIP)
`
`record and sends it to the tracking system (step 74).
`
`The tracking system verifies that the account number
`
`presented in the record is valid and that sufficient
`
`funds exist in the account to process the application
`
`(step 76).
`
`The application and the associated object can now
`
`be accessed by the rights examiner, by running an
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`GOOG-1002-Page 430 of 841
`
`GOOG-1002-Page 430 of 841
`
`

`
`W0 9_7/43717
`
`PCTIUS97/07834
`
`-49-
`
`examiner's user interface program on the examiner's
`
`workstation (step 78). Once the examiner approves the
`
`application,
`
`the registration system assigns a
`
`registration number, and the system creates the rights
`
`registration certificate (step 80).
`
`A copy of the
`
`certificate is mailed electronically to the rights
`
`registrant.
`
`An updated RIP record which shows the
`
`registration application's final status is subsequently
`
`sent to the tracking system (step 82).
`
`Registering an Objegt not in a Repository
`
`The detailed steps for registering without first
`
`depositing a copy in a repository are shown in Figures 10
`
`through 13.
`
`First,
`
`the user 42 (the rights applicant)
`
`generates a digital signature for the object (step 250)
`
`using a private key and makes the object 43 (in one
`
`file), digital signature 45 (in a second file), and
`
`public key certificate chain 47 (in a third file)
`
`available to the UA system 34 (step 252).
`
`The UA user
`
`supplies rights registration application information 49
`If the user does
`
`by filling out a form on the screen.
`
`not fill in the publication date field,
`
`then the object
`If
`
`is considered unpublished by the rights registrar.
`
`the field is filled in,
`
`then the object is treated like a
`
`published work.
`
`The UA user digitally signs the rights
`
`application information in a step 254.
`
`10
`
`15
`
`20
`
`25
`
`The UA then sends a PEM/MIME message 202 to the
`
`registration system 40.
`
`(MIME is a multimedia electronic
`
`mail specification to allow for multimedia objects to be
`
`30
`
`handled.)
`
`The message contains the object,
`
`the user's
`
`digital signature 45 over the object,
`
`the public key
`
`certificate chain 47 for the user,
`
`the rights
`
`registration application 49 information, a digital
`
`signature (not shown) over the rights registration
`
`35
`
`application information, and the UA user's public key
`
`GOOG-1002-Page 431 of 841
`
`GOOG-1002-Page 431 of 841
`
`

`
`W0 9_7/43717
`
`PCT/US97/07834
`
`-50..
`
`certificate chain (not shown)
`
`(step 256).
`
`The entire
`
`message is signed by the UA user.
`
`The registration system 40 receives the PEM/MIME
`
`message. An entry recording the receipt of the message
`
`is placed into a log file in a step 258.
`
`The registration system verifies that it accepts
`
`rights applications from the distinguished name of the UA
`
`user (step 260).
`
`If not, it returns a message to the UA
`
`user, and the verification failure is recorded in the log
`
`file (step 262).
`
`The registration system attempts to validate the
`
`digital signature over the entire message in step 264.
`
`If validation fails (i.e., the decrypted hash value does
`
`not match the computed message hash or one of the
`
`certificates in the public key certificate chain has been
`
`revoked),
`
`a message is returned to the UA user.
`
`The
`
`validation failure is recorded in the log file (step
`262) .
`
`If the validation succeeds,
`
`then an application
`
`received message is sent to the UA user (step 266).
`
`The registration system attempts to validate the
`
`rights registration information (only simple checks are
`
`performed)
`
`in step 268.
`
`If validation fails, a message
`
`is returned to the UA user. The validation failure is
`
`recorded in the log file (step 262).
`
`If the object was included in the PEM/MIME message
`
`10
`
`15
`
`20
`
`25
`
`(step 270),
`
`the digital signature over the object (step 272).
`
`the registration system attempts to validate
`If
`
`validation fails,
`
`a message is returned to the UA user.
`
`The validation failure is recorded in the log file (step
`
`30
`
`262).
`
`If the validations of the application information
`
`and the object (if it was included in the PEM/MIME
`
`message) were successful,
`
`then the following are entered
`
`in step 274 into the registration system's work in
`
`35
`
`progress database:
`
`the application information; the
`
`GOOG-1002-Page 432 of 841
`
`GOOG-1002-Page 432 of 841
`
`

`
`W0 9‘7/43717
`
`PCT/US97/07834
`
`’
`
`-51-
`
`digital signatures; the public key certificate chains;
`
`and the object (if available).
`
`The entry into the work
`
`in progress database is recorded in the log file.
`
`If the PEM/MIME message did not include the object
`
`5
`
`(step 276),
`
`the registration system attempts to retrieve
`
`a copy of it in step 278.
`
`If the attempt fails, a
`
`message is sent to the UA user (step 280).
`
`The
`
`application information, digital signatures, and public
`
`key certificates are removed from the work in progress
`
`10 database. Entries are made in the log file recording the
`
`retrieval failure and the removal of the information from
`
`the work in progress database in step 282.
`
`If the retrieval attempt succeeds,
`
`then the
`
`registration system attempts to validate the digital
`
`15 signature over the object in step 284.
`
`If validation
`
`fails, a message is sent to the UA user (step 280).
`
`The
`
`application information, digital signatures, and public
`
`key certificates are removed from the work in progress
`
`database. Entries are made in the log file recording the
`20 validation failure and the removals from the work in
`
`progress database (step 282).
`
`If the object has been published (the rights user
`
`filled in the published date field)
`
`(step 286),
`
`then the
`
`object is placed in the acquisition queue in step 288.
`
`25
`
`The registration system now prepares an initial
`
`Receipt In Progress (RIP) record (step 290).
`
`The
`
`registration system converts the information located in
`the title and claimant name fields in the registration
`
`request into the title and claimant name fields in the
`
`30 RIP record.
`
`The following conversions are performed:
`
`title words that are located in a stop word list are
`deleted and title words that are located in an
`
`abbreviated terms list are abbreviated.
`
`A bar—code number (or other identifier) is
`
`as assigned to the registration request (step 290).
`
`A
`
`GOOG-1002-Page 433 of 841
`
`GOOG-1002-Page 433 of 841
`
`

`
`W0 9,7/43717
`
`PCT/US9 7/07834
`
`-52-_
`
`verify and debit request, which contains the bar-code
`
`number
`
`(and other RIP record information)
`
`is formatted
`
`and sent to the tracking system via the File Transfer
`
`Protocol
`
`(FTP)
`
`in step 292.
`
`The tracking system verifies the account (step
`294) and debits the requested amount from the account.
`
`If the account is not valid,
`
`the tracking system will
`
`send an invalid account number presented message to the
`registration system (step 296).
`If the account is valid,
`but insufficient funds exist for this transaction (step
`
`1O
`
`298),
`
`then the tracking system will send an insufficient
`
`In
`funds message to the registration system (step 296).
`either error case,
`the validation failure is recorded in
`
`the registration system's log file; and the rights
`
`registration application is removed from the works in
`
`progress database (step 282).
`
`If the object was
`
`unpublished, it is deleted from the registration system
`
`in step 300.
`
`If a published object and registration
`
`request is resubmitted, it is possible that a object
`
`might be placed in the acquisition queue multiple times.
`
`Manual procedures catch the duplicate entries.
`
`If the tracking system 46 (Figure 10) successfully
`
`performed the account verification and debit processing,
`
`it sends an account is OK message to the registration
`
`system in step 302.
`
`the tracking system prepares an
`
`initial RIP record and places it in it's database.
`
`If
`
`the object was unpublished, a copy of it is placed into
`
`the acquisition queue.
`
`The registration system moves the registration
`request to the examiner queue database in step 304.
`The
`registrar user's workstation 50 (Figure 10) now has
`
`access to the registration request.
`
`The examiner uses
`
`to add
`workstation 50 to view the object on the screen,
`his name to the examined by line on the application form
`
`and to record the class designation for the rights
`
`15
`
`20
`
`25
`
`30
`
`35
`
`GOOG-1002-Page 434 of 841
`
`GOOG-1002-Page 434 of 841
`
`

`
`WO 97/43717
`
`PCT/US97l07834
`
`‘
`
`-53-.
`
`registration (step 306).
`
`The converted form of the
`
`author and title (as stored in the RIP record) are also
`
`shown to the examiner.
`
`If the examiner approves the application (step
`
`5 308), an examination—is-approved message is sent from the
`
`workstation to the registration system in a step 310.
`
`The registration system assigns a registration number
`
`(step 312), and the system creates and digitally signs
`
`the rights registration certificate, which includes the
`
`10 registration number and the date on which registration
`
`was granted (step 314).
`
`The rights registration
`
`certificate is sent in a PEM message to the UA user in a
`
`step 314. The certificate may be sent directly to the UA
`
`or indirectly via the repository. The certificate is
`
`15 archived on the registration system (step 312).
`
`The
`
`certificate also could be stored on a system that retains
`
`the scanned images of the manually created certificates.
`
`If the examination results in the rights
`
`registration application being rejected,
`
`the examiner
`
`20 uses the workstation to send a rights registration
`
`rejection PEM message via the UA to the applicant
`
`explaining the rejection (step 318).
`
`If the registration was approved or denied, an
`
`updated RIP record is forwarded to the tracking system in
`
`25 a step 320.
`
`once the tracking system has added the
`
`record to its database, it sends a RIP-record-update-OK
`
`message to the registration system (step 322).
`
`In step 324,
`
`the registration system moves the
`
`The
`registration request to the cataloging system.
`30 cata1oger's workstation 57 (Figure 10) now has access to
`
`this registration request.
`
`Using a connection to the cataloging system,
`
`the
`
`cataloger creates the cataloging information in step 326.
`
`When the task is finished,
`
`the workstation sends a
`
`35
`
`finished catalog message to the registration system (step
`
`GOOG-1002-Page 435 of 841
`
`GOOG-1002-Page 435 of 841
`
`

`
`W0 97/4371 7
`
`PCT/US97/07834
`
`-54..
`
`328). The registration system places a registration-
`app1ication-processing-complete message in the log file
`(step 330).
`
`aci
`
`'ec
`
`'
`
`o a
`
`e sit
`
`5
`
`Alternatively,
`
`the rights holder may choose first
`
`to place an object into a repository, as shown in Figures
`14 through 17.
`
`the user 42 makes the object
`In a first step 350,
`(object) available to the UA 34.
`The UA then sends a
`
`10
`
`request for a handle to a handle generator system 36
`(step 352).
`
`The handle generator system sends a handle to the
`
`UA system (udp)
`
`in step 354.
`
`The UA sends a PEM message to the rights manage-
`15 ment system 38 containing the handle, any non—simp1e
`
`terms and conditions for obtaining a copy of the object
`(which must include free access to the object for the
`
`registrar), and the list of distinguished names of those
`
`who are allowed to make changes to the information
`
`20
`
`(stored in the RMS) which is associated with the handle
`
`(step 356).
`
`The PEM message is signed by the UA user.
`
`The RMS verifies that it accepts new submissions
`
`from the distinguished name of the UA user in step 358.
`
`If not,
`
`the RHS sends an invalid—distinguished-name PEM
`
`25 message to the UA user and discards the contents of the
`
`received message (step 360).
`
`The RMS validates the digital signature on the
`
`received PEM message (step 362).
`
`If the validation
`
`fails, the RMS sends an invalid-digital-signature PEM to
`the UA user and discards the contents of the received
`
`30
`
`message (step 360).
`
`The RMS verifies that it does not already have a
`
`set of terms and conditions stored for the handle (step
`364).
`If it does, it sends a terms-and-conditions-
`
`GOOG-1002-Page 436 of 841
`
`GOOG-1002-Page 436 of 841
`
`

`
`WO 97143717
`
`PCT/US97/07834
`
`-55..
`
`a1ready—registered PEM to the UA user and discards the
`
`contents of the received message (step 360).
`The RMS stores the handle and the associated terms
`
`and conditions (step 366) and sends a confirming PEM to
`
`the UA user (step 368).
`
`In a step 370,
`
`the UA system computes the digital
`
`signature over:
`
`the object's handle; a date/time group
`
`(the nominal date/time of submission of the object to the
`
`repository); and the object.
`
`The UA system sends a PEM/MIME message to the
`
`repository 36 (Figure 14) containing the object's handle,
`
`the submission date/time group,
`
`the object (or the
`
`information needed to retrieve a copy of the object),
`
`the
`
`UA user's digital signature over the above,
`
`the UA user's
`
`public key certificate chain,
`
`the simple terms and
`
`conditions for the object, if any, and the distinguished
`
`name or names of the RMS(s) holding the non—simple terms
`
`and conditions for the object,
`
`if applicable.
`
`The entire
`
`message is signed by the UA user (step 372).
`
`The repository verifies that it accepts object
`
`submissions from the distinguished name of the UA user in
`
`a step 374.
`
`If not,
`
`it sends an invalid-distinguished-
`
`name PEM message to the UA user and discards the received
`
`message (step 376).
`
`The repository validates the digital signature
`
`over the entire message in step 378.
`
`If the validation
`
`fails, the repository sends an invalid-digital-signature
`
`PEM message to the UA user and discards the received
`
`message (step 376).
`
`If the object was not included in the received
`
`PEM/MIME message (step 380),
`
`the repository attempts to
`
`retrieve a copy of the object (e.g., via anonymous FTP)
`
`in a step 382.
`
`If retrieval fails,
`
`the repository sends
`
`an object-retrieval-failed PEM message to the UA user and
`
`discards the received message (step 376).
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`GOOG-1002-Page 437 of 841
`
`GOOG-1002-Page 437 of 841
`
`

`
`W0 9_7/43717
`
`PCT/US97l07834
`
`-55-
`
`The repository validates the UA user's digital
`signature over the handle, nominal submission date/time
`group,
`the object (step 384), and the reasonableness of
`
`the submission date/time group (not in the future, not
`too far in the past)
`
`If either of these
`
`(step 386).
`
`validations fail, the repository sends an invalid-
`
`submission PEM to the UA user and discards the received
`
`message (step 376).-
`
`10
`
`15
`
`20
`
`In step 388,
`
`the repository stores the object's
`
`handle,
`
`the submission date/time group,
`
`the object,
`
`the
`
`UA user's digital signature over the above,
`
`the UA user's
`
`public key certificate chain,
`
`the simple terms and
`
`conditions for the object, if any,
`
`the distinguished name
`
`of RMS, if applicable,
`
`and other properties.
`
`The
`
`repository then computes its own digital signature over
`
`the handle,
`
`the submission date/time group from the
`
`received message and the object (step 390).
`
`In step 392,
`
`the repository sends a PEM to the UA user containing the
`
`handle,
`
`the repository's digital signature, and the
`
`repository's public key certificate chain.
`
`In step 394,
`
`the UA system verifies the
`
`repository's digital signature over the handle, date/time
`
`group,
`
`and object.
`
`"The UA system then stores the handle,
`
`25
`
`the nominal submission date/time group, the object,
`repository's digital signature, and the repository's
`
`the
`
`public key certificate chain (step 396).
`
`The UA system computes the hash of the object's
`
`handle using the handle system hashing function (step
`
`398).
`
`The UA system then looks up the domain name of the
`
`handle server 38 responsible for the handle in its cached
`
`copy of the hash value/handle server table (step 400).
`
`In step 402,
`
`the UA system sends a PEM to the
`
`handle server containing the handle, and one or more
`
`pairs of domain name of repository and domain name of the
`
`RMS, and a list of distinguished names of persons who are
`
`30
`
`35
`
`GOOG-1002-Page 438 of 841
`
`GOOG-1002-Page 438 of 841
`
`

`
`wo 9,7/43717
`
`' PCT/US97/07834
`
`-57-
`
`permitted to change the pairs of domain names associated
`with the handle.
`
`The message is signed by the UA user.
`
`The handle server receives the PEM message and
`
`verifies that it is responsible for the handle in step
`
`404.
`
`If not, it sends an invalid—handle-server—selected
`
`PEM to the UA user and discards the other information
`
`(step 406).
`
`If the UA system receives an invalid-handle-
`
`server—selected rejection message from the handle server,
`
`it downloads a new copy of the hash value/handle server
`
`table from the handle server directory 59 (Figure 15)
`
`(step 408) and repeats steps 398 through 404.
`
`If the handle server is responsible for the handle
`
`submitted by the UA system, it validates the digital
`
`signature over the PEM message in step 410. If the
`
`validation fails,
`
`the handle server sends an invalid-
`
`digital—signature PEM message to the UA user and discards
`
`the other information (step 412).
`
`The handle server verifies that it accepts
`
`submissions from the distinguished name of the UA user in
`
`step 414.
`
`If not, the handle server sends an invalid-
`
`distinguished-name PEM message to the UA user and
`
`discards the other information (step 412).
`
`The handle server verifies the syntax of the pairs
`
`of domain names submitted with the handle in step 416.
`
`If it detects any errors, it sends an invalid-hand1e-
`
`submission-record syntax PEM message to the UA user and
`
`discards the other information (step 412).
`
`The handle server stores the handle,
`
`the pairs of
`
`domain names, and the list of distinguished names (step
`
`418) and sends a PEM acceptance message to the UA user
`
`(step 420).
`
`10
`
`15
`
`20
`
`25
`
`30
`
`gggistering gn Qgject Already in a gepository
`
`After the object has been deposited, an
`
`application to register may be submitted (Figures 18
`
`35
`
`through 22).
`
`GOOG-1002-Page 439 of 841
`
`GOOG-1002-Page 439 of 841
`
`

`
`W0 9_7/43717
`
`PCT/U S97I07834
`
`-53-
`
`The user (the rights applicant) 42 first generates
`a digital signature for the object (step 450) and makes
`the digital signature (in a file), and public key
`certificate chain (in a second file) available to the UA
`
`system 34 (step 452).
`
`The UA user supplies the rights registration
`
`application information by filling out a form on the
`
`screen in step 454. This includes the handle

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