U.S. patent application number 11/412348 was filed with the patent office on 2006-10-26 for trusted infrastructure support systems, methods and techniques for secure electronic commerce, electronic transactions, commerce process control and automation, distributed computing and rights management.
This patent application is currently assigned to Intertrust Technologies Corp.. Invention is credited to Karl L. Ginter, Victor H. Shear, Francis J. Spahn, David M. Van Wie, Robert P. Weber.
Application Number | 20060242075 11/412348 |
Document ID | / |
Family ID | 37036736 |
Filed Date | 2006-10-26 |
United States Patent
Application |
20060242075 |
Kind Code |
A1 |
Ginter; Karl L. ; et
al. |
October 26, 2006 |
Trusted infrastructure support systems, methods and techniques for
secure electronic commerce, electronic transactions, commerce
process control and automation, distributed computing and rights
management
Abstract
The present inventions provide an integrated, modular array of
administrative and support services for electronic commerce and
electronic rights and transaction management. These administrative
and support services supply a secure foundation for conducting
financial management, rights management, certificate authority,
rules clearing, usage clearing, secure directory services, and
other transaction related capabilities functioning over a vast
electronic network such as the Internet and/or over organization
internal Intranets. These administrative and support services can
be adapted to the specific needs of electronic commerce value
chains. Electronic commerce participants can use these
administrative and support services to support their interests, and
can shape and reuse these services in response to competitive
business realities. A Distributed Commerce Utility having a secure,
programmable, distributed architecture provides administrative and
support services. The Distributed Commerce Utility makes optimally
efficient use of commerce administration resources, and can scale
in a practical fashion to accommodate the demands of electronic
commerce growth. The Distributed Commerce Utility may comprise a
number of Commerce Utility Systems. These Commerce Utility Systems
provide a web of infrastructure support available to, and reusable
by, the entire electronic community and/or many or all of its
participants. Different support functions can be collected together
in hierarchical and/or in networked relationships to suit various
business models and/or other objectives. Modular support functions
can combined in different arrays to form different Commerce Utility
Systems for different design implementations and purposes. These
Commerce Utility Systems can be distributed across a large number
of electronic appliances with varying degrees of distribution.
Inventors: |
Ginter; Karl L.;
(Beltsville, MD) ; Shear; Victor H.; (Bethesda,
MD) ; Spahn; Francis J.; (El Cerrito, CA) ;
Van Wie; David M.; (Sunnyvale, CA) ; Weber; Robert
P.; (Menlo Park, CA) |
Correspondence
Address: |
FINNEGAN, HENDERSON, FARABOW, GARRETT & DUNNER;LLP
901 NEW YORK AVENUE, NW
WASHINGTON
DC
20001-4413
US
|
Assignee: |
Intertrust Technologies
Corp.
|
Family ID: |
37036736 |
Appl. No.: |
11/412348 |
Filed: |
April 27, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09398665 |
Sep 17, 1999 |
|
|
|
11412348 |
Apr 27, 2006 |
|
|
|
08699712 |
Aug 12, 1996 |
|
|
|
09398665 |
Sep 17, 1999 |
|
|
|
08388107 |
Feb 13, 1995 |
|
|
|
08699712 |
Aug 12, 1996 |
|
|
|
Current U.S.
Class: |
705/54 ;
348/E5.006; 348/E5.008; 348/E7.06; 348/E7.07; 375/E7.009;
375/E7.024; 375/E7.025 |
Current CPC
Class: |
H04L 2209/56 20130101;
H04N 7/162 20130101; H04L 2209/603 20130101; H04N 21/835 20130101;
G06Q 20/12 20130101; H04N 21/235 20130101; H04L 9/321 20130101;
H04N 21/6581 20130101; G06Q 40/12 20131203; H04N 21/4143 20130101;
H04N 21/4753 20130101; G06F 2221/2135 20130101; G06F 2221/2101
20130101; G06Q 20/10 20130101; H04N 21/4345 20130101; H04L 9/3263
20130101; H04N 21/2541 20130101; G06F 21/31 20130101; G06T 1/0021
20130101; H04N 21/23476 20130101; G06Q 20/123 20130101; G06Q 20/24
20130101; H04L 2463/101 20130101; H04N 21/83555 20130101; G06F
21/10 20130101; G06F 21/33 20130101; H04L 63/068 20130101; H04L
2463/102 20130101; H04N 21/2347 20130101; H04N 21/2543 20130101;
H04N 21/8166 20130101; G06Q 20/023 20130101; G06Q 30/06 20130101;
H04N 21/2362 20130101; H04N 21/435 20130101; H04N 21/443 20130101;
G07F 9/026 20130101; H04N 21/8358 20130101; H04N 21/8355 20130101;
G06F 2211/007 20130101; H04N 7/17309 20130101; G06F 21/00 20130101;
G06Q 20/14 20130101; H04L 63/0823 20130101; H04N 21/2547 20130101;
H04N 21/25875 20130101; H04N 21/44204 20130101; G06F 2221/0737
20130101; G06F 2221/0797 20130101; G06F 2221/2151 20130101; G06F
21/86 20130101; G06Q 20/1235 20130101; H04N 21/4405 20130101; H04L
2463/103 20130101; H04N 21/4627 20130101; G06Q 20/04 20130101; G06F
12/1408 20130101; G06Q 20/02 20130101 |
Class at
Publication: |
705/054 |
International
Class: |
G06Q 99/00 20060101
G06Q099/00 |
Claims
1-20. (canceled)
21. A method performed by an electronic appliance, the method
comprising: displaying a rights template, the rights template
defining a number of different types of usage relevant to a digital
property and a menu of options corresponding to each type of usage;
filling in the menu of options based at least in part on input from
a rightsholder; translating the rights template into a control set;
associating the control set with the digital property, the control
set being configured to be used by tamper-resistant hardware and/or
software at a user's electronic appliance to govern use of the
digital property by the user; and sending the control set to a
first remote site.
22. The method of claim 21, further comprising: sending the digital
property to the first remote site.
23. The method of claim 22, in which the control set is sent to the
first remote site separately from the digital property.
24. The method of claim 22, in which the control set and the
digital property are sent to the first remote site together in a
secure container.
25. The method of claim 21, in which the first remote site
comprises a user site operable to use the control set to govern use
of the digital property.
26. The method of claim 25, in which the user site includes a
secure processing unit for use, at least in part, in governing use
of the digital property.
27. The method of claim 21, further comprising: sending the control
set from the first remote site to a user site, wherein the user
site is operable to use the control set to govern use of the
digital property.
28. The method of claim 21, in which at least part of the menu of
options is automatically filled in without provision of input from
the rightsholder.
29. The method of claim 21, in which the one or more potential
actions include two or more of: (a) viewing the digital property;
(b) distributing the digital property; (c) printing the digital
property; and (d) modifying the digital property.
30. The method of claim 21, further comprising: encrypting the
digital property and the control set.
31. A computer-readable medium containing executable program
instructions, the executable program instructions including
instructions for: displaying a graphical user interface comprising
a template for facilitating specification, by a user, of
permissions to be associated with a piece of digital content, the
template including a list of potential actions to be performed on
or using the piece of digital content, the template further
providing a place for the user to specify if a given action is to
be permitted; obtaining user input from the user, the user input
specifying one or more permitted actions; and generating a control
set based on the user input, the control set being associated with
the piece of digital content, the control set being configured to
be used by tamper-resistant hardware and/or software at an
electronic appliance to govern use of the piece of digital content
by the electronic appliance in accordance with the one or more
permitted actions specified by the user input.
32. The computer-readable medium of claim 31, in which the
executable program instructions further include instructions for
encrypting the piece of digital content.
33. The computer-readable medium of claim 32, in which the
executable program instructions further include instructions for
encrypting the control set.
34. The computer-readable medium of claim 31, in which the one or
more potential actions include two or more of: (a) viewing the
piece of digital content; (b) distributing the piece of digital
content; (c) printing the piece of digital content; and (d)
modifying the piece of digital content.
35. The computer-readable medium of claim 33, in which the one or
more potential actions include three or more of: (a) viewing the
piece of digital content; (b) distributing the piece of digital
content; (c) printing the piece of digital content; and (d)
modifying the piece of digital content.
36. The computer-readable medium of claim 31, in which the one or
more potential actions include three or more of: (a) viewing the
piece of digital content; (b) distributing the piece of digital
content; (c) printing the piece of digital content; and (d)
modifying the piece of digital content.
37. The computer-readable medium of claim 31, in which the one or
more potential actions include viewing the piece of digital
content.
38. The computer-readable medium of claim 31, in which the one or
more potential actions include distributing the piece of digital
content.
39. The computer-readable medium of claim 31, in which the one or
more potential actions include printing the piece of digital
content.
40. The computer-readable medium of claim 31, in which the one or
more potential actions include modifying the piece of digital
content.
41. The computer-readable medium of claim 31, in which the one or
more potential actions include: (a) printing the piece of digital
content; and (b) modifying the piece of digital content.
42. The computer-readable medium of claim 41, in which the piece of
digital content comprises textual content.
43. A method for specifying usage permissions for a piece of
digital content: displaying a graphical user interface to a
rightsholder, the graphical user interface including a menu of
potentially permitted actions to be performed on or using the piece
of digital content, the potentially permitted actions including
modifying the piece of digital content; obtaining input from the
rightsholder, the input indicating that one or more of the
potentially permitted actions are to be permitted; and associating
an indication of the permitted actions with the piece of digital
content.
44. The method of claim 43, in which the indication of the
permitted actions is securely associated with the piece of digital
content, such that software that is unable to enforce the
indication of the permitted actions is prevented from making use of
the piece of digital content.
45. The method of claim 43, in which the piece of digital content
is encoded for decoding by tamper-resistant software operable to
enforce the indication of the permitted actions.
46. The method of claim 43, further comprising: sending the piece
of digital content and the indication over a telecommunications
network to a user's computer system, the user's computer system
including tamper-resistant software for using the piece of digital
content in accordance with the indication.
47. The method of claim 46, in which the piece of digital content
and the indication are sent to the user's computer system
separately.
48. The method of claim 43, further comprising: packaging the piece
of digital content and the indication in a secure electronic
container.
49. The method of claim 46, further comprising: encrypting the
piece of digital content.
50. The method of claim 46, in which the user's computer system
further includes a secure processing unit for assisting the
tamper-resistant software in using the piece of digital content in
accordance with the indication.
51. The method of claim 43, in which the piece of digital content
comprises audio, video, and/or textual content.
52. The method of claim 43, in which the potentially permitted
actions further include two or more of: (a) viewing the piece of
digital content; (b) distributing the piece of digital content; and
(c) printing the piece of digital content.
53. A method for packaging rights-managed digital content:
obtaining input comprising an indication of one or more actions
permitted to be performed on or using a piece of digital content;
associating control information with the piece of digital content,
the control information including information recording the one or
more permitted actions; and encrypting the piece of digital content
and the control information.
54. The method of claim 53, further comprising displaying a
graphical user interface to a holder of rights in the piece of
digital content, the graphical user interface being configured to
facilitate the step of obtaining input.
55. The method of claim 54, in which the step of obtaining input
comprises receiving selections made by the holder of rights using a
mouse pointing device.
56. The method of claim 54, in which the graphical user interface
comprises a menu of potentially permissible actions.
57. The method of claim 53, in which the indication comprises a
rights management language expression of the one or more actions
permitted to be performed on or using the piece of digital
content.
58. The method of claim 56, in which the potentially permissible
actions include one or more of: modifying the piece of digital
content, printing the piece of digital content, viewing the piece
of digital content, distributing the piece of digital content,
viewing a predefined portion of the piece of digital content,
and/or saving a backup of the piece of digital content.
59. The method of claim 57, in which the potentially permissible
actions include one or more of: modifying the piece of digital
content, printing the piece of digital content, viewing the piece
of digital content, distributing the piece of digital content,
viewing a predefined portion of the piece of digital content,
and/or saving a backup of the piece of digital content.
60. The method of claim 56, in which the graphical user interface
further comprises checkboxes for indicating whether one or more of
the potentially permissible actions are permitted.
61. The method of claim 56, in which the graphical user interface
further comprises checkboxes for indicating whether one or more of
the potentially permissible actions are prohibited.
62. The method of claim 53, in which the control information is
securely associated with the piece of digital content, such that
software for making use of the piece of digital content is able to
govern use of the piece of digital content in accordance with the
one or more permitted actions recorded in the control
information.
63. A method comprising: displaying a graphical user interface to a
user, the graphical user interface comprising (a) a list of one or
more different types of digital content usage, and (b) one or more
permission options corresponding to one or more of the different
types of digital content usage; receiving user input, the user
input selecting one or more of the one or more permission options;
and associating permission information with a piece of digital
content, the permission information being derived from the user
input, and being configured for use with tamper-resistant software
to govern use of the piece of digital content.
64. The method of claim 63, in which the different types of digital
content usage include one or more of: modifying digital content,
printing digital content, viewing digital content, distributing
digital content, viewing a predefined portion of digital content,
and/or saving a backup of digital content.
65. The method of claim 63, in which the different types of digital
content usage include three or more of: modifying digital content,
printing digital content, viewing digital content, distributing
digital content, viewing a predefined portion of digital content,
and/or saving a backup of digital content.
66. The method of claim 63, in which the user input is received
from a pointing device.
67. The method of claim 66, in which the pointing device comprises
a mouse.
68. The method of claim 64, further comprising: encrypting the
piece of digital content; and sending the encrypted piece of
digital content and the permission information to an end user's
electronic appliance, the end user's electronic appliance
comprising tamper-resistant software operable to govern use of the
piece of digital content by the end user in accordance with the
permission information.
69. The method of claim 68, in which the step of sending the
encrypted piece of digital content and the permission information
to the end user's electronic appliance comprises sending the
encrypted piece of digital content to the end user's electronic
appliance separately from the permission information.
70. A method comprising: displaying a graphical user interface
comprising (a) a list of one or more different types of usage of a
piece of digital content, and (b) a list of permission options;
receiving input from a first entity, the input selecting one or
more of the permission options; and generating a control set from
the input, the control set specifying the permission options
selected by the first entity, the control set being associated with
the piece of digital content, the control set being configured for
use with tamper-resistant software running on a second entity's
electronic appliance to govern use of the piece of digital content
by the second entity in accordance with the permission options
selected by the first entity.
71. The method of claim 70, in which the permission options include
a selectable indication that a particular type of usage of the
piece of digital content should be prohibited.
72. The method of claim 70, in which the permission options include
a selectable indication that a particular type of usage of the
piece of digital content should be permitted.
73. The method of claim 70, in which the list of different types of
usage include two or more of: (a) modifying a piece of digital
content, (b) viewing a piece of digital content, (c) printing a
piece of digital content, and/or (d) distributing a piece of
digital content.
74. The method of claim 70, in which the control set comprises one
or more data objects configured to be delivered to the second
entity's electronic appliance.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] This application is a continuation in part of commonly
assigned copending application Ser. No. 08/388,107 of Ginter, et
al., filed 13 Feb. 1995, entitled "SYSTEMS AND METHODS FOR SECURE
TRANSACTION MANAGEMENT AND ELECTRONIC RIGHTS PROTECTION" (attorney
reference number 895-13) (hereafter "Ginter et al."). We
incorporate by reference, into this application, the entire
disclosure (including all of the drawings) of this prior-filed
Ginter, et al. patent application just as if its entire written
specification and drawings were expressly set forth in this
application.
FIELD OF THE INVENTIONS
[0002] These inventions generally relate to optimally bringing the
efficiencies of modern computing and networking to the
administration and support of electronic interactions and
consequences and further relate to a secure architecture enabling
distributed, trusted administration for electronic commerce.
[0003] These inventions relate, in more detail, to a "Distributed
Commerce Utility"--a foundation for the administration and support
of electronic commerce and other electronic interaction and
relationship environments.
[0004] In still more detail, these inventions generally relate to:
[0005] efficient administration and support of electronic commerce
and communications; [0006] methods and technologies for electronic
rights administration and support services; [0007] techniques and
arrangements for distributing administration and support services
such as secure electronic transaction management/administration,
electronic process control and automation, and clearing functions
across and/or within an electronic network and/or virtual
distribution environment; and/or [0008] clearing, control,
automation, and other administrative, infrastructure and support
capabilities that collectively enable and support the operation of
an efficient, secure, peer-to-peer collection of commerce
participants within the human digital community.
BACKGROUND
[0009] Efficient, effective societies require capabilities enabling
their inhabitants to control the nature and consequences of their
participation in interactions. Every community needs certain basic
services, facilities and installations: [0010] the post office
delivers our mail, [0011] the schools teach our children, [0012]
the highway department keeps our roads passable and in good repair,
[0013] the fire department puts out fires, [0014] the power company
delivers electrical power to our homes, [0015] the telephone
company connects people and electronic devices near and far and
provides directory services when you don't know the right number,
[0016] banks keep our money safe, [0017] cable TV and radio
stations deliver news and entertainment programming to our homes.
[0018] police keep order, [0019] the sanitation department collects
refuse, and [0020] social services support societal policies for
the needy.
[0021] These and other important "behind the scenes" administrative
and support services provide an underlying base or foundation that
makes the conveniences and necessities of modern life as we know it
possible and efficient, and allow the wheels of commerce to spin
smoothly.
[0022] Suppose you want to buy bread at the local bakery. The baker
doesn't have to do everything involved in making the bread because
he can rely on support and administration services the community
provides. For example: [0023] The baker doesn't need to grow or
mill grain to make flour for the bread. Instead, he can purchase
flour from a supplier that delivers it by truck. [0024] Similarly,
the baker doesn't need to grow or produce fuel to keep its ovens
hot; that fuel can be delivered in pipes or tanks by people who
specialize in producing and supplying fuel. [0025] You can also
have confidence in the cleanliness of the local bakery because it
displays an inspection notice certifying that it has been inspected
by the local health department.
[0026] Support and administrative services are also very important
to ensure that people are compensated for their efforts. For
example: [0027] You and the bakery can safely trust the government
to stand behind the currency you take out of your wallet or purse
to pay for the bread. [0028] If you pay by check, the banking
system debits the amount of your check from your bank account
overnight and gives the bakery the money. [0029] If you and the
bakery use different banks, your check may be handled by an
automated "clearinghouse" system that allows different banks to
exchange checks and settle accounts--efficiently transferring money
between the banks and returning checks drawn on accounts that don't
have enough money in them. [0030] If the bakery accepts credit
cards as payment, the flexibility of payment methods accepted in
exchange for the bakery products is increased and provides
increased convenience and purchasing power to its customers.
[0031] Such support and administrative services provide great
economies in terms of scale and scope--making our economy much more
efficient. For example, these important support and administrative
services allow the baker to concentrate on what he knows how to do
best--make and bake bread. It is much more efficient for a bakery
and its experienced bakers to make many loaves of bread in its
large commercial ovens than it is for individual families to each
bake individual loaves in their own home ovens, or for the growers
of grain to also bake the bread and pump the fuel needed for baking
and accept barter, for example, chickens in exchange for the bread.
As a result, you and the bakery can complete your purchasing
transaction with a credit card because both you and the bakery have
confidence that such a payment system works well and can be trusted
to "automatically" function as a highly efficient and convenient
basis for non-cash transactions.
The Electronic Community Needs Administrative and Support
Services
[0032] There is now a worldwide electronic community. Electronic
community participants need the ability to shape, control, and, in
an electronic world, automate, their interactions. They badly need
reliable, secure, trusted support and administrative services.
[0033] More and more of the world's commerce is being carried on
electronically. The Internet--a massive electronic network of
networks that connects millions of computers worldwide--is being
used increasingly as the vehicle for commerce transactions. Fueled
largely by easy-to-use interfaces (e.g., those allowing customers
to "point and click" on items to initiate purchase and then to
complete a simple form to convey credit card information), the
Internet is rapidly becoming a focal point for consumer and
business to business purchases. It is also becoming a significant
"channel" for the sale and distribution of all kinds of electronic
properties and services, including information, software, games,
and entertainment.
[0034] At the same time, large companies use both private and
public data networks to connect with their suppliers and customers.
Driven by apparently inexorable declines in the cost of both
computing power and network capacity, electronic commerce will
increase in importance as the world becomes more and more
computerized. This new electronic community--with its widespread
electronic commerce--is generating great new demands for electronic
administrative, support and "clearing" services.
[0035] The electronic community badly needs a foundation that will
support both commercial and personal electronic interactions and
relationships. Electronic commerce on any significant scale will
require a dependable, efficient, scaleable, and secure network of
third party support and administrative service providers and
mechanisms to facilitate important parts of the transaction
process. For example: [0036] People who provide value to the
electronic community require seamless and efficient mechanisms
allowing them to be compensated for the value they provide. [0037]
Providers who sell goods or services to the electronic community
need reliable, efficient electronic payment mechanisms to service
themselves and other value chain participants. [0038] Purchasers in
the electronic marketplace, while often unaware of the
behind-the-scenes intricacies of payment transaction activity,
nonetheless require easy to use, efficient and flexible interfaces
to payment mechanisms and financial obligation fulfillment systems.
[0039] Rights holders in all types of electronic "content" (for
example, analog or digital information representing text, graphics,
movies, animation, images, video, digital linear motion pictures,
sound and sound recordings, still images, software computer
programs, data), and to many types of electronic control processes,
require secure, flexible and widely interoperable mechanisms for
managing their rights and administering their business models,
including collecting, when desired, payments and relevant usage
information for various uses of their content. [0040] All parties
require infrastructure support services that remain dependable,
trusted, and secure even as the volume of commerce transactions
increases substantially.
[0041] An important cornerstone of successful electronic
transaction management and commerce is therefore the development
and operation of a set of administrative and support services that
support these objectives and facilitate the emergence of more
diverse, flexible, scaleable, and efficient business models for
electronic commerce generally.
The Ginter Patent Specification Describes a Comprehensive
Solution
[0042] The above-referenced Ginter, et al. patent specification
describes technology providing unique, powerful capabilities
instrumental to the development of secure, distributed
transaction-based electronic commerce and rights management. This
technology can enable many important, new business models and
business practices on the part of electronic commerce participants
while also supporting existing business models and practices.
[0043] The Ginter et al. specification describes comprehensive
overall systems and wide arrays of methods, techniques, structures
and arrangements that enable secure, efficient distributed
electronic commerce and rights management on the Internet (and
Intranets), within companies large and small, in the living room,
and in the home office. Such techniques, systems and arrangements
bring about an unparalleled degree of security, reliability,
efficiency and flexibility to electronic commerce and electronic
rights management.
[0044] The Ginter, et al. patent specification also describes an
"Information Utility"--a network of support and administrative
services, facilities and installations that grease the wheels of
electronic commerce and support electronic transactions in this new
electronic community. For example, Ginter, et al. details a wide
array of support and administrative service providers for
interfacing with and supporting a secure "Virtual Distribution
Environment." These support and administrative service providers
include: [0045] transaction processors, [0046] usage analysts,
[0047] report receivers, [0048] report creators, [0049] system
administrators, [0050] permissioning agents, [0051] certification
authority [0052] content and message repositories, [0053] financial
clearinghouses, [0054] consumer/author registration systems, [0055]
template libraries, [0056] control structure libraries, [0057]
disbursement systems, [0058] electronic funds transfer, credit
card, paper billing systems, and [0059] receipt, response,
transaction and analysis audit systems. The Present Inventions
Build on and Extend the Solutions Described in the Ginter Patent
Specification
[0060] The present inventions build on the fundamental concepts
described in the Ginter, et al. patent specification while
extending those inventions to provide further increases in
efficiency, flexibility and capability. They provide an overlay of
distributed electronic administrative and support services (the
"Distributed Commerce Utility"). They can, in their preferred
embodiments, use and take advantage of the "Virtual Distribution
Environment" (and other capabilities described in the Ginter et al
patent specification and may be layered on top of and expand on
those capabilities.
BRIEF SUMMARY OF SOME OF THE FEATURES AND ADVANTAGES OF THE PRESENT
INVENTIONS
[0061] The present inventions provide an integrated, modular array
of administrative and support services for electronic commerce and
electronic rights and transaction management. These administrative
and support services supply a secure foundation for conducting
financial management, rights management, certificate authority,
rules clearing, usage clearing, secure directory services, and
other transaction related capabilities functioning over a vast
electronic network such as the Internet and/or over organization
internal Intranets, or even in-home networks of electronic
appliances.
[0062] These administrative and support services can be adapted to
the specific needs of electronic commerce value chains. Electronic
commerce participants can use these administrative and support
services to support their interests, and can shape and reuse these
services in response to competitive business realities.
[0063] The present inventions provide a "Distributed Commerce
Utility" having a secure, programmable, distributed architecture
that provides administrative and support services. The Distributed
Commerce Utility can make optimally efficient use of commerce
administration resources, and can scale in a practical fashion to
accommodate the demands of electronic commerce growth.
[0064] The Distributed Commerce Utility may comprise a number of
Commerce Utility Systems. These Commerce Utility Systems provide a
web of infrastructure support available to, and reusable by, the
entire electronic community and/or many or all of its
participants.
[0065] Different support functions can be collected together in
hierarchical and/or in networked relationships to suit various
business models and/or other objectives. Modular support functions
can be combined in different arrays to form different Commerce
Utility Systems for different design implementations and purposes.
These Commerce Utility Systems can be distributed across a large
number of electronic appliances with varying degrees of
distribution.
[0066] The comprehensive "Distributed Commerce Utility" provided by
the present invention: [0067] Enables practical and efficient
electronic commerce and rights management. [0068] Provides services
that securely administer and support electronic interactions and
consequences. [0069] Provides infrastructure for electronic
commerce and other forms of human electronic interaction and
relationships. [0070] Optimally applies the efficiencies of modern
distributed computing and networking. [0071] Provides electronic
automation and distributed processing. [0072] Supports electronic
commerce and communications infrastructure that is modular,
programmable, distributed and optimally computerized. [0073]
Provides a comprehensive array of capabilities that can be combined
to support services that perform various administrative and support
roles. [0074] Maximizes benefits from electronic automation and
distributed processing to produce optimal allocation and use of
resources across a system or network. [0075] Is efficient,
flexible, cost effective, configurable, reusable, modifiable, and
generalizable. [0076] Can economically reflect users' business and
privacy requirements. [0077] Can optimally distribute
processes--allowing commerce models to be flexible, scaled to
demand and to match user requirements. [0078] Can efficiently
handle a full range of activities and service volumes. [0079] Can
be fashioned and operated for each business model, as a mixture of
distributed and centralized processes. [0080] Provides a blend of
local, centralized and networked capabilities that can be uniquely
shaped and reshaped to meet changing conditions. [0081] Supports
general purpose resources and is reusable for many different
models; in place infrastructure can be reused by different value
chains having different requirements. [0082] Can support any number
of commerce and communications models. [0083] Efficiently applies
local, centralized and networked resources to match each value
chain's requirements. [0084] Sharing of common resources spreads
out costs and maximizes efficiency. [0085] Supports mixed,
distributed, peer-to-peer and centralized networked capabilities.
[0086] Can operate locally, remotely and/or centrally. [0087] Can
operate synchronously, asynchronously, or support both modes of
operation. [0088] Adapts easily and flexibly to the rapidly
changing sea of commercial opportunities, relationships and
constraints of "Cyberspace."
[0089] In sum, the Distributed Commerce Utility provides
comprehensive, integrated administrative and support services for
secure electronic commerce and other forms of electronic
interaction.
[0090] Some of the advantageous features and characteristics of the
Distributed Commerce Utility provided by the present inventions
include the following: [0091] The Distributed Commerce Utility
supports programmable, distributed, and optimally computerized
commerce and communications administration. It uniquely provides an
array of services that perform various administrative and support
roles--providing the administrative overlay necessary for realizing
maximum benefits from electronic automation, distributed
processing, and system (e.g., network) wide optimal resource
utilization. [0092] The Distributed Commerce Utility is
particularly adapted to provide the administrative foundation for
the Internet, organization Intranets, and similar environments
involving distributed digital information creators, users, and
service systems. [0093] The Distributed Commerce Utility
architecture provides an efficient, cost effective, flexible,
configurable, reusable, and generalizable foundation for electronic
commerce and communications administrative and support services.
Providing these capabilities is critical to establishing a
foundation for human electronic interaction that supports optimal
electronic relationship models--both commercial and personal.
[0094] The Distributed Commerce Utility architecture provides an
electronic commerce and communication support services foundation
that can be, for any specific model, fashioned and operated as a
mixture of distributed and centralized processes. [0095] The
Distributed Commerce Utility supported models can be uniquely
shaped and reshaped to progressively reflect optimal blends of
local, centralized, and networked Distributed Commerce Utility
administrative capabilities. [0096] The Distributed Commerce
Utility's innovative electronic administrative capabilities support
mixed, distributed, peer-to-peer and centralized networked
capabilities. Collections of these capabilities, can each operate
in any mixture of local, remote, and central asynchronous and/or
synchronous networked combinations that together comprise the most
commercially implementable, economic, and marketable--that is
commercially desirable--model for a given purpose at any given
time. [0097] The Distributed Commerce Utility architecture is
general purpose. It can support any number of commerce and
communication models which share (e.g., reuse), as appropriate,
local, centralized, and networked resources. As a result, the
Distributed Commerce Utility optimally enables practical and
efficient electronic commerce and rights management models that can
amortize resource maintenance costs through common usage of the
same, or overlapping, resource base. [0098] One or more Distributed
Commerce Utility commerce models may share some or all of the
resources of one or more other models. One or more models may shift
the mix and nature of their distributed administrative operations
to adapt to the demands of Cyberspace--a rapidly changing sea of
commercial opportunities, relationships, and constraints. [0099]
The Distributed Commerce Utility supports the processes of
traditional commerce by allowing their translation into electronic
commerce processes. The Distributed Commerce Utility further
enhances these processes through its use of distributed processing,
rights related "clearinghouse" administration, security designs,
object oriented design, administrative smart agents, negotiation
and electronic decision making techniques, and/or electronic
automation control techniques as may be necessary for efficient,
commercially practical electronic commerce models. [0100] Certain
Distributed Commerce Utility operations (financial payment, usage
auditing, etc.) can be performed within participant user electronic
appliance secure execution spaces such as, for example, "protected
processing environments" disclosed in Ginter et al. [0101]
Distributed clearinghouse operations may be performed through
"virtually networked and/or hierarchical" arrays of Commerce
Utility System sites employing a general purpose, interoperable
(e.g., peer-to-peer) virtual distribution environment foundation.
[0102] For a given application or model, differing arrays of
Distributed Commerce Utility Services may be authorized to provide
differing kinds of administrative and/or support functions. [0103]
Any or all of the roles supported by the Distributed Commerce
Utility may be performed by, and/or used by, the same organization,
consortium or other grouping of organizations, or other electronic
community participants, such as individual user web sites. [0104]
One or more parts of the Distributed Commerce Utility may be
comprised of a network of distributed protected processing
environments performing one or more roles having hierarchical
and/or peer-to-peer relationships. [0105] Multiple Distributed
Commerce Utility protected processing environments may contribute
to the overall role of a service, foundation component, and/or
clearinghouse. [0106] Distributed protected processing environments
contributing to a Distributed Commerce Utility role may be as
distributed, in a preferred embodiment, as the number of VDE
participant protected processing environments and/or may have
specific hierarchical, networked and/or centralized administration
and support relationship(s) to such participant protected
processing environments. [0107] In a given model, certain one or
more Distributed Commerce Utility roles may be fully distributed,
certain other one or more roles may be more (e.g., hierarchically),
and/or fully, centralized, and certain other roles can be partially
distributed and partially centralized. [0108] The fundamental
peer-to-peer control capabilities provided by the Distributed
Commerce Utility allows for any composition of distributed roles
that collectively provide important, practical, scaleable, and/or
essential commerce administration, security, and automation
services. [0109] Combinations of Distributed Commerce Utility
features, arrangements, and/or capabilities can be employed in
programmable mixtures of distributed and centralized arrangements,
with various of such features, arrangements, and capabilities
operating in end-user protected processing environments and/or
"middle" foundation protected processing environments (local,
regional, class specific, etc.) and/or centralized service
protected processing environments. [0110] The Distributed Commerce
Utility is especially useful to support the Internet and other
electronic environments that have distributed information creators,
users and service providers. By helping people to move their
activities into the electronic world, it plays a fundamentally
important role in migration of these non-electronic human
activities onto the Internet, Intranets, and other electronic
interaction networks. Such network users require the Distributed
Commerce Utility foundation and support services in order to
economically realize their business and privacy requirements. This
secure distributed processing foundation is needed to optimally
support the capacity of electronic commerce models to meaningfully
scale to demand and efficiently handle the full range of desired
activities and service volume. [0111] The Distributed Commerce
Utility technologies provided by the present inventions provide a
set of secure, distributed support and administrative services for
electronic commerce, rights management, and distributed computing
and process control. [0112] The Distributed Commerce Utility
support services including highly secure and sophisticated
technical and/or contractual services, may be invoked by electronic
commerce and value chain participants in a seamless, convenient,
and relatively transparent way that shields users against the
underlying complexity of their operation. [0113] The Distributed
Commerce Utility can ensure appropriately high levels of physical,
computer, network, process and policy-based security and automation
while providing enhanced, efficient, reliable, easy to use,
convenient functionality that is necessary (or at least highly
desirable) for orderly and efficiently supporting of the needs of
the electronic community. [0114] The Distributed Commerce Utility,
in its preferred embodiments, support the creation of competitive
commercial models operating in the context of an "open" VDE based
digital marketplace. [0115] The Distributed Commerce Utility can
provide convenience and operating efficiencies to their value chain
participants. For example, they may offer a complete, integrated
set of important "clearing" function capabilities that are
programmable and can be shaped to optimally support multi-party
business relationship through one seamless, "distributed" interface
(e.g., a distributed application). Clearing and/or support
functions and/or sub-functions can, as desirable, be made available
individually and/or separately so as to serve business,
confidentiality, efficiency, or other objectives. [0116] The
Distributed Commerce Utility can make it easy for providers,
merchants, distributors, repurposers, consumers, and other value
chain participants to attach to, invoke, and work with Distributed
Commerce Utility services. Hookups can be easy, seamless and
comprehensive (one hook-up may provide a wide variety of
complementary services). [0117] The Distributed Commerce Utility
can further enhance convenience and efficiency by providing or
otherwise supporting consumer brand images for clearing services
offered by participant organizations, but utilizing shared
infrastructure and processes. [0118] The Distributed Commerce
Utility can realize important efficiencies resulting from scale and
specialization by participant organizations by supporting "virtual"
models that electronically and seamlessly employ the special
services and capabilities of multiple parties. [0119] The
Distributed Commerce Utility makes it possible for consumers to
conveniently receive a benefit such as a service or product, where
such service or product results from the invocation of a "fabric"
of various support services--each of which service may be comprised
of a distributed fabric of more specialized services and/or
participating constituent service providers (the overall fabric is
apparent to the value chain participant, the underlying complexity
is (or can be) largely or entirely hidden). [0120] Distributed
Commerce Utility services and capabilities in their preferred
embodiments can employ and be combined in any reasonable manner
with any one or more Virtual Distribution Environment capabilities
described in Ginter, et. al., including for example: [0121] A. VDE
chain of handling and control, [0122] B. secure, trusted internodal
communication and interoperability, [0123] C. secure database,
[0124] D. authentication, [0125] E. cryptographic, [0126] F.
fingerprinting, [0127] G. other VDE security techniques, [0128] H.
rights operating system, [0129] I. object design and secure
container techniques, [0130] J. container control structures,
[0131] K. rights and process control language, [0132] L. electronic
negotiation, [0133] M. secure hardware, and [0134] N. smart agent
(smart object) techniques (for example, smart agents employed as
process control, multi-party, and/or other administrative agent
capabilities supporting distributed node administrative
integration). Commerce Utility Systems can be Distributed and
Combined
[0135] The support and administrative service functions provided by
the Distributed Commerce Utility can be combined in various ways
and/or distributed through an electronic community, system or
network. The preferred embodiment uses the protected processing
environment based Virtual Distribution Environment described in
Ginter et al. to facilitate such combinations and distributedness.
Since all such Virtual Distribution Environment protected
processing environments are at least to some degree trusted, every
protected processing environment can be a clearinghouse or a part
of a clearinghouse. Commerce models acceptable to the interest and
desires of VDE commerce node users, can support Distributed
Commerce Utility services that are pushed all the way to end-user
electronic appliances employing, for example, other VDE protected
processing environments, secure communication techniques and other
VDE capabilities (as discussed elsewhere VDE capabilities can be
directly integrated with the present inventions). Such appliances,
along with more centralized value chain nodes can together form
combinations that function as virtual clearing protected processing
environments. In the end, cyberspace will be populated, in part, by
big, "virtual" computers where access to resources is based upon
"availability" and rights.
[0136] The Distributed Commerce Utility is a modular, programmable
and generalizable context that it can support such virtual
computers. The Distributed Commerce Utility is a unique
architectural foundation for the design of electronic commerce
value chain models and virtual computers. The programmable nature
of a particular implementation can support differing actual
(logical and/or physical), and/or degrees of, distribution for the
same and/or similar services For example: [0137] Centralized
Commerce Utility Systems and services may be used to provide
certain support service functions, or collections of functions,
efficiently from a centralized location. [0138] Other Commerce
Utility Systems might be provided in a partially or wholly
distributed manner. [0139] Some support and administrative service
functions might be distributed in and/or throughout existing or new
communications infrastructure or other electronic network support
components. [0140] Other support services might operate within
secure execution spaces (e.g., protected processing environments)
on any or all user electronic appliances, using peer-to-peer
communications and interactions, for example, to provide a secure
web of support service fabric. [0141] Other support services might
operate both in the network support infrastructure and at user
electronic appliances.
[0142] Such distributed support services may complement (and/or
eliminate the need for) more centralized support service
installations. Different combinations of the same and/or differing,
non-distributed and differently distributed services may be
provided to support different activities. Moreover, the nature and
distribution of services for one overall model may differ from one
implementation to another. Such differing model implementations
can, if desired, share both the same Commerce Utility Systems and
Services and/or any particular and/or any combination of
Distributed Commerce Utility administrative and/or support
functions.
[0143] Further, a particular Commerce Utility Systems and Service
infrastructure may be used by differing value chains (e.g.,
business model or relationship set) in differing manners. For
example, certain value chains may elect to keep certain support
service functions more centralized for efficiency, security,
control or other reasons, others may elect more and/or differently
distributed models.
[0144] Provided that, for example, payment methods and
rightsholders and/or other value chain participants concur, any one
or more of the Distributed Commerce Utility secure infrastructure
support services may distribute and/or delegate a portion or all of
their functions and authority to any arbitrary collection or set of
end-user and/or other value chain electronic appliances.
Distributing and delegating these services and functions has
various advantages including, for example, enabling flexible and
efficient creation of temporary, ad hoc webs of secure electronic
commerce in which any, a number, or all appliance(s) in the
collection or set may participate as at least a partial (if not
full) peer of other appliances in the same commerce web fabric.
[0145] The present invention provides the following non-exhaustive
list of additional features relating to distributing administrative
and support functions: [0146] Any mixture of any administrative
and/or support functions may be integrated with any other mixture
of administrative and/or support functions. [0147] Any set or
subset of Commerce Utility System functions can be combined in an
integrated design with any other mixture of Commerce Utility system
functions. Such mixtures can be distributed to any desired degree
and any one or more portions of the mixture may be more or less
distributed than any other one or more portion. This allows a value
chain to employ optimum desired and/or practical designs. Any
mixture, including any degrees of distribution, of rights clearing,
financial clearing, usage aggregation, usage reporting and/or other
clearing and/or other Distributed Commerce Utility functions, can
be provided. Such Distributed Commerce Utility functions and/or
administrative and/or support services can be combined with any
other desired Distributed Commerce Utility functions and/or
administrative and/or support services. [0148] Any one or more such
administrative and/or support services and/or functions can operate
as a Commerce Utility System and support a web of Commerce Utility
System nodes, each of which supports at least a portion of such
Commerce Utility administrative service activities. Each Commerce
Utility System may be capable of granting authority and/or
providing services to and/or otherwise securely interoperating with
other Commerce Utility Systems and/or nodes. [0149] Each Commerce
Utility System (or combination of Commerce Utility Systems) may be
capable of participating as a "virtual clearinghouse" comprised of
plural Commerce Utility Systems. In the preferred embodiment, these
"virtual clearinghouses" may, when in accordance with VDE rules and
controls, interoperate--in a fashion prescribed by such rules and
controls--with other Commerce Utility Systems and/or other virtual
clearinghouses participating in the same web. Such "virtual
clearinghouses" may receive authority from secure chain of handling
and control embodied in electronic control sets, and may
participate in electronic commerce process automation resulting
from such chain of handling and control and other VDE
capabilities.
[0150] This ability to distribute, and, if desired to subsequently
adapt (modify), any support service functions to any desired degree
across a system or network provides great power, flexibility and
increases in efficiency. For example, distributing aspects of
support services such as clearing functions will help avoid the
"bottlenecks" that a centralized clearing facility would create if
it had insufficient capacity to handle the processing loads. Taking
advantage of the distributed processing power of many value chain
participant appliances also has great benefits in terms of improved
effectiveness and system response time, much lower overhead of
operation, greater fault tolerance, versatility in application
implementations, and, in general much greater value chain appeal
resulting from the present inventions adaptability to each value
chain participant's needs and requirements.
Some Examples of Administrative and/or Support Services Provided by
the Distributed Commerce Utility
[0151] The Distributed Commerce Utility may be organized into a
number of different, special and/or general purpose "Commerce
Utility Systems." The Commerce Utility Systems can be centralized,
distributed, or partially distributed and partially centralized to
provide administrative, security, and other services that practical
commerce management layer requires. Certain Commerce Utility
Systems comprise Distributed Commerce Utility implementations of
certain well known administrative service functions, such as
financial clearinghouse and certifying authorities. Other Commerce
Utility Systems involve new forms of services and new combinations
and designs for well known service activities. A Commerce Utility
System is any instanstiation of the Distributed Commerce Utility
supporting a specific electronic commerce model, and a Commerce
Utility System may itself be comprised of constituent Commerce
Utility Systems. Commerce Utility Systems may include any or all of
the following, in any combination of capabilities and distribution
designs, for example: [0152] financial clearinghouses, [0153] usage
clearinghouses, [0154] rights and permissions clearinghouses,
[0155] certifying authorities, [0156] secure directory services,
[0157] secure transaction authorities, [0158] multi-purpose,
general purpose and/or combination Commerce Utility Systems
including any combination of the capabilities of the systems listed
immediately above, and [0159] other Commerce Utility Systems. These
Commerce Utility Systems are far-reaching in their utility and
applicability. For example they may provide administrative support
for any or all of the following: [0160] trusted electronic event
management, [0161] networked, automated, distributed, secure
process administration and control, [0162] Virtual Distribution
Environment chain-of-handling and control, and [0163] rights
administration and usage (e.g., event) management (e.g., auditing,
control, rights fulfillment, etc.), across and/or within electronic
networks, including "unconnected," virtually connected, or
periodically connected networks. The Commerce Utility Systems may
govern electronic process chains and electronic event consequences
related to, for example: [0164] electronic advertising, [0165]
market and usage analysis, [0166] electronic currency, [0167]
financial transaction clearing and communications, [0168]
manufacturing and other distributed process control models, [0169]
financial clearing, [0170] enabling payment fulfillment or
provision of other consideration (including service fees, product
fees or any other fees and/or charges) based at least in part on
content, process control (event) and/or rights management, [0171]
performing audit, billing, payment fulfillment (or provision of
other consideration) and/or other clearing activities, [0172]
compiling, aggregating, using and/or providing information relating
to use of one or more secure containers and/or content and/or
processes (events), including contents of secure containers and/or
any other content, [0173] providing information based upon usage
auditing, user profiling, and/or market surveying related to use of
one or more secure containers and/or content and/or processes
(events), [0174] employing information derived from user exposure
to content (including advertising) and/or use of processes
(events), [0175] providing object registry services; and/or rights,
permissions, prices, and/or other rules and controls information;
for registered and/or registering objects; [0176] electronically
certifying information used with and/or required by rules and
controls, such as authenticating identity, class membership and/or
other attributes of identity context including for example,
certification of class identity for automating processes, such as
rights related financial transaction fulfillment based upon
governing jurisdiction (taxation(s)), employment and/or other group
membership including, for example, acquired class rights (e.g.,
purchased discount buyers club membership); [0177] third party
archiving and/or authenticating of transactions and/or transaction
information for secure backup and non-repudiation, [0178] providing
programmed mixed arrays of Commerce Utility System process control
and automation services, where different Commerce Utility Systems
support different value chains and/or business models requirements,
and where such Commerce Utility Systems further support
distributed, scaleable, efficient networked and/or hierarchical
fixed and/or virtual clearinghouse models which employ secure
communication among a Commerce Utility System's distributed
clearinghouse protected processing environments for passing
clearinghouse related rules and controls and derived, summarized,
and/or detailed transaction information, [0179] EDI, electronic
trading models, and distributed computing arrangements where
participants require trusted foundation that enables efficient,
distributed administration, automation, and control of transaction
value chains, and [0180] other support and/or administrative
services and/or functions.
BRIEF DESCRIPTION OF THE DRAWINGS
[0181] These and other features and advantages provided by the
present inventions will become better and more completely
understood by studying the following detailed description of
presently preferred example embodiments in conjunction with the
drawings, of which:
[0182] FIG. 1 shows an example Distributed Commerce Utility
supporting a consumer's example electronic appliance;
[0183] FIG. 1A shows a protected processing environment(s) ("PPE")
within the consumer's electronic appliance(s);
[0184] FIG. 1B shows that the Distributed Commerce Utility may
comprise a number of example Commerce Utility Systems;
[0185] FIGS. 2A-2E show examples of how administrative and support
service functions can be distributed;
[0186] FIGS. 3A-3C show example distributed Commerce Utility
Systems;
[0187] FIG. 4 shows an example web of Commerce Utility Systems;
[0188] FIG. 4A shows a limitless web of consumer appliances and
Commerce Utility Systems;
[0189] FIG. 5 shows how rights holders can select between multiple
Commerce Utility Systems connected to an electronic "information
highway";
[0190] FIG. 6 shows an example of how different Commerce Utility
Systems can work together;
[0191] FIG. 7 shows an example of how multiple administrative and
support service functions can be combined and integrated within
Commerce Utility Systems;
[0192] FIG. 7A shows an example web of combined function Commerce
Utility Systems;
[0193] FIGS. 8A?8B show example Commerce Utility System
hierarchies;
[0194] FIG. 9 shows an example hierarchy of multi-function Commerce
Utility Systems
[0195] FIG. 10 shows an example financial clearinghouse;
[0196] FIG. 11 shows an example usage clearinghouse;
[0197] FIG. 12 shows an example rights and permissions
clearinghouse;
[0198] FIG. 13 shows an example certifying authority;
[0199] FIG. 14 shows an example secure directory service;
[0200] FIG. 15 shows an example transaction authority;
[0201] FIGS. 16A-16F show that Commerce Utility Systems can support
other commerce utility systems;
[0202] FIGS. 17A through 17D-3 show an example Commerce Utility
System architecture;
[0203] FIG. 17E-1 through 17E-4 show Commerce Utility System
example interaction models;
[0204] FIG. 17F shows an example arrangement for distributing
portions of administrative and support service operations;
[0205] FIG. 18 shows an example financial clearinghouse Commerce
Utility System;
[0206] FIG. 19 shows an example financial clearinghouse
arrangement;
[0207] FIG. 20 shows an example financial clearing process;
[0208] FIGS. 20A?20F show an additional example of financial
clearing activities and processes;
[0209] FIG. 21 shows a simplified value chain (payment)
disaggregation example;
[0210] FIG. 22 shows an example of how the FIG. 21 disaggregation
can be implemented within a financial clearinghouse context;
[0211] FIG. 22A shows an example arrangement for implementing
payment disaggregation on a user protected processing
environment;
[0212] FIG. 23 shows a more complex value chain (payment)
disaggregation example;
[0213] FIG. 24 shows an example of how disaggregation can be
implemented within a financial clearinghouse context;
[0214] FIG. 25 shows a value chain disaggregation example that also
details compensation to the Distributed Commerce Utility;
[0215] FIG. 26 shows an example value chain (payment)
disaggregation to any number of payees;
[0216] FIG. 27 shows an additional example of how value chain
(payment) disaggregation and redistribution may be accomplished
through a financial clearinghouse;
[0217] FIG. 28 shows an example superdistribution payment and
redistribution scenario using a financial clearinghouse for
financial clearing;
[0218] FIG. 29 shows an example value chain (payment) aggregation
at a consumer protected processing environment or other site;
[0219] FIG. 30 shows example value chain (payment) aggregation
across multiple transactions;
[0220] FIG. 31 shows example value chain (payment) aggregation
across multiple transactions and multiple consumers;
[0221] FIG. 32 shows an example Commerce Utility System
architecture providing payment aggregation;
[0222] FIG. 33 shows an example usage clearinghouse Commerce
Utility System;
[0223] FIG. 34 shows an example usage clearinghouse
architecture;
[0224] FIG. 35 shows an example usage clearing process;
[0225] FIG. 36 shows an additional example usage clearing process
using multiple usage clearinghouses;
[0226] FIG. 37 shows an example usage clearing process using usage
and financial clearinghouses;
[0227] FIG. 38 shows an example usage clearinghouse media placement
process;
[0228] FIG. 39 shows an example usage clearing process providing
discounts based on different levels of consumer usage information
disclosure;
[0229] FIG. 40 shows an example rights and permissions
clearinghouse Commerce Utility System;
[0230] FIG. 41 shows an example rights and permissions
clearinghouse architecture;
[0231] FIG. 42 shows an example rights and permissions clearing
process;
[0232] FIG. 42A shows an example control set registration process
for updates;
[0233] FIG. 43 shows an additional example rights and permissions
clearing process;
[0234] FIGS. 44A-44E show an additional rights and permissions
clearing example;
[0235] FIGS. 45A and 45B show example rights template(s);
[0236] FIG. 45C shows an example control set corresponding to the
example rights template(s);
[0237] FIG. 46 shows another example rights and permissions
clearing process;
[0238] FIG. 47 shows an example certifying authority Commerce
Utility System;
[0239] FIG. 48 shows an example certifying authority
architecture;
[0240] FIG. 49 shows an example certifying process;
[0241] FIG. 50 shows an example distributed certifying process;
[0242] FIG. 50A shows an example control set that conditions
performance and/or other consequences on the presence of digital
certificates;
[0243] FIGS. 51A?51D show example digital certificate data
structures;
[0244] FIG. 51E shows an example technique for generating digital
certificates based on other digital certificates and a trusted
database(s);
[0245] FIGS. 51F-51H show an example technique for defining a
virtual entity;
[0246] FIG. 52 shows an example secure directory services Commerce
Utility System;
[0247] FIG. 53 shows an example secure directory services
architecture;
[0248] FIG. 54 shows an example secure directory services
process;
[0249] FIG. 55 shows an example transaction authority Commerce
Utility System;
[0250] FIG. 56 shows an example transaction authority
architecture;
[0251] FIG. 57 shows an example transaction authority process;
[0252] FIG. 58A shows an example of how the transaction authority
creates a control superset;
[0253] FIG. 58B shows example steps performed by the transaction
authority;
[0254] FIGS. 58C and 58D show an example secure checkpoint Commerce
Utility System;
[0255] FIGS. 59 and 60 show examples of how the Distributed
Commerce Utility can support different electronic value chains;
[0256] FIG. 61 shows a purchase, licensing and/or renting
example;
[0257] FIG. 62 shows a tangible item purchasing and paying
example;
[0258] FIG. 63 shows an example of a customer securely paying for
services;
[0259] FIG. 64 shows example value chain disaggregation for
purchase of tangibles;
[0260] FIG. 65 shows an example of cooperation between Commerce
Utility Systems internal and external to an organization;
[0261] FIG. 66 shows an example inter and intra organization
transaction authority example;
[0262] FIG. 67 shows an international trading example.
DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS
Distributed Commerce Utility
[0263] FIG. 1 shows an example consumer appliance 100
electronically connected to Distributed Commerce Utility 75. In
this example, an electronic network 150 connects appliance 100 to
Distributed Commerce Utility 75. Distributed Commerce Utility 75
supports the activities going on within consumer appliance 100.
[0264] Distributed Commerce Utility 75 provides a foundation of
administrative and support services for electronic commerce and
communications. This foundation is efficient, cost effective,
flexible, configurable, reusable, programmable and generalizable.
It supports all kinds of electronic relationships, interactions and
communications for both personal and business use.
The Distributed Commerce Utility can Support any Electronic
Appliance
[0265] Appliance 100 may be any sort of electrical or electronic
device such as for example, a computer, an entertainment system, a
television set, or a video player--just to name a few examples. In
the particular example shown in FIG. 1, the consumer appliance 100
is a home color television set 102, a video player/recorder 104,
and a set top box 106. Appliance 100 may be controlled by hand held
remote controller 108, for example. Set top box 106 could receive
television programs from television broadcasters 110 and/or
satellites 112 via a cable television network 114, for example.
Player/recorder 104 could play various types of program material
from tapes, optical disks or other media, and may also have the
capability of recording program materials received through set top
box 106.
The Appliance 100 can have a "Protected Processing Environment"
[0266] Appliance 100 preferably is a secure electronic appliance of
the type shown for example in FIGS. 7 and 8 of the Ginter et al.
patent specification. It is preferably part of the "Virtual
Distribution Environment" described in the Ginter, et al. patent
specification. FIG. 1A shows that television 102, set top box 106,
media player/recorder 104 and remote control 108 may each have a
"protected processing environment" ("PPE") 154. Distributed
Commerce Utility 75 may interact with and support the processes
going on within each of these protected processing environments
154.
[0267] Protected processing environments 154 may be based on one or
more computer chips, such as a hardware and/or software based
"secure processing unit" as shown in FIG. 9 of the Ginter et al.
patent specification. The protected processing environment 154
provides a highly secure, trusted environment in which electronic
processes and transactions can be reliably performed without
significant danger of tampering or other compromise. The Ginter et
al. patent disclosure describes techniques, systems and methods for
designing, constructing and maintaining the protected processing
environment 154 so that rights holders and other value chain
participants (including consumers 95) can trust its security and
integrity. In the preferred embodiment, this trustedness is
important in the interaction between the Distributed Commerce
Utility 75 and electronic appliance 100.
The Distributed Commerce Utility can be Made Up of Many "Commerce
Utility Systems"
[0268] FIG. 1B shows that Distributed Commerce Utility 75 can be
made up of a number of Commerce Utility Systems 90. There can be
different kinds of Commerce Utility Systems, for example: [0269] a
financial clearinghouse 200; [0270] a usage clearinghouse 300;
[0271] a rights and permissions clearinghouse 400; [0272] a
certifying authority 500; [0273] a secure directory services 600;
[0274] a transaction authority 700; [0275] a VDE administrator 800;
and [0276] other kinds of Commerce Utility Systems 90.
[0277] Commerce Utility Systems 90 can support and administer
functions or operations within protected processing environment(s)
154. For example: [0278] The appliance 100 protected processing
environment 154 may provide an automatic electronic payment
mechanism 118 that debits the consumers' bank or other money
account based on program consumption. Distributed Commerce Utility
75 may include a special purpose Commerce Utility System 90a called
a "financial clearinghouse" 200 that supports financial aspects of
the operation of the protected processing environment 154--ensuring
that rights holders and others get paid appropriate amounts and
that the consumers 95 are not charged excessive amounts. [0279] The
broadcaster of a television program 102a may require appliance
100's protected processing environment 154 to meter, with an
electronic usage metering mechanism 116, how much of video program
102a the consumers 95 watch, and which video programs they watch.
Distributed Commerce Utility 75 may include a special purpose
Commerce Utility System 90b called a "usage clearinghouse" 300 that
receives usage information metered by a usage meter 116 within the
protected processing environment 154, analyzes it and provides
reports. [0280] The rights holders in video program 102a may insist
upon the protected processing environment 154 providing a copy
protection mechanism 120 that securely protects against copying
video program 102a. Distributed Commerce Utility 75 may include a
special purpose Commerce Utility System 90c called a "rights and
permissions clearinghouse" 400 that supplies the protected
processing environment 154 with necessary permissions to allow
consumers 95 to watch particular programs (for example, on a pay
per view basis) and to assist in enforcing prohibitions, such as,
for example, a copy protection mechanism 120. [0281] Rights holders
in video program 102a may further require the appliance 100
protected processing environment 154 to possess a "digital
certificate" 122 certifying the consumer's identity, age, or the
like before consumers 95 can watch video program 102a.
[0282] Distributed Commerce Utility 75 may include a special
purpose Commerce Utility System 90d called a "certifying authority"
500 that creates and provides "digital certificates" 504 to the
protected processing environment 154--allowing the consumers to
efficiently interact with the permissions provided by the rights
holders.
[0283] Other Commerce Utility Systems 90 shown in FIG. 1B include:
[0284] A "Secure directory services" 600 that may assist the
protected processing environment 154 in communicating
electronically with other computers and appliances over network
150; [0285] A "transaction authority" 700 that may be available for
process control and automation such as, for example, securely
auditing and overseeing complicated electronic transactions
involving protected processing environment 154; and [0286] A
virtual distribution environment (?VDE?) "administrator" 800 that
may, in the preferred embodiment, keep the protected processing
environment 154 operating smoothly and securely.
[0287] Still other Commerce Utility Systems 90 not shown in FIG. 1B
may be used to administer and/or support additional functions and
operations. The various Commerce Utility Systems 90 can work
together, dividing up the overall tasks to support the consumers 95
efficiently and effectively.
Commerce Utility Systems can be Distributed
[0288] FIGS. 2A-2E show how Distributed Commerce Utility 75 can be
distributed. Some administrative and support functions of Commerce
Utility Systems 90 can be performed within a consumer's electronic
appliance 100--or even in a "spread out" fashion over a large
number of different appliances cooperating together.
[0289] As described above, appliances 100 each provide a protected
processing environment 154 that is tamper resistant and provides a
secure place in which administrative and support operations can be
performed. This allows an electronic appliance 100 within a
consumer's home to perform operations that can trusted by other
parties, such as rights holders, electronic commerce participants,
and the like. Because of the trusted, protected characteristics of
protected processing environment 154, the parts, extensions or even
the entirety of a Commerce Utility System 90 may exist within each
or any of the protected processing environments 154 and associated
electronic appliances within the overall system.
[0290] FIGS. 2A-2E represent the overall functions of an example
Commerce Utility System 90 such as Usage Clearinghouse 300 as a
four-piece jigsaw puzzle. FIGS. 2A-2E show that these Commerce
Utility System functions can be distributed to varying degrees. For
example: [0291] FIG. 2A shows an example in which all functions of
the Commerce Utility System 90 are performed in a secure central
facility. [0292] FIG. 2B shows an example in which most functions
of the Commerce Utility System 90 are performed in a secure central
facility, but some of its functions are performed within the
protected processing environment 154 of a user electronic appliance
100. [0293] FIG. 2C shows an example in which some functions of the
Commerce Utility System 90 are performed in a secure central
facility, but most of its functions are performed within the
protected processing environment 154 of a user electronic appliance
100. [0294] FIG. 2D shows an example in which some functions of the
Commerce Utility System 90 are performed in a secure central
facility, some of its functions are performed within the protected
processing environment 154A of a first user electronic appliance
100A, and some of its functions are performed within the protected
processing environment 154B of a second user electronic appliance
100B. [0295] FIG. 2E shows an example in which none of the
functions of the Commerce Utility System 90 are performed in a
secure central facility; some of its functions are performed within
the protected processing environment 154(1) of a first user
electronic appliance 100(1), some of its functions are performed
within the protected processing environment 154(2) of a second user
electronic appliance 100(2),), some of its functions are performed
within the protected processing environment 154(3) of a third user
electronic appliance 100(3), and some of its functions are
performed within the protected processing environment 154(N) of a
Nth user electronic appliance 100(N).
[0296] Alternately or in addition, some of the functions of the
Commerce Utility System 90 may be distributed within network
150--for example, in the equipment used to communicate data between
appliances 100.
Distributing Multiple Administrative and Support Functions
[0297] FIG. 3A shows how multiple Commerce Utility System 90
functions or sub-functions can be distributed into the same
protected processing environment 154.
[0298] For example: [0299] Financial clearinghouse function 200a
operating within consumer appliance 100A's protected processing
environment 154a may provide certain financial clearing such as
auditing that can take the place of and/or support some of the
financial clearing operations performed by a centralized financial
clearinghouse 200. [0300] Usage clearinghouse function 300a
operating within consumer appliance 100A's protected processing
environment 154a may perform certain usage information clearing
operations, such as, for example, combining or analyzing collected
usage information to complement, substitute for, or add to usage
clearing operations performed by usage clearinghouse 300. [0301]
Appliance 100A's protected processing environment 154a may perform
certain rights and permissions clearing operations 400a, certain
certifying authority operations 500a, and certain secure directory
services support operations 600a all at the consumer's site to
complement, add to or substitute for operations performed by rights
and permissions clearinghouse 400, certifying authority 500 and
secure directory services 600.
[0302] FIG. 3B shows that another example consumer electronic
appliances 100(2), . . . , 100N (in this case personal computers
124) might perform different combinations of support or
administrative functions locally (for example, some or all of the
functions performed by transaction authority 700). For example:
[0303] the processes within protected processing environment 154(1)
may rely on a partially distributed and partially centralized
financial clearinghouse 200A, a partially distributed and partially
centralized usage clearinghouse 300A, a partially distributed and
partially centralized rights and permissions clearinghouse 400A, a
partially distributed and partially centralized certifying
authority 500A, a centralized secure directory services 600A, and a
centralized transaction authority 700A; [0304] the processes within
protected processing environment 154(2) may rely on a centralized
financial clearinghouse 200B, a partially distributed and partially
centralized usage clearinghouse 300B, a partially distributed and
partially centralized rights and permissions clearinghouse 400B, a
centralized certifying authority 500B, a centralized secure
directory services 600B, and a partially distributed and partially
centralized transaction authority 700B; and [0305] the processes
within protected processing environment 154(N) may rely on a
partially distributed and partially centralized financial
clearinghouse 200N, a partially distributed and partially
centralized usage clearinghouse 300N, a partially distributed and
partially centralized rights and permissions clearinghouse 400N, a
partially distributed and partially centralized certifying
authority 500N, a partially distributed and partially centralized
secure directory services 600N, and a partially distributed and
partially centralized transaction authority 700N.
[0306] Taking this concept of distributed clearing services
further, it would be possible to completely distribute the
Distributed Commerce Utility 75 as shown in FIG. 3C--relying mostly
or completely on administrative and support service operations and
activities within the secure, protected processing environments 154
of users' electronic appliances 100. Thus, the users' own
electronic appliances 100 could--in a distributed manner--perform
any or all of financial, usage, and rights and permissions
clearing, as well as certification, secure directory services and
transaction authority services. Such "local" and/or parallel and/or
distributed processing transaction clearing might more efficiently
accommodate the needs of individual consumers. For example, this is
one way of allowing consumers to contribute controls that prevent
certain private data from ever leaving their own electronic
appliance while nevertheless providing rightsholders with the
summary information they require.
[0307] The distributed arrangements shown in FIGS. 2A-2E and 3A-3C
are not mutually exclusive ways of providing centralized Commerce
Utility System 90. To the contrary, it may be advantageous to
provide hybrid arrangements in which some administrative and
support service functions (such as, for example, micro-payment
aggregation, usage data privacy functions, and some issuing of
certificates, such as parents issuing certificates for their
children) are widely distributed while other administrative and
support service functions (for example, issuance of important
digital certificates, maintaining massive data bases supporting
secure directory services, etc.) are much more centralized. The
degree of distributedness of any particular administrative and
support service, clearinghouse or function may depend on a variety
of very important issues including, for example, efficiency,
trustedness, scalability, resource requirements, business models,
and other factors. In addition, the degree of distribution may
involve multiple levels of hierarchy based, for example, on
sub-sets determined by specific business models followed by
specific business sub-models, or, for example, geographic and/or
governing body and/or region areas.
[0308] Since a given electronic appliance 100 can participate in
multiple activities, it is possible that its different activities
may rely on different blends of distributed and centralized
Commerce Utility Systems 90. For example, for one activity a
protected processing environment 154 may rely on a centralized
financial clearinghouse 200, for another activity it may rely on a
partially distributed and partially centralized financial
clearinghouse 200, and for still another activity it may rely on a
wholly distributed financial clearinghouse 200. Different degrees
of distributedness may be used for different activities or business
models.
Web of Commerce Utility Systems
[0309] FIG. 4 shows that Commerce Utility System 75 may comprise a
vast "web" of distributed, partly distributed and/or centralized
Commerce Utility Systems 90. Network 150 can be used to connect
this web of Commerce Utility Systems 90 to a variety of different
electronic appliances 100 that can all share the Distributed
Commerce Utility 75. For example, electronic network 150 can
connect to: [0310] set top boxes 106 and/or media players 104,
[0311] personal computers 124, [0312] computer graphics
workstations 126, [0313] multi-media/video game systems 128, or
[0314] any other kinds of electronic appliances 100 including for
example, manufacturing control device, household appliances,
process control equipment, electronic networking and/or other
communication infrastructure devices, mainframe and/or mini
computers, etc.
[0315] In this example, the same Distributed Commerce Utility 75
can support a variety of different kinds of activities of a number
of different consumers, authors, distributors, providers,
merchants, and other people--and the Distributed Commerce Utility
75 can support a very large variety of different electronic
activities. FIG. 4 also shows that Commerce Utility Systems 90 may
communicate with electronic appliances 100 (and with each other) by
exchanging electronic "containers" 152 of the type disclosed in
Ginter et al. for purposes of security (for example, secrecy,
authenticity and integrity) and managed through the use of secure
rules and controls processed in protected processing
environments.
The Commerce Utility Systems Web can be Virtually Limitless
[0316] FIG. 4A shows that the web of Commerce Utility Systems may
be vast or limitless. Indeed, network 150 may be a seamless web
stretching around the world and connecting millions upon millions
of electronic appliances with any number of Commerce Utility
Systems 90.
[0317] The Commerce Utility Systems 90 web may provide a very
complex interconnection with a variety of different types of
electronic appliances performing a variety of different electronic
functions and transactions. As mentioned above, any of electronic
appliances 100 may be able to communicate with any of the Commerce
Utility Systems 90 or with any other electronic appliance. This
allows maximum efficiency and flexibility in terms of allocating
different Commerce Utility Systems to different electronic
transactions. For example: [0318] Geographically close Commerce
Utility Systems might best be used to minimize the amount of time
it takes to get messages back and forth. [0319] In some cases, more
distant Commerce Utility Systems might be better equipped to
efficiently handle certain kinds of specialized transactions.
[0320] Government regulations might also, at least in part, dictate
the selection of certain Commerce Utility Systems over others. (for
example, a Japanese customer may run into legal problems if she
tries to use a financial clearinghouse 200 located in the Cayman
Islands--or a New Jersey resident might be required by law to deal
with a financial clearinghouse 200 that reports New Jersey sales
tax). [0321] Different, competitive Commerce Utility Systems are
likely to be offered by different parties and these different
systems would populate the web comprising Distributed Commerce
Utility 75. Interoperability between such System and/or their nodes
is important for efficiency and to allow reusability of electronic
commerce resources. Rights Holders and Providers can Choose Among
Commerce Utility Systems
[0322] FIG. 5 shows how rights holders can select between different
Commerce Utility Systems 90. In this example, Bob operates a first
usage clearinghouse 300a, Alice operates a second usage
clearinghouse 300b, and Helen operates a third usage clearinghouse
300c. These various usage clearing service providers may compete
with one another based on quality and/or price, or they may be
complementary (for example, they may each specialize in different
kinds of transactions).
[0323] Because electronic network 150 may connect electronic
appliances 100 to many different Commerce Utility Systems 90,
rightsholders in the digital properties the consumers are using may
have a number of different Commerce Utility Systems to choose from.
Content providers and rights holders may authorize particular (or
groups of) Commerce Utility Systems 90 to handle different aspects
of transactions. For example: [0324] Computer software distributor
might specify that a personal computer 124 should send metering
information 116a to Helen's usage clearinghouse 300c for monitoring
usage of the computer software or other activities performed by the
personal computer. [0325] A rights holder in video program 102a
might specify that set top box 106 should send metering information
116 about the video to Alice's usage clearinghouse. [0326] A
multimedia content provider might specify that Bob's usage
clearinghouse 300a should be used for processing usage data 116c
generated by multimedia player 128.
[0327] In some instances, particular consumers 95 may also pay a
role in specifying in advance particular clearinghouses or other
Commerce Utility Systems 90 they prefer to use. FIG. 5 illustrates
the provider's (and/or consumer's) choice by a policeman directing
metering traffic to selected usage clearinghouses 300 (electronic
controls as described herein and in Ginter et al. would preferably
be the mechanism actually controlling how traffic is directed).
[0328] A content provider or rights holder could allow a consumer
95 to select from a group of Commerce Utility Systems 90 (and/or
Commerce Utility Systems 90 providers) the content provider/rights
holder wants to deal with. For example: [0329] A television studio
might authorize specific individual or classes of Commerce Utility
Systems 90 to handle transactions relating to its television
programs and/or it may specify particular individual or classes of
Commerce Utility Systems 90 that it doesn't want to have handle its
transactions. [0330] Particular Commerce Utility Systems 90 may set
requirements or standards for individual (or classes of) providers
and/or consumers 95. [0331] Value chain participants could enter
into legal agreements and/or business relationships with different
Commerce Utility Systems 90. Commerce Utility Systems can Work
Together
[0332] FIG. 6 shows that different Commerce Utility Systems 90 can
work together to support different kinds of operations. In this
example: [0333] Usage clearinghouse 300a, rights and permissions
clearinghouse 400a, certifying authority 500a, and financial
clearinghouse 200a (left-hand side of drawing) might be used to
support a particular operation by set top box 106 and television
set 102. [0334] The same financial clearinghouse 200a but a
different usage clearinghouse 300b, a different certifying
authority 500b and a different rights and permissions clearinghouse
400b (top of drawing) might be used to support certain activities
on personal computer 124. [0335] A still different financial
clearinghouse 200c, certifying authority 500c and usage
clearinghouse 300c but the same rights and permissions
clearinghouse 400b (right-hand side of drawing) might be used to
support electronic activities of multimedia system 128. [0336] A
still different combination of Commerce Utility Systems (in this
example, usage clearinghouse 300c, financial clearinghouse 200d,
rights and permissions clearinghouse 400c and certifying authority
500a--along the bottom of the drawing) might be used to support
sound system 130.
[0337] This example shows that various Commerce Utility Systems 90
may operate in combination, and that different combinations of
Commerce Utility Systems might be used to support different
electronic transactions.
Administrative and Support Service Functions can be Combined within
General Purpose Commerce Utility Systems for Efficiency or
Convenience
[0338] FIG. 7 shows that different special purpose Commerce Utility
Systems 90 administrative and support service functions or
sub-functions may be integrated together into more general or
multi-purpose Commerce Utility Systems 90 for maximum convenience,
efficiency or other reasons. For example: [0339] Bob may operate an
integrated or combined Commerce Utility System 90a providing a
financial clearinghouse 200a function, a certifying authority 500a
function, and a usage clearinghouse 300a function. [0340] Anne may
operate an integrated or combined Commerce Utility System 90b
providing a financial clearinghouse function 200b, a rights and
permissions clearinghouse function 400b and a transaction authority
function 700b. [0341] Helen may operate an integrated or combined
Commerce Utility System 90c providing a rights and permissions
clearinghouse function 400c and a certifying authority function
500c. [0342] Roger may operate an integrated or combined Commerce
Utility System 90d providing secure directory services 600d, usage
clearinghouse services 300d, financial clearinghouse services 200d
and rights and permissions clearinghouse 400d.
[0343] A consumer operating electronic appliances 100 may access
any or all of these different Commerce Utility Systems 90 or
combinations. For example, set top box 106 might obtain rights and
permissions and certificates from Helen's Commerce Utility System
90c, but might make use of Bob's Commerce Utility System 90a for
financial clearing and usage analysis.
[0344] A Commerce Utility System 90 may provide any combination of
administrative and support functions or subfunctions as may be
desirable to perform the operations required in certain business
models, provide maximum efficiency, and/or maximize convenience.
For example, Anne's Commerce Utility System 90(2) might provide
only a specialized subset of financial clearinghouse function
[0345] FIG. 7A shows another illustration of how Commerce Utility
Systems 90 can offer a wide variety of different combinations or
subcombinations of administrative and support functions. In this
FIG. 7A diagram, each of the various administrative and support
service functions is represented (for purposes of illustration) as
a different kind of child's play block: [0346] financial clearing
functions 200 are shown as square blocks, [0347] Usage clearing
functions 300 are shown as half-circle blocks, [0348] Rights and
permissions clearing functions 400 are shown as rectangular blocks,
[0349] Certifying authority functions 500 are shown as triangular
blocks, [0350] Secure directory service functions 600 are shown as
tunnel blocks, and [0351] Transaction authority functions 700 are
shown as cylinders.
[0352] Consumer and user appliances 100 are shown as standing-up
rectangular columns in the diagram. Electronic network 150 is shown
as a road which connects the various Commerce Utility Systems to
one another and to consumer electronic appliances 100. Electronic
digital containers 152 may be carried along this electronic network
or "information highway" 150 between different electronic
installations.
[0353] FIG. 7A illustrates just some of the many possible
administrative and support service combinations that might be used.
For example: [0354] In the upper left-hand corner, a Commerce
Utility System 90A provides at least some financial clearing
functions 200a, at least some rights and permissions clearing
functions 400a, and at least some certifying functions 500a. This
type of overall electronic Commerce Utility System 90A might, for
example, be in the business of managing and granting rights on
behalf of rights holders and in handling payments based on those
rights. [0355] The Commerce Utility System 90D just to the right of
installation 90A comprises financial clearing services 200d and
transaction authority services 700a. It might be especially useful
in, for example, auditing and/or managing an overall complex
multi-step transaction while also ensuring that appropriate parties
to the transaction are paid. [0356] In the lower center of the
diagram there is a Commerce Utility System 90B including financial
clearing functions 200f and usage clearing functions 300c. This
Commerce Utility System 90B could be especially useful, for
example, for handling payment and other financial details relating
to electronic usage transactions and also providing audit and
report services based on the electronic usage. [0357] The Commerce
Utility System 90C shown in the bottom center of the drawing
combines certifying authority services 500 with usage clearing
services 300f. It could be especially useful in issuing digital
certificates and then tracking the usage of those certificates (for
example, in order to evaluate risks, potential liability, insurance
costs, etc.).
[0358] The various examples shown in FIG. 7A are for purposes of
illustration. Other combinations are possible or likely depending
on business objectives, convenience and other factors.
Commerce Utility System Hierarchies
[0359] FIG. 8A shows that Commerce Utility Systems 90 or functions
can be arranged in a hierarchy. For example, an overall financial
(or other) clearinghouse 200(N) may oversee and/or have ultimate
responsibility for the operations of numerous other financial (or
other) sub-clearinghouses 200(1), 200(2), . . . . In the FIG. 8A
example, a consumer electronic appliance 100 might interact with a
clearinghouse 200(1), which might in turn interact with another
clearinghouse 200(2), etc. This administrative and support service
"hierarchy" might be thought of as being similar in some ways to a
chain of command in a large corporation or in the military--with
some clearinghouses exercising and/or delegating power, control
and/or supervision over other clearinghouses.
[0360] FIG. 8B shows another example of a administrative and
support service hierarchy. In this example, a number of centralized
overall clearinghouses and/or other Commerce Utility Systems 90
delegate some or all of their work responsibilities to other
Commerce Utility Systems 90. In this particular example shown,
organizations, such as companies, non-profit groups or the like may
have their own Commerce Utility Systems 156. Certain electronic
commerce or other activities (the entertainment industry, for
example) might have their own vertically-specialized Commerce
Utility Systems 158. Certain geographical, territorial or
jurisdictional groups (e.g., all purchasers of particular products
within the state of Wisconsin) may have their own
territorial/jurisdictional specialized Commerce Utility Systems
160. Commerce Utility Systems 156, 158, 160 lower in the hierarchy
may, in turn, further delegate authorities or responsibilities to
particular consumers, organizations or other entities.
[0361] In one example arrangement, the Commerce Utility Systems 90
to which authority has been delegated may perform substantially all
of the actual support work, but may keep the more over arching
Commerce Utility Systems 90 informed through reporting or other
means. In another arrangement, the over arching Commerce Utility
Systems 90 have no involvement whatsoever with day to day
activities of the Commerce Utility Systems to whom they have
delegated work. In still another example arrangement, the more
specialized Commerce Utility Systems do some of the work and the
more overarching Commerce Utility Systems do other parts of the
work. The particular division of work and authority used in a
particular scenario may largely depend on factors such as
efficiency, trustedness, resource availability, the kinds of
transactions being managed, and a variety of other factors.
Delegation of clearing authority may be partial (e.g., delegate
usage aggregation but not financial or rights management
responsibilities), and may be consistent with peer-to-peer
processing (e.g., by placing some functions within consumers'
electronic appliances while keeping some more important functions
centralized).
Multi-Function Commerce Utility Systems can be Organized
Hierarchically or Peer-to-Peer
[0362] FIG. 9 shows a still different, more complex Commerce
Utility System environment including elements of both a
hierarchical chain of command and a high degree of cooperation in
the horizontal direction between different multi-function Commerce
Utility Systems 90. In this example, there are five different
levels of responsibility with a master or overarching Commerce
Utility Systems 90(1) (for example, a financial clearinghouse 200)
on level 1 having the most authority and with additional Commerce
Utility Systems on levels 2, 3, 4, and 5 have successively less
power, authority, control, scope and/or responsibility. FIG. 9 also
shows that different Commerce Utility Systems on the same level may
have different functions, scopes and/or areas of responsibility.
For example: [0363] a Commerce Utility System 90(2)(1) may be a
"type A" Commerce Utility System, [0364] Commerce Utility System
90(2)(2) might be a "type B" Commerce Utility System, and [0365]
Commerce Utility System 90(2)(3) might be a "type C" Commerce
Utility System.
[0366] On the next level down, Commerce Utility Systems might be
type A Commerce Utility System (such as, 90(3)(1) and 90(3)(2)),
they might be type B Commerce Utility Systems (such as, 90(3)(4)),
they might be type C Commerce Utility Systems (such as, 90(3)(5),
90(3)(6)), or they might be hybrids--such as, Commerce Utility
System 90(3)(3) which is a hybrid having type A and type B
functions.
[0367] FIG. 9 also shows that additional clearinghouses on levels 4
and 5 might have sub-types as well as types. In the context of a
financial clearinghouse 200 for example, Type A might be
responsible for consumer credit, Type B for electronic checks, and
Type C for commercial credit. Another demarcation might be clearing
for Visa (Type A), Mastercard (Type B) and American Express (Type
C). A Type A/B clearinghouse would then be a clearing delegation
that could handle both consumer credit and electronic check
clearing. A Type B Subtype I might be responsible for commercial
electronic checks. A Type C Subtype I might be commercial credit
card transactions, and Subtype III might be credit drafts. The
rationale for multiple instances might be based on jurisdictional
boundaries (e.g., France, Germany, New York, and Alabama), and/or
contractual arrangements (e.g., delegation of responsibility for
bad credit risks, small purchasers, very large transactions, etc.)
The peer-to-peer dimension might reflect a need to coordinate an
overall transaction (e.g., between a small purchaser's
clearinghouse and a large commercial player's clearinghouse).
[0368] A rights and permissions clearinghouse 400 might break out
along content types (e.g., movies; scientific, technical and
medical; and software). Subtype A might include first run movies,
oldies, and art films; subtype B might handle journals and
textbooks; and type C might be responsible for games, office,
educational content. Peer-to-peer communications between
clearinghouses could involve multimedia presentation permissions
(e.g., a multimedia presentation might have permissions stored at
one clearinghouse that uses a back channel to other clearinghouses
to ensure that the latest permissions are distributed).
Some Example Commerce Utility Systems
[0369] As described above, Commerce Utility Systems 90 are
generalized and programmable--and can therefore provide a mix of
different support and administration functions to meet requirements
of a given transaction. Thus, many or most Commerce Utility Systems
90 as actually implemented may provide a range of different support
and administrative functions that may make it difficult to
categorize the implementation as being of one particular "kind" of
Commerce Utility System as opposed to another.
[0370] Nevertheless, certain types of idealized specialized
Commerce Utility Systems 90 are particularly useful for a wide
range of models, transactions and applications. It is helpful and
convenient to describe some of the characteristics of these "pure"
Commerce Utility Systems of different types--recognizing that
actual implementations may mix functions or function subsets from
several of these idealized models. The following are brief
vignettes of some of the characteristics of such "pure" idealized
Commerce Utility Systems.
Financial Clearinghouse 200
[0371] FIG. 10 shows an example financial clearinghouse 200 in more
detail. Financial clearinghouse 200 handles payments to ensure that
those who provide value are fairly compensated. Financial
clearinghouse 200 may securely coordinate with other Commerce
Utility Systems 90 in performing this task.
[0372] In this example, financial clearinghouse 200 may communicate
with appliance protected processing environment 154 over electronic
network 150 in a secure manner using electronic containers 152 of
the type described, for example, in the Ginter et al. patent
specification in connection with FIGS. 5A and 5B. Financial
clearinghouse 200 may receive payment information 202 from
protected processing environment 154 in these secure containers
152, and interact electronically or otherwise with various banking,
credit card or other financial institutions to ensure that
appropriate payment is made.
[0373] Financial clearinghouse 200 may, for example, interact with
a consumer's bank 206a, a provider's bank 206b and a consumer's
credit card company 206c. For example, financial clearinghouse 200
can debit funds from the consumer's bank 206a and credit funds to
the rights holder's bank 206b to pay for the consumers' watching of
a movie, television program or other content. Additionally or
alternately, financial clearinghouse 200 may interact with a
consumer's credit card company 206c to request credit checks,
obtain credit authorizations, payments and the like.
[0374] Financial clearinghouse 200 may provide payment statement
statements 204 to consumers 95--for example, by transmitting the
statements to appliance 100 in a secure electronic container 152b
to preserve the confidentiality of the statement information. In
this example, consumers 95 can view the statements 204 using their
appliance 100 protected processing environment 154, and may also be
able to print or save them for record-keeping purposes.
[0375] In one example, the payment mechanism 118 provided by
protected processing environment 154 might be an electronic wallet
supplying electronic money for use in paying for electronic
services or content. This electronic wallet may hold money in
digital form. Consumers 95 can spend the digital money on whatever
they wish. When the electronic wallet is empty, consumers 95 can
have the financial clearinghouse 200 replenish the wallet by
authorizing the financial clearinghouse to debit the funds from the
consumers' account in their bank 206a. Financial clearinghouse 200
may process electronic money payments, arrange for the electronic
wallet to be refilled automatically (based on the consumers'
pre-authorization, for example) when the consumers have spent all
of its former contents, and provide the consumers with detailed
reports and statements 204 about how they have spent their
electronic money.
Usage Clearinghouse 300
[0376] FIG. 11 shows an example usage clearinghouse 300. Usage
clearinghouse 300 in this example receives usage information 302
from usage meter 116, analyzes the usage information and provides
reports based on the analysis it performs. Usage clearinghouse 300
may securely coordinate with other Commerce Utility Systems 90 in
accomplishing these tasks.
[0377] For example, usage clearinghouse 300 may send the consumers
95 a detailed report 304a of all the movies, television programs
and other material the consumers have watched over the last month.
The communication between protected processing environment 154 and
usage clearinghouse 300 may be in the form of secure containers
152. As described in the Ginter et al. patent disclosure, usage
meter 116 can meter use on the basis of a number of different
factors, and can range from being extremely detailed to being
turned off altogether. The consumers, if they desire, could view
the detailed usage report 304a on their television set 102.
[0378] Usage clearinghouse 300 can report to others about the
consumers' viewing habits consistent with protecting the consumers'
privacy. These reports can also be sent within secure containers
152. For example, usage clearinghouse 300 might provide a summary
report 304b to advertisers 306 that does not reveal the consumers'
identity but provides the advertisers with valuable information
about the consumers' viewing habits. On the other hand, with the
consumers' consent, usage clearinghouse 300 could provide a more
detailed report revealing the consumers' identity to advertisers
306 or to other specified people. In return, the consumers 95 could
be given incentives, such as, for example, discounts, cash, free
movies, or other compensation.
[0379] Usage clearinghouse 300 can also issue reports 304c to
rights holders 308--such as the producer or director of the video
program 102a the consumers 95 are watching. These reports allow the
rights holders to verify who has watched their program material and
other creations. This can be very useful in ensuring payment, or in
sending the consumers other, similar program material they may be
interested in.
[0380] Usage clearinghouse 300 might also send reports 304d to a
ratings company 310 for the purpose of automatically rating the
popularity of certain program material. Usage clearinghouse 300
might also send reports to other market researchers 312 for
scientific, marketing or other research.
Rights and Permissions Clearinghouse 400
[0381] FIG. 12 shows an example rights and permissions
clearinghouse 400. Rights and permissions clearinghouse 400 stores
and distributes electronic permissions 404 (shown as a traffic
light in these drawings). Permissions 404 grant and withhold
permissions, and also define consequences. Rights and permissions
clearinghouse 400 may work with other Commerce Utility Systems 90
to accomplish its tasks.
[0382] In this example, rights and permissions clearinghouse 400
may act as a centralized "repository" or clearinghouse for rights
associated with digital content. For example, broadcasters,
authors, and other content creators and rights owners can register
permissions with the rights and permissions clearinghouse 400 in
the form of electronic "control sets." These permissions can
specify what consumers can and can't do with digital properties,
under what conditions the permissions can be exercised and the
consequences of exercising the permissions. Rights and permissions
clearinghouse 400 can respond to requests 402 from electronic
appliance protected processing environment 154 by delivering
permissions (control sets) 188 in response.
[0383] For example, suppose that consumers 95 want to watch a
concert or a fight on television set 102. They can operate their
remote control unit 108 to request the right to watch a certain
program. Protected processing environment 154 may automatically
contact rights and permissions clearinghouse 400 over electronic
network 150 and send an electronic request 402. The rights and
permissions clearinghouse 400 can "look up" the request in its
library or repository to see if it has received (and is authorized
to provide) the necessary permission 404b from the program's rights
holder 400. It may then send the requested permission 188 to
protected processing environment 154.
[0384] For example, permission 188 might allow the consumers to
view the concert or fight only once and prohibit its copying with
copy protection mechanism 120. Permission 188 may also (or in
addition) specify the price for watching the program (for example,
$5.95 to be deducted from the consumers' electronic wallet).
Appliance 100 can ask the consumers 95 if they want to pay $5.95 to
watch the program. If they answer "yes" (indicated, for example, by
operating remote control 108), the appliance 100 can automatically
debit the consumers' electronic wallet and "release" the program so
the consumers can watch it.
[0385] Rights and permissions clearinghouse 400 can deliver
permissions 188 within a secure container 152b that may optionally
also contain the information controlled by the permissions--or
permission 188 may arrive at a different time and over a different
path than the program or other content travels to the appliance
100. For example, the permissions could be sent over network 150,
whereas the program it is associated with may arrive directly from
satellite 112 or over some other path such as cable television
network 114 (see FIG. 1).
[0386] Rights and permissions clearinghouse 400 may also issue
reports 406 to rights holders or other people indicating which
permissions have been granted or denied. For example, the author of
a book or video might, consistent with consumer privacy concerns,
be able to learn the exact number of people who have requested the
right to publish excerpts from his or her work. These kinds of
reports can supplement reports provided by usage clearinghouse
300.
Certifying Authority 500
[0387] FIG. 13 shows an example of a certifying authority 500.
Certifying authority 500 issues digital certificates 504 that
provide a context for electronic rights management. Certifying
authority 500 may coordinate with other Commerce Utility Systems 90
to accomplish its tasks.
[0388] Certifying authority 500 issues digital certificates 504
that certify particular facts. Digital certificate 122 is like a
driver's license or a high school diploma in some respects, since
they each provide proof of a certain fact. For example, we may show
our drivers' license to prove that we are old enough to vote, buy
liquor, or watch an "R" rated movie. This same driver's license
attests to the fact that we have a certain name and live at a
certain address, and that we have certain knowledge (of state motor
vehicle laws) and skills (the ability to maneuver a motor vehicle).
Digital certificate 504 is similar to that aspect of a driver's
license that confirms the identity of, and related facts pertaining
to the licensee, except that it is made out of digital information
instead of a laminated card.
[0389] In this example, certifying authority 500 may receive
consumer requests and associated evidence 502, and may issue
corresponding digital certificates 504 that certify particular
facts. Certifying authority 500 may also receive evidence,
credentials and possibly also certificate definitions from other
people such as government authorities 506, professional
organizations 508 and universities 510. As one example, the
certifying authority 500 might receive birth certificate or other
identity information from a government authority 506. Based on this
identity information, the certifying authority 500 may prepare and
issue a digital certificate 504 that attests to person's identity
and age. The certifying authority 500 might also issue digital
certificates 504 attesting to professional status, employment,
country of residence, or a variety of other classes and categories
based on various evidence and inputs from various people.
[0390] Certifying authority 500 may certify organizations and
machines as well as people. For example, certifying authority 500
could issue a certificate attesting to the fact that Stanford
University is an accredited institution of higher learning, or that
the ACME Transportation Company is a corporation in good standing
and is authorized to transport hazardous materials. Certifying
authority 500 could also, for example, issue a certificate 504 to a
computer attesting to the fact that the computer has a certain
level of security or is authorized to handle messages on behalf of
a certain person or organization.
[0391] Certifying authority 500 may communicate with protected
processing environment 154 and with other parties by exchanging
electronic containers 152. Electronic appliance 100's protected
processing environment 154 may use the digital certificates 504 the
certifying authority 500 issues to manage or exercise permissions
188 such as those issued by rights and permissions clearinghouse
400. For example, set top box 106 might automatically prevent any
consumer under 17 years of age from watching certain kinds of
program material, or it might provide a payment discount to
students watching educational material--all based on certificates
504 issued by certifying authority 500.
Secure Directory Services
[0392] FIG. 14 shows an example of secure directory services 600.
Secure directory services 600 acts something like a computerized
telephone or name services directory. Consumers 95 can send a
request 602 specifying the information they need. Secure directory
services 600 can "look up" the information and provide the answer
604 to consumers 95. Secure directory services 600 can work with
other Commerce Utility Systems 90 to perform its tasks.
[0393] For example, suppose consumers 95 want to electronically
order a pizza from Joe's Pizza. They decide what kind of pizza they
want (large cheese pizza with sausage and onions for example).
However, they don't know Joe's Pizza's electronic address (which
may be like an electronic phone number). Consumers 95 can use
remote control 108 to input information about what they want to
have looked up ("Joe's Pizza, Lakeville, Conn."). Protected
processing environment 154 may generate a request 602 containing
the identification information and send this request to secure
directory services 600. It can send the request in a secure
container 152a.
[0394] When secure directory services 600 receives the request 602,
it may access a database to locate the requested information.
Secure directory services 600 may have earlier obtained Joe's
electronic address directly from Joe or otherwise. Secure directory
services 600 may send the requested information back to appliance
100 in a response 604. Response 604 may also be in a secure
container 152b.
[0395] The consumers 95 can use this information to electronically
send their order to Joe's Pizza--which can display on Joe's order
terminal within a few seconds after the consumers send it. Joe may
deliver to consumer 95 a piping hot cheese, sausage and onion pizza
a few minutes later (by car--not electronically--since a physical
pizza is much more satisfying than an electronic one).
[0396] Secure directory services 600 can help anyone connected to
network 150 contact anyone else. As one example, secure directory
services 600 can tell usage clearinghouse 300 how to find a
financial clearinghouse 200 on network 150. Any electronic
appliance 100 connected to network 150 could use secure directory
services 150 to help contact any other electronic appliance.
[0397] As mentioned above, the request 602 to secure directory
services 600 and the response 604 it sends back may be encased
within secure containers 152 of the type described in the Ginter et
al patent specification. The use of secure containers 152 helps
prevent eavesdroppers from listening into the exchange between
consumers 95 and secure directory services 600. This protects the
consumers' privacy. The consumers 95 may not care if someone
listens in to their pizza order, but may be much more concerned
about protecting the fact that they are corresponding
electronically with certain other people (e.g., doctors, banks,
lawyers, or others they have a relationship of confidence and trust
with). Secure containers 152 also help ensure that messages sent
across network 150 are authentic and have not been altered.
Electronic containers 152 allow Joe's Pizza to trust that the
just-received pizza order actually came from consumers 95 (as
opposed to someone else) and has not been altered, and the
consumers can be relatively sure that no one will send Joe a fake
pizza order in their name. The use of secure containers 152 and
protected processing environment 154 in the preferred embodiment
also ensures that the consumers 95 cannot subsequently deny that
they actually placed the order with Joe's Pizza if they in fact did
so.
Transaction Authority 700
[0398] FIG. 15 shows an example transaction authority 700.
Transaction authority 700 in this example provides process control
and automation. It helps ensure that processes and transactions are
completed successfully. Transaction authority 700 may work with
other Commerce Utility Systems 90 to perform and complete its
tasks.
[0399] In more detail, transaction authority 700 in this example
monitors the status of an electronic transaction and/or process and
maintains a secure, reliable record of what has happened so far and
what still needs to happen for the overall transaction and/or
process to complete. Transaction authority 700 may also, if
desired, perform a more active role by, for example, generating
requests for particular actions to occur. Transaction authority 700
may in some cases be the only participant in a complex transaction
or process that "knows" all of the steps in the process.
Transaction authority 700 can also electronically define an overall
process based on electronic controls contributed by various
participants in the process.
[0400] FIG. 15 illustrates an example of how transaction authority
700 can be used to allow consumers 95 to order merchandise such as
a sweater. In this particular electronic home shopping example
(which is for purposes of illustration but is not intended to be
limiting in any way), the consumers 95 can use their remote control
108 to select the particular seller, style and color of a sweater
they want to order at a particular price. In this home shopping
example, appliance 100's protected processing environment 154 may
generate an electronic order 702 which it sends to the order
receiving department 704 of an electronic "mail order" company. The
order 702 may be sent within a secure container 152a.
[0401] In this example, transaction authority 700 may assist the
electronic mail order company to coordinate activities and make
sure that all steps required to deliver the sweater are performed
in an accurate and timely fashion. For example: [0402] Upon
receiving the electronic order 702, the order receiving department
704 might provide an electronic notification 706 to transaction
authority 700. The transaction authority 700 stores the electronic
notification 706, and may issue a "requirement" 708. [0403]
Transaction authority 700 may have issued the requirement 708
before the order was placed so that the order receiving department
704 knows what to do when the order comes in. [0404] In accordance
with the "requirement" 708, order receiving department 704 may
issue an electronic and/or paper (or other) version of the order
710 to a manufacturing department 712. [0405] The transaction
authority 700 may issue a manufacturing requirement 714 to the
manufacturing department to make the sweater according to the
consumers' preferences. [0406] Transaction authority 700 might also
issue a supply requirement 716 to a supplier 718. For example,
transaction authority 700 may request supplier 718 to deliver
supplies, such as balls of yarn 711, so manufacturer 712 has the
raw materials to manufacture the sweater. [0407] Supplier 718 may
notify transaction authority 700 when it has delivered the supplies
by issuing a notification 720. [0408] When manufacturing department
712 has finished the sweater, it may alert transaction authority
700 by sending it a notification 722. [0409] In response to the
notification 722 sent by manufacturing department 712, transaction
authority 700 may issue a shipping requirement 724 to a shipping
department 726, for example, requesting the shipping department to
pick up completed sweater 728 from the manufacturing department and
to deliver it to the consumers. [0410] Transaction authority 700
may coordinate with other Commerce Utility Systems 90, such as a
financial clearinghouse 200, to arrange payment.
[0411] Of course, this example is for purposes of illustration
only. Transaction authority 700 may be used for all kinds of
different process control and automation such as, for example,
handling electronic orders and sales, electronic data interchange
(EDI), electronic contract negotiation and/or execution, electronic
document delivery, inter and intra company transactions, and the
secure electronic integration of business processes within or among
business organizations--just to name a few of many useful
applications.
VDE Administration Services 800
[0412] VDE administrator 800 (see FIG. 1 of this application and
FIG. 1A and associated discussion in the Ginter et al.
specification) may, in the preferred embodiment, provide a variety
of electronic maintenance and other functions to keep network 150,
appliance 100 protected processing environments 154 and Distributed
Commerce Utility 75 operating securely, smoothly and efficiently.
For example, VDE administrator 800 may manage cryptographic keys
used for electronic security throughout network 150, and may also
provide services relating to the maintenance of secure data by
appliances 100, the various Commerce Utility Systems 90, and other
electronic appliances. As described in detail in the Ginter et al.
patent disclosure, other important functions performed by VDE
administrator 800 include installing and configuring protected
processing environments 154, and helping protected processing
environments to securely maintain stored permissions and/or usage
data. The VDE administrator 800 may work with other Commerce
Utility Systems 90.
Commerce Utility Systems 90 can Support One Another
[0413] In addition to supporting consumers 95, Commerce Utility
Systems 90 can support other Commerce Utility Systems. This is
shown in FIGS. 16A-16F. For example: [0414] financial clearinghouse
200 can help ensure other Commerce Utility Systems 90 are paid for
their contributions (see FIG. 16A); and [0415] usage clearinghouse
300 (see FIG. 16B) may inform other Commerce Utility Systems 90
concerning how the support they provide is being used. For example,
usage clearinghouse 300 may tell certifying authority 500 how the
certifying authority's certificates have been used (very useful for
the certifying authority to keep tabs on the amount of potential
liability it is undertaking or in helping to detect fraudulent
certificates). [0416] FIG. 16C shows that a rights and permissions
clearinghouse 400 can support other Commerce Utility Systems 90
such as, for example, a financial clearinghouse 200, a usage
clearinghouse 300, another rights and permissions clearinghouse
400', a certifying authority 500, a secure directory services 600,
and a transaction authority 700. [0417] Certifying authority 500
can issue digital certificates 504 certifying the operation of one
or more other Commerce Utility Systems 90 (see FIG.
16D)--supporting other Commerce Utility Systems 90 such as, for
example, a financial clearinghouse 200, a usage clearinghouse 300,
a rights and permissions clearinghouse 400, another certifying
authority 500', secure directory services 600, and transaction
authority 700. [0418] FIG. 16E shows that a secure directory
services 600 may support other Commerce Utility Systems 90, such
as, for example, financial clearinghouse 200, usage clearinghouse
300, rights and permissions clearinghouse 400, certifying authority
500, other secure directory services 600', and transaction
authority 700.
[0419] FIG. 16F shows that a transaction authority 700 can support
other Commerce Utility Systems 90, such as, for example, a
financial clearinghouse 200, a usage clearinghouse 300, a rights
and permissions clearinghouse 400, a certifying authority 500, a
secure directory services 600, and another transaction authority
700'.
"A Piece of the Tick"
[0420] The Commerce Utility Systems 90 described herein provide
valuable, important services and functions. The operators of such
services can and should be compensated for the services they
provide. Financial Clearinghouse Commerce Utility Systems 200 can
ensure that they and other support service providers receive this
compensation without inconvenience to other electronic community
and value chain participants.
[0421] In assisting or compensating value chain participants, a
Commerce Utility System 90 may (based on pre-approved contractual
arrangements) take its own portion or percentage to compensate it
for the clearing services it provides Support services can be
compensated based on a small portion of payment (i.e., a
"micro-payment") attributable to each electronic transaction (a
"piece of the tick"). Providers may pass some or all of these fees
along to their own value chain participants in various ways.
[0422] Several different classes of value chain participants may be
called upon to compensate the Commerce Utility Systems 90,
including: [0423] Information Consumers (including for example,
people who make use of the information "exhaust" generated by
electronic commerce, electronic transaction management and rights
management activities); [0424] Content Rightsholders and Other
Electronic Providers; [0425] Participants in the broadest range of
secure, distributed electronic commerce transactions. [0426] In
addition, various support service providers may also need to
support one another in various ways--and may therefore need to
compensate one another. For example: [0427] One Commerce Utility
System 90 may act as an intermediary for another Commerce Utility
System 90's customer; [0428] One Commerce Utility System 90 may be
required to support the operation of another Commerce Utility
System 90; and/or [0429] Commerce Utility System 90s may need to
work together to support a common transaction.
[0430] Different Commerce Utility System 90s may cooperate to
establish a common fee that they then divide among themselves. In
another scenario, each Commerce Utility System 90 may independently
charge for the value of its own services. There may be competition
among different Commerce Utility System 90s based on quality of
service and price--just as credit card companies now compete for
providers' and consumers' business.
Example Distributed Commerce Utility System Architecture
[0431] The Ginter et al. patent disclosure describes, at pages 180
and following, and shows in FIG. 10-12, for example, a "Rights
Operating System" providing a compact, secure, event-driven,
compartmentalized, services-based, "component" oriented,
distributed multi-processing operating system environment that
integrates VDE security control information, components, and
protocols with traditional operating system concepts. The preferred
example Commerce Utility System 90 architecture provided in
accordance with these inventions builds upon and extends the Rights
Operating System described in Ginter et al.
[0432] For example, the preferred example Commerce Utility System
90 architecture provides a collection of service functions that the
Rights Operating System may execute as applications. These service
functions define a variety of useful tasks that any and/or all
Commerce Utility Systems 90 may need to perform. These service
functions are distributable, scaleable and reusable. They can be
combined in various combinations and sub-combinations--depending
upon business models, for example--to provide the overall
functionality desired for any particular Commerce Utility System 90
implementation.
[0433] FIG. 17A shows an example overall architecture of a Commerce
Utility System 90, FIG. 17B shows an example of the application
architecture of a Commerce Utility System, and FIG. 17C shows more
detail of a service function.
[0434] Referring first to FIG. 17B, in this example the application
software architecture for a Commerce Utility System 90 contains a
commerce utility system descriptor 90A. Commerce utility system
descriptor 90A contains information about the Commerce Utility
System 90 that may be used to identify such system and its
capabilities, as well as to describe, aggregate and/or interface
with any number of service functions 90B(1), 90B(2), . . . Commerce
utility system descriptor 90A and service functions 90B may, for
example, be implemented using object oriented programming
techniques to help ensure that such descriptor and service
functions are modular and reusable--as well as abstracting the
specifics of how actions requested of Commerce Utility System 90
are actually carried out and/or implemented.
[0435] Commerce utility system descriptor 90A(1) may also be
responsible for coordinating the action of service functions 90B.
In this example, descriptor 90A is used to direct requests and
other system actions to the appropriate service functions 90B, and
to ensure that actions requiring more than one service function are
coordinated by reconciling differences in interfaces, data types
and the like that may exist between the service functions 90B--as
well as helping to direct overall process flow amongst the various
service functions 90B. A non-exhaustive list of examples of such
service functions 90B include the following: [0436] audit, [0437]
maintaining records, [0438] overseeing processes, [0439] monitoring
status, [0440] complete process definition, [0441] process control,
[0442] interface(s) to settlement services, [0443] funds transfer,
[0444] currency conversion, [0445] tax calculation and application,
[0446] account creation and identifier assignment, [0447] payment
aggregation, [0448] payment disaggregation, [0449] budget
pre-authorization, [0450] status notification, [0451] confirmation,
[0452] uncompleted events record, [0453] requirements generation,
[0454] report generation, [0455] event consequences, [0456] account
reconciliation, [0457] identity authentication, [0458] electronic
currency creation, [0459] event database management, [0460] routing
database, [0461] generating requests, [0462] replication, [0463]
propagation, [0464] usage database management, [0465] bill creation
and processing, [0466] market research, [0467] negotiation, [0468]
control set database management, [0469] control set generation,
[0470] process control logic, [0471] event flow generation, [0472]
routing, [0473] archiving, [0474] rights and permissions database
management, [0475] template database management, [0476] commerce
management language processing, [0477] rights management language
processing, [0478] advertising database management, [0479]
automatic class generation, [0480] automatic class assignment,
[0481] notary, [0482] seal generator, [0483] digital time stamp,
[0484] fingerprint/watermark, [0485] offers and counteroffers,
[0486] object registry, [0487] object identifier assignment, [0488]
copyright registration, [0489] control set registry, [0490]
template registry, [0491] certificate creation, [0492] revocation
list maintenance, [0493] director database management, [0494]
database query and response processing, [0495] other service
functions.
[0496] FIG. 17C shows more detail of a service function 90B. In
this example, service function 90B is comprised of a service
function descriptor 90C, and any number of service application
components 90D(1), 90D(2), . . . Service function descriptor 90C
performs a role similar to that of commerce utility system
descriptor 90A, except that it acts with respect to service
function 90B and service application components 90D. Service
function descriptor 90C and service application components 90D may,
for example, also be implemented using object oriented programming
techniques to help ensure that such descriptor and service
application components are modular and reusable, as well as
abstracting the specifics of how actions requested of service
function 90B are actually carried out and/or implemented. In this
example, the service application components 90D implement most of
the capabilities of the service function 90B by carrying out steps
of, or subfunctions of, the service function 90B.
[0497] FIG. 17A shows an example overall Commerce Utility System 90
architecture. The overall architecture shown in this example is an
object oriented system in which the overall Commerce Utility System
90 is a single object, that is in turn comprised of reusable
service function 90B objects. These service function 90B objects
are comprised of reusable service application components (objects)
90D. Any or all of these objects may make use of the services
provided by a commerce utility support service layer 90-4, as
described in more detail below. The preferred embodiment Commerce
Utility System architecture 90 shown is built upon the Rights
Operating System 90-1 described in detail in the Ginter et al.
patent specification (see FIG. 12 of Ginter, et al., for example).
A set of service functions 90B comprise "applications" executed by
the Rights Operating System 90-1. There can be any number of
service functions 90B.
[0498] The object oriented design of the Commerce Utility System 90
architecture shown in FIG. 17A has several desirable attributes.
For example, a Commerce Utility System 90 may easily add, remove
and/or replace service functions 90B to alter, extend and/or
enhance its capabilities. Similarly, the architecture allows the
addition, removal, and/or replacement of service application
components 90D to permit similar flexibility in the case of service
functions. Furthermore, object oriented design significantly
improves the ease and efficiency of reuse of service functions
and/or service application components in different Commerce Utility
Systems 90, or different service functions 90B (as shown in FIG.
17A); respectively.
[0499] The application layer, which is comprised of service
function layer 90-2 and service application component layer 90-3
(comprising components 90D.sub.A), may be, if desired, supported by
a commerce utility support services layer 90-4. Commerce utility
support services layer 90-4 may provide increased efficiency for
large numbers of transactions. Such commerce utility support
services 90-4 may include, for example: [0500] session management,
[0501] fault tolerance, [0502] memory management, [0503] load
balancing, [0504] database bridging, and [0505] other commerce
utility support services.
[0506] In this example, service functions 90B are component based,
and may make use of the reusable and component based service
application components 90D. The service application components 90D
typically perform steps of, or subfunctions of, service functions
90B. Each service application component 90D can have either or both
of two parts:
[0507] a component 90-B.sub.a that need not execute within
protected processing environment 154; and
[0508] a secure component 90-B.sub.b that needs to execute within
protected processing environment 154.
[0509] In this example architecture, there may be a correspondence
between components 90D.sub.a and components 90D.sub.b. For example,
at least one component 90D.sub.a may correspond with at least one
secure component 90D.sub.b. There may be a one-to-one
correspondence between components 90-D.sub.a and components
90D.sub.b (as indicated in FIG. 17A by common geometric shapes). In
the preferred embodiment, this separation of function permits, when
required and/or desired, the interaction between secure processes
operating in PPE 154 and service application components 90D. By
using this architecture, it is easier and more efficient to create
service functions that implement capabilities requiring both
application level support as well as secure processing.
[0510] For example, some administrative and/or support functions
for performance by commerce utility systems 90 may involve use of
both application level database functions as well as information
protected by a protected processing environment ("PPE") 154 in the
preferred embodiment. A specific example of this might be the
records of payment by a user of a financial clearinghouse 200. If
the operator of such a financial clearinghouse 200 chose to keep
payment history information in an application level database, but
needed information protected by PPE 154 in order to accurately
determine the current account status of a customer, implementing a
service application component 90D.sub.A that coordinated the
information in the application level database with information
protected by PPE 154 and processed by service application component
90D.sub.B into a single object may significantly simplify the task
of using this information in the context of a given service
function 90B (e.g. a decision to extend additional credit).
Furthermore, this example service application component may be
reusable in other service functions 90B.
[0511] In another example, service application component 90D.sub.A
might serve principally as an application level interface object to
a corresponding PPE 154 object 90D.sub.B. For example, if a notary
service function 90B requires the application of a digital
signature, a service application component 90D.sub.A might
principally provide an interface that transports information to,
and receives information from, a corresponding service application
component 90D.sub.B that performs essentially all of the actual
work of creating and applying a digital signature. In addition, the
application level service component 90D.sub.A might provide
additional exception handling, protocol conversion, or other
functions designed to help integrate capabilities more easily or in
a different manner than originally designed for a service function
90B.
[0512] FIG. 17D-1 shows an example correspondence between service
functions 90B and general types of useful example commerce utility
systems 90. Example service functions 90B ("Audit", "Maintaining
Records", . . . ) are shown horizontally. These example service
functions 90B may be useful for implementing commerce utility
system 90 example types ("Financial Clearinghouse", "Usage
Clearinghouse", . . . ) written vertically in the row of boxes
along the top of the diagram. The FIG. 17D-1 diagram is not
exhaustive--additional useful commerce utility system types are
possible and additional service functions 90B are also possible.
Indeed, the architecture of Commerce Utility System 90 ensures that
both types and service functions 90B are extensible as business
models or other factors change.
[0513] Although certain business needs and models may tend to
inspire the use of certain combinations and collections of
important service functions in almost any implementation, the
Commerce Utility System 90 architecture is inherently
flexible--allowing the implementer to freely mix and combine a
variety of different service functions depending upon their needs.
For example, it is useful to provide a Commerce Utility System 90
that functions as a "financial clearinghouse 200"--providing
payment processing, communications, database management, and other
related service functions. The Commerce Utility System architecture
can provide such a "financial clearinghouse"--and is also
inherently much more generalized and generalizable. For example, a
particular Commerce Utility System 90 implementation of a
"financial clearinghouse" could also combine "non-financial"
service functions with financial service functions. The particular
functions or sets of functions that are realized in any given
Commerce Utility System 90 implementation depend upon the
individual needs of the implementer--as dictated for example by
business model(s) or functions.
[0514] FIG. 17D-2 shows, for example, how the overall functionality
of an example "financial clearinghouse" commerce utility system 200
can be constructed from example service functions 90B. In this
example, the service functions 90B surrounded by darker lines are
included within the commerce utility system descriptor 90a shown in
FIG. 17B. FIG. 17D-2 shows an example usage clearinghouse commerce
utility system 300 constructed based on a different subset of
service functions 90B surrounded by dark lines (shown in FIG.
17D-1). Comparing FIGS. 17D-2 and 17D-3, one can see that some
service functions 90B (for example, "audit," "status notification,"
"event database management," etc.) may be reused for both financial
and usage clearing operations. A combination financial and usage
clearinghouse commerce utility system 90 might use the union of the
service functions 90B surrounded by dark lines in FIG. 17D-2 and
the service functions 90B surrounded by dark lines in FIG. 17D-3.
More, less and/or different functionality can be provided for a
particular commerce utility system 90 simply by providing and
invoking more, less and/or different service functions 90B.
Distributing Commerce Utility System 90
[0515] The secure application components 90-3 described above may,
in the preferred embodiment, include or comprise reciprocal control
structures and associated rules and methods shown in FIGS. 41A-41D
and 48 of the Ginter et al. patent application. These reciprocal
control structures can be used to interlink different or the same
control sets operating on the same or different Commerce Utility
Systems 90 or other electronic appliances 100. Hence, each actor
can have one or more reciprocal relationships with every other
actor--with Commerce Utility System 90 involved in some role in
some of the various actions.
[0516] FIGS. 17E-1 through 17E-4 show different examples of
interaction models Commerce Utility System 90 may use to interact
with an ongoing transaction or process based in part on these
reciprocal control structures: [0517] FIG. 17E-1 shows an event
intermediation model in which a Commerce Utility System 90 receives
an event notification 748 from a secure entity (e.g., a first
protected processing environment) and generates an event 758 which
triggers activities of another (and/or the same) secure entity
(e.g., a second and/or the first protected processing environment).
[0518] FIG. 17E-2 shows a different Commerce Utility System
interaction model in which the first secure entity provides event
notification 748 to both a Commerce Utility System 90 and another
secure entity to perform a step, but the second entity awaits
receipt of an authorization from Commerce Utility System 90 to
proceed before it actually performs the next step in the process.
[0519] FIG. 17E-3 shows a notification model in which Commerce
Utility System 90 is more of a passive bystander, receiving event
notifications 748 for purposes of secure auditing but otherwise not
interacting directly with the ongoing process or transaction unless
needed to resolve exceptions (e.g., an error condition). [0520]
FIG. 17E-4 shows a prior authorization model in which the Commerce
Utility System 90 must issue a notification 748 to one secure
entity in response to receipt of an event notification 748 from
that entity before that entity may pass the event notification 748
along to the next secure entity to perform the next step in a
overall process or transaction.
[0521] The various Commerce Utility System 90 interaction models
shown in FIGS. 17E-1 through 17E-4 are not exhaustive or mutually
exclusive--any given transaction or process may include some or all
of these in different combinations based upon business models or
other requirements.
[0522] As mentioned above, the present inventions provide
techniques for distributing the operation of a particular service
function 90-2 or service application component 90-3 throughout a
system 50 or network--including for example to electronic
appliances of individual consumers 95. FIG. 17F shows an example of
a control set 188 that can be used to control a remotely located
protected processing environment (for example, a consumer's
electronic appliance) to perform a "local" portion of a clearing
operation. A Commerce Utility System 90 could deliver this control
set 188 to a consumer's electronic appliance, to another Commerce
Utility System 90, or to some other electronic appliance (e.g., one
that is part of a communicating infrastructure). The Commerce
Utility System 90 can, for example, delegate part of its clearing
authority (implemented, for example, as one or more service
functions 90-2, each including one or more service application
components 90-3) to a process that can be performed within the
protected processing environment 154 of a user's electronic
appliance.
[0523] The FIG. 17F example is a method 850 (e.g., meter, billing,
or budget) whose AUDIT event 852(1) is processed by an audit method
854. The example meter method 850, for example, might have: [0524]
a USE event 852(2) (e.g., "click" the meter), [0525] an INITIALIZE
event 852(1) (e.g., prepare the meter for use), [0526] a RESET
event 852(3) (e.g., restore the meter to a known good state after
an error condition), [0527] an AUDIT event 852(4) (e.g., gather up
records generated during USE events, as well as a copy of the
current UDE value, and arrange for shipment to the auditor(s)),
[0528] a READ USE RECORD event 852(5) (e.g., return a copy of the
requested use record), [0529] a READ UDE event 852(6) (e.g., return
a copy of the current UDE), [0530] a READ MDE event 852(7) (e.g.
that returns a copy of the requested MDE), and [0531] other
miscellaneous events.
[0532] The AUDIT event 852(4), in this example, may be linked to an
audit method 854. In order to access the data in this example, the
Commerce Utility System 90 might need permission in the form of
access tags and/or an appropriate PERC control set defining more
detailed usage permissions, and semantic knowledge of the record
format written out by the meter method 850's USE event 852(2). The
semantic knowledge could come from an out-of-band agreement (e.g.,
a standard), or through access to the MDE (or relevant MDE portion)
of the meter method 850 that describes the use record format.
[0533] The events of audit method 854 would include a USE event
856(2) that performs the functions expected by the calling method's
event--in this case, gathering use records and a copy of the
current UDE, and sending them off. In this example, let's assume
there is an INITIALIZE event 856(1) in this method as well. When
called, the INITIALIZE event 856(1) would be sent internally, and
its associated load module(s) would call back to the READ MDE event
852(7) of the meter method 850 to learn the semantics of the use
records. Then, the USE event 856(2) would be called and the load
module(s) 858(2) associated with processing this event would call
the appropriate events of the meter method 850 (e.g., READ USE
RECORD repeatedly, and READ UDE once). At this point, the
expectations of the calling method have been fulfilled, except for
administrative object packaging and transmission.
[0534] In order to implement more distributed clearing functions,
the USE event 856(2) may do more processing. For example, while
reading in the USE records from the meter, the audit method 854 may
implement analysis functions (e.g., categorizing the types of
objects used, and reducing the information reported up the clearing
chain to a simple count of how many times various types of content
were accessed). Records from content types that are not interesting
may be discarded. The detailed records themselves may be discarded
after analysis. In another example, the UDE values (e.g., how many
clicks are recorded) may be compared to the number of use records
retrieved, and if there is a discrepancy, they can be reported
and/or acted upon locally (e.g., disabling use of the objects from
a given provider until further interaction). In still another
example, records may have user identity information removed to
ensure privacy. In a further example, some use records may be
processed and analyzed locally (and then discarded), while other
detail records are saved for later processing.
[0535] Once the distributed clearing functions have been performed,
the information can be packaged up in one or more administrative
objects for transmission up the clearing chain to a centralized
location. This may involve a direct report to the provider(s),
and/or a report to another clearing function, for example. The
processed records may be released (for deletion, summary, filing,
etc. by the meter method) by the audit method 854 when received,
processed, transmitted, or on receipt of a confirmation by the
recipients.
[0536] In another example using the meter method 850 shown in FIG.
17F, the AUDIT event 854 could be performed "internally" by the
meter method 850. In this example, the use records and UDE would be
bundled up in one or more administrative objects for transmission
to the auditor(s) by the load module(s) 853 associated with the
AUDIT event 854(4) of the meter method 850. However, rather than
transmitting these objects, they could be processed locally. To do
this, the name services record used by ROS (see Ginter et al. FIGS.
12 and 13) to find the named auditor(s) could be redirected back to
the local PPE 154. In the PPE 154, a process controlled by the
Commerce Utility System 90 can be created (based on methods and/or
load modules delivered on their behalf) to perform the local
clearing functions described above, except using the content of the
administrative object(s), rather than calls to the meter method
events. This is more analogous to the function that would be
performed at a remote clearing facility in the sense that the
operations are performed on administrative objects and their
contents--but the processing can instead be done on the local
consumer electronic appliance, on a networked appliance.
[0537] Distributing support services in this manner provides
additional capabilities that may not be present or available in a
centralized architecture. For example, a rights and permissions
clearinghouse could delegate a local server within an organization
to keep track of requests and to cache copies of permissions
previously requested by the organization. Such a local rights and
permissions clearinghouse could reduce network traffic and provide
a convenient local repository for organization-specific permissions
(e.g., site licenses for computer software). The local rights and
permissions server could be authorized by rights holders or a
rights and permissioning agency or other rights distribution
organization to grant licenses on a request basis.
[0538] As another example, many secure, largely automated
administrative and support services may be distributed in whole
and/or in part to an at least occasionally connected
appliance--regardless of whether that appliance is a computer, set
top box, personal digital assistant (PDA) digital telephone,
intelligent digital television, or any other digital appliance.
Such appliances can use a protected processing environment to
ensure that the support service is performed securely and reliably,
free from tampering and other interference (e.g., as described in
the Ginter, et al. patent specification).
[0539] In another example, one possible VDE content distribution
scenario involves content providers performing the initial
packaging role, distributors performing the distribution function,
users keeping track of usage records, and clearinghouses processing
usage and financial information. This is in contrast to a
centralized processing model, in which all of these functions are
performed by a single centralized party.
[0540] As still another example, efficiency increases can be
realized by distributing clearinghouse functions across individual
user machines, local area network (LAN) servers, and/or corporate
"gateway" machines that bridge the corporate LAN/WAN environment
with the outside world, and commercial "backbone" servers.
[0541] As another example, a company's computer might be authorized
by a central certificate authority to grant certain kinds of
digital certificates. For example, the company might be a member of
a certain trade organization. The trade organization's certifying
authority might give the company a digital certificate attesting to
that fact, and delegate to the company's own computer the
certifying authority to issue certificates attesting to the fact
that each of the company's employees is a member of the trade
organization. Similarly, parents may be authorized to issue digital
certificates on behalf of their offspring.
[0542] The techniques described above illustrate how the
Distributed Commerce Utility, through use of the Commerce Utility
System 90 architecture, can be distributed across multiple Commerce
Utility Systems. Furthermore, the service functions 90-2 provided
by one or more Commerce Utility Systems 90 may be decomposed into
complete, or even partial, process steps (e.g., service application
components 90-2) that are performed in whole or in part on other
Commerce Utility Systems 90, or any other system (including end
user systems) selected by the participants in a given scenario.
Example Commerce Utility System Types
[0543] Financial Clearinghouse 200
[0544] FIG. 18 shows an example of a Financial Clearinghouse
Commerce Utility System 200. "Financial Clearinghouses" support
automated, efficient financial fulfillment for electronic
transactions. For example, financial clearinghouse 200 may collect
payment related information and details, and efficiently arrange
for the transfer of money and other compensation to ensure that
value providers get paid, including the automated, selective
disaggregation of a payment into payment portions directed to
appropriate value chain participants. Financial clearinghouses 200
may also provide credit, budgets limits, and/or electronic currency
to participant (e.g., end-user) protected processing environments,
wherein the financial clearinghouse may have distributed some of
its operations to such protected processing environments for
secure, local performance of such operations. The following are
some example financial clearing support functions that can be
provided through the use of the present inventions: [0545] Clearing
of financial transactions in a secure, efficient, timely and
accurate manner. [0546] Providing secure financial clearing on
payment mechanisms that are trusted by, and convenient for value
providers and users/consumers. [0547] Assuring payment to rights
holders and other value chain participants (for example, providers
who supply value to the electronic community in some part of the
process from creation, to distribution, to sale, and to delivery)
without requiring them to take on the task of managing a large
number of financial interfaces with widely dispersed customers
and/or a variety of often complex financial services standards and
protocols. [0548] Allowing content consumers to pay for information
goods and associated services using a variety of different payment
vehicles via a common, trustable interface. [0549] Allowing each
party involved in a transaction to verify that a given exchange has
occurred as it was mutually intended, and to preclude repudiation
of the transaction by any party. [0550] Reconciling accounts at
time of purchase or usage reporting (e.g., transferring funds from
a value chain participant account to one or more provider
accounts). [0551] Supporting frequent and granular transaction
clearing activities. [0552] Providing financial clearing services
to all value chain participants (e.g., buyers, distributors and
sellers of digital content of all kinds as well as buyers,
distributors, and sellers of physical goods and user of other
services). [0553] Interfacing distributed electronic commerce
domains with existing electronic, paper and/or other payment and/or
clearing services, including but not limited to credit card
systems, bank debit card systems, smart card systems, electronic
data interchange, automatic clearinghouses, digital money, etc.
[0554] The effecting, by one or more banks and/or other
organizations, of settlement and reconciliation and/or interfacing
directly with entities who may legally perform settlement services.
[0555] The effecting of the creation of, and assigning of,
identifying labels, numbers, names or other unique identifiers, by
one or more banks and/or other organizations to digital process
and/or digital information creators, information distributions
and/or modifiers, and/or customer and/or other user accounts for
funds, credits and debits. [0556] Using secure containers in any
step, part, or process of providing secure financial clearing
services. [0557] Controlling secure financial clearing processes
based, at least in part, on rules and controls stipulating the
distribution of processes to be performed at each protected
processing environment of a distributed financial clearinghouse
systems, e.g., clearing performed by the user protected processing
environments, web servers, centralized clearing facilities. [0558]
Efficiently and securely handling conversions from one currency to
another. [0559] Enabling payment fulfillment on provision of other
consideration including service fees, product fees and/or any other
fees or charges based at least in part on content, process control,
and/or rights management use. [0560] Supporting wide use of
micro-fees and micro-payments at least in part based on content,
process control, and/or other usage transactions, wherein said
support may include the distributed, secure accumulation and/or
processing of micro-transaction activity and the periodic passing
of information related to such activity through a clearinghouse
network for further processing and/or accumulation. [0561]
Efficiently measuring and managing micro-payment activity while
minimizing transaction overhead. [0562] Minimizing latency in
micro-payment transaction handling. [0563] Aggregating or
"bundling" transactions against local value store or other payment
vehicles (methods). [0564] Employing value chain rules and controls
and chain of handling and control for efficiently administrating
the disaggregation (splitting apart) of payments, including the
assignment or transfer to different value chain providers of
payments based on the same or differing electronic control sets
controlling usage and/or other permissions (e.g., securely
controlling payment consequences through the parsing of payment
amounts among various value chain parties as required by rules and
controls before specific payment methods are activated. [0565]
Reducing (e.g., minimizing) the number of electronic messages
required to support a given set of electronic transactions through,
for example, distributed transaction processing and/or transaction
activity accumulation. [0566] Supporting local aggregation
(bundling or combining together) of multiple payments or
micro-payments at a value chain participant's site. [0567] Allowing
value providers (e.g., value chain participants) to efficiently
check another value chain participant's ability to pay before
providing services or goods (physical and/or electronic) on credit.
[0568] Allowing value providers to authorize an appropriate level
of funding for estimated purchase levels on a value chain
participant's preferred payment vehicle, including, for example,
allowing the provision of budgets for credit and/or currency that
can be expended towards all and/or only certain classes of
transactions (e.g., content and/or process control types)
including, for example, budgets for disbursement for expressly
specified categories of expenditures such as only G and PG movies.
[0569] Providing verification of the identity of a potential value
chain participant and binding of that identity to the value chain
participant's selected payment vehicle(s). [0570] Providing
periodic reporting of transaction activity for clearinghouse
reconciliation and recordation purposes. Performing auditing,
billing, payment fulfillment and/or other consideration and/or
other clearing activities. [0571] Providing event driven reporting
based, for example, on time, place, depletion of local funds,
and/or class of disbursement activity such as purpose (for
business, entertainment, travel, household expense), family member
or other individual or group identity, category of content or other
goods and/or services acquired, and/or category any of type of
disbursement activity [0572] Receiving authority from secure chain
of handling and control embodied in electronic control sets. [0573]
Granting authority and/or providing services to, and/or in
conjunction with, one or more distributed financial clearinghouses
that are some combination of subordinate to, and/or have
peer-to-peer relationships with, one or more of said
clearinghouses. [0574] Distributing financial clearing functions
across a network or other system (for example, every consumer or
other value chain participant node can perform distributed
financial clearing services and wherein said participant node may
communicate financial clearing information directly to one or more
other participants) and in accordance with rules and controls and
other VDE techniques as described in the Ginter, et al patent
specification. [0575] Granting authority and/or providing services
to, or in conjunction with, one or more financial
sub-clearinghouses whose operations may be located logically and/or
physically elsewhere, such as within a company or government agency
and/or within one or more jurisdictions and/or serving subsets of
the overall business focus area of a senior financial
clearinghouse. [0576] Distributing and/or otherwise authorizing
financial clearing functions across a system or network, for
example, where every consumer and/or certain or all other value
chain participant nodes can potentially support a distributed usage
clearing service initiating its own, secure financial clearing
transactions and function in the context of the overall
clearinghouse network including clearinghouse interoperation with
one or more other participant, interoperable nodes, and as
elsewhere in this list, all activities employing VDE techniques as
appropriate. [0577] Efficiently calculating, collecting, and
dispersing sales and "value added taxes" imposed by at least one
jurisdiction. [0578] Supporting a web of financial clearinghouses
in which one or more classes (groups) of clearinghouse have
interoperable, peer-to-peer relationships and in which, differing
groups may have differing rights to interoperate with members of
other groups, for example financial clearinghouses on end-user
protected processing environments may have limited rights to
inter-operate with "primary" financial clearinghouses. [0579]
Supporting a web of clearinghouse protected processing environments
in which such protected processing environments comprise discreet
"banks" or banking protected processing environments, and where
such protected processing environments can employ VDE capabilities
to securely govern and perform banking functions such as the secure
storage (locally and/or remotely) of notational currency, the right
to "lend" stored currency to end-user and/or other clearinghouse
protected processing environments, the right to launch electronic
currency objects, the right to fulfill payment from local or remote
currency store(s), the ability to receive communications
representing obligations to pay (e.g., electronic bills), the
ability to fulfill such payments, and the ability to operate as a
component banking "branch" of one or more virtual bank(s) (or
banking network(s)) wherein such bank performs many of the roles
currently performed by conventional banks. [0580] Supporting the
ability for financial clearinghouses to create electronic currency
that is conditionally anonymous and where such currency may be
employed in the fulfillment of payment obligations and where such
currency is treated as authentic without the requirement that a
receiving party connect after such receipt with a remote banking
authority for assessing that the currency is valid or authorized
for use. [0581] Supporting the ability for distributed
clearinghouse protected processing environments to operate--in
conjunction with one or more capabilities described above--on
portable devices such as smart cards (e.g., electronic wallets,
etc.) where cellular or land-line communication means (or other
transport mechanisms) support on-line or asynchronous communication
of information related to a current or an plural transactions such
as billing or other audit information regarding commerce activity
including identification, for example, of purchasers, sellers,
and/or distributors, and authorization information, budget
information, credit provision, currency provision, and/or
disbursement information, etc. related to such activity. [0582]
Supporting the provision of discounts, subsidies and/or coupons to
value chain participants, for example to consumer users, in
exchange for usage data or more finely grained usage data (for
example, ameliorating privacy concerns in some contexts). [0583]
May be organized hierarchically, peer-to-peer, or in a combined
mode where responsibility for financial clearing may be distributed
in differing fashions for differing commerce models and/or
activities and/or value chains and where certain one or more
parties may be, for example, hierarchically more senior to other
parties in one or more instances and hierarchically a peer or less
senior in one or more other instances. [0584] The relationship
among participants is programmable and may be set (and later
modified) to represent one or more desired financial clearing
arrangements for given commerce activities, value chains, or
models. [0585] Distributing payments to plural parties, including,
for example, taxes to one or more governments (e.g., city, state,
and federal).
[0586] FIG. 18 shows an example function oriented diagram for
financial clearinghouse 200. In this example, financial
clearinghouse 200 is highly automated, and operates in a trusted,
secure domain to provide a protected processing environment. It
efficiently provides financial clearing services to all kinds of
electronic commerce chains. It can also serve as a gateway between
the highly secure virtual distribution environment (VDE) domain and
other domains--providing protocol support for the existing
infrastructure. The gateway functions can allow the highly flexible
and distributed VDE protected processing environments to exploit
the inflexible and centralized, but ubiquitous and trusted,
existing financial infrastructure services.
[0587] The core functions of financial clearinghouse 200 relate to
payment processing 208, payment aggregation 212, payment
disaggregation 214, and micro-payment management 216--since these
functions collect money from customers and other value chain
participants, and pay money to value chain service or product
providers such as merchants.
[0588] In more detail, financial clearinghouse 200 may perform the
following functions in this example: [0589] payment processing 208,
[0590] credit checks 210, [0591] payment aggregation 212, [0592]
payment disaggregation 214, [0593] micro-payment handling 216,
[0594] event driven reporting 218, [0595] reconciliation 220,
[0596] database maintenance/management 222, [0597] replication 224,
and [0598] propagation 226.
[0599] Financial clearinghouse 200 may receive payment information
202, customer information 230, provider information 232, and
aggregated reports and bills 234 from the outside world. It may
generate debit orders 236, credit orders 238, statements and
reports 204, 240, release signals 242, and credit checks and
authorizations 244.
[0600] Database management 222 and event driven reporting 218 may
be used to securely provide accurate financial reports to value
chain participants. Reconciliation function 220--which is related
to both reporting and financial management--allows financial
clearinghouse 200 to provide more reliable financial management.
Replication function 224 and propagation function 226 are used by
financial clearinghouse 200 to facilitate distributed processing
with other financial clearinghouses 200 and/or other secure or
insecure protected processing environments, permitting the
financial clearinghouse to securely share state and update
information with other Commerce Utility Systems or other
participants.
[0601] In the example shown, the payment information 202 (which may
arrive in one or more secure containers 152) is the primary input
to payment processing block 208. If desired, payment information
202 can also include some or all of the usage information sent to a
usage clearinghouse 300--or it may include different types of usage
information more relevant to financial auditing and transaction
tracking. This payment information 202 can arrive in real time or
on a delayed (e.g., periodic or other event-driven) basis.
[0602] Financial clearinghouse 200 uses provider information 232
and customer information 230 to effect funds transfers between
customers and providers. Financial clearinghouse 200 uses
aggregated reports and bills 234 to guide the overall payment
processing 208 as well as payment aggregation 212 and payment
disaggregation 214. For example, financial clearinghouse 200 may
issue debit and credit orders 236, 238 to third party financial
parties such as banks, credit card companies, etc., to effect
debiting of consumer accounts and corresponding crediting of
provider accounts. Financial clearinghouse 200 may issue statements
204 and reports 240 for secure auditing and/or informational
purposes. Financial clearinghouse 200 may issue credit
authorizations 244 after performing credit checks 210, thereby
extending credit to appropriate value chain participants. Such
authentication 244 may include an input/output function, unless
they are performed entirely locally (i.e., an authorization request
comes in, and clearinghouse 200 is the source of credit and/or
credit limit information).
[0603] Financial clearinghouse 200 may issue release signals 242 in
appropriate circumstances to allow electronic appliances 100 to
stop maintaining and/or keep "pending" financial information after
it has been transferred, analyzed and/or processed by financial
clearinghouse 200. In one example, the user appliance 100 may,
within business model limitations, store the financial information
even after it is "released," reduce it to a summary, etc. Of
course, it may have already done this with a copy of the data
(e.g., if previously allowed to access it). For example, suppose
the local copy of financial usage information contains confidential
business model information. A property might cost $1.00 to view,
and that dollar may be split among several parties. Normally, the
user is only aware of the overall bottom line, not the details of
the split--even though a record may exist locally for each of the
participants in the transaction.
[0604] FIG. 19 shows an example architectural diagram for financial
clearinghouse 200. Financial clearinghouse 200 in this example
includes a secure communications handler 246, a transaction
processor 248, a database manager 250, a switch 252, and one or
more interface blocks 244. This example financial clearinghouse
architecture may be based, for example, on the operating system
architecture shown in FIGS. 12 and 13 of the Ginter et al. patent
specification (general purpose external services manager 172 in
that example could support settlement service interfaces 254 for
example). Secure communications handler 246 allows financial
clearinghouse 200 to communicate securely with other electronic
appliances 100(1) . . . 100(N). Such communications may be by way
of secure digital containers 152. It is desirable for most Commerce
Utility Systems 90 (including financial clearinghouse 200) to
support both real time and asynchronous receipt of containers 152.
In addition, financial clearinghouse 90 may also support a real
time connection protocol that does not require containers 152 for
simple transactions such as making a credit card payment that
doesn't have disaggregation requirements. The advantage to using a
real time connection is real time results. This may be beneficial
in circumstances where users need more money or credit because they
have run out (rather than simply making a report or receiving a
periodic replenishment of a budget that has not been exhausted),
and also when a provider (e.g., of content or budget) insists on
clearing a transaction before allowing whatever activity initiated
the transaction to go forward.
[0605] A connection for a real time transaction doesn't always
require secure containers 152, but using containers 152 even in
this scenario has advantages. For example, containers 152 permit
attachment of rules and controls to the contents, allowing users to
specify how the contents may be used. In addition, use of
containers 152 leverages existing capabilities in the protected
processing environment. Using a technique such as electronic mail
to deliver containers 152 (e.g., as attachments to SMTP mail
messages, or as attachments to any other e-mail protocol that
supports attachments) permits asynchronous processing of contents,
thereby allowing Commerce Utility Systems 90 to smooth out their
peak processing loads. A cost of operating a commercial
clearinghouse is the depreciation expense of the equipment. The
amount of equipment is principally driven by the peak load
requirement. One can expect a significant variance in load (for
example, compare Friday night at 8 pm versus Tuesday morning at 3
am). Smoothing out this function can lead to quite considerable
savings in equipment and related costs (electricity, personnel,
maintenance, etc.)
[0606] Transaction processor 248 may process and analyze received
information, and database manager 250 may store received
information in a database for later analysis and/or for historical
analysis (to increase credit limits, analyze payment histories,
etc.) In addition, database manager 250 may also store information
associated with existing credit limits, addresses for
communications (physical and/or electronic), and other account
information. For example, the Ginter et al. patent specification
discusses budget encumbrances. The database manager 250 may be used
to store information used to track encumbrances as well. There may
also be sets of security information used to communicate with
protected processing environments and/or users employing the
protected processing environments, and the settlement services.
Records associated with communications with the settlement services
may also be stored there as well. The database 250 may also be
outfitted with various reporting facilities related to its
contents.
[0607] Transaction processor 248 and database manager 250 together
perform most of the functions shown in FIG. 18. Switch 252 is used
to route information to and from interface blocks 244. Interface
blocks 244 are used to communicate with third party settlement
services, such as credit card companies, Automatic Clearing House
(ACH) systems for bank settlements, debit card accounts, etc.
Optionally, the internal settlement services provided by a Federal
Reserve Bank 256 may be used in lieu of or in addition to the third
party settlement services shown to provide settlement of accounts
in accordance with prevailing banking arrangements and legal
requirements. The payment mechanisms used by financial
clearinghouse 200 may be symmetrical (e.g., tell VISA to charge
consumer A's charge account and credit vendor Y's account) or
asymmetrical (e.g., tell VISA to debit consumer A's charge account
and provide the money to the financial clearinghouse which will
credit vendor Y's account using some other payment mechanism) as
allowed by applicable financial and banking regulations.
[0608] Example Financial Clearing Processes
[0609] FIG. 20 shows an example financial clearinghouse process. In
this example, a provider 164 provides goods, services or content to
a consumer 95. For example, provider 164 may provide one or more
digital properties 1029 and associated controls 404 within an
electronic secure container 152. A secure protected processing
environment 154 at the consumer 95 site keeps track of payment,
usage and other information, and may provide an audit trail 228
specifying this information. Audit trail 228 may be transmitted
from the site of consumer 95 to financial clearinghouse 200 within
one or more secure containers 152b. Audit trail 220 might include,
for example, the identification of the reporting electronic
appliance 100; the amount of payment; provider identification; the
consumer's desired payment method; the name or other identification
of the electronic appliance user; and the type(s) of transaction(s)
involved. The time and/or frequency of reporting might be based on
a number of different events such as for example, the time of day,
week, month, year or other time interval; the occurrence of some
related or unrelated event (e.g., pre-approval for a purchase is
required, a certain number of purchases have taken place, a local
electronic purse has been exhausted of funds, reporting is
necessary for some other reason, etc.); or a combination of
these.
[0610] Financial clearinghouse 200 analyzes the audit trail 228,
and generates one or more summary reports 240. Financial
clearinghouse 200 may provide the summary report 240 to provider
164 by transmitting it electronically within a secure container
152c. Financial clearinghouse 200 may also coordinate with a
financial intermediary 258 and one or more financial processors 260
to effect a debiting of a bank or other account owned by consumer
95 and corresponding crediting of a bank or other account owned by
provider 164.
[0611] For example, the financial clearinghouse 200 may receive the
audit information, disaggregate the transactions (into value chain
amounts for creators, distributors, and others; as well as for tax
authorities and other governmental entities), and then calculate an
amount due it from each of the transaction beneficiaries. Then, if
desired or necessary (due to the size of the transactions, per
transaction fees, or other efficiency and/or cost considerations),
the transactions may be rolled up into lump sums for each of the
parties, and submitted to a financial intermediary 258 (along with
appropriate account information) that is responsible for performing
credit card transactions. The financial intermediary 258 (who may
also charge a fee or take a percentage) may then cause transactions
to occur at the financial processor 260 such that the beneficiaries
each receive the appropriate amounts. Alternatively, if the
financial clearinghouse 200 has the ability and authorizations
necessary to submit credit card transactions directly to credit
card companies, it may cause the transactions to occur directly
with the financial processor 260 (e.g., Visa).
[0612] Financial processor 260 may send a statement 204 to provider
164 (and/or to consumer 95) detailing the financial debits and
payments that have occurred. It may provide statement 204 within a
secure container (not shown) if desired. Financial clearinghouse
200 may receive a portion or percentage of the debited funds to
compensate it for the financial clearing services it has
provided.
[0613] FIGS. 20A-20F show an example financial clearing activity
using a local electronic money purse 262 maintained at the
consumer's electronic appliance 100. In this example, financial
clearinghouse 200 may initially provide consumer 100 with
electronic money in the form of electronic cash by transmitting the
electronic cash within one or more secure containers 152. Financial
clearinghouse 200 may automatically debit the consumer's bank 206a
or other account to obtain these funds, and may do so at the
consumer's request (see FIG. 20A).
[0614] The consumer's electronic appliance 100 upon receiving the
electronic funds may deposit them within an electronic cash purse
262 it maintains within its protected processing environment 154
(e.g., as an "MDE" described in Ginter et al.) (see FIG. 20B). The
customer's electronic appliance 100 may use this locally stored
electronic money to pay for goods and services consumed by the
consumer. For example, a publisher 68 may provide a work 166, such
as a book, film, television program, or the like, to the consumer's
electronic appliance by transmitting it within one or more secure
containers 152b. The consumer may operate his or her electronic
appliance 100 to open the container and access the work 166,
allowing the consumer to use the work in the manner specified by
its associated electronic controls (see FIG. 20C).
[0615] Assuming that the rights owner requires payment in return
for usage of the work 166, the consumer's electronic appliance 100
may automatically debit electronic purse 262 by the amount of
payment required (in this case $5) (FIG. 20C). Additionally,
electronic appliance 100 may automatically generate a usage record
264 recording this usage event. Based on time and/or other event
occurrence, the consumer's electronic appliance 100 may
automatically send an audit trail 264--which may comprise a package
of audit records transmitted at audit time or set of related
records stored in the secure database--(or a summary of it to
protect the consumer's privacy)--to financial clearinghouse 200 in
the form of one or electronic containers 152c (see FIG. 20D).
[0616] Upon receiving the usage record 262 and successfully storing
it within its own database 250, financial clearinghouse 200 may
send a release signal 242 within an electronic container 152d (see
FIG. 20D). This release signal 242 may allow the consumer's
electronic appliance 100 to delete the usage record 264 it had
previously maintained (see FIG. 20D).
[0617] The consumer may use the same or different work 166 again to
prompt generation of an additional usage record 264 and to
decrement the electronic purse 262 by another usage charge (in this
case exhausting the purse's contents) (see FIG. 20E). Exhaustion of
electronic purse 262 may prompt the consumer's electronic appliance
100 to again contact financial clearinghouse 200 to request
additional funds (see request 228) and to also provide usage record
264 (both pieces of information are transmitted within the same
electronic container 152e in this example) (see FIG. 20F).
[0618] Financial clearinghouse 200 may respond by transmitting
additional electronic funds (after debiting the consumer's bank or
other account), and may also provide another release signal
allowing the consumer's electronic appliance 100 to delete usage
record 264 (see FIG. 20F). The money collected may be paid to the
rights holders (after any appropriate reductions to compensate
Commerce Utility Systems 90).
Payment Disaggregation
[0619] FIG. 21 shows an example financial clearing activity
involving value chain "disaggregation." Financial clearinghouse 200
in this example efficiently, reliably and securely supports payment
disaggregation within a value chain. FIG. 21 shows a content
creator, such as an author, delivering a work 166 to a publisher
168. The publisher publishes the work (for example, within an
electronic book 166) and delivers it to a consumer 95. In this
example, the consumer 95 pays $20 for his copy of the book 166. The
consumer's payment is "disaggregated" or split up between the
author 164 and the publisher 168 based, for example, upon a
contractual agreement. In this example, the publisher receives four
of the consumer's $20 and the author receives the rest.
[0620] Disaggregation allows financial clearinghouse 200 to
automatically split up a consumers' payment among any number of
different value chain participants. This is extremely useful in
ensuring that all contributors to a product or service can reliably
and efficiently receive compensation for their respective
contributions.
[0621] FIG. 22 shows how financial clearinghouse 200 can support
the value chain disaggregation shown in FIG. 21. In the FIG. 22
electronic example, the customer 95 may deliver his payment
electronically to financial clearinghouse 200. This payment may be
in the form of electronic currency packaged within a secure
electronic container 152a, or it might be in some other form (e.g.,
reported usage information coupled with a preexisting authorization
for financial clearinghouse 200 to debit the bank account of
customer 95).
[0622] Financial clearinghouse 200 may distribute appropriate
shares of the customer's payment to author 164 and publisher 168 in
accordance with the agreement between the author and the publisher.
What tells financial clearinghouse 200 who should receive the
disaggregated parts of the payment? In this FIG. 22 example, the
work 166 may pass from the author 164 to the publisher 168 and from
the publisher 168 to customer 95 in electronic form within one or
more secure electronic containers 152. One or more electronic
control sets 188 may be included within the same or different
containers, these control sets being associated with the work 166
or other property. Control sets 188 may specify, among other
things, the amount of payment customer 95 must supply in order to
be able to use the work 166.
[0623] Controls 188 may also specify and control how the customer's
payment will be disaggregated among the other value chain
participants. For example, author 164 may specify within controls
188b the author provides, that she is to receive $16 for each copy
of work 166 purchased by an ultimate consumer 95. Because of the
secure chain of handling and control provided in accordance with
the virtual distribution environment (see the Ginter et al. patent
disclosure), author 164 can be confident (to the degree required by
the commercial priorities of the author and allowed by the strength
of the overall system) that publisher 168, customer 95 and any
other consumers or potential users of property 166 will be subject
to this control 188b. The publisher 168 may add its own controls to
the one specified by author 164, the publisher controls 188c
providing a $4 mark up (for example) that it will receive for the
use of its brand name, distributing and marketing services.
[0624] FIG. 22A shows a detailed example of how payment
disaggregation can be performed within the customer's protected
processing environment 154 using control sets 188 as described in
the Ginter et al patent disclosure. Ginter et al. teaches, in FIG.
48 and associated text, how a control set can implement and control
an overall metering, billing and budgeting process within a user's
protected processing environment 154. FIG. 22A illustrates payment
disaggregation based on one or more control sets 188 provided to a
consumer's protected processing environment 154. Each of the
processing blocks shown in FIG. 22A may be in response to a user
request (event) to open and access content.
[0625] In this particular example, a metering method 275 is
designed to pass an event to billing method 277 whenever the
consumer first uses a particular piece of content (meter event 275
could also or alternatively pass the event along each time the
consumer uses the content to provide a "pay per view" functionality
if desired).
[0626] The billing methods 277 include two different billing
methods 277a and 277b in this example. Methods 277a, 277b can be
independently deliverable--for example, the author 164 could
deliver billing sub-method 277a, and the publisher 168 could
deliver billing sub-method 277b. Billing method 277a writes
information to a billing trail data structure specifying how much
the author 164 is to be paid ($16 in this example). Billing method
277b writes information to the same or different billing trail data
structure specifying how much the publisher is to be paid ($4).
Billing methods 277a, 277b may each receive the open event passed
along by meter method 275, and may each write billing records to
the same (or different) billing trail data structure.
[0627] In this example, a budget method 279 may be delivered
independently of the billing methods 277a, 277b. Budget method 279
may write records to a budget trail data structure 281 specifying
(among other things) the payment disaggregation arrangement (i.e.,
the $16/$4 split between author and publisher) specified by the
billing methods 277a, 277b. The budget trail data structure 281
(which is maintained independently from the data structures
maintained by billing methods 277a, 277b and therefore cannot be
compromised by the author 164 and/or the publisher 168) might be
sent to a financial clearinghouse 200. The financial clearinghouse
200 would perform payment and debit financial clearing as described
above to result in the consumer's account being debited by $20, the
author's account being credited by $16 and the publisher's account
being credited by $4 (thus disaggregating the user's $20 payment
between the author 164 and the publisher 168). Meanwhile, the
billing trail data structure could be sent to a usage clearinghouse
300 specified by the author 164 and/or the publisher 168. Usage
clearinghouse 300 could analyze the billing trail data structure
and let author 164 and/or publisher 168 know what payments they
might expect to receive from the financial clearinghouse 200.
[0628] Thus, in this example, electronic control sets 188 may
specify or define, among other things: (i) rights available in a
particular digital object, (ii) the cost of exercising such rights,
and (iii) how payments for exercising rights will be divided
(disaggregated) among rightsholders. This ability to define payment
disaggregation in advance (before customers' payment methods and
arrangements are activated) provides a high degree of efficiency
and flexibility--since it can use the consumers' payment method,
for example, to automatically direct parts of the consumers'
payment to appropriate people who need to be compensated. Since the
same electronic appliance 100 that is being used to exercise the
rights is also being used to help direct payments to various
different value chain participants, a portion of the overall
financial clearing process is effectively distributed throughout a
large number of parallel computing resources. Because of the high
degree of trustedness that can be provided by the system disclosed
in the Ginter et al. patent specification, for example,
rightsholders can release such control sets 188 into the stream of
commerce with an appropriate that their payment arrangements will
be carried out. Financial clearinghouse 200 can help to ensure that
such disaggregated payments efficiently and rapidly reach their
required destinations.
[0629] A protected processing environment 154 at the site of
customer 95 securely enforces the augmented controls 188c,
requiring total payment and/or payment authorization from the
customer 95 before allowing the customer to access work 166.
Controls 188c may also specify which financial clearinghouse 200 is
to be used to handle payment processing, and what payment methods
are acceptable while still giving customer 95 flexibility in terms
of choosing a desired payment method. The customer's protected
processing environment 154c may then automatically send appropriate
payment or payment authorization 190a to financial clearinghouse
200 for disaggregation in accordance with controls 188a--which may
be the same controls (or a subset of those controls relating to
payment disaggregation) specified by the author and/or the
publisher.
[0630] Because the customer's protected processing environment 154c
generates controls 188a subject to the controls 188c, 188b
specified by the publisher and author (see FIG. 22), these payment
controls 188a can be trusted to carry out the payment wishes of the
author and the publisher and to reflect the payment dividing
agreement between the two of them. The customer's protected
processing environment 154c may send the customer's payment or
payment authorization 152a and these payment controls 188a to
financial clearinghouse 200 within one or more secure electronic
containers 152a.
[0631] Financial clearinghouse 200 processes the payment or payment
authorization 152a in accordance with controls 188a, distributing
payment 152b to the publisher and payment 152c to the author in
accordance with the payment dividing agreement reached between the
author and the publisher. Thus, for example, financial
clearinghouse 200 might send $4 of electronic money to the
publisher and $16 of electronic money to the author; or it might
credit the bank or other accounts of the author and publisher in
these amounts. Because this entire process takes place in a secure,
trusted virtual distribution environment, each of the value chain
participants can trust that they will in fact receive the payment
they require and the process can be carried on automatically and
electronically in a very efficient way that flexibly accommodates a
wide variety of different business models and ad hoc
relationships.
[0632] FIG. 23 shows a further, somewhat more complex payment
disaggregation example that adds a content distributor or
aggregator 170 to the value chain. In this example, the consumer
95's $20 may now need to be split three ways instead of two, with
the author 164 still receiving $16, the publisher receiving only $3
and the content distributor/aggregator 170 receiving $1 for his or
her efforts. FIG. 24 shows that the same basic arrangement shown in
FIG. 22 can be used to accommodate the payment and other interests
of this new value chain participant.
[0633] FIG. 25 shows a further payment disaggregation example. FIG.
25 shows how disaggregation can be used to compensate Commerce
Utility Systems 90 for their role in maintaining and managing the
value chain. As described above, the Distributed Commerce Utility
75 provides very important services, such as financial clearing,
usage auditing, permissioning, certification, etc. Entire
businesses or industries may be based on efficiently and reliably
providing these kinds of administrative and support services.
Commerce Utility Systems need to be compensated for their own
investments and efforts. One way for them to be compensated is to
receive a small part of every transaction--"a piece of the tick."
The same payment disaggregation mechanisms described above can also
be used to support such micropayments to Commerce Utility Systems
90.
[0634] FIG. 23 shows one example in which the Commerce Utility
Systems 90 receive 3% (e.g., $0.60 in the example shown) of the
value of each transaction. Because electronic control sets 188
discussed above can be used to implement such micro-payment
capabilities, any desired business arrangement or objective can be
flexibly and efficiently accommodated.
[0635] FIG. 26 shows that payment disaggregation can be used to
disaggregate or split up a single consumer payment into an
arbitrary number of different amounts (even recording amounts in
different types of currencies for international trading purposes)
at a variety of different destinations and using a variety of
different payment mechanisms (e.g., credit cards, bank accounts,
electronic money, etc.).
[0636] FIGS. 27 and 28 show still additional payment disaggregation
examples to further illustrate the flexibility in which Distributed
Commerce Utility 75 can handle these and other arrangements. The
FIG. 27 example shows the customer's payment being split up among
the author 164, the publisher 168, the aggregator 170, a repackager
174 and two additional authors 164a, 164b supplying additional
works incorporated within the electronic property being provided to
the customer. The FIG. 27 example is particularly applicable, for
example, where the repackager 174 takes content from several
sources on related matters and combines them into mixed source
products such as multimedia combinations, "current awareness"
packages, or newsletter-like publications for sale to interested
parties.
[0637] For example, repackager 174 might publish a newsletter on
contemporary politics, and select an essay written by author 164
for publication along with two other works written by authors 164a,
164b for publication in the next newsletter issue. Authors 164,
164a and 164b may grant repackager 174 the right to reformat and
redistribute the work. Taking advantage of this reformatting right,
repackager 174 may create the latest issue of the newsletter and
distribute it in a secure electronic container for reading by
customer 95. In this example, the secure electronic container 152a
may contain at least four separately "delivered" sets of business
requirements--one for each of the three works (as specified by each
of author 164, author 164a and author 164b) and one for the overall
newsletter (as specified by repackager 174). Alternatively, the
various works and/or the controls applying to them can be sent and
delivered in independent secure containers 152, and/or some or all
of the works and/or controls may be located remotely.
[0638] To read the newsletter, customer 95 opens electronic
container 152a. Suppose that the newsletter cost (as set by
repackager 174) is $10 per issue. The customer's $10 payment or
payment authorization is sent to financial clearinghouse 200, which
resolves it to give each value chain participant compensation (for
example, author 164 may get $1, publisher 168 may get $1,
aggregator 170 may get $0.50, each additional author 164a, 164b may
each get $1 and the repackager 174 may get the rest--all as
directed by the applicable electronic controls. Thus, the
repackager can be compensated for selecting appropriate articles on
the topic and combining them in a single, easy to read publication,
and may also bring its own brand name recognition as an indicator
of overall quality, and may itself add unique content of its own
creation.
[0639] FIG. 28 shows a "superdistribution" example. One key rights
holder concern is copyright infringement from "pass-along"--that
is, illegal duplication and redistribution. This pass-along problem
is serious in digital environments such as the Internet. The
virtual distribution environment disclosed in the Ginter et al.
patent specification and the administrative and support services
arrangements disclosed in this specification fundamentally
transform pass-along from a clear threat to an important
opportunity. Because of the unique, automated, secure electronic
management of value chain rights provided by the virtual
distribution environment in the preferred embodiment, the consumer
can be treated as a trusted member of the value chain. This makes
possible a superdistribution model in which all customers become
potential distributors. Since revenue from superdistribution incurs
only minimal rights holder costs, superdistribution provides large
profit potentials to holders of rights in successful works.
[0640] Looking at FIG. 28, assume that customer 95 received a work
from aggregator 170 that she likes so much that she wants to pass
it along to several friends and colleagues. Assuming that
aggregator 170 has granted customer 95 the right to redistribute
the work, the customer may simply and easily be able to send a copy
of the work to each of any number of additional potential customers
95(1) . . . 95(N). These additional people may know customer 95 and
believe that she would not be sending them something that was not
potentially interesting and of high quality. In addition, the
downstream customers may be able to read an abstract or see
extracts of the work (e.g., view a trailer of a film, read the
first chapter of a novel, or the like) without triggering
payment.
[0641] After reading the abstract or watching the first five
minutes of the film without cost, suppose six of the downstream
customers 95(3)-95(8) agree to pay for the content at an example
cost of $3.25 each. Financial clearinghouse 200 may ensure that the
author 164, publisher 168 and aggregator 170 each receive an
appropriate share of the income (e.g., $7 to the author, $7 to the
publisher and $8.75 to the aggregator).
[0642] Superdistribution makes possible any number of levels of
redistribution. For example, suppose that of the six downstream
customers 95(3)-95(8), three of them decide to pass the work along
to each of six additional potential customers--so that eighteen
additional people receive a copy. Since the redistributed works
have associated control structures mandating the same payment
arrangement, author 164, publisher 168 and aggregator 170 each
receive additional payments from each of these new customers. The
snowballing effect of redistribution can continue in this manner
across any number of consumers for a long time, and can
dramatically increase revenue with minimal additional cost to the
value chain members.
[0643] Payment Aggregation or Bundling
[0644] Micro-fees and micropayments may become an important basis
for content usage transactions. For example, a consumer might pay
each time she views a particular work or uses a certain piece of
computer software, or listens to a certain piece of music.
Different payment arrangements can be flexibly provided so that the
consumer might have the option of paying a larger initial fee for
unlimited usage or smaller micropayments on a per use basis. In
addition, micropayments may be the least burdensome and most
practical way for Commerce Utility Systems 90 to be compensated for
their services. The ability to efficiently handle micropayments is
thus very important in terms of supporting and enabling small
charges.
[0645] Traditional financial payment mechanisms, such as credit
cards, checks and the like, are unsuited to manage micropayments.
These systems typically have levels of transaction overhead that
impose severe burdens on business models based on many purchases
below $5 each. For example, if it costs $0.50 to handle a payment
transaction, it becomes uneconomical to handle payments for less
than some value, perhaps $2 each because the cost of handling the
payment is such a large portion of the transaction value, or even
exceeds the payment itself. Hence, traditional financial payment
mechanisms favor larger purchases and disfavor micro-purchases.
[0646] FIG. 29 shows how payment aggregation or bundling can be
used to circumvent these concerns by reducing the number of
individual financial transactions that need to be cleared, and/or
by reducing the amount of messaging required to clear those
transactions. The example payment aggregation shown in FIG. 29 may
be performed on the consumer's own electronic appliance 100 within
a protected processing environment 154; or at a centralized
financial clearinghouse 200; or part of it can be performed at the
appliance and part of it performed at the centralized
clearinghouse. This payment aggregation process can aggregate or
combine many small payments together into larger payments--or into
a bundle of small payments that can be handled all at once. Such
larger payments and/or bundles can be reported periodically along
with other transaction data if desired to be reconciled and
recorded by Distributed Commerce Utility 75. This ability to
aggregate smaller payments has important beneficial effects in
terms of increasing efficiency, reducing the number of individual
transactions that need to be cleared, and decreasing messaging
traffic over electronic network 150. Of course, payment aggregation
is not necessarily suitable for every transaction (some large,
critical or risky transactions may require real time clearing, for
example), but can be used in a large number of routine transactions
to reduce the burdens on Commerce Utility Systems 90 and overall
system 50.
[0647] In one variation on this concept, payment aggregation may
preserve the amounts of each individual transaction to allow high
degree of reporting granularity but may be used to trigger when
reporting occurs (e.g., after X dollars have been charged, or Y
number of transactions have occurred) so that many individual
transactions can be bundled and transmitted/processed together.
This type of aggregation is useful for reducing the number and
frequency of individual messages traveling over electronic network
150. In such instances, the reporting electronic appliance 100 may
report: (i) the sum of the aggregated individual transactions, or
(ii) each of the individual transactions, or (iii) both, or (iv) a
combination of the two.
[0648] FIG. 29 shows that a consumer may use his or her electronic
appliance 100 for a number of different activities, such as, for
example, reading a novel, watching a video program, obtaining and
reviewing research results, interacting with and enjoying
multimedia presentations, and home financial management such as
checkbook balancing. A per use micro-payment may be associated with
each of these activities. For example, the consumer might pay $1 to
a publisher A and $1.50 to an author A each time the consumer
accesses an electronic version of a work written by the author and
distributed by the publisher. Suppose that the author A's works
have become so popular that they have been made into films. The
consumer might pay on a per-use basis to watch one of these
films--paying the publisher A $5, the author A $3 and Distributed
Commerce Utility 75 $0.50.
[0649] Payment aggregators 266 (which may, if desired, operate at
the consumer's site within the protected processing environment 154
provided by the consumer's electronic appliance 100) may aggregate
payments to common entities, keeping a running total of the amount
of money owed to publisher A, the amount of money owed to author A,
and the amount of money owed to the Distributed Commerce Utility
75. This running total can be incremented each time the consumer
triggers an additional payment event. The aggregated payment
amounts can be periodically or otherwise reported to financial
clearinghouse 200 or other Commerce Utility Systems 90 based on
certain time intervals (for example, weekly, monthly, or daily),
the occurrence of certain events (for example, the consumer has
exceeded her credit authorization and needs a new one, certain
electronic controls have expired, etc.), and/or a hybrid of any or
all of these techniques.
[0650] FIG. 30 shows another example of payment aggregation across
a number of consumer transactions. In this example, payments to the
same value chain participants and using the same payment method are
aggregated together to provide totals. This payment
aggregation--which may take place at the consumer's site and/or
within a financial clearinghouse--reduces the number of overall
financial transactions that need to be cleared. This increases
efficiency and throughput, and decreases the cost for handling each
individual consumer transaction.
[0651] FIG. 31 shows a still additional payment aggregation example
in which aggregation is performed over transactions of a number of
different consumers. For example, all transactions using a
particular payment method pertaining to a particular provider could
be aggregated by a financial clearinghouse 200. Note that the
payment aggregation techniques shown in FIGS. 29-31 do not
necessarily result in loss of individual transaction detail. In
other words, it is still possible for consumer electronic
appliances 100 to log and report detailed per-transaction
information, and for financial clearinghouse 200 and/or the usage
clearinghouse 300 to report detailed usage information on a
transaction-by-transaction basis--even though individual
transaction payments are being combined for more efficient payment
processing and handling. This ability to separately handle and
process more detailed and granular usage information while at the
same time aggregating payments can provide a high level of auditing
accountability without unduly burdening the payment handling
mechanism. In some cases, loss of the detail records leads to
savings on the clearinghouse side. They may be discarded, but there
are advantages to keeping them around on the user's system and/or
in a repository on a Commerce Utility System 90. If there is a
billing dispute, for example, the local copy of the detail records
might serve as useful evidence of what actually occurred--even if
they were never transmitted to the clearinghouse.
[0652] FIG. 32 shows how an example financial clearinghouse 200
might be modified to include a payment aggregator component 268.
Payment aggregator 268 could be used to aggregate payments incoming
from a number of different consumer electronic appliances 100 or
other sources, and provide those aggregated payments to switch 200
for handling via third party settlement services, for example.
Payment aggregator 268 could selectively aggregate only certain
payments while permitting other payments to pass through directly
to switch 200 for direct handling without aggregation. Payment
aggregation can be based on a number of different factors. For
example, payments can be aggregated based on consumer, provider,
payment method, or a combination of any or all of these factors.
This aggregation function can be performed entirely or in part
within consumer 95 electronic appliances, or it could be performed
centrally by a centralized clearinghouse 200.
Usage Clearinghouse 300
[0653] FIG. 33 shows an example usage clearinghouse Commerce
Utility System 300. Usage clearinghouses services and functions, in
general, may collect, analyze and "repurpose" detailed, summary,
and/or derived usage information about the use and/or execution of
digital properties and/or digital processes. This information may
include any information descriptive of electronic transaction
activity. Usage clearinghouses and/or support services may, for
example, provide and/or facilitate the following: [0654]
Independent auditing and reporting (which may be presented
independently of financial settlement clearing services); [0655]
General market researching; [0656] Negotiating, implementing,
determining, and communicating levels of privacy and
confidentiality with customers and value chain participants
regarding such usage information; and [0657] Mass customized
marketing and consolidated list selling, renting, or licensing.
[0658] In more detail, usage clearing services in accordance with
the present inventions may provide, for example, any combination of
the following detailed features and/or functions: [0659] Compiling,
aggregating, using, deriving and/or providing information
descriptive of and/or otherwise relating to, use of a secure
container(s), secure container contents, and/or any other content
and/or any digital control process(es), wherein such information
describes and/or otherwise relates to (a) one or more users of
content and/or processes, (b) one or more classes of content,
control processes, uses of content, and/or users, and/or (c) one or
more recipients of such usage information. [0660] Enabling tracking
and reporting of content and/or process control usage and/or
processing information at a highly granular (e.g., detailed) level.
[0661] Can collect, aggregate, analyze, summarize, extract, report,
distribute, rent, license, and/or sell usage information. [0662]
Employing information derived from user exposure to content, such
as advertising, information materials, entertainment, training
materials, business productivity software applications, etc., and
securely supplying at least a portion of such derived information
and/or related to such information, through the use of VDE
mechanisms in the preferred embodiment, to usage information
aggregating and/or analyzing clearinghouses, and where such
clearinghouse securely provides at least a portion of said usage
information, or information derived from said information to at
lest one further clearinghouse and/or value chain rightsholder; and
wherein said clearinghouse may securely provide differing derived
usage information to different other parties who have a
clearinghouse role or other rightsholder role. [0663] Using the
"information exhaust" audit trails created by, and/or derived from,
user protected processing environment metering based on a variety
of different techniques (for example those disclosed in Ginter, et
al.). [0664] Ability to collect and analyze detailed usage
information such as the number of times a digital property or any
portion of a property has been opened, extracted from, embedded
into, or executed; or the length of time a value chain participant
has used a property such as an interactive game or multimedia
presentation, computer software, or modules or subparts of such
products. [0665] Providing a variety of repurposing capabilities
for usage information arriving from consumers or other secure
protected processing environments. [0666] Providing independent
third party auditing capabilities useful, for example, for
archiving and non-repudiation. [0667] Providing information based
upon usage auditing, user profiling and/or market surveying related
to use of one or more secure containers and/or content and/or VDE
managed process control in the preferred embodiment. [0668]
Providing neutral, trusted third-party audit usage aggregating and
reporting services for rights holders, consumers, and/or other
value chain participants and/or interested parties such as
governmental bodies (information for taxation, law enforcement,
commercial surveying and statistics, etc.). [0669] Providing audit
opportunities in conjunction with rules and controls rights and
permissions clearing (for example, to provide a report about which
rules and controls permissions and rights, were exercised, for
example by whom, for what, and when--thereby tying actual user
activity back to specific permissioning and rights and/or rules and
controls templates). [0670] In the preferred embodiment, providing
standardized and custom reporting and analyzing based upon VDE
rules and controls and produced and delivered in VDE containers to
each and/or any one or more grouping of content creators, content
distributors, industry analysts, trade associations, and any other
stakeholders and value chain participants, and/or any other
interested parties such as government statisticians, regulators,
and/or taxation authorities. [0671] Providing any combination of
raw, refined, summarized, derived, and aggregated trusted data
reporting for the support of plural business models within any
value chain, and/or across and/or plural value chains. [0672]
Distributing, to value chain participants and other parties within
or outside of the electronic community, usage information
separately from and/or with financial settlement clearing services.
[0673] Supporting privacy and confidentiality controls fully
protecting rights of all value chain participants interests related
to usage information, including, for example, rights inherent in
VDE chain of handling and control managed business models. [0674]
Can accommodate privacy concerns, e.g., to not reveal more
information than a consumer or value chain content distributor,
aggregator, repurposer, or other user of an electronic device that
employs, in the preferred embodiment, VDE for secure, managed
content or other process control, authorizes, and, for example, to
inform such authorizing user of what kind of information is being
gathered and/or cleared). [0675] Can be trusted to automatically,
based at least in part upon rules and controls, conceal (e.g.,
encrypt), remove, and/or transform one or more portions of
confidential or proprietary usage information before further
processing of such information or delivering of such information to
any one or more additional parties, including any further usage
clearinghouse(s), thereby efficiently protecting privacy and
confidentiality, including protecting business trade secret
information. [0676] Protecting key business model information from
prying eyes of other interested parties, and/or from inadvertent
disclosure to other interested parties and/or to the public,
thereby laying the foundation for truly trusted, commercial
networks. [0677] Allowing value chain participants, including, for
example, commercial publishers and distributors, and/or consumers
and service and/or product provider organizations, to negotiate the
level of detail of usage information to be conveyed to any given
value chain rightsholders, and wherein such level of detail may
differ according to who the specific receiving parties are and the
specific type and/or subtype of usage information, and where
plural, differing levels of detail for differing portions of such
usage information may be provided to a given usage information
receiver and/or as a given deliverable, and where such
determination of detail is, at least in part, determined by the
rights of a given party at least in part described by VDE rules and
controls information in the preferred embodiment. [0678] Allowing
consumers and organizations to negotiate the level of detail of
information conveyed to value chain rightsholders. [0679] Allowing
consumers or other value chain participants--creators, publishers,
distributors, repurposers--to specify and/or negotiate the level(s)
of detail, aggregation and/or anonymity they desire with respect to
usage information regarding their usage of any given piece of
content, content class, specific process, process class, and/or
payment requirement (e.g., anonymity, and/or the maintenance of
privacy related to some or all usage details, may require a payment
premium to offset the loss of the value of such information).
[0680] Allowing information consumers and/or other value chain
participants to customize their "information exhaust" and to set
rules and controls for how they wish to have their usage
information aggregated, or otherwise used--subject to the competing
requirements of rightsholders to receive information they are
entitled to and/or receive information that user and rightsholders
mutually, electronically agree may be provided to rightsholders.
Users and/or one or more rightsholders may have the right to
specify limits upon (e.g., use VDE chain of handling and control),
and/or describe specific usage information that may or must be to
be delivered to, one or more other rightsholders. [0681] Supporting
substantial value chain participant control over what kind of value
chain participant usage information is accumulated, who can access
which information and how such information may be used, how such
information is gathered and processed, and the extent that usage
records are tied to a specific value chain participant or
organization. [0682] Securely using containers (e.g., using VDE
secure containers in combination with VDE protected processing
environment and communications security capabilities as described
in Ginter, et al.) in any step, part, and/or process of providing
secure usage clearing services. [0683] Supporting providing
discounts, subsidies and/or coupons to value chain participants,
for example to consumers, distributors, repurposers, etc., in
exchange for usage data or more finely grained usage data (for
example, ameliorating privacy concerns in some contexts). [0684]
Generating and supplying to interested parties marketing research
and reporting and consolidated marketing lists (for targeted
mailing, direct sales, and other forms of targeted marketing. Such
materials are generally analogous to independent magazine and
newspaper circulation audits, television audience ratings reports,
and/or commercial targeted marketing lists, but generating in a
highly efficient, distributed, and secure electronic environment.
Such materials, when desired, can be provided with important new
forms of detail (e.g., viewing, printing, extracting, reusing,
electronically saving, redistributing, etc.), with far greater
granularity of information, and with customized, selective
reporting of materials based upon recipients requests, payments,
rights, and/or conflicts of interest with one or more parties who
have a rightsholder's interest in one or more portions of the
underlying information. [0685] Using detailed usage information to
automatically generate classification hierarchies, schemes, groups,
and/or classes, and automatically assigning individuals, groups of
individuals, organizations, groups of organizations, digital and/or
analog content or groups of digital and/or analog content to one or
more classes derived from usage data created, collected,
transmitted, in conjunction with at least one secure container
and/or VDE in the preferred embodiment. [0686] Supporting
advertising and marketing, including supporting efficient value
chain automation of the delivery of such services, such as
automatic targeting or delivery of advertising and/or other
marketing materials to defined sets (e.g., one or more classes) of
consumers, professionals, employees and companies, in which the
sets may be defined by self-selection, usage data, usage data
profiles, or by any other means, and wherein said sets may be
comprised of any one or more value chain participants (e.g.,
creators, consumers, distributors, service providers, web sites,
distributed clearinghouses) and wherein said one or more
participants may receive differing, customized materials, and
wherein said receiving participants may redistribute such
materials, if authorized by rules and controls, and where such
participants may receive credit, coupons, monetary payment, and/or
other forms of consideration for such redistribution, and where
such redistribution may take the form of directing some or all of
such received materials to one or more other parties at least in
part based upon self-selection, usage data, usage data profiles, or
by any other means, and wherein all such processes may be securely
managed (e.g., supported) by internodal VDE chain of handling and
control in the preferred embodiment.
[0687] Determining payments and/or other consideration due to
rights holders from advertisers based on value chain user exposure
to advertising and at least in part, securely automating the
distribution of portions of such consideration among plural parties
having rightsholder interests related to the content and/or
processes that served as a basis for determining such
consideration.
[0688] Supporting superior, targeted market segmentation and the
design of more suitable information products and business models
based on direct, more specific and detailed usage data and on
customer and value chain preferences implied, explicit, and/or
automatically derived from usage information, user profiles,
class(s) identification information, etc.
[0689] Enabling "private" usage clearinghouses (a usage
clearinghouse controlled and/or operated by an organization) to
acquire certain detailed usage information and where such usage
clearinghouses may perform usage analysis and/or other processing
of such information and provide to more centralized and/or other
party clearinghouses and/or other value chain participants,
selectively limited usage information (e.g., employing higher level
abstractions, summary information, restrictions on and/or manner of
use of usage information--viewing, printing, saving,
redistributing, etc.) for some or all of such usage information,
and where differing limitations on such usage information may be
applied to usage information derived from usage of differing
classes of content, processes, users, and/or user groups, and where
such limitation capabilities provide important additional
protection of the confidential trade secret information of a
company or other organization by concealing the detailed nature of
certain internal activities, and where there may be a requirement
by one or more other parties in a value chain for payment and/or
other consideration in return for the retention of such detailed
usage information.
[0690] Enabling organizations to employ private usage data
clearinghouses on corporate Intranets, where such clearinghouses
are integrated with organization document workflow and/or data
warehousing systems.
[0691] Receiving, with private usage organization (e.g.,
corporation, government agency, partnership, or any other organized
operating entity) clearinghouses, usage data from electronic
appliances within the organization, and aggregating records into
detailed reports for internal use, and/or reporting raw, detailed
data for internal use, but only aggregating usage data into summary
reports for external distribution, for example, to rights holders
and/or other value chain participants, and/or one or more
commercial clearinghouses, and where detailed data for internal use
is, in the preferred embodiment, protected as VDE protected content
and access or other use of such content is limited to specified
parties and/or in specified ways based, at least in part, on the
specified parties securely maintained electronic identity,
including, for example, any relevant party class identification
information (e.g., member of a certain research group, senior
executive officer) that has associated specific information usage
privileges. [0692] Identifying and supplying, through private usage
clearinghouses, usage related information providing important value
usage data for allocating internal organization resources,
directing research, and other important business purposes. [0693]
Distributing usage clearing (e.g., for efficiency and/or other
reasons). [0694] Distributing usage clearing functions across a
network or other system (for example, every consumer and/or other
value chain participant node is potentially a distributed usage
clearing service at least in part initiating its own, secure usage
clearing, and where such participant node may communicate usage
information directly to one or more other participants) and, in the
preferred embodiment, in accordance with rules and controls and
other VDE techniques as described in the Ginter, et al patent
specification. [0695] Hierarchically organizing usage
clearinghouses, at least in part to protect confidentiality at each
level in the hierarchy. [0696] Granting authority and/or providing
services to, or in conjunction with, one or more distributed usage
sub-clearinghouses whose operations may be located logically and/or
physically elsewhere, such as within a company or government agency
and/or within one or more jurisdictions and/or serving subsets of
the overall business focus area of a senior usage clearinghouse.
[0697] Distributing and/or otherwise authorizing usage clearing
functions across a system or network, for example, where every
consumer and/or certain or all other value chain participant
protected processing environment (node) can potentially support a
distributed usage clearing service, and function in the context of
the overall Distributed Commerce Utility. [0698] Initiating its
own, secure usage clearing transactions directly with one or more
other participants. [0699] Providing interoperable operation with
one or more other participant interoperable nodes, using any or all
activities employing Virtual Distribution Environment techniques.
[0700] Use of clearinghouse to generate usage information used, at
least in part, in the design and/or marketing of products and/or
services related to the products and/or services whose usage is
described by such usage information. [0701] May be organized
hierarchically, peer-to-peer, or in a combined mode where
responsibility for usage clearing may be distributed in differing
fashions for differing commerce models and/or activities and/or
value chains, and where certain one or more parties may be, for
example, hierarchically more senior to other parties in one or more
instances, and hierarchically a peer or less senior in one or more
other instances, that is, the relationship among participants is
programmable and may be set (and later modified) to represent one
or more desired usage clearing arrangements for given commerce
activities, value chains, or models.
[0702] FIG. 33 shows an example usage clearinghouse 300 from a
process point of view. Usage clearinghouse 300 in this example
collects, analyzes and reports on the usage of digital information
including, but not limited to, the usage of digital content. Usage
clearinghouse 300 in this example performs the following functions:
[0703] Data collection 314, [0704] Database management 316, [0705]
Privacy control 318, [0706] Secure auditing 320, [0707] Secure
reporting 322, [0708] Data aggregation 324, [0709] Advertising and
marketing 326, [0710] Usage analysis 328, [0711] Replication 330,
and [0712] Propagation 332.
[0713] Communication between usage clearinghouse 300 and other
electronic appliances 100 may be by way of secure electronic
containers 152, if desired. As explained in more detail in
connection with financial clearinghouse 200, usage clearinghouse
300 may receive the containers in real time and/or on an
asynchronous receipt basis. In the usage clearinghouse 300, the
real time requirement may involve advertising or ratings
information that loses some or all of its value as a function of
time (e.g., if certain ratings information isn't delivered by a
particular time, it may no longer be relevant in a given market
analysis; or if advertisers don't receive usage information
promptly, they may not be able to respond to customer tastes as
effectively). Another case may involve a required delivery of usage
information (e.g., a user on vacation returns to find their
required audit date and grace period has expired, and their use of
certain properties is prohibited until the audit is performed). The
asynchronous delivery case would still be preferable in some
instances for the same reasons as above in connection with
financial clearinghouse 200.
[0714] Data collection function 314 is used to gather usage records
302 in addition to other types of information, such as, rules and
controls 188 (which may provide information concerning prices and
permissions, for example), financial statements 240a, detailed
financial reports 240b, and requests for usage information and/or
analysis 336. Data collection function 314 may closely interact
with database management function 316--resulting in various types
of information being stored and maintained in a usage or other
database. Replication and propagation functions 330, 332 may be
used to synchronize the contents of database 316 with other
databases (for example, maintained by other usage clearinghouses
300) and/or to provide a distributed database across a number of
secure network protected processing environments or electronic
appliances.
[0715] Data aggregation 324 and analysis 328 may be used to analyze
the contents of data collected by data collection function 314
and/or stored within database 316, enabling usage clearinghouse 300
to perform auditing 320 and/or reporting 322. Privacy control 318
may be used in conjunction with reporting function 322 to expose
only certain information and not others to third parties--thereby
protecting the privacy and confidentiality concerns of consumers
for whom usage information has been collected. Such pending control
316 can be expressed in rules associated with the containers in
which the information arrived.
[0716] Reporting function 322 may generate a variety of usage
auditing reports 304. In addition, usage clearinghouse 300 may be
used to provide advertising and/or marketing support 326 (e.g., to
help target advertising to demographically appropriate consumers
and/or to provide market and advertising research). Thus, in one
example, usage clearinghouse 300 may itself produce and/or
distribute advertising 340 for viewing by certain targeted
consumers or deliver such advertising on behalf of others. Usage
clearinghouse 300 may also generate customized responses 342 in
response to information requests 336, and can also generate release
signals 344 authorizing electronic appliances 100 to delete and/or
make "no longer pending" the usage information from local databases
once associated audit records have been transferred to usage
clearinghouse 300 and that transfer has been confirmed. Consumer 95
may have an interest in keeping rather than deleting this usage
information after it has been "released" (e.g., as a matter of
curiosity, to monitor others' behavior (employees, children,
etc.))
[0717] Usage clearinghouse 300 may generate its own controls 188b
to, for example, govern how usage information, market analysis
information or other information can be used by others. For
example, usage clearinghouse 300 might be prepare a proprietary
report or analysis that it provides to third parties in return for
compensation. Usage clearinghouse 300 may insist that the people
that they provide the report to do not redistribute the report to
anyone else. Usage clearinghouse 300 may enforce this requirement
electronically by delivering the report within one or more
electronic containers 152, and associating electronic controls 188b
with the report. These electronic controls 188b could enforce the
"no redistribute" prohibition along with other conditions grants
and/or limitations (e.g., the report can't be modified, the report
can be printed and viewed, the report may be excerpted, etc.).
[0718] As mentioned above, usage clearinghouse 300 may also receive
financial statements 240a and/or detailed financial records 240b or
other financial information--and may generate its own financial
statements 240c and/or detailed financial records 240d. For
example, the usage clearinghouse 300 might provide a service to
content providers in which the usage clearinghouse 300 receives
controls 188a from content providers similar to the controls
delivered to consumers 95. Based on a comparison of these data,
usage clearinghouse 300 might make estimates as to the amounts of
money that the content providers should expect to receive from
financial clearinghouses 200. Usage clearinghouse 300 might thus
provide an independent audit function--serving as a double check on
financial clearinghouses 200 and providing a fraud detection
function (e.g., people submitting usage records that don't have
associated payments or otherwise incorrect payment amounts may be
detected by the usage clearinghouse 300). In addition, the control
188 might represent closed models that content providers are
considering implementing, and usage clearinghouse 300 might then
offer a service in which it runs a comparison against the usage
data it actually collects to build a model of what the financial
results might look like if the content provider actually instituted
the proposed model.
[0719] FIG. 34 shows an example architecture of usage clearinghouse
300. In this example, usage clearinghouse 300 includes a secure
communications facility 346, a database and transaction processor
348, an authenticator 350, an authorization checker 352 and a data
aggregator 354. Usage clearinghouse 300 architecture may be based
on the rights operating system architecture shown in FIGS. 12 and
13 of the Ginter et al. patent disclosure.
[0720] Secure communications 346 provides communications with a
variety of electronic appliances 100 over electronic network 150
via secure containers 152 in this example. Database and transaction
processor 348 in this example performs most of the FIG. 33
functions. An authenticator 350 may be used to authenticate
consumers and/or data, an authorization checker 352 may be used to
check authorizations, and a data aggregator 354 may be used to
perform the data aggregation function 324. Authenticator 350 and
authorization checker 352 perform authentication functions as
described in the Ginter et al. disclosure in connection with secure
electronic appliances and protected processing environments.
[0721] FIG. 35 shows an example overall usage clearing process. In
this example, a provider 164 provides a digital property to
consumers 95(1), 95(2), 95(3). For example, provider 164 might
provide a novel or other work 166 to each of the consumers 95
within electronic containers 152. One or more control sets 188 may
be associated with the work 166 (and may, in one example, be
delivered within the same electronic container 152 used to deliver
the work 166). The controls 188 may specify that certain types of
usage information must be gathered in the form of an audit trail,
and that the audit trail must be reported based on certain time
and/or other events.
[0722] Because container 152 can only be opened within a secure
protected processing environment 154 that is part of the virtual
distribution environment described in the above-referenced Ginter
et al. patent disclosure, provider 164 can be confident that the
required audit trails will be generated and reported as he or she
instructs. As consumers 95 use the property 166, their electronic
appliances 100 automatically gather and store the usage information
in the form of audit trails 302. Then, upon the occurrence of a
specified event (e.g., once a month, once a week, after a certain
number of uses, etc.), the consumer electronic appliances 100 send
audit trail information 302 within digital containers to usage
clearinghouse 300.
[0723] Usage clearinghouse 300 collects the audit trail information
302, may store it in its database 316, and analyzes the audit trail
information to generate a report 304 which it may send to provider
164 within a further electronic container 152.
[0724] Provider 164 automatically receives secure information
auditing the amount his or her work has been used and how it has
been used, with usage clearinghouse 300 relieving the provider from
having to collect or analyze this detailed usage information. In
addition, usage clearinghouse 300 may serve to protect the privacy
of consumers 95 by revealing only summary details authorized by
them (for example, how many consumers have used the work 166 but
not their names or addresses). This confidentiality function would
be more difficult or problematic if provider 164 attempted to
analyzed detailed usage records himself or herself.
[0725] FIG. 36 shows a more detailed example usage clearing process
involving two different usage clearinghouses 300(1), 300(2). In
this example, a provider 164 delivers a work 166 directly to
consumers 95, and also to distributors 168 that may redistribute
the work to the consumers. The controls 188 associated with the
distributed content 166 may specify that usage clearinghouse 300(1)
is to collect and analyze information relating to the usage of the
content 166 directly distributed by creator 164, and that another
usage clearinghouse 300(2) is to collect and analyze usage
information pertaining to the usage of the work 166 as distributed
by distributor 168. Alternatively, usage clearinghouses 300(1),
300(2) may gather different types of usage information pertaining
to the same electronic property 166 (for example, one usage
clearinghouse might gather information pertaining to "pay per view"
usage, whereas the other usage clearinghouse might gather usage
information for all one-time purchases). Usage clearinghouses
300(1), 300(2) may each issue reports 304 to creator 164 and/or
distributor 168 and/or consumer 95.
[0726] FIG. 37 shows how a usage clearinghouse 300 can be used in
combination with a financial clearinghouse 200. In this example, a
consumer's electronic appliance 100 may send: [0727] to usage
clearinghouse 300, audit trail information 302 pertaining to usage
of electronic content, and [0728] to financial clearinghouse 200,
usage and payment audit trial information 228 pertaining to
financial clearing activities.
[0729] If desired, usage clearinghouse 300 and financial
clearinghouse 200 may be operated by the same business (in this
case, both usage and financial audit trail information could be
sent within the same electronic container 152). The usage clearing
functions performed by usage clearinghouse 300 may operate in
parallel with the financial clearing functions performed by
financial clearinghouse 200 to support both detailed usage
reporting and efficient financial clearing.
[0730] FIG. 38 shows another example usage clearing operation based
on media and/or advertising content placement. Consumers 95(1),
95(2), 95(N) may subscribe to various information distribution
services 170A, 170B, . . . . These information distribution
services 170 may distribute program material and advertisements
(commercial content) produced by content providers 164. Consumers
95 consume the distributed content, and their electronic appliances
100 gather and report associated usage data to usage clearinghouses
300(1), 300(2) . . . .
[0731] The usage clearinghouses 300 may perform demographic
analysis on the received usage data and, based on this demographic
analysis, target particular ads for other commercial content 164 to
particular information services 170. For example, information
service 170A might distribute program material and commercial
content 164 of interest to runners and others with physical fitness
interests. Usage clearinghouse 300(1) might analyze the usage data
provided by the consumers 95 who subscribe to and view this type of
information. Usage clearinghouse 300(1) is thus in a unique
position to place ads in other commercial and non-commercial
content that might be of interest to the same interest group.
Similarly, information service 170B might specialize in
broadcasting information of interest to car enthusiasts. Usage
clearinghouse 300(2) may gather usage data about the usage of this
type of information--and is thus in a unique and well placed
position to distribute and target advertisements, commercial and
non-commercial content to this group of consumers.
[0732] FIG. 39 shows an additional example usage clearing operation
that may be performed by usage clearinghouse 300. In this example,
usage clearing house 300 may be authorized by rights holders 164 to
offer discounts based on the amount of usage information a consumer
95 is willing to disclose. This can, for example, be done with
controls 188 for the property by selecting from among control sets
and/or entering into an electronic negotiation (see Ginter et al.
FIGS. 76A and B). A rights holder might premeditate this as a
general rule for their property--or given rights and permissions
clearinghouses 400 could be authorized to deliver these control
sets (e.g. based on their special position as collectors of
particular categories of usage information).
[0733] As one example, the consumer's electronic appliance might be
a personal computer, and rights holders 164 who distribute computer
software may be interested in knowing what software programs
consumer 95 is using in addition to the ones they themselves are
distributing. Consumer 95, on the other hand, may not want to
reveal this detailed information about all of the software programs
that are present on his or her personal computer.
[0734] As another example, digital broadcast rights holders 164 may
want to know about every broadcasted program that consumer 95
watches, whereas the consumer may not want anyone else to know the
kinds of programs he or she is interested in.
[0735] Usage clearinghouse 300 can effectively accommodate these
countervailing interests by offering consumer 95 a financial
incentive for more full disclosure but giving the consumer a
choice.
[0736] In this example, rights holder 164 distributes electronic
content and associated controls to consumer 95. The controls may
specify options for revealing usage information. The consumer may
choose: [0737] to pay full price and keep all usage information
other than that essential for insuring payment absolutely secret;
[0738] to allow limited usage disclosure in return for a small
discount on price; or [0739] to take advantage of a big discount in
return for allowing full disclosure of usage information.
[0740] Some secretive consumers may want the outside world to know
as little as possible about their usage habits and will be willing
to pay full price to protect their privacy. Other consumers may not
care what the outside world knows about their usage habits, and
will want to take advantage of large discounts based upon more full
disclosure. Any number of such option levels may be provided,
allowing the consumer to, for example, select precisely what kinds
of information are revealed and which ones are kept secret. Because
usage data is being collected within a secure protected processing
environment 154 that is part of the consumer's electronic appliance
100, the consumer can be confident that the usage data will be
securely handled and that unauthorized disclosure will not occur
without his or her consent.
[0741] Based, for example, on one or more control sets 188 provided
to the consumers' protected processing environment 154 and/or the
consumer's selection made possible through such control sets, the
consumer's protected processing environment 154 could reveal no (or
minimal) usage information, limited usage information or full usage
information, to usage clearinghouse 300. Usage clearinghouse 300
can then freely analyze the limited and full usage information it
collects, providing reports and analysis to rights holders 164 and
to other third parties such as market researchers, brokers,
advertisers, auditors, scientists and others.
Rights and Permissions Clearinghouse
[0742] FIG. 40 shows an example of a rights and permissions
clearinghouse Commerce Utility System 400. Rights and Permissions
clearinghouse services may perform any combination of the following
overall functions: [0743] Registering digital objects and
associated permissions, prices and/or other permitted and/or
required operations supporting the execution of consequences for
performing and/or failing to perform such operations; [0744]
Providing pre-approved permissions on demand in accordance with
specified circumstances and/or other requirements such as class(s)
of permission requester, fulfillment, or ability to fulfill,
payment requirements, etc.; [0745] Securely and efficiently
performing electronic copyright registration with the appropriate
agency for one or more countries and/or other jurisdictional units;
and [0746] Reporting functions.
[0747] In more detail, rights and permissions support services in
accordance with these inventions that may include, for example,
some or all of the following functions and features: [0748]
Identifying, distributing and verifying specific property rights
and/or other business rules and controls along a digital electronic
value chain. [0749] Providing object registry services and rights,
prices and/or other control information for registered objects.
[0750] Assigning to each digital object at least one identifying
number and/or name in accordance with its own numbering and/or
naming scheme and/or in accordance with one or more numbering
and/or naming schemes defined by one or more other organizations,
associations (e.g., standards consortiums), companies, and/or
agencies (e.g., governmental regulatory bodies). [0751] Receiving
authority from secure chain of handling and control embodied in
electronic control sets. [0752] Securely providing permissions
(e.g., rules and controls based descriptions of permitted
operations and associated consequences such as prices) for digital
properties that have been registered and supporting automated
association of such registered properties with rules and controls
sets (e.g., updating of rules and controls, employing preset
templates based upon classes of properties, etc.), that may be
provided, for example, at least in part remotely and securely
downloaded to the registering site during, or as a result of, such
registration. [0753] Allowing rights holders in digital content to
determine and flexibly define and securely provide to one or more
rights and permissions clearinghouse ways in which they want their
intellectual property products (for example, VDE protected digital
properties) to be used and not used, and any consequences of such
use and/or misuse. [0754] Providing VDE supported capabilities to
distribute and manage rights and business rules (including
pre-approved and other permissions) along an ad hoc electronic
value chain, where such rights and business rules are persistently
supported. [0755] Providing digital object permissions on demand to
people authorized to use a digital object. [0756] Can provide
different terms based on different permissions securely associated
with one or more combinations of classes of users (e.g., different
age groups, jurisdictions, business capabilities, consumers,
creators, providers, partners, government, non-profit
organizations, educational organizations, organization membership,
etc.). [0757] Providing rights holders with assurances that the
terms they set are being adhered to by a potentially diverse and
distributed value chain participant base. [0758] Can provide
controls that do not include all possible permissions and/or
distribute further, required and/or desired permissions upon
request on an ad hoc and/or pre-planned basis according to the
requester's rights (class and/or individual), for example, allowing
rights holders to elect to distribute only the most frequently used
permissions associated with a particular digital property, and
allowing appropriate parties to obtain new permissions in
accordance with the rights holder's model. [0759] Refreshing
expired permissions upon request and/or upon an automated
recognition of the expiration of such rights through the use of
clearinghouse database mechanisms and the automated provisioning
and/or messaging to provide such permissions and/or notify, in the
preferred embodiment, a VDE value chain participant of the need to
acquire such permissions (notify such user, for example, before the
user is actively attempting to use associated information and/or
electronic control processes and thereby avoiding user frustration
and inefficiency). [0760] Using secure containers such as those
described in et al., in any step, part, or process of providing
secure rights clearing services. [0761] Creating, storing,
distributions, and receiving rights and permissions "templates"
allowing rights holders to efficiently and adequately specify
rights, conditions and consequences, (e.g., compensation) to be
associated with operations related to the use of their digital
properties (and/or the use of VDE process controlled electronic
events). [0762] Templates can directly correspond to digital
control sets associated with properties, content users, user
classes, and/or other digital information and/or physical or
virtual sites and/or process control for event and event
consequence governance. [0763] Templates can be self-executing.
[0764] Templates can apply to multiple objects/instances. [0765]
Templates can be delivered independently of any digital objects
they may be associated with. [0766] Templates are extensible to
anticipate new operations and scenarios, including, but not limited
to new payment methods, pricing models and pricing levels, and new
permissions. [0767] Templates can flexibly recognize all kinds of
digital rights including, for example, distribution and
transmission and/or retransmission rights. [0768] Templates can
flexibly recognize individual identity and/or class identity
rights. [0769] Different templates can apply to different content
and/or process control arrangement property types. [0770] Plural
templates can apply to the same property and/or process control
arrangement. [0771] Rights and permissions clearinghouse(s) may
maintain superset templates, permitting value chain participants
and/or hierarchically sub-clearinghouses to modify one or more of
such superset templates to create templates employing a subset
and/or extended set of said one or more superset templates. [0772]
Templates can be completed in a number of different ways using, for
example, a graphical user interface and/or a rights management
language. [0773] Template "applications" can be created and/or
modified through the use of topographical, schematic, directly
editable graphical representation of value chain rules and
controls, where such rules and controls and value chain
relationships are represented through the display of, for example,
mixed iconic, positional, flow diagram, and textual information,
and wherein rules and controls are implemented, for example,
through the use of a rights management language, and wherein, for
example, elements or higher level representation of such elements
of the rights language may directly correspond to graphical
representation components. [0774] Multiple value chain participants
can contribute to and/or modify templates and/or contribute and/or
modify different templates applying to the same digital
information. [0775] Users can select between differing templates
applying to the same digital information, including, for example,
digital information describing and/or governing control processes
(e.g., event management information) managed through, for example,
secure VDE chain of handling and control. [0776] Distributing
rights clearing functions across a network or other system (for
example, every consumer and/or other value chain participant node
is potentially a distributed rights clearing service at least in
part initiating its own, secure rights clearing, and wherein said
participant node may communicate rights information directly to one
or more other participant, interoperable clearing nodes, in the
preferred embodiment, all activities employ VDE techniques as
appropriate and as described in the Ginter, et al. patent
specification). [0777] Granting authority and/or providing services
to, or in conjunction with, one or more distributed rights
sub-clearinghouses whose operations may be located logically and/or
physically elsewhere, such as within a company or government agency
and/or within one or more jurisdictions and/or serving subsets of
the overall business focus area of a senior rights clearinghouse
distributing and/or otherwise authorizing rights clearing functions
across a system or network, for example, where every consumer
and/or certain or all other value chain participant nodes can
potentially support a distributed usage clearing service initiating
its own, secure rights clearing transactions and function in the
context of the overall clearinghouse network, including,
clearinghouse interoperation with one or more other participants
interoperable nodes, and as elsewhere in this list, all activities
employing, for example, VDE techniques as appropriate. [0778] One
or more rights may be automatically provided to a participant based
at least in part upon some aspect of content and/or process control
usage, and such provided one or more rights may be supplied, for
example, as a promotional component providing coupons in
compensation for certain usage (e.g., purchasing) profile which may
be directly ascertained from usage information or may be derived
from a weighted formula involving a variety of variables. [0779]
May be organized hierarchically, peer-to-peer, or in a combined
mode where responsibility for rights clearing may be distributed in
differing fashions for differing commerce models and/or activities
and/or value chains and where certain one or more parties may be,
for example, hierarchically more senior to other parties in one or
more instances and hierarchically a peer or less senior in one or
more other instances, that is the relationship among participants
is programmable and may be set (and later modified) to represent
one or more desired rights clearing arrangements for given commerce
activities, value chains, or models.
[0780] FIG. 40 shows an example rights and permissions
clearinghouse 400 from a functional viewpoint. In this example,
rights and permissions clearinghouse 400 may perform some or all of
the following four main functions: [0781] Object registration.
Rights and permissions clearinghouse 400 registers digital
properties and their associated permissions and prices. [0782]
Permissions on demand. In response to queries, rights and
permissions clearinghouse 400 provides permissions 188 together
with associated prices in secure electronic containers 152. The
permissions controls 188 may be provided independently of the
content. [0783] Negotiated permissions. In response to queries and
requests, the rights and permissions clearinghouse 400 negotiates
permissions and/or prices on behalf of rightsholders who have
delegated this responsibility to the rights and permissions
clearinghouse. The rights and permissions clearinghouse 400 may
also be an intermediary in the negotiations between rightsholders
and rights users. Rightsholders and rights users may negotiate
among themselves and report the results of those negotiations to
the rights and permissions clearinghouse. [0784] Reporting. Rights
and permissions clearinghouse 400 can provide reports to augment
reporting performed by financial clearinghouses 200 and/or usage
clearinghouses 300.
[0785] In this example, rights and permissions clearinghouse 400
may provide some or all of the following functions: [0786]
Permission creating, updating or changing 408, [0787] Permission
distribution 410, [0788] Database management 412, [0789] Template
definitions and/or management 414, [0790] Negotiating permissions
416, [0791] Reporting 417, [0792] Replication 418, [0793]
Registration 419, and [0794] Propagation 420.
[0795] The rights and permissions clearinghouse 400's primary task
of object registration is performed by database management 412. In
this connection, rights and permissions clearinghouse 400 may
receive control sets 188 and corresponding object identifications
422 within the same or different electronic containers 152, and
then "register" this information in a database 412 for later
reference. Rights and permissions clearinghouse 400 may assist
rights holders in defining control sets 188 specifying rights and
permissions relating to the rights holder's electronic properties
by providing a template function 414. Registration process 419 and
database 412 may register control sets 188 in addition to objects
or properties 166.
[0796] Rights and permissions clearinghouse 400 database function
412 and distribution function 410 may be used to distribute
permissions on demand in response to requests 402, and may also be
responsible for the task of distributing (via distribution function
410) all permissions relating to a particular property. Since
permissions and/or prices may expire or change, rights and
permissions clearinghouse 400 can also be responsible for updating
control sets 188 specifying previously issued permissions and/or
prices and distributing those updated control sets.
[0797] Rights and permissions clearinghouse 400 may also provide a
reporting function 417, issuing reports 406 pertaining to the
permissions and/or prices it has issued or distributed, for
example. In this example, the operation of rights and permissions
clearinghouse 400 provides audit opportunities, i.e., a channel
through which to attach usage information. Such audit operations
(which may, for example, be provided by integrating rights and
permissions clearinghouse 400 functions with usage clearinghouse
300 functions) could be used to create integrated reports about
which permissions were provided and which permissions were
exercised--very valuable information for market research and
business consequences as well as providing additional
accountability to rightsholders.
[0798] This rights and permissions clearinghouse 400 audit function
can be especially beneficial to preserve confidentiality. For
example, a private rights and permissions clearinghouse 400 may be
extended to provide payment aggregation in order to hide
confidential individual transaction level information from the
financial clearinghouse 200. In another example, a rights and
permissions clearinghouse 400 can issue reports 426 indicating, for
example, the number of registered objects in database 412 at the
beginning of a reporting period, the number of new objects
registered, and some aggregate statistics concerning perhaps the
numbers of kinds of permissions associated with these objects
and/or average or median prices for certain kinds of objects.
[0799] Rights and permissions clearinghouse 400 can also respond to
queries 402 with responses 428. A request, for example, may consist
of a request for permissions--which may be automatically granted;
or the request may need to be qualified by the rights and
permission clearinghouse 400 to determine whether the requester is
qualified to receive the permissions. Qualifications might be
established by presentation of one or more valid certificates,
which might be simply checked, or stored in the database 412 for
transmission to providers along with other information about
permissions granted by the clearinghouse. In the preferred
embodiment, other qualifications might be based on a shared secret
(e.g., one or more tags from a control set 188 held by the
requester) known by the requester's PPE 54 and the rights and
permissions clearinghouse 400. This shared secret might be used in
combination with a certificate, or in cases when qualification
requirements are lower or have already been established (e.g., to
have received the shared secret in the first place), the shared
secret alone might be adequate to receive, for example, a
permission that replaces or updates an expired permission.
[0800] Rights and permissions clearinghouse 400 also includes a
permission negotiation engine 416 that may be used to negotiate
permissions 188 that haven't been pre-approved by the rights
holder. For example, suppose that a consumer 95 wants to exercise a
right that is not within database 412. The consumer 95 could
request the right. In response, rights and permissions
clearinghouse 400 could determine whether the rights holder has
authorized it to negotiate for the right on behalf of the rights
holder. If the rights holder has not given the rights and
permissions clearinghouse 400 the power to negotiate, the
clearinghouse could contact the rights holder and request
authorization and/or the permission itself. If the rights holder
has granted the rights and permission clearinghouse 400 negotiating
authority, the clearinghouse could enter into an electronic
negotiation (see Ginter et al. FIGS. 75A-76B) between the
consumer's control set and the rights holder's control set. The
resulting negotiated control set could be sent to the consumer,
allowing the consumer to exercise the right.
[0801] FIG. 41 shows an example architecture for rights and
permissions clearinghouse 400. In this example, rights and
permissions clearinghouse 400 includes a secure communications
facility 430, a database and transaction processor 432, an
authenticator 434, an authorization checker 436, and a registration
processor 438. As discussed above, the rights and permissions
clearinghouse 400 architecture may be based on the rights operating
system architecture shown in FIGS. 12 and 13 of the Ginter et al.
patent disclosure and described in associated text.
[0802] Database and transaction processor 432 performs most of the
functions shown in FIG. 40. Registration processor 438 may perform
the registration function 419. Secure communications facility 430
communicates securely over electronic network 150 with consumers
95, authors 164, publishers 168, aggregators 170, repackagers 174,
and other value chain participants via secure containers 152.
Authenticator 434 and authorization checker 436 perform
authentication functions as the Ginter et al. patent disclosure
describes in connection with secure electronic appliances and
protected processing environments.
[0803] FIG. 42 shows an example rights and permissions clearing
process. In this example, author 164 sends a work 166 with a
control set 188A including controls A to a publisher 168. Publisher
168--in accordance with a secure chain of handling and
control--adds controls B to the control set to form a new control
set 188AB. Publisher 168 publishes the work 166 with control set
188AB to consumers 95. Publisher 168 may also specify a less often
used, but sometimes necessary additional set of permissions C
within a more comprehensive control set 188ABC (for example,
controls C may allow journalists to excerpt certain parts of work
166 for specific purposes).
[0804] Publisher 168 may register control set 188ABC (and, if
desired, also control set 188AB and control set 188A) with rights
and permissions clearinghouse 400. The publisher 168 may also
include additional "controls over controls," or "permissions for
permissions" "D" (e.g., distribution controls described in
connection with FIGS. 79-85 of the Ginter et al. patent disclosure)
along with controls 188ABC. These additional "D" controls may
specify the circumstances under which rights A, B and/or C may be
granted (qualification of credentials, frequency of reissue, number
of controls for a given user, etc.).
[0805] Consumer 95 (or any other provider, such as an aggregator,
repackager, author, or another publisher) may request a copy of any
of these various control sets registered with rights and
permissions clearinghouse 400. For example, if the consumer 95 is a
journalist who uses the work 166 in accordance with control set
188AB and decides she wants to excerpt the work for certain
purposes, she may request the control super set 188ABC that
publisher 168 previously registered with rights and permissions
clearinghouse 400. As another example, a consumer 95 in Germany may
have received the control set 188 intended for U.S. distribution,
and may need to request a different control set accommodating the
European legal and monetary environment. Additionally, a
rightsholder may modify previously distributed controls at a later
date to add new rights, provide a "sale," take away rights,
etc.--with rights and permissions clearinghouse 400 being
responsible for distributing these new control sets either on
demand.
[0806] FIG. 42A shows another example in which consumer 95 may
register with the rights and permissions clearinghouse 400 a
control set 188X that pertains to an object such as a file or
software program already received by consumer 95. This new control
set 188X requests the rights and permissions clearinghouse 400 to
send to consumer 95 a new control set 188Y for the named object
whenever the controls registered for that object at the rights and
permissions clearinghouse 400 are modified. The rights and
permissions clearinghouse 400 may automatically send updated
control set 188Y to all registered users of a particular digital
property.
[0807] In a different example, publisher 168 might distribute work
166 with a very limited control set 188X allowing the consumer 95
to view only the abstract and specifying rights and permissions
clearinghouse 400 as a contact point for obtaining permission to
view or otherwise use the content as a whole. Consumer 95 could
then contact rights and permissions clearinghouse 400 to obtain a
more expansive control set 188Y allowing additional levels of
usage. This provides a high degree of accountability and expanding
auditing capabilities, since it requires consumers 95 to contact
rights and permissions clearinghouse 400 in order to actually use a
previously distributed property. Similarly, rights and permissions
clearinghouse 400 may provide updated control sets 188Y to replace
expired ones. This mechanism could be used, for example, to provide
a variable discount on a particular item over time (for example, to
allow a movie distributor to discount its first run film six months
after its initial release date without having to decide at time of
initial release how much the discount will be).
[0808] FIG. 43 shows a further example rights and permissions
clearing operation performed by rights and permissions
clearinghouse 400. In this FIG. 43 example, each of authors 164,
publishers 168, aggregators 170, and optionally other additional
value chain participants, register their own control sets 188A,
188B, 188C, respectively, with a rights and permissions
clearinghouse 400--potentially also registering additional controls
controlling distribution of their provider controls. Rights and
permissions clearinghouse 400 may then distribute a new, combined
control set 188ABC consistent with each of the individual control
sets 188A, 188B, 188C--relieving any of the value chain
participants from having to formulate any control sets other than
the one they are particularly concerned about. In this example,
rights and permissions clearinghouse 400 may also have an interface
to other organizations (e.g., with a government agency 440, such as
a Copyright Office--or with another type of organization such as
professional associations). Rights and permissions clearinghouse
400 may automatically register copyright in works and other objects
registered with the rights and permissions clearinghouse
400--reducing or eliminating such burdens from having to be
performed by the rights holders themselves. The copyright
registration interaction between the rights and permissions
clearinghouse 400 and the government agency 440 may, for example,
make use of VDE and secure containers 152.
[0809] FIGS. 44A-44E show an additional rights and permissions
clearing process that may be performed using rights and permissions
clearinghouse 400. In this example, a publisher 168 may provide a
property 166 and associated control set 188a to a consumer 95 (see
FIG. 44A). The consumer may use her electronic appliance 100 and
associated protected processing environment 154 to attempt to
access the property 166 using control set 188a, but may determine
that she requires an additional control set 188b in order to access
the property the way she wishes. The consumer's electronic
appliance 100 may generate a request 402 to a rights and
permissions clearinghouse 400 (see FIG. 44B). In response, the
rights and permissions clearinghouse 400 may distribute the
requested control 188b containing the permissions and pricing
information requested by the consumer 95 (see FIG. 44C). The
consumer may then use the property 166 in accordance with the
control set 188 and generate usage/audit trail information 302
based on the consumer's usage (see FIG. 44D). The consumer's
electronic appliance 100 may report this usage information to usage
clearinghouse 300, and may delete and/or release as "pending" the
internally stored usage information once it receives a release
signal from the appropriate clearinghouse (see FIG. 44E).
[0810] Rights Templates
[0811] FIGS. 45A and 45B show example rights templates 450, and
FIG. 45C shows an example corresponding control set 188. Rights
template 450 may be analogous in some respects to "fill in the
blank" forms. Rights holders can use rights templates 450 to
efficiently and effectively define the rights associated with a
particular digital property. Such templates 450 are useful in
framing the general purpose capabilities of the virtual
distribution environment technology described in the Ginter et al.
patent disclosure in terms that are sensible for a particular
content industry, provider, content type or the like. This allows a
user such as a provider to be presented with a focused menu of
resources that be applicable or useful for a particular
purpose.
[0812] For example, templates 450 may make some assumptions about
the character of the content or other information being controlled,
how it is partitioned or otherwise organized and/or the attributes
those organizational entities have. Templates 450 simplify the
process of defining permissions, and reduce or eliminate the need
for specialized knowledge and substantial investments of time to
exploit the underlying capabilities of the virtual distribution
environment. It may be possible in this example for a user to avoid
using templates 450 altogether and instead define permissions 188
in terms of a rights management language (for example, a natural or
computer-based language)--but a large percentage of users will
prefer the easy-to-use graphics interface that templates 450 may
provide--and won't mind giving up the additional flexibility and
associated complexities when undertaking the day-to-day business of
defining permissions for a large number of different pieces of
content.
[0813] Example rights template 450 shown in FIG. 45A (which may be
appropriate for text and/or graphics providers for example) defines
a number of different types of usage/actions relevant to a
particular digital property, such as, for example, "view title,"
"view abstract," "modify title," "redistribute," "backup," "view
content," and "print content." Rights template 450 may further
provide a "menu" or list of options corresponding to each type of
usage. These various options allow the rights holder to define
rights that others may exercise in connection with the property.
For example, the rights may comprise: [0814] Unconditional
permission, [0815] Permission conditional on payment, [0816]
Permission based on content, [0817] Unconditional prohibition, and
[0818] Prohibitions and/or permissions based on other factors.
[0819] Rights holders may "fill in" or select between these various
options to define a "rights profile" corresponding to their
particular property. In this example, rights template 450 may
further models and/or levels for rights to be exercised conditional
on payment. Such pricing models and levels may flexibly define a
variety of different sorts of business pricing, such as, for
example, one time charges, pay per view, declining cost, etc. See
FIG. 45B for an example of how pricing models and levels might be
specified using a graphical interface.
[0820] Rights template 450 in this example can be self executing
and/or can be "translated" or compiled automatically into one or
more control sets 188 providing the necessary controls for
implementing the rights holder's selections. FIG. 45B, for example,
has a "view title" control 188a that allows unconditional viewing
of the title as specified by the FIG. 45A rights template 450.
Similarly, the FIG. 45B example controls 188 includes further
control set elements 188(2) . . . 188(N) corresponding to other
rights and permissions 188 the rights holder has defined based upon
the FIG. 45A rights template 450.
[0821] In this example, rights template 450 can be extensible. For
example, as new technology enables and/or creates new operations,
rights template 450 can be extended to accommodate the new
operations while still being "upward compatible" with preexisting
rights templates. Different rights templates 450 can be used for
different types of properties, different value chain participants,
etc.--and at the same time, certain rights templates might apply to
multiple objects or properties, multiple value chain participants,
etc. Some rights templates 450 can be supersets of other rights
templates. For example, an overall rights permissions template 450
could define all of the possible rights that might apply to a
particular property or class of properties, and sub-templates could
be further defined to define rights associated with different
consumers, classes of consumers, or rights holders. Thus, for
example, an author might use a sub-template that is different from
the one used by a distributor. Templates can also be recursive,
i.e., they can be used to refer to other templates (and similarly,
the control sets they define can refer to other control sets).
[0822] Rights and permissions clearinghouse 400 might partially
fill in rights template 450--or an automatic process could be used
(based, for example, on rights holder's pre-existing instructions)
for completing and/or duplicating rights templates. Rights holders
could use a graphical user interface to complete rights template
450 (e.g., by displaying a list of options on a computer screen and
pointing and clicking with a mouse pointing device to fill in the
options desired). In another example, a rights holder could define
his or her preferences using a rights management language that a
computer could automatically compile or otherwise process to fill
in rights template 450 and/or construct associated control set(s)
188.
[0823] FIG. 46 shows an example rights and permissions clearing
process using rights template 450. In this example, rights and
permissions clearinghouse 400 and/or individual rights holders
define rights template 450 (FIG. 46, block 452(1)). The rights are
then filled in the rights template 450 to define permissions
granted and withheld, and associated pricing models and levels
(block 452(2)). The rights holder associates the permissions
defined by the rights template with the object (e.g., by creating
one or more control sets 188 that reference and/or apply to the
property being controlled) (block 452(3)). The rights holder may
then convey the permissions (control set 188) with or separately
from the object (block 452(4)). Rights holders may send these
control sets 188 directly to consumers 95 (block 452(5)), and/or
they may sent them to a rights and permissions clearinghouse 400
for registration and storage in a database (block 452(6)). Rights
and permissions clearinghouse 400 may provide such preauthorized
permissions to consumers (block 452(7)) on demand upon receiving
consumer requests (block 452(8)).
[0824] As described above, providers may control distribution of
such pre-authorized permissions by rights and permission
clearinghouse 400 by the mechanism of providing additional,
"distribution controls" directing and/or controlling the
distribution process.
Certifying Authority
[0825] FIG. 47 shows an example certifying authority Commerce
Utility System 500. Certifying authorities and services may, in
general, create digital documents that "certify," warrant, and/or
attest to some fact. Facts include, for example, identification
and/or membership in a particular class, e.g., such as an
organization; age group, possession of a certain credential type;
being subject to one or more certain jurisdictions; and/or having a
certified one or more rights to use content and/or processes for a
fixed time period or terminating at a specific time.
[0826] In more detail, a certifying authority in accordance with
these inventions may provide any combination of the following
advantageous features and functions, for example in the form of
certificates: [0827] Electronically certifying information used
with or required by rules and/or controls such as authenticating,
identity, class membership and/or other attributes of identity
and/or context, and including automatically certifying said
information based upon the source (for example, one or more
certified provider identities) and/or class of said information.
[0828] Providing trusted verification that a consumer or other
value chain participant is who she says she is and/or is a member
of one or more particular groups, classes and/or organizations.
[0829] Providing trusted verification that a group of value chain
participants are collectively who they say they are, wherein a
plurality of certificates from different parties are tested as an
aggregate and where such aggregate of certain certificates is
required under certain circumstances to use content and/or execute
one or more control processes. [0830] Automatically producing a
certificate, representing authentication of a value chain or value
chain portion, as a result of the confluence of a plurality of
certain certificates. [0831] Anticipating, through the use of rules
and controls, allowable collections of certificates from plural
parties that can form a certificate that virtually represents a
specific group of certified parties and in the presence of certain
certificates identifying two or more anticipated parties and/or
parties who have met a certain criterion--e.g., sufficient
transaction revenue, sufficient credit worthiness, etc.--a new
certificate may be automatically generated and act as a composite
certificate certifying the plural parties collective and
coordinated presence, and wherein said certificate can be
associated with certain rules and controls allowing certain
electronic activities such as usage of content and/or control
processes in, for example, multiparty EDI, content distribution,
trading system, and/or financial transaction systems. [0832]
Generating one or more certificates at least in part as a result of
rules and controls governance of certificate creation, wherein such
generated one or more certificates are produced, for example, as a
result of secure rules and controls based one or more instructions
after the satisfaction of certain required criteria such as certain
specific activities by each of plural parties--e.g. provision of
one or more certificates and/or authorizations and/or usage
activity and/or credit and/or payment activity and/or reporting
activity and/or VDE supported electronic agreement activity
(including, for example, electronic negotiation activity). [0833]
Certifying other support services (e.g., financial clearinghouses,
usage clearinghouses, rights and permissions clearinghouses,
transaction authorities, and other certifying authorities, etc.).
[0834] Certifying based on another certificate (e.g., identity) and
an automatic secure database lookup which may be performed locally,
across a distributed database arrangement, or remotely. [0835]
Providing non-automatic (i.e., at least in part human provided or
assisted) services issuing more fundamental certificates (e.g.,
identity certificates) based on physical evidence in addition to
automatic services for issuing dependent certificates. [0836] May
use public key cryptography, private key, and/or secure VDE virtual
networks to support, e.g. create, digital certificates. [0837] Can
issue certificates that support the context for rights usage in an
automatic, trusted, distributed, peer-to-peer secure electronic
environment that supports chain of handling and control. [0838] As
with other Distributed Commerce Utility services, supporting an
unlimited variety of different business models and scenarios
through general purpose, reusable, programmable, distributed,
modular architecture. [0839] Can issue certificates that support
control sets having elements whose use is dependent on presence
and/or absence of specific, and/or class and/or non-specific, one
or more digital certificates attesting to certain facts and where
differing requirements may coexist regarding the presence or
absence of certificates related to differing issues. [0840] Can
issue one or more certificates that cooperate with conditional
electronic control sets to grant certain rights only to certain
consumers and/or other value chain participants, including, for
example, consumers. [0841] Issuing replacements for expired
certificates and supporting sophisticated time and/or usage and/or
other event driven expiration (including termination) of
certificates--for example, where criteria for such expiration may
variety based upon specific certificates, classes of certificates,
specific and/or classes of users, user nodes, etc. [0842]
Maintaining and distributing, including selectively distributing to
distributed nodes revocation list information, based, for example,
upon node distributed profiles and/or rules and controls. [0843]
Distributing revocation list information among interoperable,
peer-to-peer networked, Distributed Commerce Utility nodes on a
time based, other event based manner, wherein information is
selectively distributed to certain one or more nodes in accordance
with agreed to revocation information requirements and/or where
revocation information is non-selectively distributed to certain
one or more nodes. [0844] Receiving authority from secure chain of
handling and control embodied in electronic control sets. [0845]
Distributing certificate authority functions across a network or
other system (for example, every consumer node is potentially a
certificate authority with respect to certain kinds of
certificates; parents may be empowered to issue certificates for
their children). [0846] Organizing certificate authorities
hierarchically, including allowing automatic verification of some
certificate authorities (that is, their issued certificates and
associated determinations regarding trustedness, appropriateness,
etc.) through reliance on certificates issued by other certificate
authorities at least in part for such purpose. [0847] Granting
authority and/or providing services to, or in conjunction with, one
or more distributed certificate authority sub-clearinghouses whose
operations may be located logically and/or physically elsewhere,
such as within a company or government agency and/or within one or
more jurisdictions and/or serving subsets of the overall business
focus area of a senior certificate authority clearinghouse
distributing and/or otherwise authorizing rights clearing functions
across a system or network [0848] Every consumer and/or certain or
all other value chain participant nodes can potentially support a
distributed certificate authority clearing service initiating its
own, secure certificates and function in the context of the overall
clearinghouse network, including, clearinghouse interoperation with
one or more other participants interoperable nodes, and as
elsewhere in this list, all activities employing VDE techniques as
appropriate. [0849] Providing liability acceptance control (i.e.,
for insuring digital certificates based on the amount of liability
accepted by the issuer(s)), and may include securely maintaining
information regarding such liability acceptance and providing
notices to recipients of such certificates regarding the liability
protection afforded by such certificates, and may further include
recipients of such insured certificates accepting, for example,
through explicit VDE managed electronic acceptance or through
implied acceptance by continuing, any liability above the insured
amounts. [0850] May be organized hierarchically, peer-to-peer, or
in a combined mode where responsibility for certificate authority
activities may be distributed in differing fashions for differing
commerce models and/or activities and/or value chains and where
certain one or more parties may be, for example, hierarchically
more senior to other parties in one or more instances and
hierarchically a peer or less senior in one or more other
instances, that is the relationship among participants is
programmable and may be set (and later modified) to represent one
or more desired specific certificate authority arrangements for
given commerce activities, value chains, or models.
[0851] FIG. 47 shows an example certifying authority 500 from a
process viewpoint. In this example, certifying authority 500
creates digital documents called certificates 504 that "certify"
some fact, such as identity or class membership. For example a
trusted third party certifying authority 500 can provide a secure
digital assurance that a consumer is who she claims to be or has
certain characteristics, attributes, class memberships, or the
like. For example, some attributes may signify membership in a
particular class (e.g., all employees of a certain company), those
born before a certain date, those having a certain physical
disability, members of the faculty, administration or student body
of a college, or retired members of the armed forces.
[0852] In this example, digital certificates 504 issued by
certifying authority 500 are used as a conveyor of the context of
rights usage and transaction authorizations. As described in the
Ginter et al. patent disclosure, certificates 504 are particularly
powerful in the virtual distribution environment because they
provide contexts for rights usage. For example, class-based
certificate use and automated, distributed governance of commerce
rights may fundamentally enhance the efficiency of trusted
networks. Suppose, for example, that a content publisher wants to
charge commercial prices for a scientific journal subscription to
all those but in higher education and is willing to give college
and university students and professors a 20% discount. Digital
certificates 504 issued by a trusted certifying authority 500 can
be used to automatically provide assurances--within the context of
distributed electronic network--that only people who are truly
entitled to the discount will be able to exercise it (in this
example, that only those certified as affiliated with an
institution of higher education).
[0853] In the FIG. 47 example, certifying authority 500 may perform
the following overall functions: [0854] Fact collection and
checking 522, [0855] Certification generation 524, [0856]
Maintaining revocation lists 526, [0857] Certificate and revocation
list distribution 528, [0858] Authentication 530, [0859]
Certificate renewal 532, [0860] Authorization 534, [0861]
Replication 536, [0862] Propagation 538, and [0863] Archive
554.
[0864] Certifying authority 500 may gather evidence 502 as a basis
for which to issue digital certificates 504. In this example,
evidence 502 may include other digital certificates 504' (e.g., so
that one certificate can build on another). The fact collection and
checking function 522 may accept this evidence 502 as well as
additional trustedness data 540 (e.g., information concerning
compromised or previously misused certificates) Certificate
generation function 524 may generate new digital certificates 504
based upon this fact collection and checking process 522.
Distribution function 528 may then distribute the new digital
certificates 504, and issue bills 542 to compensate a certifying
authority for undertaking the effort and liability that may be
associated with issuing the certificate.
[0865] Certifying authority 500 may also maintain a revocation list
542 based on trustedness data 540 indicating, for example,
certificates that have been compromised or that previously
certified facts are no longer true (for example, Mr. Smith used to
be a Stanford University professor but has since left the
University's employ). The maintained revocation list function 526
is important for providing a mechanism to ensure that "bad"
certificates cannot continue to be used once they are known to be
bad. Certificates 504 issued by certifying authority 500 can
expire, and the certifying authority can (for example, for a fee)
renew a previously issued certificate by performing certificate
renewal function 532. The certifying authority 500 may maintain a
record or database of the certificates it has issued, and this
database can be distributed--which can benefit from replication
function 536 and propagation function 538 to accurately and
efficiently distribute the database across a number of different
locations.
[0866] FIG. 48 shows an example architecture for certifying
authority 500. In this example, certifying authority 500 may
include a secure communications facility 544, an
encryption/decryption processor 546, a billing system 548, a key
generator 550, a query mechanism 552, and an electronic archive
554. In this example, secure communications 544 is used to
communicate with other electronic appliances 100 and/or other
Commerce Utility Systems 90. Electronic archive 554 stores keys,
certificates 504 and other information required to maintain the
operation of certifying authority 500. Encryption/decryption
processor 546 is used to create digital certificates 504 by using
strong cryptographic techniques. Billing system 548 issues bills
542. Query mechanism 552 is used to query electronic archive 554.
Key generator 550 is used to generate cryptographic keys the
certifying authority 500 needs for its own operation.
[0867] FIG. 49 shows an example certifying authority process. In
this example, a publisher may send an electronic secure container
152 to a consumer 95. To use certain permissions 188a in secure
container 152, the consumer 95 may require a certificate from
certifying authority 500 that certifies as to a particular fact
about the consumer (e.g., the consumer is a United States citizen,
the consumer is a retired member of the armed forces, the consumer
is over 18 years of age, etc.). The consumer may generate a request
502 to certifying authority 500 for issuance of an appropriate
certificate. Certifying authority may check the evidence 502 the
consumer 95 provides, or that some third party may provide,
and--once the certificate authority 500 is satisfied--issue the
consumer the required digital certificate 504. This digital
certificate 504 may be used not only with the publisher's control
set 188a, but with control sets from other rights holders that
require certification of the same fact and that have agreed to
trust certificate authority 500 as an issuer of certificates.
[0868] Certifying authority 500 may communicate with consumer 95
using secure containers 152. It may generate and provide a control
set 188b with certificate 504. This control set 188b may control
some aspect of usage of the certificate 504 (e.g., it may not be
redistributed and/or modified) and/or to define a chain of handling
and control for the issuance of further dependent certificates
(e.g., parents give authority to issue certificates about their
offspring).
[0869] One certificate authority 500 may be "proxied" to issue
certificates on behalf of another--such as for example in a chain
of handling and control defined by one or more electronic control
sets 188. Distributing the certifying authority 500 across a number
of different electronic appliances has certain advantages in terms
of efficiency for example. FIG. 50 shows one useful example of this
distributed certificate issuance scenario.
[0870] FIG. 50 shows that a rightsholder 164 (and/or a rights and
permissions clearinghouse 400) may request (e.g., by issuing
electronic controls 188a within a secure container 152a) a
certifying authority 500 to issue digital certificates 504(1) to
accredited institutions of higher learning such as institution
1060. Control set 188a may establish the policies and procedures
necessary to ascertain whether in fact a particular institution is
duly accredited. Based on electronic controls 188a and evidence 502
submitted by the institution 1060, the certifying authority 500 may
issue a digital certificate 504A attesting to the fact of
accreditation.
[0871] In order to take advantage of certificate 504A, a student,
faculty member and/or staff member of institution 1060 may need to
provide a further certificate attesting to the fact that he or she
is affiliated with institution 1060. Instead of having certifying
authority 500 issue a further certificate 504 to each student,
faculty member and staff member of institution 1060, it may be
efficient and/or desirable for each institution 1060 holding a
certificate 504A to issue dependent certificates 504(2) to its own
faculty, staff and students. For example, institution 1060 may
maintain a current list of all students, faculty and employees.
Rather than requesting certifying authority 500 to issue a separate
certificate 504(1) to each student, faculty member and employee of
institution 1060, the institution may undertake this responsibility
itself.
[0872] For example, institution 1060 may elect to operate its own,
distributed certifying authority 500A. In one example, certifying
authority 500 may issue electronic controls 188b (subject to
controls 188a issued by rights holder 164, for example) that
delegate, to the institution's certifying authority 500A, the
authority and responsibility to issue dependent certificates 504(2)
within certain limits (e.g., attesting to a limited universe of
facts such as for example "This person is officially associated
with the institution 1060"). Such dependent certificates 504(2)
could, for example, be copies of certificate 504(1) with an
addendum stating that a particular person is associated with the
institution 1060 and stating a particular expiration date (e.g.,
the end of the current academic term). The institution's certifying
authority 500A may then issue such dependent certificates 504(2) to
each faculty member, student and staff member on its current
roster.
[0873] Recipients of certificates 504(2) may need a still further
certificate 504(1) attesting to their identity. This is because
certifying authority 500A issues certificates 504(2) attesting to
the fact that a certain named person is affiliated with institution
1060--not to the fact that a particular recipient of such a
certificate is that person. The recipient may need to obtain this
further "identity" certificate 504(1) from a governmentally
operated certifying authority 500 such as a state or federal
government.
[0874] Rightsholder 164 (and/or a rights and permissions
clearinghouse 400 not shown) may issue control sets 188c for
digital properties 166 that grant discounts or that provide other
benefits to those who can provide a combination of valid digital
certificates 504 attesting to their membership in the class
"accredited higher education institution." Each student, faculty
member and staff member of the institution 1060 who has received a
certificate 504(2) may take advantage of these discounts or other
benefits. FIG. 50A illustrates how such different digital
certificates can be used to support certificate-conditional
controls 188--that is, control sets whose elements are dependent on
the presence or absence of certificates 504 that attest to certain
facts.
[0875] In this FIG. 50A example, one or more control sets 188c
include a number of discrete controls 188(1) . . . 188(N) applying
to the same digital property 166 or group of properties, for
example. Control 188(3) may provide additional and/or different
rights to all students, faculty and staff members of Stanford
University. In the FIG. 50A example, multiple certificates can be
used together to provide the requested certifications. For example,
the certificates 504(1), 504(2), 504A shown in the FIG. 50 example
can be used together to allow a particular person to take advantage
of a discount offered to students, faculty and staff members of
accredited institutions of higher learning. For example: [0876] a
certificate 504(1) may attest to the fact that a certain person
John Alexander is who he says he is. [0877] another certificate
504A may attest to the fact that Stanford University is an
accredited institute of higher learning, [0878] another certificate
504(2) may attest to the fact that John Alexander is a student at
Stanford University for the current academic semester.
[0879] Each of these various certificates 504 can be issued by
different certifying authorities 500. For example, one certifying
authority 500 (e.g., operated by a governmental entity) might issue
a certificate 504(1) certifying the consumer's identity, while
another certifying authority may issue certificate 504(2) attesting
as to student status, and a third certifying authority may issue
the certificate attesting to the fact that Stanford is an
accredited University (see FIG. 50).
[0880] As an additional example, a control set element 188(1) shown
in FIG. 50A may provide a certain benefit for California residents.
Its condition may be satisfied by the consumer presenting a digital
certificate 504(3) certifying residency (e.g., in combination with
the "identity" certificate 504(1)). A still further permission
180(N) shown in FIG. 50A might be satisfied by presenting a
certificate 504(5) indicating U.S. citizenship. Such certificates
504(3), 504(5) that warrant that a given person is subject to one
or more jurisdictions (for example, a resident of, or doing
business in a particular city, state, nation, or other political
unit--and therefore, subject to that unit's sales, income, or other
taxes, or subject to certain administrative fees) are particularly
useful for interstate and/or international commerce transactions.
For example, a certifying authority 500 might issue a certificate
504 to a financial clearinghouse 200 in the United Kingdom. This
certificate 504 could be used in conjunction with control sets 188
distributed by rightsholders and/or a rights and permissions
clearinghouse 400 specifying that only United Kingdom financial
clearinghouses 200 are authorized to accept payment in pounds
sterling. A customer wishing to pay in pounds sterling will only be
able to complete the payment transaction if the financial
clearinghouse being used has the appropriate UK certificate. This
UK clearinghouse might then pay appropriate UK taxes--relieving the
provider from the burden of having to determine which of his or her
transactions were subject to UK tax payments and which were
not.
[0881] FIG. 50A also shows a further certificate 504(4) certifying
that a certain person is married to a certain other person. To use
certificate 504(4), it may also be necessary to present the first
certificate 504(1) certifying identity. Such certificates attesting
to relationship between individual people or between people and
organizations are useful in allowing, for example, family members
to use the certificates of other family members (e.g., a person can
obtain a benefit based on his or her spouse's or parents' certified
credential(s)).
[0882] FIGS. 51-51D show example detailed formats of various
digital certificates 504. The FIG. 51A digital certificate 504(1)
may certify that a person is who he says he is. This certificate
504(1) might include, for example: [0883] a field 560(1) stating
the person's name, [0884] a field 560(2) specifying the person's
date of birth, [0885] an expiration field 560(3) specifying when
the digital certificate expires, [0886] a public key 560(4)
corresponding to the person's public key, an ID code 560(5) (which
in this example could be a hash of the public key field 560(4)),
and [0887] a check sum field 560(6) providing an error checking
ability.
[0888] Digital certificate 504(1) is encrypted in this example by
the certifying authority 500 using the certifying authority's
private key of a public key-private key cryptosystem pair, such as
RSA or El Gamal. The certifying authority 500's corresponding
public key can be made public (e.g., by publishing it in several
publicly accessible sites on the World Wide Web or in another
widely distributed context), or it could remain secret and never be
exposed outside of protected processing environments 154. In either
case, successful decryption of the digital certificate 504(1) to
reveal the original clear text information provides a high degree
of assurance that the digital certificate was issued by certifying
authority 500 (presuming that the certifying authority's private
key has not been compromised).
[0889] Expiration field 560(3) is useful because people who skip
checks of revocation lists have at least some assurance that a
certificate is good if it must be renewed periodically. Expiration
date field 560(3) provides an additional safeguard by insuring that
certificates do not last forever--allowing certifying authorities
500 to use different cryptographic key pairs for example to provide
overall integrity and trustedness of the certification process.
Changing the certifying authority 500's key pair reduces the
incentives for an adversary to break a given key, because the
amount of information protected by that key is limited, and the
fraudulent use of a compromised key will only have a limited time
of effectiveness. Furthermore, (currently) unexpected advances in
mathematics may render some cryptographic algorithms useless, since
they rely on (currently) theoretically intractable computations. A
built in mechanism for changing the certifying authority 500's keys
allows the impact of such breakdowns to be limited in duration if
new algorithms are used for reissued certificates (alternatively,
this risk can also be addressed by using multiple asymmetric key
pairs generated in accordance with different algorithms to sign and
validate keys, at the cost of additional decryption time).
[0890] FIGS. 51B, 51C and 51D show additional digital certificate
examples containing different sorts of information (e.g.,
professional credential field 560(7) in the case of certificate
504(5), address field information 560(8) in the case of certificate
504(3), and student credentials field 504(9) in the case of student
certificate 504(2)). These certificates 504(2), 504(3), 504(5) are
tied to identity, certificate 504(1) via the common ID field
560(5), and both the identity certificate and the independent
certificate would generally need to be presented together.
[0891] FIG. 51E shows how an example digital certificate issued by
one certifying authority can--in conjunction with a trusted
database--be the basis for another certifying authority to grant
another certificate. One certifying authority 500A can, for
example, validate user identity and create the identity certificate
504(1) shown in FIG. 51A. The user can submit this identity
certificate 504(1) to another certifying authority 500B that has a
data base 554a of people and/or organizations who have a particular
attribute. For example, certifying authority 500B may be operated
by a professional organization that maintains an internal database
554a. Certifying authority 500B will trust the contents of this
internal database 554a because the certifying authority 500B
maintains it and keeps it accurate.
[0892] By comparing the identity information in the FIG. 51A
certificate with the contents of the trusted database 554a,
certifying authority 500B can issue the FIG. 51B certificate
without requiring any physical evidence from the owner of the FIG.
51A certificate. This solves an important problem of requiring the
user to "show up" each time he needs a highly trusted
certificate--and also allows the second certificate-generating the
process to be automated.
[0893] FIG. 51E also shows that the certificate 504(2) issued by
certifying authority 500B may be (along with identity certificate
504(1)) a sufficient basis for a further certifying authority 500C
to issue a further certificate 504(3) based on its own lookup in a
trusted database 554b.
[0894] Another example would be a corporation that has proven its
identity to the Secretary of State in the jurisdiction in which it
is organized. If this corporation has passed muster to handle
hazardous material it could submit its certificate of identity
504(1) from the Secretary of State (which in this case would
comprise certifying authority 500A) to the agency (certifying
authority 500B responsible for maintaining the database 554a of
which companies are currently qualified and authorized to handle
hazardous materials. The certifying authority 500B could then issue
a certificate 504(2) attesting to this fact in an entirely
automated way if desired.
[0895] Insert before heading on p 219 Secure Directory Services
(FIG. 52 shows)
Certification to Allow Participants to Act as Agents of an
Entity
[0896] Sometimes, one or more participants in a particular value
chain, or having a particular relationship with other participants
need to be authorized to act on behalf of the collection of
participants. For example, several parties may wish to act based on
authorization from the partnership or joint venture of which they
are a member--or all participants within a particular value chain
may need to act for the value chain as a whole. Each of the
participants receiving such authority from the entity may need
authorization from the entity to act.
[0897] The present invention provides a mechanism in which digital
certificates 504 may be used to create a "virtual entity" that can
grant any combination of participants any combination of the same
or different powers to exercise defined powers under controlled
Deleted: container conditions of use. More particularly, a digital
certificate grants each participant in a virtual entity the power
to act on behalf of the entity--within the constraints of the
conditions of use and further with any consequences defined in the
conditions of use specified by electronic controls associated with
the container.
[0898] FIG. 51F shows an example electronic container 152 that
encases the following information:
[0899] a value 564 that identifies the "virtual entity,"
[0900] signatures 566(1)-566(N)--one for each member of the
entity,
[0901] other information 568 pertaining to the entity,
[0902] digital certificates 504(1)-504(N)--one for each member of
the entity, and
[0903] control information 188 that specifies powers (e.g., rights
or permissions) and "conditions of use."
[0904] Value 564 provides an identifier that uniquely identifies
the entity. The "other information" field 568 may provide further
information concerning the entity (e.g., the name of the entity,
the name and address of each participant, the expiration date on
which the entity ceases to exist, and other information).
Signatures 566(1)-566(N) are like signatures on a partnership
agreement--each member of the virtual entity affixes his or her
"signature" to indicate assent to be a member of the entity and
assent to the conditions being granted to each participant.
[0905] Container 152 in this example further includes an electronic
control set 188 describing conditions under which the power may be
exercised. Controls 188 define the power(s) granted to each of the
participants--including (in this example) conditions or limitations
for exercising these powers. Controls 188 may provide the same
powers and/or conditions of use for each participant, or they may
provide different powers and/or conditions of use for each
participant.
[0906] For example, controls 188 may grant each participant in a
virtual entity the power to act as a certifying authority 500 on
behalf of the entity. In this particular example, controls 188 may
allow each party of the virtual entity to make certificates on
behalf of the virtual entity--within the constraints of the
conditions of use and further with the consequences defined in the
conditions of use specified by controls. As discussed above, the
right to grant certificates is only an example--any type of
electronic right(s) or permission(s) could be granted based on any
type of electronic condition(s) of use.
[0907] FIG. 51G shows one example process for creating the FIG. 51F
container 152. In this example, the parties to the virtual entity
may negotiate control information governing collective action based
on, for example, the electronic negotiation techniques shown in
FIGS. 75A-76B of the Ginter et al. patent specification (FIG. 51G,
block 570). The resulting control information 188 specifies
"conditions of use" such as the rights that may be exercised by
each participant in the entity, and limitations on each of those
rights (which may be defined on a participant-by-participant
basis).
[0908] The participant initiating issuance of digital container 152
(actually, the participant's protected processing environment 154)
may select a random value for use as entity identifier value 564
(FIG. 51G, block 572). The participant's PPE 154 may next create
the certificate information for the virtual entity by associating
the entity identifier value 564 with other information 568 (FIG.
51G, block 574). The participant's PPE 154 may next sign the
virtual entity certificate information to indicate the
participant's assent to be a member of the virtual entity and
assents to the conditions of use control information 188 (FIG. 51G,
block 576).
[0909] The participant's PPE 154 may then make electronic container
152, and place into it the control information 188, the virtual
entity certificate information 564, 566, 568, and the participant's
own certificate 504 specifying a cryptographic key the participant
may use to exercise rights (FIG. 51G, block 578). The participant
may then determine whether any more participants need to be added
to the entity certificate (FIG. 51G, decision block 580). If yes,
the container 152 may be transmitted (FIG. 51G, block 582) to
another participant member of the virtual entity and accessed and
validated by that next participant (FIG. 51G, blocks 584, 586). The
next participant may similarly sign the virtual entity certificate
information by adding his signature 566(2) to the list--indicating
the she also agrees with the controls 188 and agrees to join the
virtual entity (FIG. 51G, block 588). This new information is used
to add to and/or replace the entity certificate information 564,
566, 568 (FIG. 51G, block 590). This next participant also adds
their own certificate 504(2) to the container 152 (FIG. 51G, block
592).
[0910] Steps 580-592 may be repeated until container 152 has been
signed by each participant within the virtual entity ("no" exit to
decision block 580). The completed container 152 may then be
transmitted to all participants (FIG. 51G, block 594).
[0911] FIG. 51H shows an example process a virtual entity
participant may use to exercise powers on behalf the virtual entity
based on the controls 188 shown in FIG. 51F. The FIG. 51H example
process is performed by the participant's protected processing
environment 154 based on a request. The participant's protected
processing environment 154 writes an audit record (FIG. 51H, block
594a) and then evaluates the request using the conditions of use
specified by controls 188 (FIG. 51H, block 594b). If the request is
permitted by the controls 188 ("yes" exit to decision block 594c,
FIG. 51H), the participant's protected processing environment 154
accesses the virtual entity value 564 from container 152 (FIG. 51H,
block 594d) and uses the control information 188 associated with
conditions of use to fulfill the request and perform appropriate
consequences (FIG. 51H, block 594e). In one example, the
participant's protected processing environment 154 may act as a
certifying authority 500 on behalf of the virtual entity by issuing
a digital certificate 504 in accordance with the conditions of
use--digitally signing the digital certificate by encrypting the
entity identifier value 564 with a cryptographic key corresponding
to the participant's own certificate 504 within container 152, and
making the digital certificate part of the newly issued
certificate. The example may then write additional audit
information 594H reporting on the action it has taken.
[0912] If the requested action is not permitted by controls 188
(FIG. 51H, "no" exit to decision block 594c), the example FIG. 51H
process determines whether the error is critical (decision block
594f). If the error is critical ("yes" exit to decision block
594f), the process may disable further use of the information
within container 152 (block 594g), writes additional audit
information (block 594h), and then stops (FIG. 51H, block 594i). If
the error is not critical ("no" exit to decision block 594f), the
protected processing environment 154 writes additional audit
information (block 594h) and may then end this task (FIG. 51H,
block 594i).
[0913] The processes and techniques shown in FIGS. 51F-51H have a
variety of different uses. As one example, suppose that a first
publisher publishes a derivative work including his own content and
content provided by a second publisher. The two publishers may form
a virtual entity that allows the first publisher to act on behalf
of the entity--but only in accordance with the conditions of use
negotiated and agreed upon by both partners. For example, the
second publisher may be willing to allow the first publisher to
republish the second publisher's content and to allow excerpting
and anthologizing of that content by consumers 95--but only if the
consumers present an appropriate certificate 504 issued by the
virtual entity attesting to the fact that the consumer is permitted
to exercise that right. For example, only special subscribers
having certain characteristics may be entitled to receive a
certificate 504. The techniques above allow the first publisher to
issue certificates 504 to subscribers on behalf of the virtual
entity comprising both the first and second publishers. The second
publisher can be confidant that the first publisher will only issue
certificates in accordance with the conditions of use negotiated
and agreed by both publishers.
[0914] Another example is a manufacturing process comprising
multiple participants. The conditions of use provided by controls
188 may allow any of the value chain participants in the
manufacturing process value chain to perform certain actions on
behalf of the value chain as a whole. For example, a materials
manufacturer, a finished goods supplier and the shipping company
that transports materials between them may for a virtual entity.
This virtual entity may then submit a control set to a transaction
authority that describes a process that describes all three
participants acting in concert. For example, the control set
created in accordance with the conditions of use applicable to
their virtual entity might permit a unified presentation of
materials requirements, finished appearance and delivery schedule,
as one simple example.
[0915] In another example, a semiconductor company, a systems
integrator, and three different suppliers of software may form a
virtual entity supporting the semiconductor company's chip design,
simulation, and design testing applications. In this example,
certificates may be issued to each company comprising this example
entity and to particular individuals within each of the companies.
Rules and controls negotiated among the companies may specify who
has access to which parts of the software applications and
associated databases and who may make modifications to the software
and/or data. In this way, the semiconductor company can authorize
access to outside contractors and/or suppliers and to specific
individuals representing those outside companies. These individuals
may be authorized just enough access to solve typical problems and
perform system maintenance tasks. Also, they may be granted
additional rights (authorizations) for a limited period of time in
order to resolve specific problems requiring for resolution access
to certain executables and/or data not included in their default
permissions.
[0916] The virtual entity feature of the present invention
represents, in part, an extension that builds upon the chain of
handling and control techniques disclosed in Ginter et al. For
example, certificates produced in accordance with this aspect of
the present invention can use capabilities of a VDE chain of
handling and control to manage a chain of certificates.
Secure Directory Services
[0917] FIG. 52 shows an example of a secure directory services
Commerce Utility System 600. Secure directory services may securely
provide electronic and/or other directory information such as
names, addresses, public keys, certificates and the like.
Transmittal of such information securely (e.g., through the use of,
in the preferred embodiment, the Virtual Distribution Environment)
helps prevent eavesdropping, helps ensures confidentiality, and
provides significant infrastructure support by enabling important
participant interaction efficiencies.
[0918] In more detail, secure directory services provided in
accordance with these inventions may provide the following example
advantageous features and functions: [0919] Securely and reliably
providing directory information based on a variety of different
parameters, including various classification information. [0920]
May securely provide consumer's, content provider's,
clearinghouse's and/or other party's electronic address(es) and/or
other communication pathway(s) based on name, function, physical
location, and/or other attributes. [0921] May provide consumer's,
content provider's, clearinghouse's and/or other party's public
key(s) and/or certificate(s) based on, for example, name, function,
physical location, and/or other attributes. [0922] Protects, and
where appropriate may conceal, identity related information while
efficiently managing and/or automating the confidential
communicating of requests and responses in secure containers.
[0923] Using secure containers and rules and controls to guarantee
integrity and non-reputability of content. [0924] Receiving
authority from secure chain of handling and control embodied in
electronic control sets. [0925] Distributing secure directory
services functions across a network or other system (for example,
every consumer and/or other value chain participant node is
potentially a distributed secure directory service initiating its
own, secure directory service transactions directly with one or
more other participants using VDE as described in the Ginter, et
al. patent specification). [0926] Granting authority and/or
providing services to, or in conjunction with, one or more
distributed secure directory services sub-clearinghouses whose
operations may be located logically and/or physically elsewhere,
such as within a company or government agency and/or within one or
more jurisdictions and/or serving subsets of the overall business
focus area of a senior directory service authority distributing
and/or otherwise authorizing secure directly service functions
across a system or network. [0927] Every consumer and/or certain or
all other value chain participant nodes can potentially support a
secure directory services authority providing naming and related
services and function in the context of the overall naming services
network, including interoperation with one or more other
participants interoperable nodes, and as elsewhere in this list,
all activities employing VDE techniques as appropriate. [0928] May
be organized hierarchically to delegate responsibility for, and
operation of secure directory services for a subset of the overall
directory based on name, function, physical location, and/or other
attributes. [0929] May be organized hierarchically to provide a
directory of directories, for example. [0930] May be organized
hierarchically, peer-to-peer, or in a combined mode where
responsibility for directory services may be distributed in
differing fashions for differing commerce models and/or activities
and/or value chains and where certain one or more parties may be,
for example, hierarchically more senior to other parties in one or
more instances and hierarchically a peer or less senior in one or
more other instances, that is the relationship among participants
is programmable and may be set (and later modified) to one or more
desired specific directory service arrangements for given commerce
activities, value chains, and/or models.
[0931] FIG. 52 shows an example secure directory services 600 from
a process point of view. In this example, secure directory services
600 is an archive that securely keeps track of directory
information relating to consumers, value chain participants and/or
electronic appliances, and securely provides this information upon
qualified demands. In this example, secure directory services 600
may provide the following functions: [0932] Database management
606, [0933] Database search/retrieval 608, [0934] Database
replication 610, [0935] Database propagation 612, [0936]
Authentication 614, and [0937] Authorization 616.
[0938] Database 606 may be accessed by search and retrieval engine
608 which takes consumer-provided input information as a source and
uses it to retrieve records that are relevant. For example, secure
directory services 600 may receive identities 618 of individuals,
organizations, services and/or devices; electronic addresses 620;
certificate 622; and/or keys 624. This information may be stored in
database 606.
[0939] In response to requests 602, secure directory services
search and retrieval engine 608 may access database 606 to retrieve
additional information (for example, the electronic mail address of
a certain individual or organization, the public key of a certain
individual, the identity of a person having a certain electronic
mail address, the identity and address of a person having a certain
public key, etc.).
[0940] Additionally, secure directory services 600 may return
access controls, audit requirements and the like. For example, a
user may be required to present valid credentials (e.g., a
certificate 504) to access the internal email addresses of a
corporation. Certain fields of information known to the database
606 may not be available to all corners (e.g., the office location
or a particular employee, their home directory(ies) on the
company's servers, etc.; or a consumer's physical address may be
available to people that present a certificate 504 issued by the
consumer acting as his own certificate authority 500, but no one
else. These controls can be specified in secure containers that
carry the information to the secure directory service 600.
[0941] When the information is provided to requesters, they may be
required to use the information only in authorized ways. For
example, they may be allowed to use the information to formulate
email messages, but not excerpt a physical address for a mailing
list. These restrictions can be enforced by controls 188b the
secure directory services 600 associates with the information it
provides.
[0942] As shown in FIG. 53, secure directory services 600 may
provide a database 606 and search and retrieval engine 608 in
addition to a secure communications facility 626. The architecture
of secure directory services 600 may be based on FIGS. 12 and 13 of
the Ginter et al. patent disclosure.
[0943] FIG. 54 shows an example secure directory service process
performed by secure directory services 600. In this example, a
sender 95(1) wants to send a message to a receiver 95(2). The
senders and receivers could be electronic appliances 100 owned by
consumers, clearinghouses, or the like. Sender 95(1) may send an
address request 602 to secure directory services 600 providing
certain information and requesting other information. In response,
secure directory services 600 provide the requested information to
sender 95(1)--who may use the information to send a message to
receiver 95(2). In this example, both the address request 602 and
the responsive information 604 are contained within secure
electronic containers 152 in order to maintain the confidentiality
and integrity of the requests and responses. In this way, for
example, outside eavesdroppers cannot tell who sender 95(1) wants
to communicate with or what information he or she needs to perform
the communications--and the directory responses cannot be "spoofed"
to direct the requested messages to another location. In addition,
as discussed above, directory services 600 can include controls 188
along with its responses and/or request or require controls 188 as
part of its input.
Transaction Authority 700
[0944] FIG. 55 shows an example Transaction Authority Commerce
Utility System 700. These inventions also enable secure
"transaction authority" capabilities providing the following
overall functions: [0945] Securely validating, certifying, and/or
auditing events (including, for example, authenticating, and, for
example, for non-repudiation purposes) in an overall multi-event
transaction or chain of handling and control process; [0946]
Securely storing, validating, certifying, and/or distributing
control sets (including, for example, authenticating, and, for
example, for non-repudiation purposes) for multi-event transaction
or chain of handling and control processes; [0947] Issuing
requirements for any or all of the transaction and/or process
steps; and [0948] If desired, actively participating in the
transaction or process (e.g., through managing, directing,
intermediating, arbitrating, initiating, etc., including
participating in models employing reciprocal control methods and
distributed, automated events for, for example, distributed
computing, process management, EDI, reference to currency, etc.)
[0949] Can certify steps and/or pathways, including certifying
proper routing for electronic information through transaction
authority telecommunication switches adapted to certify certain
information and wherein certificates certify that a required route
was followed and/or the sending of such electronic information was
pursuant to certain stipulated rules and controls, for example
acquiring certain archiving information and/or not exceeding budget
and/or other limits and/or restrictions for, for example: numbers
of "shipped" information containers in a given period of time,
value of electronic currency contained within (represented by) a
current container and/or by containers over a certain period of
time, financial amount committed in purchase order, proper ordering
authority, etc.
[0950] The transaction authority may simply be a secure, watchful
bystander to, and certifier of, the electronic transaction and/or
transaction step (in a sequence of overall transaction steps), it
may be a secure facilitator of a secure plural-party electronic
transaction, and/or it may actively and directly participate in the
electronic transaction.
[0951] In more detail, a transaction authority in accordance with
these inventions may provide the following advantageous features
and/or functions: [0952] Securely maintaining and validating event
notification information pertaining to a multi-stage transaction
and/or chain of handling and control process(es). [0953] May
enforce, through requirements for its certification or
authentication, a sequence of required transaction and/or chain of
handling and control processes steps based on component
representation of elements of a business process, where, for
example, one or more transaction authorities respectively certify
and/or authenticate one or more specific events at one or more step
"locations" in a transaction sequence. [0954] May form an overall
transaction control set from a number of discrete sub-control sets
contributed, for example, by a number of different participants.
[0955] Using reciprocal methods to coordinate required transaction
events, including for example, sequence of events, between value
chain participants. [0956] Receiving authority from secure chain of
handling and control embodied in electronic control sets. [0957]
May intervene to actively manage transactions and/or chain of
handling and control processes. [0958] Can coordinate workflow
and/or chain of handling and control processes and/or other
business processes. [0959] Can provide automatic and efficient
management based on a trusted, secure distributed electronic
commerce environment, including certifying and/or authenticating
steps in distributed proprietary information, EDI, financial
transaction, and/or trading system value chain activities that very
substantially improves security for distributed rights management,
wherein such security can meet or exceed the security available
with centralized, online commerce models. [0960] May manage at
least a portion of the transactions within and/or between value
chain participants (e.g., organizations, individual consumers,
virtual groupings). [0961] May specify and/or monitor, at least in
part through the use of rules and controls, conditions of
satisfaction for, and/or consequences of, atomic transactions.
[0962] May direct what happens based on error conditions and/or
transaction profile analysis (e.g., through use of an inference
engine and/or expert system). [0963] Can provide confidential
coordination of security, routing, prioritizing, and negotiating
processes allowing different, distributed parties to work
efficiently together through a confidential, trusted interface.
[0964] Providing notarization, validation, certification, and/or
delivery, as appropriate, for secure document and/or process
control. [0965] Can certify steps and/or pathways, including
certifying proper routing for electronic information through
transaction authority telecommunication switches adapted to certify
certain information and wherein certificates certify that a proper
route was followed and the sending of such electronic information
was pursuant to certain stipulated rules and controls, for example
not exceeding budget or other limits for: numbers of "shipped"
information containers in a given period of time, value of
electronic currency represented by current container and/or by
containers over a certain period of time, financial amount
committed in purchase order, proper ordering authority, etc., are
issued to satisfy requirements regarding receiving a proper such
certification or authentication at a node receiving such routed
information. [0966] Distributing transaction authority functions
across a network or other system (for example, every consumer
and/or other value chain participant node is potentially a
distributed usage clearing service at least in part initiating its
own, transaction authority functions, and wherein said participant
node may communicate usage information directly to one or more
other participants) and in accordance with rules and controls and
other VDE techniques as described in the Ginter, et al patent
specification. [0967] May provide arbitration, mediation and
negotiation services, electronic or otherwise.
[0968] FIG. 55 shows a particular example transaction authority 700
from an overall function viewpoint. Transaction authority 700
provides, among other things, a secure auditing facility for
maintaining the current state of an overall transaction or process
based upon event notifications it receives from the participants in
the transaction.
[0969] In this specific example, transaction authority 700 performs
the following functions: [0970] Event notification collection 730,
[0971] Validated event database management 732, [0972] Requirement
generation 734, [0973] Secure authenticated auditing 736, [0974]
Reporting 738, [0975] Notifying 740, [0976] Replication 742, and
[0977] Propagation 744.
[0978] In this example, transaction authority 700 receives
notifications that events have occurred in the form of event
notifications 748 which may be carried in one or more secure
electronic containers 152. Event notification collection process
730 collects these event notifications 748 and may store them in a
validated event database 732. Transaction authority 700 may
generate additional notifications 748 based on its validated event
database 732, and may also issue responses 750 indicating the
current status of a transaction or process in response to requests
752 and/or based on other requirements. In addition, transaction
authority 700 may generate and output audit records 754 indicating
the progress and status of transactions or processes based upon the
contents of its validated events database 732 as analyzed by
auditing function 736. Transaction authority 700 may also issue
reports 756 based on its reporting function 738. Validated event
database 732 may be a distributed event notification database, in
which case replication process 742 and propagation process 744 are
used to maintain and update the database in a distributed
manner.
[0979] Another major function of transaction authority 700 in this
example is to issue new or modified event requirements 758 that can
be used to control or influence an overall process or transaction.
Transaction authority 700 may receive control set 188, prices and
permissions 188, event flow requirements 760 and/or process routing
requirements 762. Both event flow requirements 760 and process
routing requirements 762 can be specified in one or more control
sets. In response to this information and the validated event
database 732 contents, transaction authority 700 may use its
requirement generation process 734 to create new or modified event
requirements 758. Transaction authority 700 may also create new or
modified control sets 188'' and new or modified prices and/or
permissions 188'''. Transaction authority 700 may use financial
statements 764 as an input to its secure auditing function 736.
[0980] FIG. 56 shows an example architecture for transaction
authority 700. In this example, transaction authority 700 (which
may be based on the VDE rights operating system ("ROS")
architecture shown in Ginter et al. FIGS. 12 and 13) includes a
secure communications facility 770, a database and transaction
processor 772, process control logic 774, routing tables 776, and
an adaptive control set database 778 (these functions could be
performed by methods at one or more control sites). In addition,
transaction authority 700 may also include a document notarizer 780
including a seal generator 782, a digital time stamp generator 784,
and a fingerprint/watermark generator 786.
[0981] Secure communications facility 770 permits transaction
authority 700 to communicate in a secure manner over electronic
network 150 (for example, via secure electronic containers 152).
Database and transaction processor 772 performs most of the
processes shown in FIG. 55. Adaptive control set database 778 may
perform the validated event database function. Routing tables 776
may be used as part of requirement generation function 734 to route
appropriate messages to appropriate entities.
[0982] Process control logic 774 may include an inference engine or
expert system for use in handling error conditions not fully
anticipated or specified by the event flow requirements 760 and/or
process routing requirements 762. Process control logic 774 might
operate based on rule based principles, fuzzy logic, neural
networks, or a combination of some or all of these--or any other
method of process control logic. Process control logic 774
determines the next event that is to occur within the overall
transaction or process.
[0983] Document notarizer 780 may be used to provide authenticated
document generation, for example, to affix digital seals and/or
stenographic information to written and/or digital documents.
[0984] FIG. 57 shows an example transaction authority process. In
this simplified example, transaction authority 700 may be an entity
internal to a corporation used to securely audit and direct an
overall goods delivery process. In this example, a customer 95
issues an order 788 for goods. This order 788 is received by an
order receiving department 704 which issues an order event 710 to
transaction authority 700. In response to this order event 710,
transaction authority 700 may issue rules and/or requirements in
the form of one or more electronic control sets 188 specifying how
the order receiving department 704 is to handle the order. These
rules 188 may specify, for example, a sequence of chain and
handling that also directs the activities of a fulfillment
department 709A, a warehouse 709B, a transportation company 726,
and a payment collection department 709C. The rules 188 ? which may
be passed from one department to the other within secure electronic
containers 152--thus specifies the requirements and overall process
flow of the transaction that is to occur. Each department may then
pass the secure controls 188 along to the next department, with
routing being directed by the rules themselves and/or by
transaction authority 700. Each department may also issue event
notifications 748 alerting transaction authority 700 of the current
status of the overall process. Transaction authority 700 may store
this status information within its secure validated event database
732 for auditing purposes and/or to permit the transaction
authority to direct the next step in the process.
[0985] Transaction authority 700 can, for example, use the
interaction models shown in FIGS. 17E-1 through 17E-4 to
interaction with an ongoing transaction or process. One
particularly useful scenario for transaction authority 700 is to
manage a process performed by multiple parties, such as
corporations working on a joint venture or other common objective.
In this type of business scenario, multiple corporations may be
working toward a common overall goal but may themselves have their
own objectives internally such as, for example, protecting their
own confidential trade secret information. Transaction authority
700 can be used as an independent third party mediator/arbitrator
to coordinate activities between the multiple corporations without
requiring any of the corporations to expose detailed process
information to anyone other than transaction authority 700.
[0986] For example, transaction authority 700 can generate control
sets specifying event flow and/or process routing requirements 758
and/or control sets 188 that mean different things in different
contexts. As an example, a control set that transaction authority
700 issues might cause one corporation to perform one step and
another corporation to perform another step--with each corporation
never learning the particular step or sequence of steps being
performed by the other corporation. Thus, transaction authority 700
can develop control sets 188 that can be used to provide only
partial disclosure between different individual or corporate
actors.
[0987] FIGS. 58A and 58B show example steps and processes performed
by transaction authority 700 to perform an "atomic transaction". In
this example, transaction authority 700 performs a role that is
somewhat analogous to the coach of a football team. By accepting
the skill set and requirements of each individual "player" and
linking them together into an overall "game plan," the transaction
authority 700 can involve any number of value chain participants in
an overall "atomic" transaction.
[0988] In this example, each value chain participant 164(1), . . .
164(N) in a process administered by transaction authority 700 could
contribute a control set 188(1), . . . 188(N) specifying or
governing the participant's own business requirements, limitations
and processes for the transaction (FIGS. 58A and 58B, block 750).
These individual control sets 188(1), 188(N) specify how each
individual participant performs its own role. Each participant
164(1) . . . 164(N) knows its own role in the overall transaction,
but may have no idea what roles others may play or have any clear
idea how to form a "team" of other participants--and so these
individual control sets 188(1), 188(N) typically describe only
sub-transactions and may not take overall transaction
considerations into account.
[0989] Transaction authority 700 also receives another control set
188X specifying how to link the various participants' control sets
together into overall transaction processes with requirements and
limitations (FIGS. 58A and 58B, block 752). This overall
transaction control set 188Y specifies how to resolve conflicts
between the sub-transaction control sets 188(1), 188(N) provided by
the individual participants (this could involve, for example, an
electronic negotiation process 798 as shown in FIGS. 75A-76A of the
Ginter et al. patent disclosure). The transaction authority 700
combines the participant's individual control sets--tying them
together with additional logic to create an overall transaction
control superset 188Y (FIGS. 58A and 58B, block 752). Transaction
authority stores the resulting control superset 188Y in local
storage (FIG. 58B, block 754). This overall control superset
controls how transaction authority 700 processes events to perform
an "atomic" transaction.
[0990] Upon receipt of an incoming event requiring processing (FIG.
58B, block 756), transaction authority 700 may activate the overall
transaction control superset 188Y (FIG. 58B, block 758). The
transaction authority 700 may then deliver corresponding reciprocal
control sets corresponding to portions of the overall transaction
control superset 188Y to each participant in the
transaction--thereby enabling each participant to communicate with
the superset (FIG. 58B, block 760). Alternatively, each participant
in this example may--at the time it contributes its control set
188(1), 188(N) to transaction authority 700--maintain a reciprocal
control set that can communicate with the control set the
participant sent to transaction authority 700.
[0991] Transaction authority 700 may then begin monitoring events
received using the activated control superset (FIG. 58B, block
762). If the incoming event is not an error condition ("N" exit to
FIG. 58B decision block 764), then transaction authority 700
determines whether the event indicates that the atomic transaction
is complete (FIG. 58B, block 765). If the atomic transaction is not
complete ("N" exit to FIG. 58B, decision block 765), control
returns to block 762 to monitor events. If the atomic transaction
is complete ("Y") exit to decision block 765), the transaction
authority 700 determines that the transaction is finished (FIG.
58B, block 774).
[0992] If the incoming event is an error condition ("Y" exit to
FIG. 58B decision block 764), transaction authority 700 processes
the error event in the control superset 188Y (FIG. 58B, block 766).
If the error is not critical (FIG. 58B, decision block 767, "N"
exit), then control returns to block 762 to wait for the next event
notification to arrive.
[0993] If the error is critical (FIG. 58B, decision block 767, "Y"
exit), transaction authority 700 may call a critical error handing
routine (FIG. 58B, block 768). Critical error handling routine 768
may attempt to resolve the error based on the rules within the
control superset 188Y and/or on an inference engine 774 or other
process control logic. Such an inference engine or other process
control logic 774 may be programmed concerning the business model
of the overall transaction so it has enough information to select
appropriate actions based on error conditions.
[0994] The process shown in FIG. 58B can be nested. For example,
the sub-transaction defined by one "participant" may itself be an
atomic transaction based on the contributions of a number of
participants--all of which are managed by the same or different
transaction authority 700.
Security Checkpoint Commerce Utility System
[0995] A Commerce Utility System 90 can include service functions
that enable it to perform as a "Security Checkpoint System 6000"
(see FIG. 58C) that provides security, archiving, and
non-repudiation services that can certify and/or authenticate
communicated information in certain ways. Security Checkpoint
Systems 6000 can: [0996] provide a distributed, highly efficient,
and automated auditing and archiving layer for electronic commerce
interactions, and [0997] enhance the depth of security of a
distributed security environment such as VDE and the Distributed
Commerce Utility layer.
[0998] Thus, Security Checkpoint System 6000 may perform security
and/or administrative functions. This Commerce Utility System
capability takes the positive benefits of centralized security
models (e.g., ability to have a central authority physically
control the processing node) and deploys these capabilities into a
distributed "user space" model that can achieve maximum efficiency
and flexibility, support secure and manageable scalability (a
principal weakness of centralized systems), and provide the
enhanced security benefits of multiple, independent, secure
environment layers. The latter capability is particularly adapted
for highly sensitive communications desiring extra security
assurance. These security layers are enabled by the required
participation and security processing of one or more independent
security checkpoint protected processing environments that
reinforces the foundation distributed security environment.
[0999] Information that passes through one or more Security
Checkpoint Systems 6000 can be certified and/or authenticated to
assure an information recipient (e.g., a party receiving
information in a container) that certain communications functions
and/or security steps (processes) occurred prior to receiving the
information. This certification and/or authentication can include,
for example, certifying or authenticating proper communication
routing through required and/or authorized protected processing
Security Checkpoint Systems 6000. Such checkpoints may be, for
example, distributed throughout a telecommunications network, and
"local" to the physical and/or logical location of end-user VDE
nodes (see FIG. 58C).
[1000] Security Checkpoint Systems 6000 may employ
telecommunication switches adapted to certify and/or authenticate
certain information and processes. For example, certificates issued
by a Security Checkpoint System 6000 may certify that a required
route was followed and that a required checkpoint examined a
communicated secure electronic container, and/or that the sending
of such a container or other electronic information was performed
pursuant to certain stipulated rules and controls. For example,
such a service can help ensure and/or certify and/or authenticate,
that certain budgets, other limits, and/or restrictions are not
exceeded, and/or certain other requirements are met.
[1001] For example, a Security Checkpoint System 6000 may help
ensure requirements (including that limits or other restrictions
are not exceeded) for: the number of "shipped" information
containers in a given period of time; the value of electronic
currency contained within (or represented by) a given container
and/or by containers over a certain period of time (very important
to reduce improper electronic currency activities); the financial
amount committed in a purchase order, including that proper
ordering authority is present; and so on. Such requirement
assessment may be in reference to, for example, container (or other
digital information communication) activity communicated from a
certain logical and/or physical area, node, node group, user or
user organization, and/or other user grouping, wherein said
reference is determined through referencing secure node and/or
individual user and/or organization and/or area identification
information as, for example, a VDE secure container travels through
said adapted one or more telecommunication switches.
[1002] These Commerce Utility System "communications checkpoint"
capabilities can provide useful security features by, for example,
providing one or more "independent" distributed security "check
points" along a telecommunication route that substantially
increases security reliability by requiring the presence of a
proper certificate and/or authentication securely provided by such
checkpoint and securely associated with and/or inserted within said
container by a process managed by said checkpoint (or a group of
checkpoints). This presence can be tested by a receiving node--and
a proper certificate or authentication can be required to be
present, for example according to rules and controls, before such
receiving node will process at least a portion of the content of
one or more classes of received containers. Such container classes
may include, for example, containers from specific individuals
and/or groups and/or containers and/or container contents that have
certain one or more specific attributes.
[1003] Security Checkpoint Systems 6000 may be "independent" of
end-user Virtual Distribution Environment nodes from a security
perspective. Such nodes may, for example, be independent from a
security perspective because they use key management to maintain
multiple secure execution compartments within their protected
processing environments for checkpoint management, such that a
security breach in end-user nodes shall not directly comprise the
security of checkpoint operation, and to help ensure that a breach
related to a secure execution compartment will not comprise other
such compartments.
[1004] Security Checkpoint Systems 6000 may also gather audit
information including, for example, retrieving identity information
of intended container recipient(s), class(es) of container
information, checksum and/or other information employed for future
validation (e.g., non-repudiation), and/or archiving of some or all
portions of said container's content. Some of this information may
be at least in part in encrypted such that one or more portions of
such information may not be decrypted without the cooperation of
one or more of the container sender, the intended and/or actual
container recipient(s), and/or a government body having authority
to access such information.
[1005] FIGS. 58C and 58D show an example of a "checkpoint security"
Commerce Utility System 6000 arrangement that provides
communication checkpoint security, non-repudiation, and archiving
services within the context of a telecommunications network
connecting users 95(1), 95(2), 95(3). In this example, the security
checkpoint systems 6000 may be part of the telecommunications
infrastructure. For example security checkpoint systems 6000 may be
part of one or more telecommunications switches or other equipment
that has been designed to detect secure electronic containers 152
based, for example, on the header information they contain.
[1006] Security checkpoint systems 6000 in this example have the
secure ability to control whether or not a secure container 152
transmitted through the communications infrastructure will be
permitted to pass--and the consequences of routing the container
through the communications infrastructure. In one example, controls
operating with a user 95(1)'s protected processing environment may
require certain kinds of containers 152 (e.g., containers that
carry electronic currency) to include controls 404 that require
them to be routed through a security checkpoint systems 6000 (or a
certain class of security checkpoint systems). Such controls 404
can prevent the container 152 or its content (e.g., currency it
contains) from being used unless it is routed through the
appropriate security checkpoint system 6000.
[1007] For example, suppose that user 95(1) wishes to send a secure
container 152 to user 95(2). In this example, the user 95(1)
transmits the container 152 to user 95(2) through the
telecommunications infrastructure. That infrastructure may detect
that the information being sent is a container, and may route the
container for interception by the a security checkpoint system
(system 6000(5), for example).
[1008] Security checkpoint system 6000(5) may, after intercepting
the container 152, examine the control information within the
container to determine whether requirements for further
communicating the container to user 95(2) have been satisfied.
Security checkpoint system 6000(5) may forward the container to
user 95(2) only if those requirements have been met--or it may
modify the container to permit user 95(2) to open and use the
container subject to the container's controls 404 (which may limit
use, for example). The security checkpoint system 6000 may be
authorized to modify at least a portion of the container's controls
404--for example to add further use limitations.
[1009] This FIG. 58C example shows two "webs" of security
checkpoint systems 6000. In this example, these "webs" represent
collections of security checkpoint systems 6000 that have each been
certified (by a Certifying Authority 500 for example) as being:
[1010] (1) a security checkpoint system, and
[1011] (2) a member of the particular class.
[1012] Hence, in this example "web 1" represents the class of
certified security checkpoint systems 6000(1)-6000(5), 6000(7); and
Web 2 represents the class of security checkpoint systems
6000(4)-6000(6). As one example, "web 1" security checkpoint
systems 6000 may be certified as being capable of handling
containers containing electronic currency 6004.
[1013] One of the requirements specified within the control
information associated with the container 152 may be that it must
pass through a "web 2" security checkpoint system (e.g., system
6000(5))--for example, to enable certain secure auditing functions
such as trusted electronic currency tracking. A "web 1" security
checkpoint system (e.g., system 6000(3)) may refuse to pass the
container 152 to user 95(2) based on these controls 404--or it may
refuse to modify the container 152 to make it usable by user
95(2).
[1014] By way of further example, suppose user 95(2) wishes to pass
the container 152 along to another user 95(3). The controls 404
associated with the container 152 may require, in this particular
example, that further communication of the container 152 must be
through a "web 1" security checkpoint system 6000(7). This routing
requirement may be been present in the controls 404 provided by
user 95(1), or it may be added by security checkpoint system
6000(5) or the user 95(2)'s protected processing environment.
[1015] In the particular example shown, the controls 404 may enable
the "web 1" security checkpoint system 6000(7) to pass the
container 152 along to user 95(3) via a further routing that does
not include a security checkpoint system 6000 (e.g., via another
type of commerce utility system and/or a non-secure
telecommunications switch).
[1016] FIG. 58D shows an example process performed by an example
security checkpoint system. In this example process, the security
checkpoint system 6000 receives a container 152 (FIG. 58D, block
6002) and determines whether the requirements specified by its
associated controls 404 have been satisfied (FIG. 58D, decision
block 6004). If the requirements have been satisfied, the security
checkpoint system 6000 may perform "requirements satisified"
consequences, e.g., modifying controls 404 to satisfy the routing
requirement mentioned above (FIG. 58D, block 6006). If the
requirements are not satisfied (FIG. 58D, "N" exit to decision
block 6004), the security checkpoint system may perform
"requirements not satisfied" consequences (FIG. 58D, block
6008).
[1017] Each set of consequences may involve some form of secure
auditing, for example. If the security checkpoint 6000 passes a
container 152 containing electronic currency for example, the
security checkpoint 6000 may record one or more of the following
auditing information: [1018] sender identity, [1019] sender node
identity, [1020] receiver identity, [1021] receiver node identity,
[1022] certificate(s) on which the currency is based, [1023] other
security checkpoints 6000 the currency has passed through, [1024]
the identity of prior handlers of the currency, [1025] date, time,
and location of transmission, [1026] date, time, and location of
receipt, [1027] how long the currency has been in transit, and
[1028] other secure auditing information.
[1029] If the security checkpoint system 6000 refuses to pass
and/or modify a container 152, it may produce an audit report
including available tracking information, for example: [1030]
sender name, [1031] nature of deficiency, [1032] intended receiver,
and [1033] other tracking information. It may also notify the
sender, the intended receiver, a government agency, or other
authority. It may further charge a "failed communication" overhead
fee to the sender, for example.
[1034] The security checkpoint system 6000 may then determine
whether additional communications are required (FIG. 58D, decision
block 6010). If not, the process may complete. If additional
communications are required ("Y" exit to decision block 6010), the
security checkpoint system 6000 may transmit the container 152 to
the next system (FIG. 58D, block 6012). The next system may be an
additional security checkpoint system 6000 that performs additional
processing (FIG. 58D, blocks 6016, 6004, 6006, 6008).
EXAMPLES
Example
Electronic Content Distribution Value Chain
[1035] FIG. 59 shows how example Distributed Commerce Utility 75
can be used to support an example electronic content distribution
value chain 162. In the FIG. 59 example, an author 164 may create a
valuable work, such as a novel, television program, musical
composition, or the like. The author provides this work 166 (for
example, in electronic digital form) to a publisher 168.
[1036] The publisher may use his own branding, name recognition and
marketing efforts to distribute the work to a consumer 95. The
publisher 168 may also provide the work 166 to a content
"aggregator" 170--someone who provides customers access to a wide
range of content from multiple sources. Examples of aggregators
include, for example, traditional on-line information database
services and World Wide Web sites that host content from many
diverse sources. Typically, consumers use an aggregator's services
by searching for information relevant to one or more
consumer-defined topics. An aggregator 170 may provide the search
tools to the consumer 95 who will make their own selections.
[1037] The aggregator 170 might distribute the work 172 containing
some or all of the original work 166 directly to consumer 95.
Aggregator 170 may also distribute the work 172 to a "repackager"
174. Repackager 174 may, for example, take content from several
sources on related matters and combine them into mixed source
products, such as multimedia combinations, newsletter publications,
or "current awareness" packages. In these services, the repackager
makes the selection of content and organizes based on
audience-indicated interest. A consumer 95 may subscribe to an
electronic newsletter on a particular topic or the consumer may
give the repackager 174 a short list of topics they are interested
in. The repackager 174 will select relevant information and
communicate the information to the customer. Here the repackager is
doing the selecting for the consumer.
[1038] For example, repackager 174 might be the publisher of a
newsletter and might republish some or all of the author's work 166
in this newsletter 176. Repackager 174 could directly distribute
newsletter 176 to consumer 95, or the newsletter could pass through
still additional channels. Repackager 174 could use a search engine
provided by aggregator 170 to find articles of interest to consumer
95 and combine those articles into an electronic newsletter that
has both the aggregator 170's brand and the repackagers 174's
brand, and then send the newsletter to the consumer 95.
[1039] Distributed Commerce Utility 75 may support the FIG. 59
value chain in a number of ways. For example:
[1040] 1. Certifying authority 500 can issue certificates that
allow each of the value chain participants to identify who they are
and to demonstrate that they are members of one or more particular
classes. For example, author 164 and/or publisher 168 might specify
that any certified aggregator or repackager is entitled to excerpt
or anthologize work 166 so long as appropriate payment is made.
Certifying authority 500 could issue digital certificates 504
supporting this desired business objective, the certificates
certifying that aggregator 170 is in fact a reputable aggregator
and that repackager 174 in fact a reputable repackager. So long as
author 164 and/or publisher 168 trust the security of the overall
system 50 and the certificates 504 issued by certifying authority
500, they will have no fear that the work 166 will be excerpted or
anthologized by anyone other than the appropriate types of people
they specify.
[1041] In another example, certifying authority 500 could issue a
certificate 504 to aggregator 170 or other user. Certifying
authority 500 could issue this certificate 504 at the direction of
author 164 or publisher 168. The certificate 504 may attest to the
fact that author 164 or publisher 168 agree that aggregator 170 or
other user is authorized to modify certain permissions 404. Author
164 or publisher 168 may have specified permissions 404 so that
that will allow themselves to be modified only on the condition
that an "authorized aggregator" certificate is present.
[1042] In another example, certifying authority 500 could issue a
certificate to one or more classes of users, enabling, for example,
utilization of content and/or specific portions of content and/or
modification of permissions, which such enabling may be limited to
specific utilization and/or modification by employing certain VDE
rules and controls put in place by the author or publisher or
certificate authority (as allowed by in place rules and
controls).
[1043] 2. Rights and permissions clearinghouse 400 in this
particular example may be used to register work 166 and issue
appropriate permissions 404 consistent with authorizations and
instructions provided by each value chain participant. For example,
the author 164 could register work 166 with rights and permissions
clearinghouse 400, and specify an electronic control set 404
defining the rights of every other value chain participant.
[1044] For example: [1045] This control set 404 could specify, as
one example, that publisher 168 can distribute an unlimited number
of copies of the work 166 so long as the publisher pays the author
164 a certain dollar amount for each copy distributed. [1046] The
control set 404 might permit publisher 168 to add his own
additional controls that allow consumer 95 to read the work 166 an
unlimited number of times but prevents the consumer from copying or
redistributing the work. [1047] Although the electronic control set
may travel in an electronic container 152 with the work 166, it may
also be provided separately. For example, rights and permissions
clearinghouse 400 might, upon request, supply a control set
associated with work 166 to anyone who requests a control set.
[1048] Rights and permissions clearinghouse 400 might maintain
different versions of the control set 404 for different user
classes so that, for example, consumers 95 might receive one
control set 404a, aggregators 170 might receive another control set
404b, and repackagers 174 might receive a still further, different
control set 404c. Each of these control sets can be provided in
advance by author 164 or other rights holders, providing a
"pre-approved permissioning" system that makes widespread usage of
work 166 extremely efficient and yet highly secure, and further,
such control sets may interact with VDE distributed template
applications in a seamless manner--one or more template
applications may be distributed with a control set by such
distributors of such control sets (or may be otherwise made
available) to such control set recipients. In one particular
"superdistribution" business model, work 166 is allowed to be
distributed as widely as possible, and rights and permissions
clearinghouse 400 does the work of providing current control sets
404 authorizing particular value chain participants to use the work
in particular ways under particular conditions.
[1049] 3. Usage clearinghouse 300 in this particular example may
support the value chain by collecting usage information from each
value chain participant. The usage clearinghouse 300 may thus
provide a secure auditing function, generating, for example,
reports that track how many times the work 166 has been used and
how it has been used.
[1050] As one example, usage clearinghouse 300 might analyze usage
information to determine how many consumers 95 have read the work.
Usage clearinghouse 300 can, for example, report consumption
information in varying amounts of detail and/or specific kinds of
information, to various value chain participants consistent with
privacy concerns and the accepted business rights of each party. As
one example, the usage clearinghouse 300 might give consumer 95 a
very detailed report about his or her own particular usage of work
166, while providing author 164 or publisher 168 with only summary
report information that may, for example, not include the consumer
name, address, or other direct, identifying information.
[1051] As another example, reports could also flow directly from
the repackager 174 to the aggregator 170, publisher 168 and author
164. Reports may be directed along any logical pathway, directly,
or through any sequence of parties, and containing whatever mix of
information for each party as is acceptable to the value chain and
as may be enforced, for example, at least in part by VDE rules and
controls
[1052] 4. Financial clearinghouse 200, in this example, may provide
secure clearing of financial details of the transaction--ensuring
that appropriate value chain participants compensate other
appropriate value chain participants. As one example, financial
clearinghouse 200 may receive payments from consumer 95 based on
the consumer's use of work 166, and distribute parts of the
payments appropriately to author 164, publisher 168, and other
appropriate value chain participants in an automated, efficient
process managed at least in part by VDE rules and controls. For
example, financial clearinghouse 200 might interface with other
banks or financial institutions to accomplish an automation of
payment transfers, and/or it might assist in managing electronic
money maintained within the overall value chain shown. Financial
clearinghouse 200 may also assist in ensuring that itself and the
other Commerce Utility Systems 90 are appropriately compensated for
the administrative and support services they provide, that is, for
example, secure VDE processes operating within Commerce Utility
Systems 90 may automatically ensure the payment to such
administrative and support service providers.
[1053] 5. Secure directory services 600, in this example, may
support the example value chain by facilitating electronic
communications between value chain participants and/or between
Commerce Utility Systems 90. For example, secure directory services
600 can, upon request, provide electronic address and/or routing
information allowing one value chain participant to electronically
contact another. As one example, suppose a consumer 95 wants to
obtain the latest addition of work 166 but discovers that the
electronic address of publisher 168 has changed. Consumer 95 can
electronically contact secure directory services 600, which can
provide current address information. Of course, in commercial
trading system applications, for example, secure directory services
may provide much more elaborate services for the identification of
desired parties, such as multi-dimensional searching of directory
resources for identifying parties based on class attributes. Secure
directory services 600 may also provide services that enable the
identification of content, for example based upon content type
and/or rules and controls associated with such content (pricing,
allowed usage parameters such as redistribution rights, etc.).
[1054] 6. Transaction authority 700 in this example might be used
to assist repackager 174 in developing newsletter 176. For example,
transaction authority 700 might help in automating a process in
which a number of different works created by a number of different
authors were all aggregated and excerpted for publication in the
newsletter. Transaction authority 700 can securely maintain the
current status of an overall multi-step process, specifying which
steps have already been performed and which steps have yet to be
performed. Transaction authority 700 can also, for example, help
arbitrate and mediate between different participants in such a
multi-step process, and can in some cases actively influence or
control the process (for example, by issuing new instructions or
requirements based upon error or other conditions).
Example
Manufacturing Chain
[1055] FIG. 60 shows an example manufacturing value chain supported
by Distributed Commerce Utility 75. In this particular example, a
customer 95 places an order with a manufacturer 180 and receives an
order confirmation. The manufacturer may order parts and supplies
from a number of different suppliers 182(1)-182(N). Suppliers
181(1)-182(N) may, in turn, order additional parts or
sub-assemblies from additional suppliers 182(a1), . . . . A bank
184 may supply funds to suppliers 182 based on proofs of order and
assurances that the manufacturer will pay back the advances. A
transportation/warehousing company 186 may provide transportation
and warehousing for supplies and/or final products.
[1056] In this value chain, certifying authority 500 and
transaction authority 700 can assist with secure flow of electronic
orders, confirmations, terms and conditions, and contracts, and can
also help to ensure that each value chain participant can maintain
the desired degree of confidentiality while exchanging necessary
information with other value chain participants. Usage
clearinghouse 300 may assist in secure auditing of the overall
process, tracking of physical and electronic parcels between the
value chain participants, and other usage related operations.
Financial clearinghouse 200 may handle the financial arrangements
between the value chain participants, for example, assisting in
coordinating between the world of electronic network 150 and a
paper-oriented or other world of bank 184. Rights and permissions
clearinghouse 400 may provide a secure archive for electronic
controls 404 defining parts or all of the transaction. Transaction
authority 700 may securely monitor the overall progress of
transactions occurring among value chain participants, and provide
periodic status reports as appropriate to each value chain
participant. In addition, transaction authority 700 can assist in
directing or arbitrating the overall transactions to ensure that
all steps and requirements are fulfilled. Secure directory services
600 can assist in routing information electronically between the
different value chain participants. Of course, as previously stated
for the present inventions and as applicable throughout this
specification, VDE chain of handling and control and other
capabilities, including rules and controls and secure communication
techniques, would preferably be used as a foundation for the above
activities.
Examples of how Commerce Utility Systems can Support One
Another
[1057] FIGS. 16A-16E described above show how different Commerce
Utility Systems 90 can support one another. In more detail, FIG.
16A shows that a financial clearinghouse 200 may provide services
to one or more other Commerce Utility Systems 90, including, for
example, the usage clearinghouse 300, the rights and permissions
clearinghouse 400, the certifying authority 500, the secure
directory services 600, the transaction authority 700 and another
financial clearinghouse 200'. Under such circumstances, the plural
Commerce Utility Systems constitute both a virtual clearinghouse
and a higher order Commerce Utility System.
[1058] In each instance, the financial clearinghouse 200 may
collect funds due the support services and deposit these funds to
at least one provider account employing at least one payment
method. The financial clearinghouse 200 may also provide VDE audit
records confirming the source and amount of the funds and the
provider account in which the finds were deposited by the financial
clearinghouse 200. The financial clearinghouse 200 may provide
assistance to one or more other support services in establishing
provider accounts and communicating to such one or more support
services the account number and/or numbers and terms and conditions
that may apply. Both the support service request to the financial
clearinghouse 200 and its responses to the requesting support
service can be communicated in VDE secure containers (as mentioned
earlier) to take advantage of their substantial security,
confidentiality, flexible control architecture, and trustedness,
and can be processed at each location by one or more VDE Protected
Processing Environments. Financial and account information may be
provided in the form of VDE control sets and/or be incorporated in
VDE control sets by the financial clearinghouse 200 and/or by one
or more other support services. Financial clearinghouses 200 may
also provide services to each other to promote further operating
and administrative efficiencies. For example, one financial
clearinghouse 200 may provide services to its counterparts in other
countries or in other geographic regions. In another example, one
financial clearinghouse 200 may provide another financial
clearinghouse 200 access to one or more payment methods not
directly supported by the second financial clearinghouse 200.
[1059] FIG. 16B shows that the usage clearinghouse 300 may also
provide services to other Commerce Utility Systems 90. In one
example, the usage clearinghouse 300 may provide raw data,
aggregated data, at least in part derived information, and/or
reports to other electronic commerce support services such as
financial clearinghouses 200, rights and permissions clearinghouses
400, certifying authorities 500, secure directory services 600,
transaction authorities 700, and other usage clearinghouses 300'.
These other infrastructure services may use this information as
independent third party verification of certain transactions and
their details, for market research on behalf of their own services,
and/or to resell this information, perhaps in conjunction with
their own usage information. In one example, a rights and
permissions clearinghouse 400 might sell reports to a publisher
containing a combination of their own information, and that from
the financial clearinghouse 200 and usage clearinghouse 300 plus
secure directory service 600 and certifying authority 500. More
specifically, a report might contain a list of objects registered
at the rights and permissions clearinghouse 400 by a particular
publisher, the number of requests to the rights and permissions
clearinghouse for updated or additional rights and permissions,
financial clearinghouse 200 summary revenue numbers for each
digital property, the number of certificates by the certifying
authority 500 on behalf of the publisher indicating that the user
had been certified and had a valid subscription to the publisher's
digital works, and the number of requests to the secure directory
service 600 seeking information about the network addresses of the
publisher's online web servers. In each case, a support service
provided the information to the rights and permissions
clearinghouse for incorporation in this report to the
publisher.
Example
Distributed Commerce Utility 75 Can Support Digital Property
Purchasing, Licensing and/or Renting Transactions
[1060] Distributed Commerce Utility 75 provides significant
trustedness, security, convenience, and efficiencies for instances
in which customers pay for digital information. Moreover,
information creators and distributors can price this
information--indeed, any digital property in any digital format--in
various ways and in different ways in different markets.
[1061] FIG. 61 shows an example of an information delivery service
arrangement 1000 in which an information provider 168 provides
electronic content for purchase, rental and/or licensing. In this
example, an information services company 168 distributes
information 166 to several global markets, including individuals,
Their market areas include professionals, home office users, and
the small office marketplace, as well as medium and large companies
and consumers at home. For example, provider 168 may deliver
content 166 in electronic form to a home consumer 95(1), a
professional such as a lawyer 95(2), and to a corporation or other
organization 95(3). In one example: [1062] an individual consumer
95(1) buys under subscription pricing three articles 166(1) from an
online encyclopedia; [1063] a lawyer 95(2) buys three chapters
166(2) from a treatise on patent law; and [1064] two product
marketing managers in a large company 95(3) receive a proprietary
market research report 166(3).
[1065] Prior to information delivery transactions, the consumer
95(1), professional 95(2) and company 95(3) may use a secure
directory service 600 to locate the network address of the
information provider 168 as well as assist in identifying the
content they wish to work with. Subsequently, these parties 95 may
send an electronic message to provider 168 requesting the specific
information they want to receive. Provider 168 may deliver this
information 166 within VDE secure electronic containers 152 along
with associated rules and controls 188 that control pricing and
permissions. Each of parties 95 has an electronic appliance 100
including a protected processing environment 154 that enforces
these controls 188.
[1066] The provider 168 can price information differently for
different markets. For example: [1067] professionals 95(2) and SOHO
(small office/home office) pay transaction fees; [1068] large
companies 95(3) pay a mixture of subscription and transaction fees
(e.g., company 95(3) may pay $10 per page printed or excerpted from
a larger report, and may also pay a subscription fee); and [1069]
Individual consumers 95(1) pay a flat subscription rate.
[1070] In each of these cases, local, state, and/or federal sales
taxes, as appropriate, are included in the retail price. Payment
methods may be provided within electronic control sets 188
delivered in electronic containers 152 with, and/or independently
of, the associated content 166 (for example, as provided in Ginter,
et al).
[1071] A financial clearinghouse 200 ensures that provider 168
receives payment through any authorized payment method. The
information delivery service 168 accepts a broad range of payment
methods. Some forms of payment are more popular in certain markets
than in others. For example: [1072] In the professional, SOHO, and
consumer markets, credit (MasterCard and Visa) and charge (American
Express) are popular. [1073] Consumers 95(1) also like credit
cards, and are making increasing use of bank debit cards. [1074]
Large companies 95(3) also use credit and charge cards, payment
through Automated Clearinghouses (ACHs), and billing and payment
through traditional and VDE secure Electronic Data Interchange
(EDI) transactions based, for example, on X.12 protocols.
[1075] A financial clearinghouse 200 makes payment more efficient
in several ways. For example, financial clearinghouse 200 furnishes
provider 168 with a convenient, "one stop shopping" interface to
the several payment methods, and keeps track of the at least one
account number associated with a given provider.
[1076] In this particular example, a certifying authority 500 may
deliver digital certificates to each of consumers 95 specifying a
consumer's one or more classes. For example, certifying authority
500 may deliver: [1077] one or more certificates 504(1) attesting
to the fact that consumer 95(1) is an individual consumer
subscriber to information service 1000 and further attesting to the
fact that the consumer is a registered college student and is a
resident (for the taxation purposes related to the transaction) of
California, [1078] a certificate 504(2) attesting to the fact that
professional 95(2) is a lawyer admitted before the bar of the State
of California, and [1079] one or more certificates 504(3) attesting
to the fact that corporation 95(3) is a legally incorporated entity
and has a certain credit worthiness.
[1080] Control sets 188 may activate the different payment methods
based on the presence of an appropriate digital certificate 504.
For example, control set 188(1) delivered to consumer electronic
appliance 100(1) authorizes consumer 95(1) to use each of the three
articles 166(1). Control set 188(1) may, for example, contain a
requirement that the consumer 95(1) must have a certificate 504(1)
from an independent certifying authority 500 (or from the
information distributor or other party acting in a certifying
authority capacity under authorization from a more senior
certifying authority) attesting to the fact that the consumer 95(1)
has a subscription that has not yet expired to the online
encyclopedia. This certificate 504(1) may, for example, be used in
conjunction with other certificates issued by the certifying
authority 500 (e.g., perhaps run by, or authorized by, the US
government or other governing body) attesting to the fact that the
consumer 95(1) is a US citizen, resides within the US, and is a
legal resident of the State of California.
The Individual Consumer
[1081] The consumer 95(1) pays the information provider 168 for the
subscription through a transaction transmitted to the financial
clearinghouse 200 in a VDE electronic container 152. The payment
transaction may involve, for example, the consumer appliance 100
sending to financial clearinghouse 200 an electronic container
152(7) including rules and controls 188(4) and audit records
302(1). The audit records 302(1) may indicate, for example: [1082]
who should be paid, [1083] the amount of the transaction, [1084]
the particular payment method (a VISA card, for example), [1085]
the subscriber's VISA card number and expiration date, [1086] an
identifier of the information subscription, and [1087] the number
of the provider's account to which the payment should be
credited.
[1088] The secure container 152(7) may also contain rules and
controls 188(4) indicating that municipal, California and US
federal sales taxes should also be collected. The financial
clearinghouse 200 collects the appropriate sales taxes and deposits
the funds in the appropriate accounts, for example certain funds
would be deposited in the account belonging to the appropriate
State of California tax collection agency 1002.
[1089] In exchange for the payment, the subscribing customer 95(1)
may receive from certifying authority 500 a certificate 504(1)
indicating she is in fact a subscriber and the expiration date of
the current subscription.
The Professional
[1090] The lawyer 95(2) in this example may be located in the
United Kingdom. He purchases the three chapters 166(2) from a
treatise on patents using a MasterCard, but pays in pounds sterling
rather than in dollars. To perform the purchase transaction, the
lawyer 95(2) may first be preauthorized by the financial
clearinghouse 200 for purchases each month of up to $500 US (or the
equivalent in pounds). The pre-authorization may be sent from the
financial clearinghouse 200 to the lawyer's appliance 100(2) in the
form of a budget control 188(5) in a secure container 152(8). The
protected processing environment 154(2) within the lawyer's
appliance 100(3) may open the container 152(8), authenticate the
budget record 188(5), and store the control within an associated
secure database maintained by PPE 154(2).
[1091] Upon receiving opening each of the three chapters 166(1),
the lawyer's protected processing environment 154(2) may create an
associated audit record, and may decrement available credit in the
budget record by the amount of the purchase. At month end, or when
the $500 preauthorized credit has been exhausted, the lawyer's PPE
154(2) may send to the financial clearinghouse 200, a secure
container 152(9) with audit records 302(2) indicating all the
purchases, their amounts, and the provider account or accounts to
be credited, this supporting efficient automation of clearing
processes. The financial clearinghouse 200 may open the secure
container 152(9), debit the lawyer's credit card account, and pay
the appropriate provider accounts their due.
The Company
[1092] Preliminary to content transactions, a distributed corporate
financial clearinghouse 200A within the company 95(3), while
operating under the authority of the financial clearinghouse 200,
sends to each of managers 95(3)A, 95(3)B a secure container 152 a
budget record 188 indicating their currently approved monthly
information and market research budget. A corporate distributed
certifying authority 500A (in the same trust hierarchy as the
certifying authority 500, in this example) may also issue digital
certificates 504 (not shown) to employees of the company.
[1093] In this example, each product manager 95(3)A, 95(3)B prints
selected portions of the report and the budget on his or her local
appliance 100, which is decremented by $10 for each page printed.
The protected processing environment 154(3) within the local
electronic appliance 100(3) securely performs this process,
conditioning it on controls 188(3) that may require appropriate
digital certificates 504(3) issued by certifying authority 500
and/or the distributed corporate certifying authority 500A.
[1094] According to controls 188(3) supplied by the information
provider, for example, at the end of the month, or when the budget
for that month is exhausted, the corporation's appliance 100(3)
sends to the corporate internal financial clearinghouse 200A audit
records (not shown) indicating any purchases that might have been
made during the reporting interval and the amounts and provider
account numbers for those purchases. The distributed, local
corporate financial clearinghouse 200A aggregates the sums in the
audit records and sends in a secure container 152(12) at least one
audit record 302(3) to the external financial clearinghouse 200 to
authorize payment of the total amount owed the provider of the
market research reports through an Automated Clearinghouse (ACH).
Also in the secure container 152(11) (e.g., as part of audit record
302(3)) are the account number of the company 95(3) from which the
funds should be debited and the account number of the market
research company that issued the report into which the funds should
be credited. The financial clearinghouse 200 completes the payment
process through the ACH and sends a VDE secure container (providing
at least one audit record) back to the internal, corporate
financial clearinghouse 200A as confirmation. Distributed
clearinghouse 200A may, in turn, send, using a secure container
(not shown), at least one confirming audit record to each of the
product managers 95(3)A, 95(3)B.
Example
Distributed Commerce Utility 75 Can Support Transactions where a
Consumer Purchases and Pays for a Tangible Item
[1095] A significant portion of electronic commerce will entail the
sale, purchase, distribution management, and/or payment for
intangibles of all kinds. Commerce in tangibles has many of the
same security, trustedness, and efficiency requirements as commerce
in intangibles (e.g., digital information). For the computer to
become a true commerce appliance, a distributed, secure, trusted
rights/event management software layer (e.g., rights operating
system or middleware) such as the Virtual Distribution Environment
described in the Ginter et al. specification is a necessity. Thus,
even when tangibles rather than digital properties are the object
of secure electronic commerce, Distributed Commerce Utility 75 can
play an important role.
[1096] FIG. 62 shows an example tangible goods purchasing and
payment system 1010. In the FIG. 62 example, imagine a well-known
provider of clothing and certain related household items, for
example, L.L. Bean or Lands' End, offers their wares over a digital
network such as the Internet/World Wide Web. In this example, the
company creates: [1097] a Web catalog server 1012 to offer a line
of clothing to consumers 95, [1098] a web fulfillment server 1014
that is an interface to the fulfillment function, and [1099] a
third web server 1016 that acts as a secure financial clearinghouse
200 and as an interface to several payment methods (e.g.,
MasterCard ("MC"), VISA, and American Express ("AMEX").
[1100] The company also in this one example [1101] registers the
service with the secure directory service provider 600, and [1102]
through the financial clearinghouse 200, establishes a provider
account with at least one payment method, such as a credit card,
debit card, and/or bank, and [1103] registers several transactions
with a transaction authority 700.
[1104] In this example, the company registers with the transaction
authority 700, which may be a distributed transaction authority
within the company selling the goods, an atomic transaction
comprising at least one electronic control set that describes, for
example: [1105] sending the order to the fulfillment processing one
or more organizations such as a warehouse 1018 and logistics 1020
(which may or may not be the same company), [1106] receiving
confirmation that the desired merchandise is in fact in stock,
[1107] receiving confirmation of the order, [1108] receiving
payment pre-authorization from a payment method for the particular
customer placing the order, [1109] shipping instructions for the
merchandise, [1110] confirmation that the merchandise was actually
shipped, and [1111] controls for completing the payment
transaction.
[1112] In this one example, the company also obtains at least one
digital certificate 504 from a certifying authority 500 attesting
to at least one fact, for example, that [1113] the company is a
legitimate corporation registered in the State of Delaware; [1114]
the company is not in bankruptcy and/or the company has a certain
degree of creditworthiness, [1115] the company has been assigned a
particular Federal tax Identification Number, and [1116] that the
company has State tax Identification Numbers in each of several
states, the specific states and their corresponding Identification
Numbers,
[1117] A customer 95 uses his or her electronic appliance 100 with
Web browsing capabilities to access the catalog server 1012 over
the Internet's World Wide Web. The catalog server 1012 sends the
customer 95 a web page 1022 providing a page from an electronic
catalog. Web page 1022 may be sent in one or more secure electronic
containers 152(1). The customer 95 displays the web page 1022A
using his or her electronic appliance 100, and clicks on the part
of the web page showing a men's short sleeve Oxford button down
shirt selling for $15.95. The current Web page is replace by a web
page 1022B from the fulfillment server 1014. This second web page
1022B may be sent in a secure container 152(2).
[1118] The customer's electronic appliance 100 has a protected
processing environment 154. PPE 154 opens the secure container 152,
and displays the page 1022B on the screen. The page 1022B being
displayed is a form that has several fields including the catalog
number and description of the shirt and retail price. The customer
95 fills in fields for color, neck size, normal or tall person,
normal or trim fit, and quantity. The customer 95 also indicates
where the shirt(s) are to be delivered, the class of delivery
service desired, and the customer's address.
[1119] Upon the customer 95 completing the required information,
the electronic appliance 100 puts the form field information 1024
in a secure container 152(3) and sends the container back to the
fulfillment service 1014. Fulfillment server 1014 opens the
container 152(3) and reads the field information 1024. Fulfillment
server 1014 creates a VDE audit record indicating receipt of
information 1024. Fulfillment server 1014 may also create a control
set 188 and/or an event notification that initiates a purchase
transaction.
[1120] Fulfillment server 1014 may communicate with warehouse 1018
directly or through transaction authority 700. The fulfillment
server 1014 then determines whether the required items are in stock
and available to be shipped. If fulfillment server 1014 determines
that the required items are in stock and available to be shipped,
and if the information 1024 provided by the consumer is sufficient
to proceed, the fulfillment service sends back to the consumer
another Web page 1022C indicating: [1121] that the purchase can be
fulfilled, [1122] what are the various sales taxes and delivery
charges, [1123] the address provided and class of delivery service
chosen, [1124] new fields for payment related information, and
[1125] a query asking whether the consumer wishes to proceed.
[1126] The fulfillment service 1014 also sends audit records 302(1)
to the consumer's PPE 154 and to the transaction authority 700
indicating which parts of the larger, atomic transaction have been
fulfilled.
[1127] If the customer 95 determines he or she does not wish to
continue with the transaction after viewing fulfillment details,
his or her appliance 100 can send a secure VDE container 152(5) to
the fulfillment service 1014 and to the transaction authority 700
indicating that the transaction is canceled. If the customer 95
says yes, please continue with the transaction, the customer is
prompted to pick a payment method from among the list provided. In
this example, the list corresponds to payment methods supported by
both the merchandise provider and by the financial clearinghouse
200. The customer 95 fills in credit or charge card number, for
example, expiration date, and billing address.
[1128] Upon completion of the required information, the customer's
appliance 100 can send the information, using his or her secure
PPE, in a secure VDE container 152(5) to the financial
clearinghouse 200, and may send a separate VDE container (not
shown) with an audit record to the transaction authority 700.
[1129] The financial clearinghouse 200 gets pre-authorization from
the credit card processing company, and, for example, using a
secure VDE container 152(6) returns the pre-authorization approval
information 1026 to the fulfillment server 1014. Financial
clearinghouse 200 may send another VDE container 152(7) to the
transaction authority 700 with an audit record 302(2) indicating
completion of the pre-authorization step.
[1130] The fulfillment server 1014 may send a further VDE secure
container 152(8) to the customer 95 with a new Web page 1022D and
audit record information 302(3) indicating that: [1131] the order
process is complete, [1132] the sale has been approved by payment
method, [1133] when the goods are shipped, the customer's credit
card will be charged the total amount, and [1134] a transaction
confirmation number for further reference in order to be able to
make inquiries with the fulfillment service 1014 and/or with the
transaction authority 700
[1135] The fulfillment service 1014 (e.g., in cooperation with
warehouse 1018) packages the goods, hands them off to an express
delivery service 1020, and, for example, sends VDE secure
containers 152(9), 152(10) with audit records 302(4), 302(5)
indicating shipment to the financial clearinghouse 200 and the
transaction authority 700, respectively. In this example, the
express delivery service ("logistics") 1020 also sends a VDE secure
container 152(11) to the transaction authority 700 and to the
fulfillment service (and also, if desired, to the customer 95)
indicating that the express service 1020 has taken possession of
the package.
[1136] Upon delivery of the package with the merchandise, in this
example, the express delivery service 1020 sends a VDE secure
container 152(12) containing an audit record 302(7) indicating that
delivery of the package has been completed to the transaction
authority 700 which then marks the transaction completed and then
may send additional VDE secure containers 152 indicating completion
to the financial clearinghouse 200, to the express delivery service
1020, to the fulfillment service 1014, and in some examples to the
customer 95.
Example
Distributed Commerce Utility 75 can Support Transactions in which
Customers Pay for Services
[1137] A hallmark of advanced Western economies, especially the
economy of the United States at the end of the present century, has
been the transition from a largely manufacturing, "smoke stack"
economy to not only an "information economy" but to a "service
economy" as well. Distributed Commerce Utility 75 can support
transactions in which customers pay for, and in many examples,
consume or otherwise make use of services.
[1138] FIG. 63 shows an example online service system 1030. In one
example, an online service 1032 registers with the secure directory
service 600 and obtains a digital certificate 504(1) from a
certifying authority 500 attesting to identity of the online
service. The online service also agrees to trust certificates 504
issued by the certifying authority 500 and by parties certified by
the certifying authority 500 to issue certificates for specified
facts.
[1139] For example, the online service 1032 agrees to accept
certificates 504(3) issued by a distributed certifying authority
500A from parents certified by the certifying authority 500
(through certificate 504(2)) to issue certificates attesting to the
facts that they have children and that these children are currently
minor children. In turn, the online service 1032 will not allow
children so certified to access certain subject matter materials
distributed by the online service nor to accept digital signatures
based on those certificates for purchase transactions, unless the
adult person responsible for the child has issued another
certificate attesting to their willingness to be financially
responsible (e.g., unconditionally or for purchases up to some
specified limit per transaction or some aggregate level of spending
in a specified time period, in one example, so much per month).
These certificates 504(2), 504(3) may be sent from the certifying
authority 500 to the parent and/or to at least one child in a VDE
secure container 152.
[1140] Now suppose the child 95(2) subscribes to an online game
called "chat." Online service 1032 has a Web interface specifically
designed for school aged children. This service 1032 offers a
subscription that must be renewed quarterly. Using an electronic
appliance 100 such as a personal computer or TV and settop box with
bi-directional communications and a protected processing
environment 154, the child 95(2) uses secure directory services 600
to locate the online service 1032, and sends a message requesting a
subscription. In response, the online service 1032 sends to the
parent 95(1) or guardian in a VDE secure container 152(4), a
request 1034 for payment, membership, and member information. The
parent or guardian and/or other paying individual 95(1) provides
his or her (or their) credit card number(s), expiration date(s),
and billing address information 1036 in one or more other secure
containers 152(5) to the online service 1032.
[1141] In this example, the online service 1032 communicates the
customer's service account, credit card and/or other payment
information 1036 to the financial clearinghouse using a VDE secure
container 152(6) (in a variation on this example, the parent 95(1)
may have provided this financial and related information directly
to the financial clearinghouse 200 in a VDE secure container
152(5)). The online service provider 1032 also provides to the
financial clearinghouse 200 the clearinghouse network address and
provider account number. Within a protected processing environment
(which may, for example, comprise a general purpose computer locked
in a physically secure vault or other secure installation), the
financial clearinghouse 200 opens the secure container 152(6),
extracts the payment information 1036, and completes the payment
transaction with the credit card company.
[1142] For this example, the financial clearinghouse 200, in turn,
communicates the following information 1038 (this list is for
illustrative purposes only and does not detract from the general
case in which any available set of information might have been
communicated) to the online service 1032 in at least one secure VDE
container 152(7): [1143] VDE audit record for this transaction,
[1144] transaction authorization number, [1145] provider account
number, [1146] account number of the customer at the service, and
[1147] amount of the payment.
[1148] In turn, the online service 1032 sends a secure container
152(8) to the customer 95(1) indicating that payment has been
accepted. In one example, online service 1032 may instruct
certifying authority 500 to issue a certificate 504 attesting to
the validity of the subscription until a specified date. Online
service 1032 may also provide audit records 302(1) derived from the
information 1038 provided by the financial clearinghouse 200.
[1149] Each time the child 95(2) logs on to the online information
service 1032, the child's PPE 154 checks to determine if any
certificates 504 are present or known and if so, whether: [1150]
these digital certificates attest to an current, unexpired
subscription to the online service, and [1151] any minor child
certificates are present and valid (for example, have not expired
because the child has not yet reached their 18.sup.th
birthday).
[1152] Having ascertained through these certificates 504 that the
child 95(2) is authorized to use the online service 1032 and is
prohibited from accessing certain "adult" content, the online
service grants selective access, that is to authorized
portions.
[1153] Among the features of this online service are distributed,
multiperson interactive games. The child 95(2) in this example
plays the game with at least one other authorized and certified
minor child--adults are precluded by underlying VDE rules and
controls from playing this game in this particular example. At
least one portion of the software (e.g., executable code and/or
interpretable code, such as Java) that implements at least one
portion 1040 of the at least one game can be download from the
online service 1032 to the child's information appliance 100(2)
using at least one VDE secure container 152(9).
[1154] Using methods described in the Ginter et al. disclosure,
these programs and/or portions of programs 1040 are determined to
be authentic and unmodified. At least one of the keys used to
calculate the one way hash function that produces the digital
signature used for determining the integrity of the at least one
program 1040 or at least one part of a program is bound to the
identity of the online service 1032 by a certificate 504 issued by
certifying authority 500.
[1155] As the child 95(2) in this example plays the game, at least
a portion of his or her activities are metered according to methods
disclosed in the co-pending Ginter et al. application and audit
records 302(2) are created that indicate this child's usage. At
certain times, these audit records 302(2) are transmitted to the
online service 1032 which may, in this example, include a usage
clearinghouse 300. Usage clearinghouse 300 analyzes these usage
records 302(2), and may use them to determine how much to charge
child 95(2).
Example
Distributed Commerce Utility 75 can be Used to Provide Value Chain
Disaggregation for Purchase and/or Use of Tangible Items
[1156] Distributed Commerce Utility 75 can be used to facilitate a
purchase or other type of transaction relating to tangible goods.
FIG. 64 shows an example tangible goods delivery system 1040. For
example, a company 1042 places an order for office supplies using
an electronic appliance 100 including a PPE 154. The order is for a
box of paper clips, a stapler, staples, a case of 8.5.times.11 inch
copy paper, and a dozen yellow legal size note pads. The items are
manufactured by a manufacturer 1050, distributed by a distributor
1048, and sold to the company by a retailer 1046.
[1157] In this example, a financial clearinghouse 200 receives a
payment 1052 from the company 1042, and disaggregates the payment
by dividing it up into disaggregated payments 1052A, 1052B, 1052C
which it delivers to each of retailer 1046, distributor 1048 and
manufacturer 1050.
[1158] For example, the company 1042 sends its order 1044 within a
VDE electronic container 152(1) to a retailer 1046. In this
example, retailer 1046 provides a fulfillment service that receives
the order 1044 and, in response, provides a control set 188
indicating the provider account number of the distributor 1048
and/or manufacturer 1050 of each item and the percent of the retail
price to be received by each. If desired, retailer 1046 may provide
a different control set 188 for each item ordered (regardless of
quantity)--allowing different payment disaggregation to be
performed on an item-by-item basis. Retailer 1046 may provide this
control set 188a to company 1042.
[1159] Control set 188a may be conditioned on the presence of one
or more digital certificates 504 issued by certifying authority
500. For example, control set 188a may require company 1042 to
provide a digital certificate 504(1) issued by the certifying
authority 500. Certificate 504(1) attests to the identity of the
ordering company 1042. The company 504(1) may provide another
certificate 504(2) in the same chain of trust hierarchy as the
certifying authority 500 warranting that the person placing the
order is authorized to place orders up to a specified spending
limit per order. Company 1042 may provide the same or different
certificate 504(2) also indicating that the purchaser employee
within the company is authorized to make use of a corporate charge
card.
[1160] In this example, the company 1042 pays with a corporate
charge card. The financial clearinghouse 200 first gets payment
authorization from the credit card company prior to the retailer
1046 shipping the merchandise. Upon receiving notification of
preauthorization, retailer 1046 may ship the goods 1047 to the
company 1042. Following delivery of the merchandise 1047, the
retailer 1046 creates at least one VDE audit and/or billing record
1052 in at least one VDE secure container 152(2), and transmits the
container to the financial clearinghouse 200 (audit information may
also or alternatively be sent to retailer 1046).
[1161] The financial clearinghouse 200 then completes the charge
card transaction by allocating the total payment amount to each of
the value chain participants represented by control set 188a (which
it may have received, for example, directly from retailer 1046
and/or through company 1042). In this way, the distributors 1048
and/or manufacturers 1050 receive their payments at the same time
the retail seller 1046 receives its payment. Control set
information 188a may also indicate shares of the total payment and
provider account numbers for local, state, and federal taxes, if
any, and, for example, for delivery charges, such as to an
overnight express company, if any.
[1162] This FIG. 64 example shows that value chain disaggregation
can apply for both tangibles and for intangibles. Similar
techniques can also be used much further back through the
manufacturer's 1050 supply chains if so desired (e.g., to the
providers of the metal from which the paper clips were
fabricated).
Example
Distributed Commerce Utility 75 can Help Distribute Digital
Properties by Providing Object Registry and Other Services
[1163] Distributed Commerce Utility 75 can assist the electronic
community in efficiently distributing electronic or digital
properties or content. For example, using an electronic appliance
100 equipped with a protected processing unit 154, a creator or
other rights holder 400 sends a digital object in a secure
container to a rights and permissions clearinghouse 400 to be
registered.
[1164] The rights and permissions clearinghouse 400 opens the
container using, for example, its own VDE protecting processing
unit, and assigns a uniform object identifier indicating the
identity of the creator, the type of object being
registered--software, video, sound, text, multimedia, etc., and the
digital signature for the object. The uniform object identifier may
be globally unique or may be unique only in the namespace domain of
the creator or some other entity, such as an online service,
digital library, or specific jurisdiction, such as a specific
country.
[1165] In this example, using its protected processing environment,
the rights and permissions clearinghouse 400 digitally signs the
uniform object identifier with the rights and permissions
clearinghouse private key and returns the object and identifier to
the person or organization registering it in a VDE secure
container. The rights and permissions clearinghouse 400 may retain
a copy of the object or may retain only the uniform object
identifier for the object, and the signatures for the object and
its uniform object identifier. In another example, the rights and
permissions clearinghouse 400 digitally signs a new object
comprised of the original object and its uniform file identifier,
and stores both the new object and/or its signature in the rights
and permissions clearinghouse 400 archive.
[1166] The creator may have also sent in a VDE secure container a
permissions and pricing template 450 (see FIGS. 45A-45C) indicating
which permissions are granted, the prices to be charged upon
exercising those permissions, and if applicable, the individual,
class and/or jurisdiction to which those prices and permissions
apply. More than one permission and pricing template 450 may be
sent in a single VDE secure container 152, or separate VDE secure
containers 152 may be used for each permission and pricing
template.
[1167] In this example, using a VDE secure container 152, the
object is then transmitted from the creator to a distributor 168
(see FIG. 16). Using a certificate 504, the distributor 168 can
prove to the VDE instance (PPE 154) interpreting the creator's
control set that the distributor is indeed authorized to
selectively alter permissions and prices of the object and creates
a new permissions and pricing template. The distributor 168 then
sends a VDE secure container to the rights and permissions
clearinghouse 400 containing the uniform object identifier together
with the new controls. In the preferred embodiment, if the object
remains unmodified, the distributor 168 has the option of leaving
the uniform object identifier unmodified; however, if the
distributor has modified the object, perhaps to add its own brand,
then the uniform object identifier must be modified to reflect the
distributor's version. The digital signature is recomputed using
the private key of the distributor. As before, the object registry
has the option of storing only the digital signature or both the
signature and the actual object.
Example
Distributed Commerce Utility 75 can be Used to Facilitate Copyright
Registration
[1168] As a value added service, the rights and permissions
clearinghouse 400 can provide a copyright registration service (see
FIG. 43). The rights and permissions clearinghouse 400 can send a
copy of the object to the appropriate online copyright registration
service of the appropriate government agency 440, for example, the
US Copyright Office. The object and uniform object identifier may
be sent in a VDE secure container together with controls indicating
the mode of payment, if a registration or processing is being
charged.
[1169] In this example, the copyright registration service can send
at least one VDE secure container to the financial clearinghouse
200 with at least one audit record indicating the amount to be
paid, the payment method and account of the registering party, and
the account of the government to receive the funds, and receives in
return in a VDE secure container an audit record indicting that the
transaction has been pre-authorized (or that for whatever reason,
the proposed transaction has not been authorized).
[1170] If the transaction has been pre-authorized by the financial
clearinghouse 200, a VDE enabled computer located, in this one
example, in US Copyright office opens the secure container and adds
the uniform object identifier and the object to the registration
database. Under a chain of trust emanating from the certifying
authority 500--which in this example may be operated by, or on
behalf of the US government--the copyright registration service
issues at least one digital certificate 504 attesting to the facts
that an object with a specified uniform object identifier and with
a specified digital signature has been in fact registered with the
registration authority and that the at least one person is in fact
the owner of the copyright at the time the object was registered.
This certificate 504 is sent in a VDE secure container to the
person who registered the object (and/or who was named as the
person to be notified) and to the rights and permissions
clearinghouse 400 who, in turn, may provide copyright registration
information upon request in a secure VDE container.
[1171] The copyright registration service sends at least one VDE
secure container to the financial clearinghouse 200 with at least
one audit record instructing the clearinghouse 200 to proceed with
fulfillment of the pre-authorized transaction (if all necessary
information was part of the pre-authorization process) and/or
providing information to the clearinghouse 200 regarding, for
example, the amount to be paid, the payment method and account of
the registering party, the account of the US government to receive
the funds, and that the payment transaction should be completed,
and receives in return from the financial clearinghouse in a VDE
secure container an audit record indicting that the transaction has
been completed and funds deposited in the appropriate account or
accounts, or that the payment transaction fail and the reason why
it failed to be completed.
Example
Distributed Commerce Utility 75 can Support Renewal or Modification
Of Permissions and Prices
[1172] Distributed Commerce Utility 75 can further facilitate the
distribution of electronic and digital properties by providing a
mechanism for renewing rights and permissions that have expired.
See FIG. 42A.
[1173] In one example, suppose an employee of a Fortune 1000
company has a control set for a digital property, perhaps a piece
of software or a Java applet, that has expired. The VDE protected
processing environment on the employee's computer can send a VDE
secure container to the rights and permissions clearinghouse
400.
[1174] Distributed Commerce Utility 75 can also facilitate the
distribution of electronic and digital properties by providing a
mechanism for distributing rights, permissions and prices that have
been changed by one or more participants in a distribution chain.
In one example, suppose a customer has a digital object on her hard
disk and its VDE control set as distributed by the publisher. The
permissions and prices originally indicated a pay per use model in
which the user pays 10 cents for each operation on the object, such
as printing or viewing.
[1175] To determine if new rights and prices are now available, the
protected processing environment on the customer's PC can send a
VDE secure container to the Rights and Permissions clearinghouse
400 using its network address obtained from the control set
together with MIME-compliant electronic mail. The customer obtained
the address of the rights and permissions clearinghouse from the
secure directory service 600, having, for example, sent a query in
a VDE secure container and having received a response in a VDE
secure container.
[1176] The VDE secure container sent to the rights and permissions
clearinghouse 400 contains the object identifier plus a request for
the current controls including prices. The protected processing
environment at the rights and permission clearinghouse 400 server
opens the VDE secure container, retrieves the most recent control
set from the database of controls, and sends via return electronic
mail another VDE secure container with the desired controls. The
customer's protected processing environment opens this container,
and replaces and/or augments the expired controls with the new
ones. The customer is now able to use the content according to the
rules and controls specified in the control set just received from
the rights and permissions clearinghouse and processed by the
instance of VDE on the local computer or other appliance. In this
example, these new rules and controls have reduced the pay per use
price from ten cents per operation to five cents per operation.
Example
Distributed Commerce Utility 75 can Support Models to Distribute
New Rights
[1177] Distributed Commerce Utility 75 can also support
transactions in which some or all rights are not initially
distributed to the ultimate consumer with the content, but must be
requested instead. In one example, suppose a lawyer decides to go
into the publishing business by combining her/his own articles with
other materials obtained from legal information distributors. The
legal information distributors have chosen a rights and permissions
clearinghouse 400 to be their distributor of control set
information for their many properties. With each object they
register at the rights and permissions clearinghouse 400 they also
register two control sets in the formats described in the Ginter et
al. disclosure: [1178] one control set specifies default controls
including prices for retail customer, and [1179] a second control
set conveys rights and prices seldom of interest to the retail
customer, for example, the anthologizing right.
[1180] The attorney newsletter publisher obtains a chapter from a
treatise on patent law and wants to include a 1000 word excerpt in
the newsletter in addition to other articles. Having already
obtained the treatise chapter and its retail control set, the
newsletter publisher sends an inquiry in a VDE secure container
using Internet MIME-compliant e-mail to the rights and permissions
clearinghouse 400 asking for the excerpting right and the
anthologizing right for the chapter identified by the enclosed
uniform object identifier. The lawyer found the rights and
permissions clearinghouse 400 using a secure directory service 600
(alternatively the rights and permissions clearinghouse 400 address
may be contained in the original retail version received by the
lawyer).
[1181] The rights clearinghouse 400 checks the object database,
locates the control set information for the object named in the
universal object identifier, and determines that both the
excerpting and anthologizing rights are available along with the
prices for each. The excerpting right does not convey the right to
modify the excerpted portion. The anthologizing right is conveyed
along with controls that set the price to a 30% discount from
retail prorated for the length of an excerpt if the whole chapter
is not anthologized.
[1182] Using a VDE aware page composition application, the
newsletter publisher combines several works, including the 1000
word excerpt into a new work, and registers the new object with the
rights and permissions clearinghouse together with its control
set(s). The newsletter publisher also registers the new object with
a copyright registration function, for example, the US Patent and
Copyright Office. The newsletter publisher distributes the new work
in a VDE secure container, which also contains control sets for
each of the separate anthologized works, and for the whole,
complete newsletter as well. The local VDE protected processing
environment on the appliance of the user keeps track of usage
according to the controls that apply to the composite object and to
the controls of each of its parts for which there are separate
rules. At some time, the VDE instance sends audit records to the
usage clearinghouse 300 and to the financial clearinghouse 200.
Example
Distributed Commerce Utility 75 can Support Electronic Rights
Negotiations
[1183] Distributed Commerce Utility 75 can support electronic
rights negotiations. In one example, suppose a professor is
creating a "course pack": a compilation of many different works to
be used by students in a particular course that in this example,
lasts only one semester. In this example, the professor sends a VDE
secure container with a query to the appropriate rights and
permissions clearinghouse 400 and gets back control sets for the
digital properties listed in the query. Upon reviewing the
permissions and prices, the professor notes that a chapter from a
book carries a price large enough to make the overall price of the
course pack higher than the maximum s/he desires.
[1184] Using the negotiation mechanisms disclosed in Ginter et al.
(see, for example, FIGS. 75A-76B), the professor attempts a
negotiation with the rights and permission clearinghouse 400. The
rights and permissions clearinghouse 400, in turn, automatically
determines it lacks the authority to negotiate and redirects the
negotiation to the publisher.
[1185] Having obtained an appropriate certificate 504 from a
certificate authority 500 by providing credentials indicating
membership in the class "higher education", the protected
processing environment of the publisher's Web server makes an offer
of a new, modified control set for the property targeted for this
professor. The controls have a discounted price, require that the
copies be printed on a VDE enabled authorized printer that will
keep track of the number of copies printed, and report back to the
various parties to the transaction using VDE techniques. Still
unhappy with the price, the professor sends a VDE negotiation
counter-offer in a secure container to the publisher. The
publisher's VDE instance negotiates with the professor's
negotiation counter-offer control set and an agreement is reached
that and provides a new control set with the new, agreed-upon
prices and terms and conditions to the professor, who then goes
ahead to produce the course pack. The rights and permissions
clearinghouse 400 is willing to grant the reduced price in part
because the professor in this example is able to provide a digital
certificate attesting to the fact that she has a full-time
appointment at the University of California, Los Angeles and has a
certain, minimum number of students who will employ the materials.
This authentication meets requirements stated by the publisher to
the rights and permissions clearinghouse 400.
Example
Certification of Executables
[1186] One valuable use of certifying authorities 500 is for the
issuance of digital certificates on behalf of the government. In
addition to issuing certificates attesting to identity, legal
status, etc., government certifying authorities 500 might issue
certificates certifying executables, for example load modules. For
example, government certifying authorities 500 at all levels might
certify the set of executables that represents the laws and trade
practices of their administrative districts. For example, Saudi
Arabia might insist that all appliances in their administrative
control have load modules certified by the government that examine
attributes of containers to insure that only appropriate content is
released. The State of California might certify a load module that
calculates state tax, etc.
Example
Entertainment Distribution
[1187] Distributed Commerce Utility 75 can be used to efficiently
and flexibly support models for film distribution to the consumer
market. For example, suppose that a film and entertainment company
such as Disney wants to provide electronic Distributed Commerce
Utility 75 to support distribution of its films to consumers 95.
Disney could open a Commerce Utility System 90 itself, or it might
contract with a neutral third party to provide Commerce Utility
Systems 90 on its behalf. The purpose of the Commerce Utility
Systems 90 in this example is to support secure
pay-per-view/pay-per-use, rental, lease and other film distribution
transactions to consumers.
[1188] The films themselves could be distributed in digitized
linear form--for example, on Digital Versatile Disk (DVDs) or other
high capacity media. Such media would store, in addition to the
films themselves, one or more secure containers including control
sets for controlling use of the films. Consumers 95 could play the
films using a media player 104 (see FIG. 1) having a network 150
connection or other "back channel" (e.g., the ability to read from
and write to a smart card or the like).
[1189] Media player 104 has a protected processing environment 154
such as a secure processing unit for use in managing rights and
manipulating the electronic containers. The storage media might
also be played by a personal computer 124 equipped with a protected
processing environment and a network connection.
[1190] Set top box 104 may be controlled by electronic controls
distributed on the media and/or via the back channel. The controls
require the set top box 104 to record customer usage and payment
information for each property the consumer decides to view. For
example, a consumer 95 might place a media such as an optical DVD
disk into media player 104 and hit the "play" button. The
consumer's media player 104 might next display (e.g., on television
set 102) a message telling the consumer how much it will cost to
view that particular film (e.g., $2.95), and ask the consumer if
she wants to proceed. If the consumer answers "yes", media player
104 will play the film on the consumer's television set
102--recording usage and payment information for reporting to
Commerce Utility Systems 90. The protected processing environment
154 within media player 104 may, under secure control of one or
more associated electronic control sets delivered to it--monitor
and collect information that can ultimately be used to ensure the
consumer pays for watching the film and to provide a secure usage
audit. The secure usage audit may be used, for example, to allow
Disney, the film's actors and director, and others involved in
making the film to securely verify how many consumers watched the
film (and also potentially to provide demographic information for
targeting advertising or the like). For example, the media player
104's protected processing environment may securely collect and
record, for example, the following information within meter,
billing and/or budget audit trails associated with particular
controls: [1191] name of film [1192] digital identifier of film
[1193] time and date property played [1194] number of times
property played [1195] who played the property.
[1196] In one example, consumers 95 would have to possess a digital
certificate 122 issued by an appropriate certifying authority that
attests to certain facts. Such a digital certificate 122 can be
used to provide a context for the electronic control set(s)
delivered to media player 104. Such a certificate might need to be
present before the consumer would be permitted to play the film
and/or to prevent the film from playing under certain conditions
and/or to effect the controls that apply when the film is
played.
[1197] For example, the parents could obtain a digital certificate
122 indicating that the household has children. This "child
present" digital certificate 122 could be used to prevent media
player 104 from playing any films other than those that have "G",
"PG" ratings. Such certificates 122 could be issued by the same
organization that provides the other administrative and support
services in connection with this example if desired.
[1198] The electronic controls provided with a particular film on a
media such as an optical disk may also specify a particular value
chain disaggregation to be applied in connection with payment
arrangements. For example, the media player 104 would "know" from
the electronic rules and controls delivered to it that the film
distributor, studio and the Distributed Commerce Utility 75 are to
receive particular percentages of the $2.95 usage fee, and that a
state government authority must receive a certain tax payment in
the form of a sales tax or VAT. Because this information is
maintained within the protected processing environment 154 within
media player 104, the consumers 95 may never be exposed to the
payment disaggregation scheme and/or its details. (Typically,
consumers do not care what the distributor "cut" is as opposed to
the studio revenue. The protected processing environment within
media player 104 may provide this payment disaggregation locally or
through a distributed or centralized financial clearing function
200 as described above.)
[1199] Media player 104 can report the usage containment
information it has collected on a real time (online) and/or
periodic event-driven basis. In one example, media player may
report at the end of each month the information it has collected
over the preceding month. It may report collected payment
information (including disaggregation data provided by the control
set) to a financial clearinghouse 200 run by Disney (or, for
example, such information may be reported directly to clearinghouse
200). Financial clearinghouse 200 ensures that the consumer's
account is appropriately debited and that the various payees (e.g.,
Disney, the film's distributor, and others in the value chain)
receive appropriate "splits" of the consumer's payment. The
financial clearinghouse 200 may also provide consumer credit checks
and authorizations, helping to ensure that the consumer doesn't run
up a big bill she can't pay.
[1200] Media player 104 may report the usage information it has
collected to a usage clearinghouse 300 operated by an independent
auditor (the film's producer and actors may insist that an
independent third party auditor--not Disney--performs this
function) or, for example, may report such information to Disney
and/or clearinghouse 200--certain of such information may be
concealed from Disney if required by rules and controls to ensure
other value chain party rights and Disney may not be able to
identify, alter, and/or remove such information due, for example,
to VDE protection mechanisms. The usage clearinghouse 300 may
analyze the usage data and issue reports indicating total number of
views, market share, etc. Usage clearinghouse 300 may also further
analyze the information to provide demographic and/or other
marketing research information. This type of information can be
very useful to advertisers and marketers.
[1201] Disney may also operate a rights and permissions
clearinghouse 400. Even though permissions are distributed on the
optical media in this example, the rights and permissions
clearinghouse can provide supplemental control sets for various
reasons. For example, the control sets distributed on the media may
expire on a certain date. Rights and permissions clearinghouse 400
may issue new control sets in lieu of the expired ones. Rights and
permissions clearinghouse 400 may also issue permissions to provide
"sales" and/or to otherwise change prices (e.g., to reduce the
price of an older film). Rights and permissions clearinghouse 400
can also issue special permissions (e.g., an extracting or
anthologizing right that multi-media developers or advertisers
might be able to request, and/or, for example, redistribution
rights to certain frames such as an approved image of Mickey Mouse
for printing purposes). Disney could "pre-approve" some of these
special permissions so that the rights and permissions
clearinghouse could automatically provide them on demand. Digital
certificates 122 might be used to interact with the
permissions--thereby assuring that the user receiving the control
set is entitled to take advantage of it.
Example
Distributed Commerce Utility 75 can Support the Collection,
Analysis, and Repurposing of Usage Information
[1202] Prior to the inventions disclosed in the Ginter et al.
specification, the electronic community lacked general purpose,
reusable, distributed, peer-to-peer technologies that could, among
other things, efficiently and effectively monitor and measure usage
on the local computer or protected processing environment.
Collecting, analyzing, and reporting usage data provides
significant value to rightsholders and to other distribution chain
participants, to infrastructure Distributed Commerce Utility 75, to
customers, and to other interested parties. Understanding what has
happened can often be a fundamental determinant or contributor to
what might or should happen. In addition, usage information can be
repurposed to support a wide range of other commercial activities,
including advertising and merchandising models.
[1203] Suppose one or more customers in each of several companies
have information appliances 100, in this one example such as
personal computers, with VDE protected processing environments
(PPEs) 154 as described in Ginter et al. Suppose further that over
some time period, perhaps a month in this example, that VDE has
been keeping track of detailed usage information and storing this
information in the encrypted database on each hard drive on each
computer that is a logical extension and under the control of each
consumer PPE. These consumers have each been purchasing different
combinations of information and entertainment from generally
different sources. Each instance of VDE keeps track of usage
information according to the controls associated with the content
and/or service being purchased or otherwise used.
[1204] On or shortly after the first of each month, and/or any
other required (or, if supported, allowed) reporting intervals,
each instance of VDE communicates the usage records to the usage
clearinghouse 300 according to the controls associated with each of
the digital properties they have used during the previous month. In
turn, the usage clearinghouse 300 provides reports to each of the
rightsholders regarding any use of a property during the previous
month or other reporting interval (e.g., daily, weekly, quarterly,
annually, etc.).
[1205] In one example these reports contain information identifying
both the individual customer and the company that employees them.
In another example, the reports contain detailed usage information,
but the identities of the individual customers has been removed by
the usage clearinghouse 300. Alternatively, both the individual and
corporate identities may be removed. Instead, the usage information
may be aggregated by any one or more certain classes, such as by
industry, geography, and/or by country, and/or any other useful
classes.
[1206] In another useful example, a particular company or
individual customer may have not permitted VDE (subject, of course,
to this right being available through in place rules and controls)
to communicate identity information to the usage clearinghouse 300
from their information appliances in the first place. The user may
have established VDE controls prohibiting disclosure of such
identifying information. In another example, the user may have used
the negotiation mechanisms disclosed in the Ginter et al.
application to negotiate additional levels of privacy and
confidentiality other than those required in the various control
sets associated with the information being purchased or otherwise
used by each customer, that is, the electronic negotiation process
generates a modified or new rules and controls set reflecting the
additional levels of privacy and confidentiality. In yet another
example, a rightsholder, rights and permissions clearinghouse 400
or usage clearinghouse 300 or other party, may have used the same
negotiation mechanisms to negotiate, through the use of VDE rules
and controls sets alternative levels of privacy and
confidentiality.
[1207] As illustrated in FIGS. 11 and 33-39, the usage
clearinghouse functions that may remove identifying information,
aggregate data, analyze data, generate reports, and/or transmit
those reports to rightsholders and other interested parties may
exist in one or more logical and physical locations. For example, a
distributed usage clearinghouse 300 executing on the local computer
(or other information appliance) may perform any or all of these
usage clearinghouse functions. One or more usage clearinghouses may
exist within a given company or within a given collection of
companies comprising a vertical industry, healthcare, for example,
trading group, or family of companies ("keiretsu"). Similarly these
usage clearinghouse functions may be performed by usage
clearinghouses within each country or other jurisdiction or defined
by any other class and/or geographic variable.
[1208] Usage clearinghouse 300 may also provide raw data,
aggregated data, and/or customized reports to rightsholders,
distribution chain participants, and/or other interested parties.
These parties include: for example, content creators, publishers,
repackagers, repurposers, advertising agencies and their clients,
trade associations, market research and consulting companies,
circulation audit and audience measurement bureaus, the sales,
marketing, and advertising functions of companies with an interest
in one or more markets, and government agencies.
[1209] In another example the usage clearinghouse 300 may also sell
information to advertisers indicating exposure to particular ads
and/or classes of ads by individuals, customers within a company
and/or group of companies, markets, and/or other analysis groupings
and categories.
Example
Secure Directory Services Protect Confidentiality and Privacy
[1210] Personal and business confidentiality and privacy are often
essential aspects of the modern experience. Individuals may not
want others to know with whom they are associating. In many aspects
of business, firms may not wish to reveal their interest in
communicating or interacting or conducting business with other
parties. In today's Internet, for example, it is possible for those
with certain kinds of access to determine the nature of queries
between a given person and a directory service. Such information
may provide important clues regarding existing or pending business
arrangements that have not yet been publicly announced, a merger or
acquisition, for instance.
[1211] VDE secure containers provide one basis for secure directory
services 600 in which confidentiality and privacy are preserved. In
one example, the Corporation Counsel in a Fortune 100 company
wishes to obtain the email address of the investment banker in the
firm handling a proposed acquisition--but without revealing her
interest to anyone else. The attorney sends a query in a VDE secure
container to the secure directory service 600 with the name and
company of the person she wishes to contact. The secure directory
service then sends the response in another VDE secure container
back to the attorney. Both the query and the response can make use
of certificates issued by the certifying authority 500
authenticating both the attorney and the secure directory service
600. Payment for the query can be handled by the financial
clearinghouse 200 who deposits payment in the provider account of
the secure directory service 600 while debiting the account of the
company that employs the attorney.
[1212] Because these transactions are conducted using VDE and VDE
secure containers, those observing the communications learn no more
than the fact that these parties are communicating. Security
analysts have developed techniques for "traffic analysis", in which
the frequency of communications among two or more parties is
observed and changes in the frequency of communications are
correlated with other information to make inferences regarding the
content and/or purpose of these communications.
[1213] Using VDE and VDE secure containers, it is possible to
defeat traffic analysis, however at some added expense. In this one
example, the company could send a VDE container to the secure
directory service 600 with an empty or "null" query that would
generate in the average amount of elapsed time a return message in
a VDE container with a null response. The instance of VDE on the
attorney's computer would generate a payment transaction destined
for the financial clearinghouse, but would aggregate these payment
records with others to eliminate correlations between the pattern
of queries and payments. While inefficient from a commerce
standpoint, this method of using VDE and VDE secure containers to
defeat traffic analysis attacks can in principle be used among
plural parties wishing to hide the pattern of communications among
them while taking advantages of the secure, trusted, efficient
distributed transaction capabilities disclosed in the Ginter et al.
application.
Example
Cooperation Among Clearinghouses Internal and External to an
Organization
[1214] The various Commerce Utility Systems 90 may be distributed
to varying degrees and in varying combinations as illustrated in
FIGS. 2A-2E and 3A-3C). In one example shown in FIG. 65, an
American Fortune 100 company 1070 with operations in several
countries (e.g., the United States, Japan and Europe) and within
many of those, in multiple locations within each country, has found
it desirable to internationally distribute VDE Distributed Commerce
Utility 75. To increase the efficiency of purchasing external
information, and to maximize its leverage with information
providers, the company 1070 has chosen to negotiate with several
providers, agreements that treat all purchases as having been made
from within the US and being in US dollar currency. In this
example, the company 1070 maintains its own global Intranet 1072.
Intranet 1072 connects company headquarters 1074HQ (shown here as
being located within the United States) with company US employee
electronic appliances 1074US(1), . . . , 1074US(N), company
Japanese employee electronic appliances 1074JP(1), . . . ,
1074JP(N), and company European employee electronic appliances
1074EU(1), . . . , 1074EU(N). Intranet 1072 also permits each of
these employees 1074 to communicate with one another. VDE-based
transactions between the company 1070 and its information suppliers
are also routed through one or another of the company's US gateways
to the Internet.
[1215] To provide efficient administrative and support services,
the company 1070 has deployed in each country at least one
distributed financial clearinghouse 200 and at least one
distributed usage clearinghouse 300. For example, company 1070 may
operate a financial clearinghouse 200A and a usage clearinghouse
300A in the United States, a financial clearinghouse 200B and a
usage clearinghouse 300B in Japan, and a financial clearinghouse
200C and usage clearinghouse 300C in western Europe. In countries
with multiple sites and within the United States, several of these
distributed clearinghouses may exist. In addition to negotiating
agreements with information providers, the company 1070 may also
have negotiated agreements with a large commercial usage
clearinghouse 300 and with a major financial clearinghouse 200.
These centralized clearinghouses could be located anywhere, and may
communicate with company 1070 via the Internet and the corporate
Intranet 1072. Neither of these clearinghouses 200, 300 are
affiliated with the company 1070 other than through this business
arrangement. Each of the distributed clearinghouses within the
company 1070 operates under the simultaneous authority of both the
company and the external clearinghouses with which the company has
a business arrangement.
[1216] In this one example, a product marketing manager 1074JP(1)
employed by this company 1070 in Japan acquires a market research
report 166 from an American distributor 1076. The report and
associated controls are sent from the American distributor 1076 to
this employee 1074JP(1) in a VDE secure container 152a. The
instance of VDE on the manager's appliance 1074JP(1) keeps track of
usage and the payment due the information provider. Periodically,
these audit records 302(1), 302(2) are transmitted in VDE secure
containers 1052b, 1052c to distributed usage clearinghouse (private
usage clearinghouse) 300B and to the internal financial
clearinghouse 200B--both of which are located in Japan on the
company's internal, private corporate network (or Intranet) 1072.
From time to time and in accordance with VDE controls associated
with the content purchased, the private usage clearinghouse 300B
removes, in this example, individual identifying information in
accordance with VDE rules and controls managing protected
processing environment processes and sends in a VDE secure
container the audit records 302(3) to the external, commercial
usage clearinghouse 300. All of the company's internal, distributed
usage clearinghouses 300A, 300B, 300C send periodic communications
in VDE secure containers 152 to the commercial usage clearinghouse
300. In turn, the master usage clearinghouse 300 creates and sells,
licenses, and/or otherwise distributes reports to rightsholders and
other parties (e.g., third parties having a commercial interest in
obtaining the information) in which the identities of individuals
are removed, and which in many circumstances company names, in
accordance with VDE rules and control, have also been removed.
[1217] From time to time and in accordance with VDE controls 188a
associated with the content 166 purchased, copies of the complete
usage records (with employee identification information) are also
sent to the company's master usage clearinghouse 300HQ (which may
be located at corporate headquarters), as are audit records from
all the company's distributed usage clearinghouses 300A, 300B,
300C. These are then aggregated and combined for further analysis,
reporting, and auditing.
[1218] The internal, distributed financial clearinghouses 200A,
200B, 200C also receive audit records 302 in VDE secure containers
152 in accordance with VDE controls sets for the purchased
information from each of the VDE protected processing environments
1074 reporting to them. Each internal financial clearinghouse 200A,
200B, 200C aggregates the payments and from time to time sends a
VDE secure container 152 with audit records 302 indicating the
aggregate sums to be transferred to the information providers as a
result of transactions. The company may also provide update
information regarding the accounts from which the company's funds
are to be transferred and/or the provider accounts that are to
receive such funds. In turn, the external master financial
clearinghouse 200 completes these payment transactions and sends
audit records back to the company 1070 and to the information
providers confirming the payment transactions. In the preferred
embodiment, these activities occur securely under the control of
distributed VDE nodes, and are automated at least in part through
the use of VDE containers and chain of handling and control
managing multi-nodal, multi-party, sequence of processes. As an
alternative example, the calculation for the amount of payment and
the completion of the payment transactions is performed at the
external master financial clearinghouse 200 from usage information
received from the usage clearinghouse 300 (of course, if usage
clearinghouse 300 and financial clearinghouse 200 are the same
party, the financial clearinghouse already has received such
information). The external and internal financial might then, in
this example, compare payment information.
[1219] This example does not depend on the extent to which
administrative and support services are distributed. In a related
example, the usage and financial clearinghouse functions could have
been distributed to each VDE-aware protected processing environment
1074 as illustrated in FIGS. 2A-2E and 3A-3C. In this example, each
protected processing environment 1074 could report directly to the
master external clearinghouses 200, 300, to distributed external
clearinghouses, and/or to internal clearinghouse functions
organized differently than described just above, for example, by
continent (North America, South and Central America, Australia,
Europe, etc.) rather than by country and company 1070 location.
[1220] In one further example, the corporate headquarters 1074HQ
and its associated headquarters-based clearinghouses 200HQ, 300HQ
provide a centralized clearinghouse system through which all usage
and financial information must flow. In this particular, more
centralized example, all user appliances 1074 report their usage
and financial transactions to headquarters-based clearinghouses
200HQ, 300HQ in secure containers 152 over Intranet 1072. Company
headquarters financial clearinghouse 200HQ may interface directly
into VDE compliant general purpose payment systems that directly
support the use of VDE chain of handling and control for ensuring
the enforcement of automated, secure, financial transaction
fulfillment in accordance with rules and controls governing payment
related variables such as payment amounts, parties, locations,
timing and/or other conditions. These headquarters-based
clearinghouses 200HQ, 300HQ, (which may function as a single,
integrated Commerce Utility System) in turn, may communicate
appropriate aggregated and/or other audit trail and/or payment
information to the individual clearinghouses 200A, 200B, 200C,
300A, 300B, 300C within each country. While less efficient than the
less hierarchical example described above, this arrangement may
appeal to large corporations who wish to exert centralized control
over usage and financial information by acting as the central
administrator for the provision of credit and/or electronic
currency to distributed internal financial clearinghouses and by
efficiently managing in-house collection of transaction related
information.
Example
Transaction Authorities can be Used within and Between
Organizations
[1221] FIG. 66 shows an example use of transaction authority 700
for inter and intra organizational communications. FIG. 66 shows an
organization A (left-hand side of the drawing) as having an
"Intranet" (a private data network within a particular
organization) 5100(A). Intranet 5100(A) may be a local and/or wide
area network for example. User electronic appliances 100(A)(1), . .
. , 100(A)(N) (for example, employees of organization A) may
communicate with one another over Intranet 5100(A).
[1222] FIG. 66 also shows another organization B that may have its
own Intranet 5100(B), user electronic appliances 100(B)(1), . . . ,
100(B)(N), and private transaction authority 700(B). In addition,
FIG. 66 shows a public data network 5104 (such as the Internet for
example) and a public transaction authority 700(C). FIG. 66 shows
that in this example, organizations A and B communicate with the
outside world through trusted transaction authority 700(A), 700(B)
(which may, if desired, also include "gateways", "firewalls" and
other associated secure communications components). In other
examples, trusted transaction authority 700(A), 700(B) need not be
the actual "gateway" and "firewall" to/from Internet 5104, but
could instead operate wholly internally to the respective
organizations A, B while potentially generating electronic
containers 302 for transmission over Internet 5104.
[1223] In this example, organization A user protected processing
environments 100(A)(1), . . . , 100(A)(N) each have an instance of
a virtual distribution environment protected processing
environment, and can communicate with one another over Intranet
5100(A) via secure electronic containers 302. Similarly,
organization A user electronic appliances 100(B)(1), . . . ,
100(B)(N) each have an instance of a virtual distribution
environment protected processing environment, and can communicate
with one another over Intranet 5100(B) via secure electronic
containers 302. In addition, organization A and organization B can
communicate with one another over Internet 5104 via secure
electronic containers 302.
[1224] Organization A's private trusted transaction authority
700(A) may be used for facilitating organization A's internal
communications and processes. Private trusted transaction authority
700(A) might be used, for example, to carefully track items sent
from one user to another within organization A. The public
transaction authority 700(C), meanwhile, can be used to coordinate
between organization A and organization B without, for example,
revealing confidential information of either organization to the
other organization. Below are more detailed examples of how the
FIG. 66 arrangement might be advantageously used to conduct
business transactions.
[1225] Suppose a confidential memo needs to be approved by users
100(A)(1), 100(A)(3) and 100(A)(5) (who can each revise the memo)
before being distributed to each of users 100(A)(2),
100(A)(7)-100(A)(10) and 100(A)(12) (none of whom can change the
memo), with copies to users 100(A)(1), 100(A)(3) and 100(A)(5) (who
also can't change the memo after all three of them have signed off
on it) and to no one else. Private transaction authority 700(A) can
maintain a rule set that specifies these requirements. Transaction
authority 700(A) can: [1226] send the memo (in secure containers)
in "round robin" fashion to each of users 100(A)(1), 100(A)(3) and
100(A)(5) for approval. [1227] If any one of these users changes
the memo, then transaction authority 700(A) can circulate the
revised memo to the other two for additional comments and
revisions. [1228] Once all three of users 100(A)(1), 100(A)(3) and
100(A)(5) approve the memo, transaction authority 700(A) may be
empowered to place each of their digital and/or handwritten
signatures or initials on the memo, place it into one or more
secure containers with a control set specifying it is read only and
can only be read by users 100(A)(1)-100(A)(3), 100(A)(5),
100(A)(7)-100(A)(10) and 100(A)(12). [1229] Transaction authority
700(A) may then send a copy of the memo in a container to each of
these users, or could require the same container to circulate from
one to another. [1230] The transaction authority 700 may require
the electronic controls to maintain a secure audit trail indicating
where the container has been, who has opened it, who has accessed
the memo it contains, and when. Transaction authority 700(A) might
thus increase personal accountability by evidencing whether a
particular person had seen a particular document, when, and for how
long.
[1231] Organization A's Intranet 5104 might also be used to
exchange and/or distribute highly confidential design
specifications. Transaction authority 700(A) can, for example,
maintain, in digital form, a detailed record of who has "signed
off" on the design specifications--thus ensuring personal
accountability and providing a high degree of efficiency.
[1232] As mentioned above, private transaction authorities 700(A),
700(B) can also provide a "firewall" function to protect
confidential information from escaping to outside of the respective
organizations A, B. Suppose for example that organization A is an
integrated circuit design house and organization B is an integrated
circuit foundry. Organization A designs and specifies the circuit
layout of a chip, producing a "tape out" that it sends to
organization B. Organization B manufactures an integrated circuit
based on the "tape out", and delivers chips to organization A.
[1233] Transaction authority 700 can be used to facilitate the
above business transaction while protecting confidentiality within
each of organizations A and B. For example: [1234] organization A's
private transaction authority 700(A) can supervise an overall
design and specification development effort within organization A.
All communications take place in secure containers 302 over
organization A's Intranet 5100(A) to maintain confidentiality.
Transaction authority 700(A) can maintain a secure archive of
historical design documents, works in progress, and specification
versions as the design process progresses. [1235] Organization A's
private transaction authority 700(A) can manage the final design
specification development--ensuring that all conditions required to
finalize the design specifications are followed. [1236] Once the
design specification has been finalized, transaction authority
700(A) can circulate it within secure containers 152 to those
individuals within organization A that need to "sign off" on it.
Their respective appliances 100(A)(1), . . . 100(A)(k) can affix
and/or embed digital signatures, handwritten signatures, seals
and/or fingerprints as described above to indicate specification
approval. [1237] Upon being satisfied that the specification has
been "signed off" by the appropriate people, transaction authority
700(A) can send it over Internet 1104 within a secure container 302
to public transaction authority 700(C). Public transaction
authority 700(C) may be a commercial transaction authority retained
by organizations A and B to act as a liaison between them.
Organization A's private transaction authority 700(A) can filter
(or protect) all information it sends to public transaction
authority 700(C) to ensure that organization B can access only that
information intended for it. For example, private transaction
authority 700(A) might provide additional electronic controls
within the container to prevent organization B from seeing any
detailed audit information showing where the specification has been
within organization A. [1238] The public transaction authority
700(C) might act as an independent trusted third party, notarizing
and/or certifying the design specification to later evidence that
organization A delivered it on a particular date and time in
accordance with a contract. [1239] Public transaction authority
700(C) could then forward the design specification (still within a
secure container) over Internet 5104 to organization B's private
transaction authority 700(B). [1240] Organization B's private
transaction authority 700(B) could automatically send a copy of the
design specification over organization B's Intranet 5100(B) to the
appropriate users 100(B)(1), 100(B),(N) within organization B. No
one outside of organization B would need to know who received a
copy of the specification. On the other hand, organization A's
transaction authority 700(A) could, if desired, include electronic
controls restricting access to only certain engineers within
organization B--and these secure controls would be carried along
into organization B and securely enforced by electronic appliances
100(B)(1), . . . , 100(B)(N).
[1241] Organization B's transaction authority 700(B) could manage
the chip manufacturing process, ensuring that all steps and
conditions required to manufacture chips in accordance with
organization A's design specification are followed.
Example
Transaction Authority can Facilitate International Commerce
[1242] FIG. 67 shows an example of how transaction authority 700
can be used to conduct international commerce. In this particular
example, a transaction authority 700 coordinates a complex
multi-national transaction between companies 1106A, 1106B and 1106C
located in their own respective countries (e.g., the United States,
Australia and Europe). Company 1106A has its own bank 1108A and
lawyers 111A. Similarly, company 1106B has its own bank 1108B and
lawyers 1110B, and company 1106C has its own bank 1108C and lawyers
1110C.
[1243] The transaction authority 700 may assist in forming
agreements between the international parties, by for example
passing offers and counteroffers back and forth in secure
containers and using the contract forming techniques described
above to establish some or all of the terms and provide
non-repudiation. Once a contract is formed, transaction authority
700 may maintain a master set of rules and controls specifying all
the conditions that must be satisfied to complete the
transaction--and may thus provide consequences for different
events. Alternatively, once the contract is executed, the
transaction authority role may be virtual, particularly in simpler
models, that is the value chain rules and controls can be carried
by VDE containers whose rules and controls may, as a whole, specify
all processes and conditions that must fulfilled, including their
sequence of operation. Rules and controls provided by a transaction
authority 700 may take international law into account--with
differing rules applying to different countries. The rules could
take into account various import and export requirements and
restrictions, international tax treaties between nations, contain
upfront and/or ongoing customs related routing and filing
requirements, identify reputable currency transaction authorities,
assist in filing contracts or certain contract terms with relevant
national and international authorities, manage any shipping or
other transportation requirements, assist in establishing
conclusive translation services for contract terms (particularly
standard terms and conditions), manage differences in international
certifying authority requirements and formats, impose societal
regulations required by applicable governing bodies, and collect
applicable governing body taxes, such as taxes for both national
and regional governing entities, etc. Transaction authority 700 may
communicate between the various international parties using secure
electronic containers, and may securely validate and authentic
various event notifications provided by the international
parties.
Example
Distributed Transaction Authorities
[1244] Complex business interactions under the control of a
transaction authority 700 may also be distributed within and among,
for example, organizations and/or jurisdictions. Suppose a complex
international real estate transaction requires participation of
several functions within the purchasing and selling companies,
several financial institutions, insurance companies, and law firms,
and perhaps government agencies in a few countries. Suppose further
that each of the organizational and individual parties to the
transaction has computers that are VDE-aware, and that within each
organization or agency there is at least one distributed
transaction authority that performs services for this real estate
transaction under an authority granted by a master transaction
authority 700.
[1245] In this one example, each of the parties to'the real estate
transaction has contributed commerce rules and parameters
representing their business relationships in the form of VDE rules
and controls that define each parties role in the overall
transaction. For instance, the insurance company must insure the
property at a value and cost that the purchaser finds acceptable
and that is also approved by the mortgage lender(s). Also, suppose
that these transaction VDE rules and controls have already been
mutually agreed upon using negotiation mechanisms described in the
Ginter et al. application, and that the negotiated rules and
controls together with the history of negotiating these rules and
controls have all been stored at the master transaction authority
for this real estate transaction. The most senior transaction
authority may be a master transaction authority 700 or might be any
mutually agreed upon distributed transaction authority. In this one
example we assume the former. In short, in short, all parties have
agreed to the rules and controls that govern the transaction. The
negotiation process may have been simplified because the
transaction authority 700 may have distributed a distributed
template application for international real estate sales, the
template being based on the transaction authority 700's past
experience or that were created by the transaction authority 700
especially for this transaction as a value added service to its
important customers.
[1246] Each of the parties to the transaction is, according to the
VDE control sets that define this atomic transaction, responsible
for seeing that certain pieces of the transaction are completed
prior to the closing and consummation of the overall transaction.
In some cases, plural parties are jointly responsible for
completing part of the over all transaction. For example, the buyer
and seller must have agreed on a purchase price. In this example,
they contribute their business requirements, including, for
example, their price and other variables, and they use the VDE
negotiation mechanisms to arrive at an agreement that represents a
fair balance of interests. If the electronic negotiation is
unsuccessful, the parties may directly negotiate, or VDE secure
containers with audit records indicating failure are sent to the
transaction authority who, in turn, notifies each of the other
parties authorized to participate in the overall transaction.
[1247] If the buying and selling parties do agree, in this one
example, notification is sent by the VDE protected processing
environment that completes the negotiation (or receives negotiation
completion instructions digitally signed by both parties through
the use of VDE techniques) to a distributed transaction authority,
which in turn, notifies other parties, including other
participating transaction authorities, that price has been agreed
upon. Based on VDE controls for subtransactions, VDE may securely
notify a party or parties that certain other subtransactions are
now to be completed. In this example, the title search company may
now perform their task; an insurance company may now begin
negotiations with the buyer for coverage using the VDE negotiation
mechanisms. An attorney in the Counsel's office for the purchaser
may begin negotiations with his counterpart in the seller's
company; both in-house attorneys may interact with their outside
counsel using VDE and VDE secure containers in creating and
negotiating the various documents whose execution completes parts
or the overall transaction.
[1248] In this example, each of the parties may have one or more
digital certificates issued by the certifying authority 500 to
authenticate each of the parties to this transaction and its
subtransactions. The financial clearinghouse 200 provides a payment
vehicle for various value added services, in one example, those
provided by the transaction authority 700. The usage clearinghouse
300 collects audit records sent from time to time in VDE secure
containers from each of the participating VDE protected processing
environments and provides an independent third party audit of these
transactions. The secure directory services 600 helps participants
locate each other's electronic addresses while maintaining
confidentiality and privacy.
[1249] As each of the subtransactions is completed, a distributed
transaction authority within the organization within which the
subtransaction is completed notifies the master authority for this
transaction 700 of completion of that subtask. According to the
previously agreed upon VDE rules and controls sets, some or all of
the persons participating in the transaction may also be notified
by audit records and/or messages that are securely sent from, and
authenticated by, at least one participating VDE protected
processing environment, including, for example, PPEs at nodes for
individuals, distributed Commerce Utility Systems, a distributed
transaction authority, and/or the master authority for this
transaction.
[1250] When all the component elements of the overall transaction
have completed, a transaction authority, in this example, the
master transaction authority for this real estate sale, notifies
each of the participants and each of the participating distributed
transaction authorities, that the preconditions have all been met
and settles the overall transaction. Optionally, the transaction
authority may give seller and purchase a last opportunity to
proceed to completion or to hold up the transaction.
[1251] This one example shows that Commerce Utility Systems 90,
including transaction authority 700, may be distributed to
intermediate VDE protected processing environments that support one
or more Commerce Utility Systems 90.
Example
Digital Broadcasting Network
[1252] Amortizing infrastructure and other resources across many
users, building critical mass more rapidly than competitors,
supporting specialization to tailor and deliver the most appealing
products and services to customers, maximizing negotiating leverage
power for purchasing, and building the most comprehensive
infrastructure to serve as the best "one-stop" resource for a given
business activity--these are all central concepts in building
successful, modern businesses. VDE and Distributed Commerce Utility
provide a foundation for creating highly competitive and successful
cyberspace businesses that demonstrate these attributes. Many of
these businesses will reflect the character of the Internet and the
World Wide Web. Like VDE and Distributed Commerce Utility, they
will comprise a distributed community that realizes maximum
advantage by supporting electronic commerce partnerships. They will
provide different layers of services and complementary products and
services, and will realize great advantage in coordinating their
activities to their mutual benefit.
[1253] The Digital Broadcasting Network ("DBN") will be just such
an innovative commercial enterprise. Comprised of many different
World Wide Web ("WEB") based sites and services, DBN participants
will gain greater leverage and operating efficiency by sharing
resources, experiencing maximum buying power, generating marketing
and customer information, and supporting a rational administrative
overlay that ties together their many, frequently complementary,
activities. Much like the consistent rules that enable and underlie
both the World Wide Web and the design of VDE and Distributed
Commerce Utility, and layered upon the capabilities of both these
architectures, the Digital Broadcasting Network employs their
inventions to support a highly efficient, largely automated and
distributed community that maximizes business efficiencies. In a
similar manner, other examples would include other groupings of
entities that function together as Virtual Enterprises (e.g.
corporations or other organizations). The distributed nature of VDE
and the Commerce Utility Systems are particularly important in
providing an effective infrastructure for these modern, potentially
large scale, cyberspace business activities.
[1254] The Digital Broadcasting Network may function as a
cooperative of WEB sites and, for example, service providers, with
a central and perhaps regional and logical (e.g. market based)
headquarters groups, or it may function as a for profit,
shareholder corporation in a business model reminiscent of
television broadcast companies (e.g., NBC), or it may function as a
cooperative or virtual corporation that has some mix or combination
of mixes of the above attributes and employ distributed peer to
peer, hierarchical, and centralized administrative business
relationships and activities. In one example, a plurality of
corporations may join together to provide the advantages of size
and coordination with individual participants providing some degree
of specialty expertise and the body of entities coordinating
together in some fashion in a "higher" level cooperative or
corporation.
[1255] In one example, the Digital Broadcasting Network may be a
single corporation that has many licensed franchisees. The licensed
franchisees may comprise WEB sites that serve geographically and/or
logically specialized market areas and/or serve other WEB sites in
a hierarchy and/or peer-to-peer context of Distributed Commerce
Utility services as described above. On behalf of itself and its
franchisees, this corporation may, for example: [1256] negotiate
optimal rates for exposure time with advertisers and their agents,
[1257] obtain the lowest costs for content provided by third
parties, [1258] resell market analysis and user profiling
information, [1259] share its revenue with its franchisees which
themselves may share revenue with DBN and/or other franchisees,
[1260] provide advertising to franchisees in response to franchisee
and/or franchisee user base profiles, [1261] guarantee a certain
number of "eyes" (exposures and/or other interactions) with respect
to advertiser materials, [1262] provide a secure virtual network
employing VDE and Distributed Commerce Utility capabilities so that
the overall organization can operate in a secure and highly
efficient manner, including using common user application tools,
interfaces, and administration operations, [1263] do advertising
for the network to the benefit of the network and the franchisees,
[1264] purchase and/or otherwise supply content to franchisees in
response to franchisee needs as demonstrated by their requests
and/or usage profiles, [1265] collect and analyze content
(including advertising) usage, cyberspace purchasing, and other
data as allowed under its agreement with franchisees, [1266] allow
franchisees to perform many of the network functions on a local
basis--that is acquire and make available geographically and/or
logically local (consistent with there focus) content (and/or other
content of particular interest to its user base), [1267] negotiate
agreements regarding advertising materials that are of commercial
value given the franchisees physical and/or logical market focus,
[1268] control at least a portion of its WEB "broadcasting"
space--that is exercise local control over at least some portion of
the content--with the remainder of the control, by agreement, and,
for example, enforced by rules and controls, being under the
control of DBN and/or some one or more other network participants,
and [1269] perform other administrative, support and/or service
functions on behalf and/or for the network.
[1270] In one example, DBN may employ many of the security and
administrative capabilities of VDE and many of the service
functions provided by the present inventions to manage and automate
the distributed relationships and activities that are central to
the DBN business model. For example: [1271] Transaction Authority
700 can provide the overall administrative context for managing the
network community. For example, the transaction authority 700 may
manage (through the use of VDE rules and controls in the preferred
embodiment) the routing of content to appropriate franchisees. It
may also manage the chains of handling and control related to
reporting usage information. The transaction authority 700 may
obtain and/or derive its electronic control sets from the agreement
relationships between DBN and its franchisees. Electronic
negotations may be used to create these agreement relationships.
The transaction authority 700 may also receive controls reflecting
bilateral or other networked relationships directly among
franchisees and other participants. [1272] Rights and Permissions
Clearinghouse 400 can extend commercial rights related to content
to network franchisees. It acts as a repository of rights related
to content that is supplied by network entities to
customers--including content rights held by network entities
themselves, and made available to other network entities. Such
content rights may include, for example, displaying, vending,
redistributing, repurposing, and for advertising. It can provide
additional rights (e.g., redistribution rights or specialized
repurposing rights) upon request and/or automated profiling based,
for example, upon usage. [1273] Usage Clearinghouse 300 can collect
usage data in support of market analysis, user profiling, and
advertising. It may also analyze that information and derive
reports. It may distribute those reports internally to the DBN as
appropriate, and sell reports and/or other usage based information
externally based upon commercial opportunity. [1274] Financial
Clearinghouse 200 can ensure proper compensation fulfillment
throughout the network. It may collect payments due to DBN from
franchisees for content. It may distribute to franchisees payments
due them as a result of advertising and reselling of usage
information. It can collect payments from franchisees for support
of generaly DBN infrastructure and services such as, for example,
network advertising. It connects to general purpose financial
clearinghouse infrastructure to transmit and receive payment
related information. [1275] The secure directory services 600 may
maintain directory services based upon unique identity and/or class
attribute(s). There may be a very large number of franchisees
globally. Directory services 600 could also maintain directory
information on customers, including unique identifier and profiling
information. Secure directory services 600 may maintain directory
infrastructure for content owned, managed and/or available to the
network. [1276] A certifying authority 500 may certify the roles of
all participants in the network. It would issue a certificate to
each franchisee, for example. It may also issue certificates
certifying commercial relationships of groupings of network
entities to facilitate efficient, secure relationships with third
parties. They may also issue certificates to customers to represent
certain specialized customer rights regarding customer commercial
activities with outside parties (for example, discounts, or being a
member of the greater "DBN" community).
[1277] Portions or all of specific service functions (e.g., as
described above) may be highly distributed and may operate
significantly, primarily or even exclusively on franchise and
service network web servers.
[1278] While the inventions have been described in connection with
what is presently considered to be the most practical and preferred
embodiment, it is to be understood that the inventions are not to
be limited to the disclosed embodiment, but on the contrary, are
intended to cover various modifications and equivalent arrangements
included within the spirit and scope of the appended claims.
* * * * *