`Exhibit 1012
`
`Exhibit 1012
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`ZTE Corporation and ZTE (USA) Inc.
`ZTE Corporation and ZTE (USA) Inc.
`
`

`

`.0)
`
`Europiisches Patentamt
`
`European Patent Office
`
`Office européen des brevets
`
`@ Publication number:
`
`0 268 139
`
`A2
`
`®
`
`EUROPEAN PATENT APPLICATION
`
`@ Application number: 87116179.0
`
`@ Int CL“: G05F 1/00
`
`@ Date offiling: 03.11.87
`
`
`
`@ Priority: 05.11.86 US 927299
`
`,
`Date of publication of application:
`25.05.88 Bulletin 88/21
`
`® Applicant: lntematlonal Business Machines
`Corporation ‘
`Old Orchard Road
`Armonk, N.Y. 10504(US)
`
`Designated Contracting States:
`DE FR GB iT
`
`'
`
`@ inventor: Comerford, Liam David
`Box 191 Rd. No. 1 10 Valley Road
`Carmel. N.Y. 10512(US)
`Inventor: White, Steve Richard
`7 Park Avenue Apt. 33
`New York, N.Y. 10016(US)
`
`
`
`Flepresentative:1'eufel, Fritz, Dipl.-Phys;et al
`iBM Deutschland GmbH. Europ‘a’ische
`Patentdienste Postfach 265
`
`D-8000 Mfinchen 22(DE)
`
`® Manipulating rights-to-execute in connection with a software copy protection mechanism.
`
`FIG.2
`
`it;
`g‘:
`= g;
`is“
`‘73.;
`
`
`
`@ A software asset protection mechanism segre-
`gates the right to execute software from the software
`itself. The rights to execute, when installed on a
`composite computing system, (10,20) are stored in a
`coprocessor element (20) of the composite ccmput-
`ing system. The software asset protection mecha-
`nism is enhanced as described herein by providing
`for the manipulation of those rights to execute. More
`particularly, the rights to execute can be conditioned
`at least in terms of a valid period of execution or a
`valid number of executions. The rights to execute
`can be safely transferred from one coprocessor to
`“another. or can be returned to the software vendor.
`<Finally, a method of backing up the rights to execute
`mto provide the user with the rights to execute in case
`”the coprocessor element of the composite comput-
`ing system fails.
`
`1 E
`
`P0268
`
`Xerox Copy Centre
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1012-00001
`
`

