`
`PCT/US96/02303
`
`specified as the string ”fire fly“ or ”fire flies“. Content type B is
`
`associated with the following rule set:
`
`1.
`
`A use event that specifies that the use may only be
`
`by the software agent or a routing agent. The
`
`software agent has read only permission, the routing
`
`agent has read/write access to the information.
`
`There are no charges associated with using the
`
`information, but two meters; one by read and one by
`
`write are kept to track use of the information by
`
`various steps in the process.
`
`2.
`
`Audits of usage are required and will be stored in
`
`object 300w under control information specified in
`
`that object.
`
`After container 300y and its control sets are specified, they
`
`are constructed and embedded in the smart object container 300.
`
`Container 300x is specified as a content object that is
`
`empty of content. It contains a control set that contains the
`
`following rules:
`
`707
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1001
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1001
`
`
`
`W0 96/27155
`
`PCT/US96l02303
`
`1.
`
`A wfite_without_bfllm§ event that specifies a meter
`
`and a general budget that limits the value of writing
`
`to $15.00.
`
`2.
`
`Audits of usage are required and will be stored in
`
`object 300w under control information specified in
`
`that object.
`
`3.
`
`An empty use control set that may be filled in by the
`
`owner of the information using predefined methods
`
`(method options).
`
`After container 300x and its control sets are specified, they
`
`are constructed and embedded in the smart object container 300.
`
`Container 300w is specified as an empty administrative
`
`object with a control set that contains the following rules:
`
`1.
`
`A use event that specifies that the information
`
`contained in the administrative object may only be
`released to the creator of smart object container 300..
`
`2.
`
`No other rules may_be attached to the administrative
`
`content in container 300w.
`
`708
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1002
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1002
`
`
`
`WO 96127155
`
`I
`
`PCT/US96/02303
`
`After container 300w and its control sets are specified, they
`
`are constructed and embedded in the smart object container 300.
`
`At this point, the smart object has been constructed and is
`
`ready to be dispatched to a remote VDE site. The smart object is
`
`sent to a remote VDE site (e.g., using electronic mail or another
`
`transport mechanism) that contains an information locator
`
`service 3012 via path 3014. The smart object is registered at the
`
`remote site 3012 for the ”item locator service.“ The control set in
`
`container related to ”item locator service“ is selected and the
`
`rules contained Within it activated at the remote site 3012. The
`
`remote site 3012 then reads the contents of container 300y under
`
`the control of rule set 806f and 300y(l), and permits writes of a
`
`list of location information into container 300y pursuant to these
`
`rules. The item locator service writes a list of three items into the
`
`smart object, and then ”deregisters“ the sma.rt object (now
`
`containing the location information) and sends it to a site 3016
`
`specified in the list written to the smartobject via path 3018. In
`
`this example, the user may have specified electronic mail for
`
`transport and a list of remote sites that may have the desired
`
`information is stored as a forwarding list.‘
`
`The smart object 3000, upon arriving at the second remote
`
`site 3016, is registered with that second site. The site 3016
`
`provides agent execution and software description list services
`
`709
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1003
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1003
`
`
`
`WO 96127155
`
`PCITUS96/02303
`
`compatible with VDE as a service to smart objects. It publishes
`
`these services and specifies that it requires $10.00 to start the
`
`agent and $20/piece for all information returned. The
`
`registration process compares the published service information
`
`against the rules stored within the object and determines that an
`
`acceptable overlap does not eidst. Audit information for all these
`
`activities is written to the administrative object 300w. The
`
`registration process then fails (the object is not registered), and
`
`'
`
`the smart object is forwarded by site 3016 to the next VDE site
`
`3020 in the list via path 3022.
`
`The smart object 3000, upon arriving at the third remote
`
`site 3020, is registered with that site. The site 3020 provides
`
`agent, execution and software description list services compatible
`
`with VDE as a service to smart objects. It publishes these
`
`services and specifies that it requires $1.00 to start the agent and
`
`$0.50/piece for all information returned. The registration process
`
`compares the published service information against the rules
`
`stored within the object and determines that an acceptable
`
`overlap exists. The registration process creates a URT that
`
`specifies the agreed upon control information. This URT is used
`
`in conjunction with the other control information to execute the
`
`software agent under VDE control.
`
`710
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1004
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1004
`
`
`
`W0 96/27155
`
`PCT/US96/02303
`
`The agent software starts and reads its parameters out of
`
`container 300y. It then starts searching the database and
`
`obtains 253 ”hits“ in the database. The list of hits is written to
`
`container 300x along with a completed control set that specifies
`
`the granularity of each item and that each item costs $0.50. Upon
`
`completion of the search, the budget for use of the service is
`
`incremented by $1.00 to reflect the use charge for the service.
`
`Audit information for all these activities is written to the
`
`administrative object 300w.’
`
`The remote site 3020 returns the now ”fi1ll“ smart object
`
`3000 back to the original sender (the user) at their VDE node
`
`3010 via path 3024. Upon arrival, the smart object 3000 is
`
`registered and the database records are available. The control
`
`information specified in container 300x is now a mix of the
`
`original control information and the control information specified
`
`by the service regarding remote release of their information. The
`
`user then extracts 20 records from the smart object 3000 and has
`
`$10.00 charged to her VISA budget at the time of extraction.
`
`In the above smart agent VDE examples, a certain
`
`organization of smart object 3000 and its constituent containers
`
`is described. Other organizations of VDE and smart object
`
`related control information and parameter data may be created
`
`711
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1005
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1005
`
`
`
`W0 96/27l55
`
`PCI‘/US96/02303
`
`and may be used for the same purposes as those ascribed to
`
`object 3000 in the above example.
`
`Negotiation and Electronic Contracts
`
`An electronic contract is an electronic form of an
`
`agreement including rights, restrictions, and obligations of the
`
`parties to the agreement. In many cases, electronic agreements
`
`may surround the use of digitally provided content; for example,
`
`a license to view a digitally distributed movie. It is not required,
`however, that an electronic agreement be conditioned on the
`
`presence or use of electronic content by one or more parties to the
`
`agreement. In its simplest form, an electronic agreement
`
`contains a right and a control that governs how that right is
`
`used.
`
`Electronic agreementsplike traditional agreements, may be
`
`negotiated between their parties (terms and conditions submitted
`
`by one or more parties may simply be accepted (cohesion
`
`contract) by one or more other parties and/or such other parties
`
`may have the right to select certain of such terms and conditions
`
`(while others may be requi.red)). Negotiation is defined in the
`
`dictionary as ”the act of bringing together by mutual agreement.“
`
`The preferred embodiment provides electronic negotiation
`
`processes by which one or more rights and associated controls can
`
`be established through electronic automated negotiation of terms.
`
`712
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1006
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1006
`
`
`
`W0 96/27155
`
`PCT/US96/02303
`
`Negotiations normally require a precise specification of rights
`
`and controls associated with those rights. PERC and URT
`
`structures provide a mechanism that may be used to provide
`
`precise electronic representations of rights and the controls
`
`associated with ‘those rights. VDE thus provides a ”vocabulary“
`
`and mechanism by which users and creators may specify their
`
`desires. Automated processes may interpret these desires and
`
`V negotiate to reach a common middle ground based on these
`
`desires. The results of said negotiation may be concisely
`
`described in a structure that may be used to control and enforce
`
`the results of the electronic agreement. VDE fiirther enables this
`
`process by providing a secure execution space in which the
`
`negotiation process(es) are assured of integrity and
`
`confidentiality in their operation. The negotiation process(es)
`
`may also be executed in such a manner that inhibits external
`
`tampering with the negotiation.
`
`A final desirable feature of agreements in general (and
`
`electronic representations of agreements in particular) is that
`
`they be accurately recorded in a non-repudiatable form. In
`
`traditional terms, this involves creating a paper document (a
`
`contract) that describes the rights, restrictions, and obligations of
`
`all pa.rties involved. This document is read and then signed by
`
`all parties as being an accurate representation of the agreement.
`
`Electronic agreements, by their nature, may not be initially
`
`713
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1007
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1007
`
`
`
`W0 96/27155
`
`.
`
`_
`
`PCITUS96/02303
`
`rendered in paper. VDE enables such agreements to be
`
`accurately electronically described and then electronically signed
`
`to prevent repudiation. In addition, the preferred embodiment
`
`provides a mechanism by which human-readable descriptions of
`
`terms of the electronic contract can be provided.
`
`VDE provides a concise mechanism for specifying control
`sets that are
`site interpretable. Machine interpretable
`mechanisms are often not human readable.
`often operates
`the negotiation procession behalf of at least one human user. It
`
`is thus desirable that the negotiation be expressible in ”human
`
`readable form.“ VDE data structures for objects, methods, and
`
`load modules all have provisions to specify one or more DTDs
`
`within their structures. These DTDs may be stored as part of the
`
`item or they may be stored independently. The DTD describes
`
`one or more data elements (NUDE, UDE, or other related data
`
`elements) that may contain a natural language description of the
`
`function of that item. These natural language descriptions
`
`provide a language independent, human readable description for
`
`each item. Collections of items (for example, a BUDGET method)
`
`can be associated with natural language text that describes its
`
`function and forms a term of an electronically specified and
`
`enforceable contract. Collections of terms (a control set) define a
`
`contract associated with a specific right. VDE thus permits the
`
`714
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1008
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1008
`
`
`
`W0 96/27155
`
`PCTIUS96/02303
`
`electronic specification, negotiation, and enforcement of electronic
`
`contracts that humans can understand and adhere to.
`
`VDE 100 enables the negotiation and enforcement of
`
`electronic contracts in several ways:
`
`0
`
`it enables a concise specification of rights and control
`
`information that permit a common vocabulary and
`
`procedure for negotiation,
`
`0
`
`it provides a secure processing environment within
`
`which to negotiate,
`
`0
`
`it provides a distributed environment within which
`
`rights and control specifications may be securely
`
`distributed,
`
`0
`
`it provides a secure processing environment in which
`
`negotiated contracts may be electronically rendered
`
`and signed by the processes that negotiate them, and
`
`0
`
`it provides a mechanism that securely enforces a
`
`negotiated electronic contract.
`
`.715
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1009
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1009
`
`
`
`WO 96127155
`
`PCI‘/US96l02303
`
`Types ofNegotiations
`
`A simple form of a negotiation is a demand by one pa.rty to
`
`form an ”adhesion“ contract. There are few, if any, options that
`
`may be chosen by the other party in the negotiation. The
`
`recipient of the demand has a simple option; she may accept or
`
`reject the terms and conditions (control information) in the
`
`demand. lfshe accepts the conditions, she is granted rights
`
`subject to the specified control information. If she rejects the
`
`conditions, she is not granted the rights. PERC and URT
`structures may support negotiation by demand; a PERC or
`
`control set from a PERC may be presented as a demand, and the
`
`recipient may accept or reject the demand (selecting any
`
`permitted method options if they are presented).
`
`A common example of this type of negotiation today is the
`
`purchase of software under the terms of a ”shrink-wrap license.“
`
`Many widely publicized electronic distribution schemes use this
`
`type of negotiation. CompuServe is an example of an on-line
`
`service that operates in the same manner. The choice is simple:
`
`either pay the specified charge or don’t use the service or '
`
`software. VDE supports this type of negotiation with its
`
`capability to provide PERCS and URTs that describe rights and
`control information, and by permitting'a content owner to provide
`a REGISTER method that allows a user to select from a set of
`.
`
`predefined method options. In this scenario, the REGISTER
`
`716
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1010
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1010
`
`
`
`W0 96/27155
`
`PCTIUS96/02303
`
`method may contain a component that is a simplified negotiation
`
`process.
`
`A more complex form of a negotiation is analogous to
`
`”haggli.ng.“ In this scenario, most of the terms and conditions are
`
`fixed, but one or more terms (e.g., price or payment terms) are
`
`not. For these terms, there are options, limits, and elements that
`
`may be negotiated over. A VDE electronic negotiation between
`
`two parties may be used to resolve the desired, permitted, and
`
`optional terms. The result of the electronic negotiation may be a
`
`finalized set of rules and control information that specify a
`
`completed electronic contract. A simple example is the scenario
`
`for purchasing software described above adding the ability of the
`
`purchaser to select a method of payment (VISA, Mastercard, or
`
`American Express). A more complex example is a scenario for
`
`purchasing information in which the price paid depends on the
`
`amount of information about the user that is returned along with
`
`a usage audit trail. In this second example, the right to use the
`
`content may be associated with two control sets. One control set
`
`may describe a fixed (”higher“) price for using the content.
`
`Another control set may describe a fixed (”lower“) price for using
`
`the content with additional control information and field
`
`specifications requiring collection and return the user’s personal
`
`information. In both of these cases, the optional and permitted
`
`fields and control sets in a PERC may describe the options that
`
`717
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1011
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1011
`
`
`
`I
`
`wo 95/27155
`
`PCI‘/US96I02303
`
`may be selected as part of the negotiation. To perform the
`
`negotiation, one party may propose a control set containing
`
`specific fields, control information, and limits as specified by a
`
`PERC; the other party may pick and accept from the control sets
`
`proposed, reject them, or propose alternate control sets that
`
`might be used. The negotiation process may use the permitted,
`
`required,
`
`optional designations in the PERC to determine an
`
`acceptable range of parameters for the final rule set. Once an
`
`agreement is reached, the negotiation process may create a new "
`
`PERC and/or URT that describes the result of the negotiation.
`The resulting'PERCs and/or URTs may be ’’signed“ (e.g., using
`
`digital signatures) by all of the negotiation processes involved in
`
`the negotiation to prevent repudiation of the agreement at a later
`
`date.
`
`Additional examples of negotiated elements are: electronic
`
`cash, purchase orders, purchase certificates (gift certificates,
`
`coupons), bidding and specifications, budget “rollbacks” and
`
`reconciliation, currency exchange rates, stock purchasing, and
`
`billing rates.
`
`A set of PERCS that might be used to support the second
`
`example described above is presented in Figures 75A (PERC sent
`
`by the content owner), 75B (PERC created byuuser to represent
`their selections aiid rights), and 75c (PERC for controlling the
`
`718
`
`Petitioner'App1e Inc. — Exhibit 1002, p. 1012
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1012
`
`
`
`W0 96/27155
`
`IUS96/02303
`
`negotiation process). These PERCs might be used in conjunction
`
`with any of the negotiation process(es) and protocols described
`
`later in this section.
`
`Figure 75A shows an example of a PERC 3100 that might
`
`be created by a content provider to describe their rights options.
`
`In this example, the PERC contains information regarding a
`
`single USE right. Two alternate control sets 3102a, 3102b are
`
`presented for this right in the example. Control set 3102a
`
`permits the use of the content without passing back information
`
`about the user, and another control set 3102b permits the use of
`
`the content and collects ”response card“ type information from
`
`the user. Both control sets 3102a, 3102b may use a common set
`
`of methods for most of the control information. Th.is common
`
`control information is represented by a CSR 3104 and CS0 3106.
`
`Control set 3102a in this PERC 3100 describes a
`
`mechanism by which the user may obtain the content without
`
`providing any information about its user to the content provider.
`
`This control set 3102a specifies a well-known vending control
`
`method and set of required methods and method options.
`
`Specifically, in this example, control set 3102a defines a
`
`BUDGET method 3108 (e.g., one of VISA, Mastercard, or
`
`American Express) and it defines a BILLDIG method 3110 that
`
`specifies a charge (e.g., a one-time charge of $100.00).
`
`719
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1013
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1013
`
`
`
`WO 96127155
`
`PCTIUS96/02303
`
`Control set 3102b in this PERC 3100 describes another
`
`mechanism by which the user may obtain the content. In this
`
`example, the control set 3102b specifies a different vending
`control method and a set of required methods and method
`options. This second control set 3102b specifies a BUDGET
`
`method 3112 (e.g., one of VISA, Mastercard, or American
`Express), a BILLING method 3116 that specifies a charge (e.g., a
`
`lesser one—time charge such as $25.00) and an AUDIT method
`
`3114 that specifies a set of desired and required fields. The
`
`required and desired field specification 31 16 may take the form of
`
`a DTD specification, in which, for example, the field names are
`
`listed.
`
`The content creator may ”prefer“ one of the two control sets
`
`(e.g., control set 2) over the other one. If so, the ”preferred“
`
`control set may be ”ofiered“ first in the negotiation process, and
`
`. Withdrawn in favor of the ”non-preferred“ control set if the other
`
`party to the negotiation ”rejects“ the ”preferred“ control set.
`
`In this example, these two control sets 3102a, 3102b may
`
`share a common BUDGET method specification. The BUDGET
`
`method specification may be included in the CSR 3104 or CSO
`
`3106 control sets if desired. Selecting control set 3102a (use with
`
`no information passback) causes a unique component assembly to
`
`be assembled as specified by the PERC 3100. Specifically, in this
`
`720
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1014
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1014
`
`
`
`W0 96/27155
`
`PCT/US96/02303
`
`example it selects the ”Vending“ CONTROL method 3118, the
`
`BILLING method 3110 for a $100 fixed charge, and the rest of
`
`the control information specified by CSR 3104 and CS0 3106. It
`
`also requires the user to specify her choice of acceptable
`
`BUDGET method (e.g., from the list including VISA, Mastercard,
`
`and American Express). Selecting control set 3102b assembles a
`
`different component assembly using the ”Vending with ’response
`
`card"‘ CONTROL method 3120, the BILLING method 3116 (e.g.,
`
`for a $25 fixed charge), an AUDIT method 31 14 that requires the
`
`fields listed in the Required Fields DTD 3116. The process may
`
`also select as many of the fields listed in the Desired Fields DTD
`
`3116 as are made available to it. The rest of the control
`
`information is specified by CSR 3104 and CS0 3106. The
`
`selection of control set 3102b also forces the user to specify their
`
`choice of acceptable BUDGET methods (e.g., from the list
`
`including VISA, Mastercard, and American Express).
`
`Figure 75B shows an example of a control set 3125 that
`
`might be used by a user to specify her desires and requirements
`
`in a negotiation process. This control set has a USE rights
`
`section 3127 that contains an aggregated CSR budget
`
`specification 3129 and two optional control sets 3131a, 3131b for
`
`use of the content. Control set 3131a requires the use of a
`
`specific CONTROL method 3133 and AUDIT method 3135. The
`
`specified AUDIT method 3135 is parameterized with a list of
`
`721
`
`Petitioner Apple Inc. — Exhibit" 1002, p. 1015
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1015
`
`
`
`WO 96127155
`
`PCT/US96I02303
`
`fields 3137 that may be released in the audit trail. Control set
`
`3131a also specifies a BILLING method 3139 that can cost no
`
`more than a certain amount (e.g., $30.00). Control set 3131b in
`
`this example describes a specific CONTROL method 3141 and
`
`may reference a BILLING method 3143 that can cost no more
`
`than a certain amount (e.g., $150.00) if this option is selected.
`
`Figure 75E shows a more high-level view of an electronic
`
`contract 3200 formed as a ”result“ of a negotiation process as
`
`described above. Electronic contract 3200 may include multiple
`
`clauses 3202 and multiple digital signatures 3204. Each clause
`
`3202 may comprise a PERC/URT such as item 3160 described
`
`above and shown in Figure 75D. Each ”clause“ 3202 of electronic
`
`contract 3200 thus corresponds to a component assembly 690
`
`that may be assembled and executed by a VDE electronic
`
`appliance 600. Just as in normal contracts, there may be as
`
`many contract clauses 3202 within electronic contract 3200 as is
`
`necessary to embody the ”agreement“ between the ’’parties.‘‘
`
`Each of clauses 3202 may have been electronically negotiated
`
`and may thus embody a part of the ”agreement“ (e.g., a
`
`”compromise“) between the parties. Electronic contract 3200 is
`
`”self-executing“ in the sense that it may be literally executed by a
`
`machine, i.e., a VDE electronic appliance 600 that assembles
`
`component assemblies 690 as specified by various electronic
`
`clauses 3202. Electronic contract 3200 may be automatically
`
`722
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1016
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1016
`
`
`
`W0 96/27155
`
`PCTIUS96/02303
`
`”enforced“ using the same VDE mechanisms discussed above that
`
`are used in conjunction with any component assembly 690. For
`
`example, assuming that a clause 3202(2) corresponds to a
`
`payment or BILLING condition or term, its corresponding
`
`component assembly 690 when assembled by a user’s VDE
`
`electronic appliance 600 may automatically determine whether
`
`conditions are right for payment and, when they are,
`
`automatically access an appropriate payment mechanism (e.g., a
`
`virtual ”credit card“ object forthe user) to arrange that payment
`
`to be made. As another example, assuming that electronic
`contract clause N 3202(N) corresponds to a user’s obligation to
`
`provide auditing information to a particular VDE participant,
`
`electronic contract 3200 will cause VDE electronic appliance 600
`
`to assemble a corresponding component assembly 690 that may,
`
`for example, access the appropriate audit trails within secure
`
`database 610 and provide them in an administrative object to the
`
`correct participant. Figure 75F shows that clause 3202(N) may,
`
`for example, specify a component assembly 690 that arranges for
`
`multiple steps in a transaction 3206 to occur. Some of these steps
`
`(e.g., step 3208(4), 3208(5)) may be conditional on a test (e.g.,
`
`3208(3)) such as, for example, whether content usage has
`
`I exceeded a certain amount, whether a certain time period has
`
`expired, whether a certain calendar date has been reached, etc.
`
`723
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1017
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1017
`
`
`
`WO 96/27155
`
`_
`
`PCT/US96/02303
`
`Digital signatures 3204 shown in the Figure 75E electronic
`
`contract 3200 may comprise, for example, conventional digital
`
`signatures using public key techniques as described above. Some
`
`electronic contracts 3200 may not bear any digital signatures
`
`3204. However, it may be desirable to require the electronic
`
`.
`
`appliance 600 of the user who is a party to the electronic contract
`
`3200 to digitally. ”sign“ the electronic contract so that the user
`
`cannot later repudiate the contract, for evidentiary purposes, etc.
`
`Multiple parties to the same contract may each digitally ”sign“
`
`the same electronic contract 3200 similarly to the way multiple
`
`parties to a contract memorialized in a written instrument use an
`
`ink pen to sign the instrument.
`
`Although eachof the clauses 3202 of electronic contract
`
`3200 may ultimately correspond to a collection of data and code
`
`that may be executed by a PPE 650, there may in some instances
`
`be a need for rendering a human readable version of the
`
`electronic contract. This need can be accommodated by, as
`
`mentioned above, providing text within one or more DTDs
`
`associated with the component assembly or assemblies 690 used
`
`to ”self-execute“ the contract. Such text might, for example,
`
`describe from a functional point of view what the corresponding
`
`electronic contract clause 3202 means or involves, and/or might
`
`describe in legally enforceable terms what the legal obligation
`
`under the contract is or represents. ”Templates“ (described
`
`724
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1018
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1018
`
`
`
`W0 96/27155
`
`PCTIUS96/02303
`
`elsewhere herein) might be used to supply such text from a text
`
`library. An expert system and/or artificial intelligence capability
`
`might be used to impose syntax rules that bind diflerent textual
`
`elements together into a coherent, humanly readable contract
`
`document. Such text could, if necessary, be reviewed and
`
`modified by a"’human“ attorney in order customize it for the
`
`particular agreement between the parties and/or to add further
`
`legal obligations augmenting the ”sel.f-executing“ electronic
`
`obligations embodied within and enforced by the associated
`
`component assemblies 690 executing on a VDE electronic
`
`appliance 600. Such text could be displayed automatically or on
`
`demand upon execution of the electronic contract, or it could be
`
`used to generate a printed humanly-readable version of the
`
`contract at any time. Such a document version of the electronic
`
`contract 3200 would not need to be signed in ink by the parties to
`
`H
`
`the agreement (unless desired) in view of the fact that the digital
`
`signatures 3204 would provide a sufficiently secure and trusted
`
`evidentiary basis for proving the parties’ mutual assent to all the
`
`terms and conditions within the contract.
`
`In the preferred embodiment, the negotiation process
`
`executes within a PPE 650 under the direction of a further PERC
`
`that specifies the process. Figure 75C shows an example of a
`
`PERC 3150 that specifies a negotiation process. The PERC 3150
`
`contains a single right 3152 for negotiation, with two permitted
`
`control sets 3154a, 3154b described for that right. The first
`
`725
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1019
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1019
`
`
`
`wo 95/27155
`
`PCI‘/US96/02303
`
`control set 3154a may be used for a ”trusted negotiation“; it
`
`references the desired negotiation CONTROL method
`
`(”Negotiate“) 3156 and references (in iields 3157a, 3157b) two
`
`UDEs that this CONTROL method will use. These UDEs_may
`be, for example,~the PERCS 3100, 3125 shown in Figures 75A and
`
`75B. The second control set 3154b may_ be used by ”multiple
`
`negotiation“ processes to manage the negotiation, and may
`
`provide two negotiation methods: ”Negotiate1,“ and ”Negotiate2“.
`
`Both negotiation processes may be described as required methods
`
`("Negotiate1“ and ”Negotiate2“) 3156, 3158 that take respective
`
`PERCs 3100, 3125 as their inputs. The CONTROL method 3158
`
`for this control set in this example may specify the name of a
`
`service that the two negotiation processes will use to
`
`communicate with each other, and may also manage the creation
`
`of the URT resulting from the negotiation.
`
`Whenexecuted, the negotiation process(es) specified by the
`
`PERC 3150 shown in Figure 75C may be provided with the
`
`PERCS 3100, 3125 as input that will be used as the basis for
`negotiation. In this example, the choice: of negotiation process
`type (trusted orimultiple) may be made by the executing VDE
`node. The PFIRC .3150 shown in Figure 75C might be, for
`
`example, created by a REGISTER method in response to a
`
`register request from a user. The process specified by this PERC
`
`726
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1020
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1020
`
`
`
`WO 96/27155
`
`«
`
`PCT/U596/02303
`
`3150 may then be used by a REGISTER method to initiate
`
`negotiation of the terms of an electronic contract.
`
`During this example negotiation process, the PERCs 3100,
`
`3125 shown in Figures 75A and 75B act as input data structures
`
`that are compared by a component assembly created based on
`
`PERC 3150 shown in Figure 35C. The component assembly
`
`specified by the control sets may be assembled and compared,
`
`starting with required ”terms,“ and progressing to
`
`preferred/desired ”terms“ and then moving on to permitted
`
`”terms,“ as the negotiation continues. Method option selections
`
`are made using the desired method and method options specified
`in the PERCs 3100, 3125. In this example, a control set for the
`
`PERC 3100 shown in Figure 7 5A may be compared against the
`
`PERC 3125 shown in Figure 75B. If there is a ”match,“ the
`
`negotiation is successfully concluded and ”results“ are generated.
`
`In this embodiment, the results of such negotiation will
`
`generally be written as a URT and ”signed“ by the negotiation .
`
`process(es) to indicate that an agreement has been reached.
`
`These electronic signatures provide the means to show that a
`
`(virtual) ”meeting of minds“ was reached (one of the traditional
`
`legal preconditions for a contract to exist). An example of the
`
`URT 3160 that would have been created by the above example is
`
`shown in Figure 75D‘.
`
`727
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1021
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1021
`
`
`
`wo 95/27155
`
`PCI‘/US96/02303
`
`This URT 3160 (which may itself be a PERC 808) includes
`
`a control set 3162 that reflects the ”terms“ that were ”agreed
`
`upon“ in the negotiation. In this example, the ”agreed upon“
`
`terms must ”match“ terms required by input PERCs 3100, 3125
`
`in the sense that they must be ”as favorable as“ the terms
`
`required by those PERCs. The negotiation result shown includes,
`
`for example, a ”negotiated“ control set 3162 that in some sense
`
`corresponds to the control set 3102a of the Figure 75A PERC
`
`3100 a_nd to the control set 3131a of the Figure 75B control set
`
`3125. Resulting ”negotiated“ control set 3162 thus includes a
`
`required BUDGET method 3164 that corresponds to the control
`
`set 3125 desired BUDGET method 3142 but which is ”within“ the
`
`range of control sets allowed by control set 3100 required
`
`BUDGET method 3112. Similarly, resulting negotiated control
`
`set 3162 includes a required AUDIT method 3166 that complies
`
`with the requirements of both PERC 3100 required AUDIT
`
`method 3114 and PERC 3125 required AUDIT method 3135.
`
`Similarly, resulting negotiated control set 3162 includes a
`
`required BILLING method 3170 that ”matches“ or complies with
`
`each of PERC 3100 required BILLING method 3116 and PERC
`
`3125 required BILLING method 3170.
`
`Another class of negotiation is one under which no ru.les
`
`are fixed and only the desired goals are specified._ The
`
`negotiation processes for this type of negotiation may be very
`
`728
`
`Petitioner Apple Inc. — Exhibit 1002, p. 1022
`
`Petitioner Apple Inc. - Exhibit 1002, p. 1022
`
`
`
`W0 96/27155
`
`PCT/US96/02303
`
`complex. It may utilize artificial intelligence, fuzzy logic, and/or
`
`related algorithms to reach their goals.
`
`supports these
`
`types of processes by providing a mechanism fo