g
`
`74. Please type a plus sign (+) inside this box —> [+]
`
`PTO/SB/016 (O8-O0)
`Approved fro use through 10/31/2002. OMB 0651-0031
`U.S. Patent and Trademark Office: U.S. DEPARTMENT OF COMMERCE
`Under the Paperwork Reducfion Act of 1995, no persons are required to respond to a collection of information unless it contains a valid OMB control number.
`
`PR 0 VISIONAL APPLICA TION FOR PA TENT C0 VER SHEET
`This is a request for filing a PROVISIONAL APPLICATION FOR PATENT under 37 CFR 1.53(c).
`
`0
`F
`
`/iiiiiiiiiiiiiiiii
`
`ll
`-;_-..-_5
`sf’? ifl1-I
`
`E:‘‘’
`1'‘
`
`l|||||
`
`llJllllll
`lilililiililllilllllllll
`
`
`
`4:,
`‘~ I
`
`Given Name (first and middle [if any])
`
`Family Name or Surname
`
`INVENTOR(S)
`
`Ta
`DeMartini
`Fung
`
`Residence
`(City and either State or Foreign Country)
`Huntington Beach, California
`Culver City, Calilfomia
`Cerritos, California
`
`'2] Additional inventors are being named on the Page 2 separately numbered sheets attached hereto
`
`TITLE OF THE INVENTION (280 characters max)
`
`DURING-CONDITION
`
`Direct all correspondence to:
`E] C t
`N b
`us Omar
`um er
`
`OR
`
`Firm 0’
`Individual Name
`
`CORRESPONDENCE ADDRESS
`
`22204
`
`I
`
`Place Customer Number
`Bar Code Label here
`
`Type Customer Number here
`
`Marc S Kaufman
`‘
`NIXON PEABODY LLP
`
`<70» 790-9110
`ENCLOSED APPLICATION PARTS (check all that apply)
`
`22102
`<vos>sss~os~/o
`
`Specification
`
`Number ofPages
`
`D CD(s), Number l:,
`
`El DraWing(s)
`
`NumberofSheez‘s E El Other (specify) L::I
`
`El Application Data Sheet. See 37 CFR 1.76
`METHOD OF PAYMENT OF FILING FEES FOR THIS PROVISIONAL APPLICATION FOR PATENT
`
`Applicant claims small entity status. Se 37 CFR 1.27.
`A check or money order is enclosed to cover the filing fees
`The Commissioner is hereby authorized to
`charge filing fees or credit any overpayment
`to Deposit Account Number:
`Payment by credit card. Form PTO~2038 is attached.
`The invention was made by an agency of the United States Government or under a contract with an agency of the United States
`Government.
`
`FILING FEE
`AMOUNT ($)
`$160-00
`
`19_23 80
`
`El No.
`
`D Yes, the name of the U.S. Government agency and the Government contract number are:
`
`Respectfully sub we
`
`SIGNATURE
`
` ’
`
`TYPED or PRINTED NAME Marc S. Kaufman
`
`Date
`
`1 1/20/2001
`
`REGISTRATION NO.
`(ifappropriate)
`
`Docket Number:
`
`35212
`
`1 1 1325_91
`
`.
`
`,
`
`TELEPHONE 703-790-9110
`USE 0NL Y FOR FILING A PRO VISIONAL APPLICA TION FOR PA TENT
`This collection of information is required by 37 CFR 1 51 The inforrnation is used by the public to file (and by the PTO to process) a provisional application Confidentiality is governed by 35
`USC 122 and 37 CFR I 14 This collection is estimated to take 8 hours to complete, including gathering, preparing, and submitting the complete provisional application to the PTO Time will
`vary depending upon the individual case Any comments on the amount of time you require to complete this form and/or suggestions for reducing this burden, should be sent to the Chief
`Information Officer, U S. Patent and Trademark Office, U S Dcpamnent ufComme.rce, Washington, D C 20231 DO NOT SEND FEES OR CONELETED FORMS TO THIS ADDRESS
`SEND TO Box Provisional Application, Comrrussioner for Patents, Washington, D C 20231
`NVA2054-93.1
`
`Petitione1tiApple Inc. - Ex. 1018, p. 1
`
`Petitioner Apple Inc. - Ex. 1018, p. 1
`
`