`

`1
`
`D 268 139
`
`an
`
`MANIPULATING RIGHTS-TO-EXECUTE IN CONNECTION WITH A SOFTWARE COPY PROTECTION MECHA-
`NISM
`
`Technical Field
`
`The invention is in the field of data processing.
`especially in connection with a software copy pro~
`tection mechanism. That mechanism restricts soft-
`ware, distributed on a magnetic disk or other me-
`dium, for use on any computer which is associated
`with an authorized, physically secure coprocessor
`where the mechanism does not interfere with the
`user creation of “backup“ copies; but the protec-
`tion is not compromised by any such “backup"
`copies. The present
`invention is particularly di-
`rected at manipulating a right-to-execute which is a
`distinguishing characteristic of that copy protection
`mechanism.
`
`Background of‘the invention
`
`The basic copy protection mechanism is de-
`scribed in copending application [Y0985-091]: this
`mechanism separates the software which is to be
`protected from the right to execute that software.
`To provide security and implement the mechanism,
`each computer on which a protected application is
`to run (hereinafter referred to as a host) is asso=
`ciated with a logically and physically secure
`coprocessor. When installed in the coprocessor.
`the right-to-execute a particular protected applica-
`tion exists in the form of a software decryption key
`called an application key (AK). 30 long as the
`software decryption key AK is retained in the per-
`manent memory of
`the coprocessor,
`the corre-
`sponding protected software can be executed on
`the composite system including the host and
`coprocessor. The software copy protection mecha-
`nism has the advantage that it negligibly interferes
`with present and contemplated software distribution
`techniques,
`it allows the user to make unlimited
`numbers of "backup" copies and it does not re-
`quire any two-way communication between the
`user and the software vendor. This is supported by
`distribution of an authorization to the coprocessor
`to accept a right to execute provided in the form of
`a hardware cartridge (or token). Furthermore, the
`user need only employ the token the first time the
`protected application is run in order to transfer the
`right to execute, which is represented by the un-
`used token,
`to the coprocessor. Thereafter,
`the
`token may be discarded and it is thereafter totally
`unnecessary to maintenance or use of the right to
`execute.
`'
`
`The invention described in copending applica-
`
`10
`
`15
`
`20
`
`25
`
`'30
`
`35
`
`4O
`
`45
`
`50
`
`tion [Y0985-091] does not address manipulation of
`the right to execute (other than describing how a
`user may first acquire it). nor does it describe the
`possibility of conditioning the right to execute. The
`present
`invention is particularly directed at con-
`ditioning or manipulating or transferring the right to
`execute which exists in a coprocessor.
`in particular, the present invention prevides the
`capability of safely transferring the right to execute.
`The right to execute may be transferred to another
`coprocessor or may be merely transferred outside
`the coprocessor for external storage. In either event
`it is essential that the process of transferring the
`right to execute not generate or allow spurious or
`duplicate rights to execute which would of course
`defeat the purpose of the copy protection mecha-
`nism. As described herein, the transfer of a right to
`execute can be indirect,
`through the use of a
`transfer set (which in many respects is identical to
`the distribution set through which the right to ex-
`ecute was acquired) or direct via a coprocessor to
`coprocessor communication link. Safety is main-
`tained even though the communication is unse-
`cured in the sense that the transfer transaction may
`be observed.
`
`The present invention also provides techniques
`for conditioning the right to execute. For example,
`the right to execute might be conditioned by a time
`period (a right to execute which exists up until a
`cut-off date and/or time) or it could be conditioned
`based on the number of times it is invoked (for
`example the vendor could sell a user the right to
`execute the protected application ten times). As will
`be described,
`the right
`to execute can be con-
`ditioned on any other parameter so long as it can
`be measured by the coprocessor to the satisfaction
`of the source of that right to execute (the software
`vendor). The availability of conditioned rights to
`execute provides the software vendor with addi-
`tional flexibility and it further opens up the possibil-
`ity, for the first time in the software field, of a truly
`safe "return” policy. For obvious reasons, a soft-
`ware vendor, using today's software distribution
`techniques, will be in jeopardy of giving his pro-
`ducts away free if he accepts the "return" of soft-
`ware for full purchase credit. The vendor has no
`way of verifying with present distribution tech-
`niques whether or not
`the user has already du-
`plicated the software so that after the return the
`user could still maintain a fully usable copy of the
`application. Using the principles described herein,
`however,
`the software vendor can implement a
`“return" policy and be assured that if a user re-
`turns the software, the user no ionger retains an
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1012-00002
`
`

