A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
1. Field of the Invention
The invention relates to the management of resources in a computer system. More specifically, the invention relates to a method and apparatus for tracking the state of protected resources, such as digital content, and usage rights associated with the protected resources.
2. Description of the Related Art
One of the most important issues impeding the widespread distribution of digital works (i.e. documents or other content in forms readable by computers), via electronic means, and the Internet in particular, is the current lack of ability to enforce the intellectual property rights of content owners during the distribution and use of digital works. Efforts to resolve this problem have been termed “Intellectual Property Rights Management” (“IPRM”), “Digital Property Rights Management” (“DPRM”), “Intellectual Property Management” (“IPM”), “Rights Management” (“RM”), and “Electronic Copyright Management” (“ECM”), collectively referred to as “Digital Rights Management (DRM)” herein. There are a number of issues to be considered in effecting a DRM System. For example, authentication, authorization, accounting, payment and financial clearing, rights specification, rights verification, rights enforcement, and document protection issues should be addressed. U.S. Pat. Nos. 5,530,235, 5,634,012, 5,715,403, 5,638,443, and 5,629,940, the disclosures of which are incorporate herein by reference, disclose DRM systems addressing these issues.
For example, U.S. Pat. No. 5,634,012, discloses a system for controlling the distribution of digital documents. Each rendering device has a repository associated therewith. A predetermined set of usage transaction steps define a protocol used by the repositories for enforcing usage rights associated with a document. Usage rights persist with the document content. The usage rights specify various manners of use of the content such as, viewing only, use once, distribution, and the like. Pre-conditions, such as payment of a fee, proof of identity or other conditions can be required prior to permitting access to the content in accordance with the usage rights. Once the pre-conditions are satisfied access to the content is granted. The concept of conditional access is well known in access control applications also. For example, it is known to grant access to network resources upon entry of login name and password.
The concept of conditional access is a foundation for both access control and DRM systems. A typical pre-condition, i.e. a condition for granting access, defines a list of authorized users along with a set of access rights and conditions to a given resource. Pre-conditions associated with a given resource can be defined as resources associated with certain users. This is known as “role-based” access control. Pre-conditions can also be defined by rules in a process known as “rule-based” access control. Both types of pre-conditions are expressed as an access control list, which is a set of resources or rules defined in some language or data structure.
Conditional access is typically implemented by most systems as an authorization process in which a principal (e.g., a person, a system or a process) is allowed access to a protected resource after certain conditions are met and/or verified.
A first aspect of the invention is a system for managing the state of a protected resource in a system for granting access to a protected resource in accordance with usage rights. The usage rights include state variables indicating a status of an associated protected resource. The system comprises a protected resource associated with a usage right defined at least in part by a state variable, a resource control device coupled to said resource to control use of said resource by enforcing the usage right, a state controller operative to track the value of a state variable, and an interface framework operative to receive a message related to said state variable from said resource management device, load said state controller, and instruct said state controller to manipulate the value of the state variable in accordance with said message.
A second aspect of the invention is a method for managing the state of a protected resource in a system for granting access to a protected resource in accordance with usage rights including a state variable indicating a status of an associated protected resource. The method comprises transmitting a message related to the state variable from a resource control device to an interface framework, said resource control device being coupled to said resource to control use of said resource by enforcing the usage right, loading into said framework a state controller operative to track the value of the state variable, and instructing said state controller to manipulate the value of the state variable in accordance with said message.
The invention is described through a preferred embodiment and the attached drawing in which:
Different types of resources require different types of conditions and different mechanisms to protect them from unauthorized use. In the preferred embodiment conditions and rights are part of the entire lifecycle of protected resources. This means that conditions of rights are not just evaluated prior to allowing access, but are also evaluated during the actual consumption of the resource. Additionally, conditions are associated with both the protected resource and the state of the protected resource. Associating conditions with various states of a protected resource provides content owners or service providers a flexible way to protect different types of resources. Resources can be digital content, hardware, software programs, memory space, goods, services (including web services), time, fees, usage rights or a license.
Usage rights, specify manners of use. For example, a manner of use can include the ability to use an item in a specified way for a specified period of time. Further, usage rights can specify transfer rights, such as distribution rights and can permit granting of usage rights to others or the derivation of usage rights. In the preferred embodiment conditions and rights are associated to define manners of use of resources. Accordingly, conditions and rights are referred to as a single entity in the preferred embodiment. However, conditions and rights can exist separately.
The preferred embodiment verifies and validates conditions of rights prior, during and after the usage or consumption of protected resources. Rights and associated conditions can be represented as a state so that the current state and history of each right can be logged and later used. “State variables” track potentially dynamic conditions. State variables are variables having values that represent status of a resource or other dynamic conditions. State variables can be tracked, and the value of state variables can be used in a condition. For example, a usage right, as a resource, can be the right to view content and a condition can be that no other users are logged into the network when the usage right is exercised. In this example, when the value of the appropriate state indicates that other users are logged in, the condition is no longer satisfied and the content can not be viewed, or viewing is terminated.
State manager 40, a computer device in the preferred embodiment, addresses security aspects of access to resource 100 and derived resource 100a. In particular, state manager 40 may authenticate messages by verifying and validating signatures, such as a cryptographic signature, or other identifying characteristics of the messages in a known manner. State manager 40 includes, resource manager 42 and condition validator 44. Resource manager 42 is responsible for resource registration, resource transformation, and resource termination. “Transformation” refers to deriving derived resource 100a from resource 100. As illustrated in
Condition validator 44 monitors the set conditions and manages the “state of the rights”, i.e., a collection of current values of state variables for a given right, as described below. Condition validator 44 interacts with the resource manager 46, as described in greater detail below, to control derived resource 100a. When the current state of right 44b is no longer valid, i.e., does not correspond to authorized state of rights 44a condition validator 44 requests resource manager 42 to delete (or disable) all the derived resources 100a or to notify application 12 that the use of derived resources 100a is no longer allowed as described in greater detail below. State Manager 40 also includes state of rights framework 20, state controller 22, and state validator 24, all of which are described in detail below.
Access to protected resource 100 is based on conditions 80. This type of condition is referred to as an access condition or “pre-condition.” However, by associating conditions with both resource 100 and the state of resource 100, it becomes possible to protect resource 100 at various stages during its life cycle. Resource 100 can be protected before a user is granted access, when access is granted, during the actual use of resource 100 and after the use of resource 100. Conditions 80 that are associated with the entire lifecycle of the protected resource can be expressed by use of a grammar including data structures, sets of rules or a language such as XrML™. The preferred embodiment uses of XrML™ as the language to express conditions.
To protect resource 100, conditions 80 can be imposed on resource 100 itself, or any other resources—either tangible or intangible—including those resources that make up any executing environments, such as a application 12 of client environment 30, from which protected resource 100 is accessed and used.
Conditions 80 can be the identity of a user or a group of users who is/are granted access as principals and who use protected resource 100. Examples of conditions 80 are set forth below as expressed in the XrML™ language. Example A expresses a condition associated with a principal “Edgar” who is granted the right to “view” the protected digital content “XrML Book”. Example B expresses a condition associated with a group of principals, i.e. all persons that fall under the category “ContentGuard employee” who are granted the right to print the protected digital work “XrML Book”.
Conditions 80 can be conditions on principals who must possess certain properties, such as a certain title, or rights, such as a security clearance. Example C expresses the condition that principals must possess a manager's badge.
Conditions 80 can be conditions on the time interval for access to the protected item. Example D below expresses conditions that key holder “Edgar”, as a principal, can view the content “XrML book” not before May 29, 2002 and not after May 29, 2003.
Conditions 80 can be related to the physical location of the principal or resource used to access content. Example E below expresses the condition that anyone currently in US can print the content “XrML Book”
Conditions 80 can specify a fee that the principal must pay for access. Example F below expresses the condition that anyone can print the content “XrML book” upon payment of a fee of $3.10. Example G below expresses the condition that anyone can print the content “XrML book” upon payment of a fee of $3.10 for each print. Example H below expresses the condition that anyone can view the content “XrML book upon payment of a fee of $10.00 per hour of viewing time.
Example I below expresses the condition that anyone can print the content but the exercise of the print right will be tracked by a tracking service before printing.
Conditions 80 may also be conditions on the system in which resource 100 is consumed. For example, condition 80 may require that the system has an authorized security mechanism or other specific hardware or software, or only a specific maximum number of users are logged on.
Conditions 80 can specify the repository or other device in which resource 100, such as content, resides. Conditions 80 can relate to the approval notice that the principal must obtain before using the protected resources 100. Conditions 80 can require notification before or after using resource 100. Conditions 80 can specify the previous rights related to the protected resource 100 or other resources. Conditions 80 can also be imposed on other conditions 80 such as how to verify a condition.
Of course, conditions 80 are not limited to the above examples, but can be any restriction, obligation or requirement that is associated with a right to protected resource 100 as pre-conditions, during-access conditions, post-conditions or other conditions. Also, even though the examples above are expressed using XrML™ conditions are not limited to or by XrML and can be expressed in any manner.
As noted above, state variables 84 represent the status of condition 80. Each state variable 44 has a corresponding value at any moment in time for the principal, right, and resource. As note above, the collection of current values of state variables for a given right is referred to as the “state of rights” herein.
Using state of rights 50 to represent condition 80 for a right simplifies the process of verifying conditions 80 because all the information needed to verify condition 80 is readily accessible. State of rights 50 is constructed and then used whenever the corresponding condition 80 is evaluated and verified. Each state of rights 50 can contain all information needed to verify values 52 of state variables 84.
An authenticated principal is a user that has been processed by a system which validates the authenticity of that user, for example when a user successfully logs-in with a user name and a password, the user becomes an authenticated principal or just “principal”. Condition 80 for a given set of rights is defined as a set of required states variable values under which a principal is allowed to access protected resource 100. When an authenticated principal wishes to access protected resource 100, the system state changes from an “original state” to an “authorized state”.
Once the system is in an authorized state the principal is then able to access the protected resource 100 for an authorized operation. In many cases, it is not the authenticated principal itself that actually accesses protected resource 100. For example, the access can be delegated to another authenticated principal such as a rendering application, service, or the like. While protected resource 100 is being accessed and consumed, the set of pre-conditions 80 for granting the initial access may no longer be applicable for authorizing continued access. Also, consuming protected resource 100 may transform the resource into a set of temporary, i.e., derived, resources 100a from which the access conditions 80 imposed on the original resources are also not applicable. In order to protect resource 100 and its derived resources 100a while they are being accessed, the preferred embodiment uses a concept for authorization and protection called “during-access conditions” which is described in detail below.
In a conventional system, resources are in one of two states. As illustrated in
During-access conditions are transferred from the original resource 100 to itself and any of derived resources 100a while they are being accessed and consumed by an authenticated principal. For example, if resource 100 is a document which is displayed on a screen of client environment 30 during the authorized operation “view,” then derived resources 100a may include the memory that contains the data from the document, the presentation format of the document, and the displayed windows respectively. Derived resources 100a will all be protected by the set of during-access conditions. In other words, the principal will only have access to derived resources 100a as long as the during-access conditions are satisfied. During-access conditions can be defined in the same manner as other conditions 80.
Another example is where an application, such as application 12, requests a service that is a protected resource 100. 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-access conditions while the service is being executed. During-access conditions define authorized state of rights 44a are applied to current state of rights 44b in the manner described n detail below. Once the requested operation is completed, either mandatory or voluntarily, all derived resources 100a protected by during-access conditions are deleted (or disabled) and the system state is then transferred to the final state by the set of post-access conditions.
Conditions 80 after or during the use or access of a resource may or may not change. Those conditions with unchanged state are called “stateless conditions”, while conditions that change after or during the use of the resource are called “stateful conditions”. Pre-conditions 80 are usually stateless conditions 80 and are used to control the access to the protected document. During-access conditions and post-conditions are usually stateful conditions 80. They are used to control the lifetime of protected resource 100. (For example, protected resource 100 can no longer be accessed once a specific number of users logged into a network has been exceeded.) With these expanded types of conditions 80 associated with different stages of protected resource 100, the preferred embodiment provides a mechanism to authorize the use of protected resource 100 and to protect and track resource 100 while it is being used.
As illustrated in
In recursive situations, in which multiple accesses are given for the same resource 100, the post-condition can be the same as the pre-condition of the next cycle. In such a case, a non-static parameter can be used in order to prevent infinite loop situations. For example a time-dependent condition or a condition modified or imposed by an external entity, such as human intervention.
Access authorization grants an authenticated principal the right(s) to access protected resource 100 for an authorized operation. Pre-conditions are evaluated, i.e., enforced, against the state of rights. If enforcement is successful, resource 100 and any derived resources 100a enter the authorized state in step 406 and during-access conditions begin to be enforced.
As noted above, resource protection protects both the initial protected resource 100 and its derived resources, 100a by enforcing the set of during-access conditions. The authorized state returned from the access authorization state contains the list of during-access conditions to be enforced during the authorized operation. In a mandatory system all derived resources 100a can be registered with resource repository 46 (see
The termination of an authorized operation executes the set of post conditions (if any are present). Executing post-conditions can permanently change the state of rights and affects the next request for access to resource 100. For example, if a post condition is the removal of access to the resource 100 after an exercise limit has been reached, when the limit is reached the resource 100 is deleted or some other action is taken which disables or prevents access. Operation termination can include resource termination. Resource manager 42 can delete (disable) derived resources 100a when the operation is being terminated, whether or not the operation is forced to terminate, or the application is voluntarily terminating the operation. Deletion (or disabling) of derived resource 100a is important in the process of protection of resource 100. Condition validator 44 commits the use of protected resource 100 and enforce the set of post-conditions. Condition validator 44 will invalidate (disable) protected resource 100 if resource 100 becomes invalid as a result of the change in the system state.
It can be seen that the state of rights may change during the use of resource 100 and therefore, there is a need to maintain, update and retrieve the state of rights. As noted above, condition validator 44 accesses current state of rights 44b to validate conditions 80 that are associated with rights. While resources 100 are being used or accessed, Condition validator 44 monitors the set of during-conditions and manages the current state of rights 44b. Condition validator 44 interacts with resource manager 42 to control derived resource 100a. When the current state of rights is no longer valid, i.e., no longer satisfies the during-access conditions the during-condition validator 44 requests that resource manager 42 delete (or disable) all the derived resources 100a or to notify application 12 that the use of derived resources 100a is no longer allowed. Using the state of rights to represent condition 80 simplifies the process of verifying conditions 80 because all the information needed to verify a specific condition 80 is readily available.
As illustrated in
Each state controller 22 is a component that manages the state for, i.e., tracks the value of a given state variable. The basic structure of state controller 22 consists of a software component that manipulates APIs defined by state of rights framework 20, a protocol to interact with the persistent storages or services to store, and update and query for the current value of the state variable and the history of the state variable. The location of the persistent storage or service that manages the state variable is thus transparent to the state of rights framework 20.
Each state validator 24 is a component that verifies the value of a state variable. Each state validator 24 includes a software component that implements the set of interfaces defined by state validation and monitoring API 20c of rights framework 20. Like state controller 22 the state validator 24 may operate locally or remotely.
As illustrated in
Like state variables, the values can be represented by a grammar such as a data structure or the XrML™ rights language that describes the current value. The preferred embodiment uses XrML™ to define the state variables and extensions thereof to define the value of the state variables. However the representation of the state variables and its values are not limited to or by XrML™. The following example, shows how a state variable can be defined using XrML™.
The above example describes the state variable of a print right that allows no more than 9 copies of the resource to be printed. The value associated with a condition could be as simple as a number as in an example of an exercise limit, or could be a boolean value “yes” or “no” as in an example of requiring an approval. The value can also be stored and managed by a service or component as shown in example K below.
Example K illustrates a state associated with a floating interval of a “play” right. In this example, the state variable does not contain an actual value associated with the condition. Rather, the remote service (stateReference), acting as state controller 22 is the one that manages the value and it is “opaque” in the expression for the state variable.
State manipulation API 20b includes a query interface to query the values of a state variable. A query for a value state variable requires an input that contains the state variable to be queried and the value-type of the response. The value of the response for the state query can be the state value, the state history or both.
The following example L the value of a state variable “exerciseLimit” associated with a “print” right.
In order to process the query, the state of rights framework 20 will determine what state controller 22 is responsible for this request and then locate, authenticate and load that specific state controller 22 and pass the request to the state controller 22 for processing. State controller 22 can be local or remote. Once the request is processed the response is then returned to the requester via the state of rights framework 20. The following example M describes the response
The query response contains the original query, current value of the queried state variable if available, current status of the state variable or the state history, an identification, a session id and a digital signature of the response. The digital signature can be used guarantee the integrity of the response.
The state can only be updated based on the prior response of the state query provided that the “session ID” in the state query's response is valid. The sessionID is used in the preferred embodiment to identify a request, but any other identification can be used to match the query and the update. Thus, state manage 40 must query the current value of the state variable to obtain the state variable value and the valid session ID in order to update the target state variable. Updating the value of state variable will change the current value of the state variable to the new value.
There are many constraints that can be imposed on updating the value of the state variable. For example, the rights associated with the state variable must still be valid prior to the update request. Another constraint can be that the new value of the state variable after updating must be a valid value allowed for the state variable. For example if the maximum print copy (state variable) is 4 and the current print copy is 3 (current value of state variable) then a request for 2 more copies (update value) will be rejected because the value of the state variable after updating is not an allowed value. Additionally, The principal or the application making the request for the update must be authorized to do so. State of rights framework 20 will identify, authenticate and load state controller 22 to process an updating request. Example M below is an example of a request to update a state value.
State value transfer is similar to the state value update in terms of state management. The main different between the two is how the state history for the state variable is maintained. Once the state is transferred, the current value of the state variable and its history are updated according to the transfer. If the rights from which its states are transferred expire as the result of the state transfer then the transfer is called a complete transfer, otherwise it is called a partial transfer. A state value transfer can have the same constraint as the state value update. The elements involved in the transfer of the state value can be authorized before the transfer occurs.
State manager 40 also manages a set of state validators 24 and provides the set of interfaces to the application which verifies each state variable individually or as a set representing the state of rights. Recall that state of rights is the collection of current values of state variables associated with a given right. State of rights framework 20 will select and load the appropriate state validator 24 for each of the state variables. Once the state validator 24 is selected and loaded, state of rights framework 20 then passes the request to the target state validator 24 and waits for the result as a response message. State manager 40 may concurrently execute all state validators 24 at once or sequentially execute them depending on the dependency between state variables and the configuration of the system.
State validator 24 verifies the state variable value given a state query response. Upon receiving the request for validation for a state variable, state of rights framework 20 examines the state query response and then selects, authenticates and loads the appropriate state validator 24 and passes the state query response to the state validator 24. Based on a configurable policy and information stored in the state query state validator 24 may accept or challenge the information stored in both the state query and response. Once the information stored in the state query and response are verified, the validation process can be as simple as comparing the current value of the state variable with the set of possible (or allowed) values of the state variable. Each state validator 24 can include a software component that implements the set of interfaces defined by state of rights framework 20. State validator 24 may operate locally or remotely.
The preferred embodiment can utilize various devices, such as a personal computers, servers, workstations, PDA's, thin clients and the like. For example, the client environment can be a handheld device such as a mobile phone or a PDA. Various channels for communication can be used. Further, the various functions can be integrated in one device. The disclosed functional devices and modules are segregated by function for clarity. However, the various functions can be combined or segregated as hardware and/or software modules and devices in any manner. The various functions modules and devices have utility separately or in combination.
The various records, messages, elements and portions thereof can be stored on the same device or on different devices. Various links, references, specifications, and the like can be used to associate the elements. Access to any type of resource can be controlled. Any mechanism for tracking values of state variables can be used.
The invention has been described through a preferred embodiment and examples. However, various modifications can be made without departing from the scope of the invention as define by the appended claims and legal equivalents.
This application claims benefit from U.S. provisional application Ser. Nos. 60/331,621 filed on Nov. 20, 2001, 60/331,623 filed on Nov. 20, 2001, 60/331,624 filed on Nov. 20, 2001, 60/331,625 filed on Nov. 20, 2001, 60/296,113, filed on Jun. 7, 2001, 60/296,117 filed on Jun. 7, 2001, and 60/296,118 filed on Jun. 7, 2001, the disclosures of which are incorporated herein by reference. This application is a continuation-in-part of copending application Ser. No. 09/867,745 filed on May 31, 2001, the disclosures of which is also incorporated herein by reference.
Number | Name | Date | Kind |
---|---|---|---|
3263158 | Janis | Jul 1966 | A |
3609697 | Blevins et al. | Sep 1971 | A |
3790700 | Callais et al. | Feb 1974 | A |
3798605 | Feistel | Mar 1974 | A |
4159468 | Barnes et al. | Jun 1979 | A |
4220991 | Hamano et al. | Sep 1980 | A |
4278837 | Best | Jul 1981 | A |
4323921 | Guillou | Apr 1982 | A |
4442486 | Mayer | Apr 1984 | A |
4529870 | Chaum | Jul 1985 | A |
4558176 | Arnold et al. | Dec 1985 | A |
4593376 | Volk | Jun 1986 | A |
4614861 | Pavlov et al. | Sep 1986 | A |
4644493 | Chandra et al. | Feb 1987 | A |
4658093 | Hellman | Apr 1987 | A |
4713753 | Beobert et al. | Dec 1987 | A |
4740890 | William | Apr 1988 | A |
4796220 | Wolfe | Jan 1989 | A |
4817140 | Chandra et al. | Mar 1989 | A |
4868376 | Lessin et al. | Sep 1989 | A |
4891838 | Faber | Jan 1990 | A |
4924378 | Hershey et al. | May 1990 | A |
4932054 | Chou et al. | Jun 1990 | A |
4937863 | Robert et al. | Jun 1990 | A |
4949187 | Cohen | Aug 1990 | A |
4953209 | Ryder, Sr. et al. | Aug 1990 | A |
4961142 | Elliott et al. | Oct 1990 | A |
4975647 | Downer et al. | Dec 1990 | A |
4999806 | Chernow et al. | Mar 1991 | A |
5010571 | Katznelson | Apr 1991 | A |
5014234 | Edwards, Jr. | May 1991 | A |
5023907 | Johnson et al. | Jun 1991 | A |
5047928 | Wiedemer | Sep 1991 | A |
5052040 | Preston et al. | Sep 1991 | A |
5058164 | Elmer et al. | Oct 1991 | A |
5103476 | Waite et al. | Apr 1992 | A |
5113519 | Johnson et al. | May 1992 | A |
5136643 | Fischer | Aug 1992 | A |
5138712 | Corbin | Aug 1992 | A |
5146499 | Geffrotin | Sep 1992 | A |
5148481 | Abraham et al. | Sep 1992 | A |
5159182 | Eisele | Oct 1992 | A |
5183404 | Aldous et al. | Feb 1993 | A |
5191193 | Le Roux | Mar 1993 | A |
5204897 | Wyman | Apr 1993 | A |
5222134 | Waite et al. | Jun 1993 | A |
5235642 | Wobber et al. | Aug 1993 | A |
5247575 | Sprague et al. | Sep 1993 | A |
5255106 | Castro | Oct 1993 | A |
5260999 | Wyman | Nov 1993 | A |
5263157 | Janis | Nov 1993 | A |
5263158 | Janis | Nov 1993 | A |
5276444 | McNair | Jan 1994 | A |
5276735 | Boebert et al. | Jan 1994 | A |
5291596 | Mita | Mar 1994 | A |
5293422 | Loiacono | Mar 1994 | A |
5295266 | Hinsley et al. | Mar 1994 | A |
5301231 | Abraham et al. | Apr 1994 | A |
5311591 | Fischer | May 1994 | A |
5319705 | Halter et al. | Jun 1994 | A |
5335346 | Fabbio | Aug 1994 | A |
5337357 | Chou et al. | Aug 1994 | A |
5339091 | Yamazaki et al. | Aug 1994 | A |
5341429 | Stringer et al. | Aug 1994 | A |
5347579 | Blandford | Sep 1994 | A |
5381526 | Ellson | Jan 1995 | A |
5386369 | Christiano | Jan 1995 | A |
5394469 | Nagel et al. | Feb 1995 | A |
5412717 | Fischer | May 1995 | A |
5428606 | Moskowitz | Jun 1995 | A |
5432849 | Johnson et al. | Jul 1995 | A |
5438508 | Wyman | Aug 1995 | A |
5444779 | Daniele | Aug 1995 | A |
5453601 | Rosen | Sep 1995 | A |
5455953 | Russell | Oct 1995 | A |
5457746 | Dolphin | Oct 1995 | A |
5473687 | Lipscomb et al. | Dec 1995 | A |
5473692 | Davis | Dec 1995 | A |
5485577 | Eyer et al. | Jan 1996 | A |
5499298 | Narasimhalu et al. | Mar 1996 | A |
5502766 | Boebert et al. | Mar 1996 | A |
5504814 | Miyahara | Apr 1996 | A |
5504818 | Okano | Apr 1996 | A |
5504837 | Griffeth et al. | Apr 1996 | A |
5509070 | Schull | Apr 1996 | A |
5530235 | Stefik et al. | Jun 1996 | A |
5532920 | Hartrick et al. | Jul 1996 | A |
5534975 | Stefik et al. | Jul 1996 | A |
5539735 | Moskowitz | Jul 1996 | A |
5563946 | Cooper et al. | Oct 1996 | A |
5568552 | Davis | Oct 1996 | A |
5621797 | Rosen | Apr 1997 | A |
5629980 | Stefik et al. | May 1997 | A |
5633932 | Davis et al. | May 1997 | A |
5634012 | Stefik et al. | May 1997 | A |
5638443 | Stefik et al. | Jun 1997 | A |
5649013 | Stuckey et al. | Jul 1997 | A |
5655077 | Jones et al. | Aug 1997 | A |
5708709 | Rose | Jan 1998 | A |
5708717 | Alasia | Jan 1998 | A |
5734823 | Saigh et al. | Mar 1998 | A |
5734891 | Saigh | Mar 1998 | A |
5737413 | Akiyama et al. | Apr 1998 | A |
5737416 | Cooper et al. | Apr 1998 | A |
5745569 | Moskowitz et al. | Apr 1998 | A |
5748783 | Rhoads | May 1998 | A |
5757907 | Cooper et al. | May 1998 | A |
5761686 | Bloomberg | Jun 1998 | A |
5764807 | Pearlman et al. | Jun 1998 | A |
5765152 | Erickson | Jun 1998 | A |
5768426 | Rhoads | Jun 1998 | A |
5825892 | Braudaway et al. | Oct 1998 | A |
5848154 | Nishio et al. | Dec 1998 | A |
5892900 | Ginter et al. | Apr 1999 | A |
5917912 | Ginter et al. | Jun 1999 | A |
5991306 | Burns et al. | Nov 1999 | A |
6047067 | Rosen | Apr 2000 | A |
6112239 | Kenner et al. | Aug 2000 | A |
6115471 | Oki et al. | Sep 2000 | A |
6209092 | Linnartz | Mar 2001 | B1 |
6226618 | Downs et al. | May 2001 | B1 |
6233684 | Stefik et al. | May 2001 | B1 |
6253193 | Ginter et al. | Jun 2001 | B1 |
6301660 | Benson | Oct 2001 | B1 |
6327652 | England et al. | Dec 2001 | B1 |
6330670 | England et al. | Dec 2001 | B1 |
6345256 | Milsted et al. | Feb 2002 | B1 |
6397333 | Söhne et al. | May 2002 | B1 |
Number | Date | Country |
---|---|---|
0 084 441 | Jul 1983 | EP |
0 180 460 | May 1986 | EP |
0 332 304 | Sep 1989 | EP |
0 332 707 | Sep 1989 | EP |
0 651 554 | May 1995 | EP |
0 668 695 | Aug 1995 | EP |
0 715 246 | Jun 1996 | EP |
0 725 376 | Aug 1996 | EP |
0 731 404 | Sep 1996 | EP |
0 818 748 | Jan 1998 | EP |
0 818 748 | Jan 1998 | EP |
1 041 823 | Oct 2000 | EP |
2 136 175 | Sep 1984 | GB |
2 236 604 | Apr 1991 | GB |
62-241061 | Oct 1987 | JP |
64-068835 | Mar 1989 | JP |
H03-282733 | Mar 1990 | JP |
04-369068 | Dec 1992 | JP |
05-268415 | Oct 1993 | JP |
06-175794 | Jun 1994 | JP |
06-215010 | Aug 1994 | JP |
07-084852 | Mar 1995 | JP |
07-200317 | Aug 1995 | JP |
07-244639 | Sep 1995 | JP |
0 715 241 | Jun 1996 | JP |
WO 9220022 | Nov 1992 | WO |
WO 9301550 | Jan 1993 | WO |
WO 9401821 | Jan 1994 | WO |
WO 9624092 | Aug 1996 | WO |
WO 9748203 | Dec 1997 | WO |
WO 9811690 | Mar 1998 | WO |
WO 9842098 | Sep 1998 | WO |
WO 9949615 | Sep 1999 | WO |
WO 0059152 | Oct 2000 | WO |
WO 0073922 | Dec 2000 | WO |
WO 01 13198 | Feb 2001 | WO |
WO 0124530 | Apr 2001 | WO |
WO 0163528 | Aug 2001 | WO |
Number | Date | Country | |
---|---|---|---|
20030182235 A1 | Sep 2003 | US |
Number | Date | Country | |
---|---|---|---|
60331621 | Nov 2001 | US | |
60331623 | Nov 2001 | US | |
60331624 | Nov 2001 | US | |
60331625 | Nov 2001 | US | |
60296113 | Jun 2001 | US | |
60296117 | Jun 2001 | US | |
60296118 | Jun 2001 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 09867745 | May 2001 | US |
Child | 10163631 | US |