`
`Additional inventors:
`
`Page 2
`
`Family Name or Surname
`
`(City and either State or Foreign Country)
`Given Name (first and middle [if any])
`Torrance, California
`Lao
`Guillermo
`Buena Park, California
`Nguyen
`Mai
`Germantown, Maryland
`Tadayon
`Bijan
`Torrance, California
`Tieu
`Vincent
`Westminster, California
`Tran
`Duc
`
` Xin Wang Los Angeles, California
`
`
`Residence
`
`
`
`NVAZOS493 . 1
`
`Petitioner Apple Inc. - Ex. 1018, p. 2
`
`Petitioner Apple Inc. - Ex. 1018, p. 2
`
`

`
`Inventors: Thahn Ta; Thomas DeMartini; Joseph Fung; Guillermo Lao; Mai
`Nguyen; Bijan Tadayon; Vincent Tieu; Duc Tran; Xin Wang
`
`Durjrrg-»Cgnd‘;tEon
`
`Table of Contents
`
`During-Condition ......................................................................................................................................... .. 1
`Introduction .......................................................................................................................................... .. 1
`
`Summary of the invention .................................................................................................................... .. 1
`Conditions ............................................................................................................................................. .. 2
`System to validate conditions ............................................................................................................... .. 4
`Resource protection .............................................................................................................................. .. 5
`Operation Commitment ........................................................................................................................ .. 6
`Conclusion ............................................................................................................................................ .. 7
`
`Introduction
`
`The concept of conditional access is a foundation of both Access Control and DRM systems. A
`typical access condition defines a list of authorized users along with a set of access rights and
`their conditions to a given resource. Access conditions associated with a given resource can be
`predefined as simple as Access Control Lists, which define the access rights to the given
`resource for the list of users or user groups (role based). Access conditions can also be defined
`as lists of rules such as in Rule Based Access Control. Either access conditions are expressed as
`an access control list, a set of rules defined in some language or data structure, the conventional
`condition access as implemented by most systems is just an authorization process in which a
`subject (e.g., a user or a system process) can only access to a protected resources after a certain
`list of conditions have been verified.
`
`This invention extends the concepts of our previous United States patents 5629980, 5634012, 5638443,
`5715403 and 5715403 the specifications of which are incorporated by reference.
`
`Summary of the invention
`
`The invention in this proposal extends the conventional concept of prerequisite conditions for
`access to cover the entire lifecycle. The invention proposes a system design that could be used
`to verify and validate conditions either before or during usage of the protected resources. With the
`new concept, conditions are associated with both the protected resource as well as the state of
`the protected resource ~- not just associated with the resource as in the conventional concept of
`prerequisite conditions. Attaching conditions to various states of the protected resource provide
`content owners or service providers a flexible way to protect different type of resources such as
`digital work (definition of digital work is defined in our previous patents), web services, entities,
`software systems, etc. The system also proposes a flexible way to represent each condition as a
`state so that the current status and history of each condition can be logged and later be used.
`
`
`
`NVA205455.1
`
`Petitioner Apple Inc. - Ex. 1018, p. 3
`
`Petitioner Apple Inc. - Ex. 1018, p. 3
`
`

`
`
`
`
`Conditions
`
`Our framework presents a new model for authorization that integrates both authorization and
`protection for a wide range of
`resources. Like the conventional model, authorizing an
`authenticated principle the rights to access to a protected resource is based on a list of
`conditions. This type of conditions is called access condition or precondition. However, we extend
`the concept of conditions to protecting the resource during the time it is being accessed as well
`as the time the access has been committed. An example of use of this invention is the XrML
`rights language but this invention is not limited to use with XrML.
`
`Our concept of conditions is associated with the whole lifetime of the protected resource and can
`be expressed by any data structures, rules or languages. To protect a resource, conditions can
`be imposed on both tangible and intangible resources such as conditions on the principle who is
`granted access and use the protected resource, conditions on the system from which the
`resource is consumed, conditions on the time interval from which the protected document is
`allowed to access, conditions on the geography (territory), conditions on the repository from
`which the protected resource is reside, conditions on the fee that the user has to pay - either pre-
`pay, per-use or meter, conditions on the approval notice that the principle who is granted the
`rights to use the protected resource must obtain before using the protected resources, conditions
`on the notification that must be notified before or after using the resource, or conditions on the
`previous rights either related to the target protected resource or other resources. However our
`concepts of conditions are not limited to those conditions mentioned above but can be applicable
`to any resources. Resources defined in our concept of conditions can be tangible or intangible but
`must be measurable. Examples of such resources are digital document, device, system, services,
`time, fee or even permission or rights. No matter how condition is expressed - data structures,
`rules or languages - the basic information contained in a condition must include at least the
`following information: the resource — implicitly or explicitly - from which the condition is applied,
`and a set of values associated with the conditions. Optional information in conditions may include
`the method to obtain the condition value, and the server from which the condition value is
`obtained. These optional information are conditions imposed on conditions that a certain method
`must be used in order to verify a condition.
`
`Current value of conditions can be represented by a data structure called state. State contains a
`reference to the condition from which it is associated to, the current value of the condition, the
`session id of the request and information needed to verify the value of the state such as method
`used to obtain the value of the conditions, the source from which the value is obtained, etc...
`Using state to represent condition has certain advantage that it will simplify the process of verify
`conditions. The state for each of conditions is constructed and then is used to verify against the
`associated condition. Each state contains all information needed by the verifier to verify the state
`value if the verifier decides to challenge the value stored in the state.
`
`The state of a condition can either be fixed or changed over time and a collection of the states of
`conditions for a given rights/permission associated with an authenticated principle and a
`protected resource called “system state” for the principal and resource. Using the “system state”
`concept, condition for a given rights is defined as a set of required system states within which an
`authenticated principle is allowed to access to the protected resource. Thus, after a principal is
`authorized to access the resource, the system must be in one of these states; for convenience,
`we call them authorized states.
`
`Access authorization: Origin System State -> Authorized System State
`
`Once the system is in an authorized state, the authenticated principle is now able to access to the
`protected resource for an authorized operation.
`In many cases,
`it
`is not
`the authenticated
`principle itself that actually access the protected resource; rather the access is delegated to
`another authenticated principle (such as rendering application, service, etc.). While the protected
`resource is being accessed and consumed, the set of preconditions for granting the initial access
`
`NVA205455 .1
`
`Petitioner Apple Inc. - Ex. 1018, p. 4
`
`Petitioner Apple Inc. - Ex. 1018, p. 4
`
`