`

`3
`
`,
`
`o 268 139
`
`"
`
`4
`
`I)
`
`executable copy.
`Because the software copy protection mecha-
`nism operates in the real world, with real world
`devices, and because the distinct right to execute
`exists in the form of a cryptographic key stored in
`the permanent memory of a coprocessor,
`it
`is
`necessary to address
`the possibility that
`the
`coprocessor storing the right to execute may fail.
`Such failure should not result in the complete loss
`of the user's rights to execute, and the present
`invention provides apparatus and methods for se-
`curing the user against
`the loss of the right
`to
`execute in the event his coprocessor does fail.
`Much as in the case with moving or transferring the
`right to execute, any hardware “backup" technique
`(available in case a coprocessor fails) should not
`have the property of being useful to generate spur-
`ious rights to execute. The hardware backup meth~
`ed provides minimal opportunity (and significant
`disincentive)
`for
`improperly multiplying rights to
`' execute.
`
`Summary of the invention
`
`The invention meets these and other objects as
`described below.
`-
`
`Conditioned Right-to-Execute
`In order to condition the right to execute, in a
`system such as described in our copending ap-
`plication [mess-091], there must be:
`1) a statement of
`the condition (or condi-
`tions) under which the application software may (or
`may not) be allowed to execute fully, and
`2) some objective criteria against which the
`condition or conditions can be measured. and -
`3) a software program which can test the
`conditions against
`the criteria and act
`in a way
`determined by results of that test.
`These objectives must be met in a way which
`is secure against attempts of the user, or anyone
`else not specifically authorized by the software
`vendor to either vary the conditions or the objective
`criteria under which the conditions are met.
`in
`accordance with the invention, the criteria are stat-
`ed in software, and more particularly,
`in the pro-
`tected or encrypted portion of the application soft-
`ware. As is described in our copending application
`[Y0985-091], the only form in which the protected
`application software is available to the user is in
`encrypted form; because the user does not have
`access to the decryption key as a data object. he
`is unable to modify. or even read the protected
`software. Thus, incorporating the conditions of the
`right to execute within the protected software re-
`sults in securing these conditions against alteration
`by the user or anyone else unless authorized by
`the software vendor.
`in order to save (for testing)
`
`the conditions which are tested against the pro-
`grammed criteria, we use some storage space in
`the non volatile memory of the coprocessor",
`this
`storage space has already allocated to it the func-
`tion of storing the decryption key necessary to
`decrypt the encrypted software. Thus the storage
`space allocated to a particular protected piece of
`software is expanded to include the condition which
`can be measured against the criteria. Because of
`the non-volatility of the memory, so long as the
`right to execute is available in the coprocessor, the
`objective conditions are also available.
`it should be
`understood that the coprocessor contains a con-
`tinuously powered real-time clock within its phys-
`ically secure boundary so that
`in the case that
`criteria involving time are to be used,
`the time
`information is available. Because the information is
`
`stored in a coprocessor's non-volatile memory, and
`only the portion of this memory allocated to any
`particular application can be accessed by that ap-
`plication, the information is secure against any at-
`tempt at modification by the user. The application
`software may modify the conditions stored in its
`portion
`of non-volatile memory, but may not
`change the value of the maritime clock.
`For example, the software thus could c0unt the
`number of times or.the total period it had been
`used by changing numbers kept in this storage and
`executing only until criteria related to number or
`total period of executions were no longer met by
`the stored conditions.
`
`As an example, assume that the software ven-
`dor has transferred to the user the right to execute
`on the condition that a certain terminal date had
`
`not passed, (ie. the user has the right to execute
`the protected application up to, but not after March
`1, 1987). The coprocessor's operating instructions
`necessarily, therefore, provide for storage of a last
`allowed use (terminal) date along with the software
`decryption key. Since the coprocessor maintains a
`real
`time clock, whenever the decryption key is
`accessed or at intervals during application execu-
`tion,
`the terminal date and the current date are
`available. The terminal date provision is protected
`against unauthorized alteration by the security of
`the coprocessor as is the real time clock setting.
`The encrypted portion of the software (the pro-
`tected portion) describes the criterium that execu-
`tion is not available beyond the terminal date.
`Whenever the protected software is run, the de-
`cryption key and the terminal date are accessed
`from the coprocessor's non-volatile memory. The
`criterion tested in the protected software requires
`that the terminal date be compared to the current
`date;
`if
`the current date is beyond the terminal
`date, then execution of the protected software does
`not proceed. The protected software can also be
`arranged to provide for deleting the particular soft-
`
`.10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`50
`
`55
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1012-00003
`
`

`

`5
`
`0 268139
`
`6
`
`were decryption key in the event that the current
`date is beyond the terminal date.
`It should be
`apparent to those skilled in the art
`that another
`condition which can be substituted for the terminal
`
`date condition is the number of times the software
`is executed. For this case. the protected software
`describes the number of executions which have
`been authorized, and in lieu of storing the current
`date along with the software decryption key, a
`count of allowed uses is stored which is decremen-
`ted each time the software is executed. The pro-
`tected portion then tests the allowed number of
`executions against the criterion that the number is
`greater than zero.
`it
`then either decrements the
`number or,
`if the number of authorized executions
`is zero, denies the.user's request to execute the
`software (and perhaps the software decryption key
`is also deleted).
`it should be apparent that there
`are many variations to these specific implementa-
`tions. including elapsed time, passwords, and com-
`binations of these and other measurables, all of
`
`which are within the scope of the invention.
`
`Transfer of Hight-to-Execute .
`
`Transferring the right to execute from one user
`to another
`(or more particularly,
`from a source
`coprocessor to a sink coprocessor) can be accom=
`plished by reconstructing a distribution set. This
`procedure returns the right to execute to a portable
`form which is substantially identical
`to that froin
`which it was acquired in the first place, see copen-
`ding application [Y0985-091]. This procedure, nec-
`essarily,
`removes the right to execute from the
`source coprocessor.
`This transaction requires that the user obtain
`either a token or a disk and a token pair (also
`referred to as a Transfer Set), depending on the
`structure of the token. These sets can be provided
`by the hardware vendor. The token (or cartridge) in
`the set
`is
`loaded by the coprocessor hardware
`manufacturer. The Transfer Set, prior to manipula-
`tion by the user has a single piece of information,
`token data, stored in two forms. The token is load-
`ed, by the hardware vendor with clear text token
`data; the physical characteristics of the token pro-
`tect
`this sensitive information from unauthorized
`persons. The same data is encrypted under a
`hardware manufacturer secret key called a Com-
`mon Supervisor Key (CSK) to generate Ecsxhoken
`data). It is stored either on the disk of the Transfer
`Set, or in the token if it is so structured as to allow
`it. Because Ecsxaoken data) is encrypted,
`it may.
`be stored on the disk even though in that form it
`can be read and even copied by anyone.
`it
`is
`necessary that the transfer set be prepared by a
`trusted source, such as a hardware vendor, be-
`
`'10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`cause if the token contents are known, other tokens
`could be loaded with known contents and the trans-
`
`ferred right to execute replicated. Assuming that
`the user has acquired a suitable transfer set. the
`distribution set is prepared using a Reconstruct
`Distribution Set (RDS) process, by the user and his
`composite computing system, for example, as fol-
`lows.
`
`A utility program, running on the host com-
`puter, signals the (source) coprocessor that an
`RDS sequence is about to begin. The utility pro-
`gram identifies to the coprocessor the location of
`the key to be transferred. The coprocessor ex-
`ecutes a CBS (Create Backup Set) procedure on all
`allowed keys except
`the indexed key. The CBS
`procedure is described below. At this point
`it
`is
`sufficient
`to note that the CBS procedure invali-
`dates any existing hardware backup mechanism.
`The coprocessor requests and receives a copy of
`the encrypted token descriptor Ecsxhoken data)
`from the transfer set. The coprocessor decrypts the
`token descriptor to provide clear text token data.
`This clear text token data is then encrypted using
`the software decryption key identified by the index
`to produce EAK(token data). The coprocessor then
`stores this encrypted token descriptor E “(token
`data) in a reserved non-volatile storage area of the
`token or on the disk and either erases or otherwise
`
`de-activates the software decryption key AK at the
`given storage
`location. The coprocessor
`then
`passes the encrypted token descriptor to the host
`for storage on the transfer set disk. As will be
`described later, the key (AK) to be transferred may
`be associated with conditions of execution. If these
`
`conditions of execution are unchanging (such as
`terminal date) then the encrypted application key
`may be copied to the transfer set disk.
`if
`the
`conditions of execution are changing (such as re-
`maining hours of use or
`remaining number of
`uses),
`then the encrypted file containing the ap-
`plication key and the conditions of execution can-
`not be copied from the distribution disk without
`resetting the conditions. This synchronization of a
`token descriptor file and an application key file can
`be achieved by including a correspondence test
`number in each file. The next step in transfer is
`thus the preparation of an encrypted application
`key file for storage on the transfer disk. This prep-
`aration is
`identical
`to the encrypt vendor key
`(EVK)
`transaction described below save that the
`correspondence test number is substituted for the
`random number. This correspondence number
`could be a fraction of the token data. After this
`
`preparation and transfer. the utility program, run-
`ning in the host, then transfers to the transfer set
`disk the two files containing the plain text and
`cipher text parts of the protected program. The
`reader can now verify that the distribution set is
`
`m
`
`it
`
`(u.
`
`11"
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1012-00004
`
`

`

`n
`
`7
`
`/
`
`O 268 139
`
`8
`
`identical to the distribution set described in EP-A-
`
`...... [Y0985-091] in that it includes the encrypted
`token data, encrypted with the software decryption
`key AK,
`the plain text
`file and the protected or
`encrypted software file, also encrypted under the
`software decryption key AK, as well as the software
`decryption key AK encrypted by the hardware ven-
`dor's key CSK. The latter three elements may be
`copied from the original distribution disk or any
`backup copy of those files if permitted by execu-
`tion conditions.
`It should be self-evident that since
`the distribution set is now identical in all but one
`
`respect, it is usable with any coprocessor to trans-
`fer the right
`to execute the particular encrypted
`software file. The only difference between the dis-
`tribution set and the original set from which the
`right
`to execute was acquired,
`is that the token
`data is very likely to be different; this is immaterial
`as long as both portions of
`the set
`(the token
`cartridge and the diskette) have been derived from
`identical token data. The (source) coprocessor now
`deletes the decryption key AK from its temporary
`memory. At
`this point,
`the right
`to execute has
`been deleted from the source coprocessor and
`exists solely in the Transfer Set.
`Transfer of the right to execute, however, need
`not be indirect, eg. through the transfer set already
`referred to. Transfer of the right to execute can be
`direct, eg. using a coprocessor to coprocessor
`communication link. Furthermore, the coprocessor
`‘to coprocessor communication link need not be
`secure in order to maintain the safety of the rightto
`execute being transferred; rather the safety is cryp-
`tographically secured as will now be described.
`in
`the following discussion we will refer to a transfer
`from coprocessor to coprocessor, however,
`the
`reader should understand that the communication
`
`link between coprocessors can either be through
`direct connection, or can be through any bidirec-
`tional data communication system. A transfer of a
`right to execute from one coprocessor to another is
`considered safe when the two coprocessors in-
`volved
`are
`able
`to
`identify
`one
`another as
`"members of the family" and generate a one time
`only Session Key for their use in that transaction.
`The identification as members of
`the family is
`needed for assurance that the procedures used by
`each will mesh correctly, so that proliferation of
`rights to execute will not occur, an so that other
`protected information will not be revealed.
`The transaction in which the Session Key is
`generated relies on the presence of information in
`high privilege memory which is common to the two
`coprocessor systems participating in the transac-
`tion and on the ability of coprocessors to generate
`good random numbers. The process which gen-
`erates a Session Key will result in both coproces-
`sors involved in the transaction possessing the
`
`same key only if both coprocessors have the nec-
`essary antecedent information in common.
`The transaction for mutual
`identification and
`
`generation of a Session Key is as follows. For
`purposes of this description we will refer to the
`user or the user's composite computing system or
`the user's coprocessor as the source user, source
`composite computing system or source coproces-
`sor if the right to execute is being transferred from
`that
`user,
`composite
`computing
`system or
`coprocessor. We will refer to the user, composite
`computing system or coprocessor as the sink user,
`sink
`composite
`computing
`system or
`sink
`coprocessor if the right to execute is being trans-
`ferred thereto. The source user signals the source
`coprocessor that a Session Key is needed. The
`source COpl’OCSSSOf generates a random number
`which will be used in generating the session key,
`pads it with another random string of bits, and
`appends a Message Authentication Code (MAC).
`The MAC can be used to ensure that the plain text
`message which is recovered on decryption is iden-
`tical to the one transmitted. The source coproces- »
`sor then encrypts the number with a key CSK and
`sends the encrypted number to the sink coproces-
`sor. The sink coprocessor has performed the same
`function and has sent its random encrypted num-
`ber
`to the
`source
`coprocessor. The
`source
`coprocessor decrypts the number received under
`the encryption key (CSK).
`in the event that each
`coprocessor
`stores multiple CSKs,
`then each
`coprocessor decrypts the received number under
`each CSK in succession until either a valid MAC is
`
`supervisor keys
`the collection of
`obtained, or
`(CSK) is exhausted.
`If a valid MAC is not found.
`then an error message is returned. This will be the
`typical outcome if a processor which is not a
`"member of the family" tries to pass itself off as
`one.
`if a valid MAC is obtained, then the random
`numbers generated in the two coprocessors are
`combined in both coprocessors and are used as
`the Session Key. Of course, part of the operating
`instructions for
`the coprocessors will define, a
`priori, the particular manner in which the random
`numbers are to be combined in order to generate
`the Session Key: one number could be concat-
`enated with
`another;
`the numbers
`could be
`EXCLUSIVE-OFt'ed, etc.
`In order to avoid the procedure which may
`require successive decryptions in a search for the
`"correct" supervisor key,-lccation information such
`as an index for the supervisor key which had been
`used could be sent along with the encrypted num-
`ber. There is an advantage, however, to the tech‘
`nique which requires coprocessors to "search" for
`the correct supervisor key. A procedure which
`transmits an index number along with the encryp-
`ted number provides a growing collection of
`in-
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1012-00005
`
`

`

`9
`
`0 268 139
`
`10
`
`formation about
`server.
`
`the supervisor keys to any ob-
`
`Once the Session Key has been generated, it
`is possible for the coprocessors to transfer rights to
`execute by encrypting them under the Session
`Key. The coprocessors‘ firmware, controlling the
`procedure. ensures that the rights are erased from
`the source processor. The right to execute could
`be erased when transmitted by the source proces-
`sor, although a preferable technique is to erase the
`right to execute (the software key) only when the
`sink coprocessor indicates that the right to execute
`has been safely received and to activate the right
`to execute only when the source coprocessor in-
`
`dicates the right to execute has been deactivated.
`The right to execute. which is transferred in en-
`crypted form, is secured against an observer by its
`encryption and there is no need to employ a se-
`cure communication link or channel.
`
`Direct or inter-coprocessor communication is
`the method of choice for movement of rights to
`execute in a network or a mainframe link environ-
`
`in these cases or others involving placing
`ment.
`more than one right to a particular application in a
`particular coprocessor, a count of the rights for a
`given package is maintained in the key storage
`area of the source coprocessor so that the number
`of rights which have been received limits the num-
`ber which are distributed.
`It should be clear from the above descriptions
`it
`is within the realm of this mechanism to
`
`that
`
`associate with an AK a description pf the life 'span
`of an AK in several dimensions ( time, numbers of
`use, etc.). It should also be clear that it is within the
`capacity of this mechanism to divide or parcel out
`this span under control of software provided by the
`software vendor and executed by a coprocessor.
`Libraries of software could be maintained in distrib-
`
`uted computing systems by these means without
`violating the conservation of rights to execute while
`providing benefit to the distributed computing sys-
`tem's user.
`
`In the event that a transfer of multiple rights to
`execute is required, the coprocessor to coproces-
`sor transfer proceeds as follows once a Session
`Key has been created. The source user identifies
`to the source coprocessor those rights to execute
`(AKs)
`to be transferred. The source coprocessor
`executes a CBS procedure (defined hereinafter) in
`order to update any backup set of rights to ex-
`ecute. The source coprocessor then encrypts the
`software keys under the Session Key and stores
`them with the Session Key in a reserved location of
`temporary memory. The source coprocessor marks
`each software key from the key store (permanent
`memory) as inactive and sends the encrypted in-
`formation to the
`sink coprocessor. The sink
`coprocessor receives the collection of encrypted
`
`keys from the source coprocessor. and decrypts
`them under the Session Key. The sink coprocessor
`then stores the decrypted keys in its key store
`(permanent memory) marking them inactive and
`sends its host computer location information by
`which the applications can access the keys in the
`load decrypt run procedure. The files actually com-
`prising'the protected software can be sent by any
`conventional (unprotected) technique or apparatus.
`The sink coprocessor can return a message to the
`source coprocessor indicating receipt of the par-
`ticular software key or keys to induce the source
`coprocessor to eliminate those software keys from
`its temporary memory. When the source coproces-
`sor confirms the removal, the keys are then ac-
`tivated by the sink coprocessor.
`It should be noted that a software vendor may
`not wish to allow transfer of a right to execute and
`that this constitutes a term or condition of sale.
`Conditions which control the allowed movement of
`
`rights to execute can be stored in association with
`Jan AK as part of the procedure in which it
`is
`acquired.
`If a manipulation of an AK is requested
`by a user, then these conditions (flags) are tested
`against go/no-go criteria stored in the coprocessor
`firmware which implements the requested manipu-
`Iation.
`
`Backup of Right-to-Execute
`
`The backup procedure to be described is one
`which is intended to insure that the collection of
`
`rights to execute stored in a user's coprocessor are
`not lost due to an unforeseen failure of, for exam-
`ple, the supply of power to the coprocessor's non-
`volatile memory. This is to be distinguished from
`backup procedures which are applied to files of
`data and software. The latter procedures are en-
`tirely conventional, well understood. and are ap-
`plicable to those kinds of objects, where they exist,
`in this system (plain text and encrypted software
`and encrypted application key). Many functional
`copies of such objects may be kept for use by any
`authorized system, thus ensuring against their loss.
`it is, rather. the objective of the backup procedure
`described below to back up rights to execute so
`that they are not lost but so that many functional
`copies of that kind of object cannot be made.
`Because the backup procedure is designed to
`circumvent the results of an unforeseen failure in
`
`the coprocessor, the backup procedure must cre-
`ate, external to the coprocessor, sufficient informa-
`tion so that the right to execute can be installed
`entirely independently of
`the (source) processor
`which stores an entirely valid right
`to execute.
`Because of this necessary independence, the bac-
`kup procedure itself
`is a potential source of a
`
`1O
`
`15
`
`2O
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`ml
`
`in
`
`m
`
`'3
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1012-00006
`
`

