throbber
W0 96/27155
`
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket