`
`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