`

`11
`
`0268139
`
`12
`
`to execute. Allowing
`(duplicate or spurious) right
`the creation of backup rights is a policy decision
`for the software vendor.
`it
`is a potential detriment
`to his security and would be provided for his cus-
`tomers' convenience. As noted earlier with respect
`to transfers of rights, a provider of software may
`not wish to allow backup. This condition of sale is
`enforceable by the same mechanism as described
`for control of transfer given the existence of a no-
`backup. flag associated with an AK. This option is
`desirable in the case that the conditions of execu-
`
`tion may change. To minimize the impact of bac-
`kup rights,
`they are,
`in this system, made con-
`ditional
`in that
`they expire after a.conveniently
`short
`interval which is long enough for the user
`who has actually had a failure in his coprocessor to
`have that failure verified, for example by the hard-
`ware manufacturer.
`
`Assuming the hardware manufacturer verifies
`the failure of the user's coprocessor, the means are
`provided to the user to carry out an additional
`procedure to remove the condition on the backup
`rights.
`In order to safely integrate the creation of
`backup rights with the other capabilities described
`herein,
`the creation of backup rights should be
`thought of as beginning a transfer of all allowed
`rights which is then left pending completion. Trans-
`fer procedures are necessarily interrelated with the
`backup procedures so that any user backup set
`(which carries a potential right to execute) is invali-
`dated at the time any complete transfer is effected.
`This prevents the transferred rights from also being
`present
`in a valid backup. Accordingly,
`the user
`has the following options in connection with the
`procedures described herein:
`1. With his right to execute installed on a
`coprocessor,
`the user can have a backup set
`(representing a collection of potential rights to ex-
`ecute) which can be converted into an actual, but
`conditioned. right to execute, or
`2. The user can remove one or more rights
`to execute from his coprocessor and install them in
`a transfer set or directly transfer them to another
`coprocessor, but that procedure requires invalida-
`tion of the existing backup set. This requirement is
`entirely consistent with the user's rights since when
`rights to execute are removed from a coprocessor,
`there is no need for the rights to be represented in
`the backup set. Obviously, a new backup set which
`correctly reflects the diminished set of installed
`rights to execute may be prepared immediately
`after a transfer.
`
`The procedures arranged for creating backup
`rights are comprehensive in that a single backup
`set can retain potential rights to execute for mul-
`tiple applications. The procedures contemplate that
`the user's collection of rights on execute may be
`dynamic, e.g. his collection of rights on one clay
`
`.10
`
`75
`
`2O
`
`25
`
`30
`
`35
`
`50
`
`55
`
`may be greater or less than his collection of rights
`on another day. This necessarily requires that the
`backup rights be dynamic too and track changes in
`the user's collection of rights to execute.
`Basically, th