`
`Sends R
`
`Aciess
`
`Sm, R1. . .R,,
`
`Duri g—C0nditz'0ns
`
`Post—Condi ions
`
`-3-
`
`may no longer be applicable for authorizing the continuous access. Also, consuming the
`protected resource may transform the resource into a set of temporary resources (derived
`resources) from which the access conditions imposed on the original resources are also not
`applicable.
`In order to protect the protected resource and its derived resources while they are
`being accessed, our model introduces a new concept for authorization and protection, called
`during-conditions or protection conditions.
`
`Pre—C0nditz'ons
`
`org:
`S R—‘——:?—‘—> S,,,,,;,,R
`
`
`
`During—conditions are conditions that are transferred from the original resource to itself and any
`set of derived resources while they are being accessed and consumed by an authenticated
`principle. For example, if the protected resource is a document, which is displayed on the screen
`during the authorized operation view, then the derived resources may include the memory that
`contains the data from the document, the presentation format of the document, and the displayed
`windows. Those derived resources will all be protected by the set of during-conditions. Another
`example is that an application or user requests for a service and the requested service is a
`protected resource. Once the request is authorized, the application that executes the service may
`be considered as a derived resource and is subjected to the set of during-conditions while the
`service is being executed. During-conditions continuously change the system state until the
`derived resources are no longer used or the system state becomes unauthorized.
`
`the derived
`Once the requested operation is completed, either mandatory or voluntary, all
`resources protected by during-conditions are deleted and the system state is then transferred to
`the final state by the set of post-conditions. State of conditions after the operation completed may
`or may not be changed. Those conditions with unchanged state are called stateless conditions,
`while others are called state conditions. Stateless conditions are usually pre-conditions used to
`control the access to the protected document. Stale conditions are usually during-conditions or
`post-conditions. They are used to control the lifetime of the protected resource. (For example, the
`protected resource becomes invalid once the number of copies is reached).
`
`With different type of conditions associated with different stages of the protected resource, our
`framework does provide a complete mechanism to authorize the use of the protected resource
`and to protect that resource while it is being used.
`
`inactive Resource
`
`Active Resource (usage)
`
`Inactive/Invalid Resource (expired
`
`Pre-conditions
`
`During—conditions
`
`Post—conditions
`
`NVA20545 5.1
`
`Petitioner Apple Inc. - Ex. 1018, p. 5
`
`Petitioner Apple Inc. - Ex. 1018, p. 5
`
`

`
`System to validate conditions
`
`Based of our concepts of different types of conditions in this invention we outline a generic
`architecture for a system to enforce such conditions, which is independent of security aspect of
`principle authentication. Generic architecture consists of 3 major components:
`
`authorizes an authenticated principle for accessing a
`o Access Authorization:
`protected resource for an authorized operation.
`0 Resource Protection: protects the resource and its derived resources while they
`are being used.
`- Operation Commitment: Commit the use of the protected resource for a given
`operation.
`
`Authorization
`(pre-conditions)
`
`Protection
`(during-
`
`conditions)
`
`Commitment
`(post-condition)
`
`
`
`In recursive situations, in which multiple access is given for the same resource, the post-condition becomes
`the same as the pre-condition of the next cycle. In those cases, one may want to have a non-static
`parameter to be able to get out of the loop, for example a time-dependent condition or a condition modified
`or imposed by an external entity, such as a human intervention.
`
`In general, conditions can be static or dynamic, for example, time—dependent conditions, conditions
`dependent on other conditions, multi-variable conditions, or conditions dependent on external sources.
`This can be combined with the dynamic assignment of the rights, which we have described in more details
`in another patent application. This makes the task of creation, assignment, or modification of conditions
`more flexible and more powerful.
`
`Access authorization.
`
`Access authorization authorizes the authenticated principle the rights to access to the protected
`resource for an authorized operation. The process of authorization consists of:
`
`-
`
`Collect the current state of the system based on the list of conditions associated
`with the triple [authenticated principle, operation, protected resource]. Depend on
`each condition state can be obtained either from the local system or remote system,
`from a device, an application, a repository or a service.
`
`-
`
`o
`
`Build a goal (for example, as an XrML document) from the authenticated principle,
`desired operation, and the current state. Information used to construct the goal must
`be authenticated and authenticable.
`
`Enforce or validate the set of pre-conditions against the goal. Enforcement of a
`condition to making sure the information stored in the goal is acceptable. If not, the
`enforcer will change the information stored in the goal before authorizing the request
`for access to the protected resource. The system that accepts information stored in
`the goal called “voluntary system,” and the system that challenges information stored
`in the goal called “mandatory system”. The enforcement or validation will change the
`system from its original state to either authorized state or rejected state.
`
`NVA205455.1
`
`Petitioner Apple Inc. - Ex. 1018, p. 6
`
`Petitioner Apple Inc. - Ex. 1018, p. 6
`
`

`
`
`
`-5-
`
`0 Once conditions validated and the system is in an authorized state, the protected
`resources is then released to the either the requested principle or its delegation for
`an authorized operation.
`
`Auth. Principle
`Operation
`
`i
`
`$
`
`Conditions
`
`l
`
`Auth. State+
`
`Access Authorization (pre-conditions)
`
`Conditions
`
`Request State
`
`Goal
`Builder
`
`Condition
`Validation
`
`Resource + operation
`
`Rejected State
`
`————>
`
`Data Authenticator
`
`Resource protection
`
`Resource protection protects both the protected resource and its derived resources by enforcing
`the set of in-conditions. The authorized state returned from the Access Authorization contains the
`list of in—conditions to be enforced during the authorized operation. In the “mandatory system,” all
`the derived resources must be registered to the Resource Registrar before they are constructed
`and used. However, this invention is not limited to “mandatory systems.” During the resource
`registration and transformation, a track-able object, such as special mark or ID, will be inserted
`into the derived resource, so that they can be tracked by the resource protection component. The
`insertion mark would be in the format transparent to the application which processes the derived
`resource.
`
`0 Resource Manager — Manages both resource registration, resource transformation, and
`resource termination. The transformation of the protected resource to the derived
`resource includes the insertion of the track-able mark or ID in the derived resource. For
`example, if the protected document is the encrypted file, which represents an image, then
`the derived resources include the clear image itself and the address of the memory that
`holds the image. Special track—abIe mark (such as a watermark) can be inserted into the
`image, so that it can be tracked at any time, and the address of the memory that holds
`the image is recorded by the resource manager, so that any access to that memory can
`be tracked.
`
`0
`
`Condition Validator — Monitors the set of in-conditions and manages the current state of
`the system. Condition Enforcer interacts with the resource manager to control the derived
`resource. Once the current system state is no longer valid, the condition enforcer will
`request
`the resource manager to delete all
`the derived resources or to notify the
`application that the use of the derived resources is no longer allowed.
`
`NVA205455.1
`
`Petitioner Apple Inc. - Ex. 1018, p. 7
`
`Petitioner Apple Inc. - Ex. 1018, p. 7
`
`

`
`Derived Resources
`Registration
`
`Derived Resource
`(modified — to application)
`
`System State
`Manager
`
`'
`
`Resource
`Registration
`
`Resource
`T°1'mi“afi°“
`
`A
`
`Resource
`Transformation
`
`During-conditions
`Validator
`
`Protected Resource
`(from Access Authorization)
`
`Authorized State
`(from Access Authorization)
`
`Operation Commitment
`
`The termination of the authorized operation is controlled by a set of conditions called post-
`conditions or commitment conditions. This type of condition is to commit the use of the protected
`resource and will permanently change the system state from which the next request for use of the
`protected resources may or may not be granted, depending on the committed system state. For
`example, if the requested operation has been committed and the number of copy count (usage)
`has been reached, then the protected resource becomes no longer valid, and subsequent request
`to use the expired resource will be rejected. The commitment of the operation on the protected
`resource includes:
`
`Resource termination — This is a part of the resource management to delete all the derived
`resource once the operation is being terminated, whether or not the operation is forced to
`terminate, or the application is voluntarily terminating the operation. Deletion of the derived
`resource is important in the process of protection of the original resource.
`
`Condition validator — To actually commit the use of the protected resource and to enforce the set
`of post-conditions. Condition validator will
`invalidate the protected resource if the resource
`becomes invalid as a result of the change in the system state, committed by the post-conditions.
`
`Resource Protection
` Derived Resources
`
`
`
`Post-condition
`
`Validator
`
`Syste
`
`states
`
`Resource
`Termination
`
`Resource
`Registration
`
`
`
`
`
`
`Resource Control
`(Invulidate/validate
`the resourcefor
`next use)
`
`
`
`
`
`
`
`Operation Commitment
`
`NV'A205455.1
`
`Petitioner Apple Inc. - Ex. 1018, p. 8
`
`
`
`Petitioner Apple Inc. - Ex. 1018, p. 8
`
`

`
`Conclusion
`
`Different types of resources need different types of conditions and different mechanisms to
`protect them from illegal or unauthorized use. Whether or not a resource is a document or a
`service, in this invention we have extended the conventional access conditions, to include both
`protection and commitment conditions, and have presented a flexible mechanism to express and
`enforce such conditions.
`
`
`
`NVA20545 5 .1
`
`Petitioner Apple Inc. - Ex. 1018, p. 9
`
`Petitioner Apple Inc. - Ex. 1018, p. 9