DIRECT DEMOCRACY FRAMEWORK

Abstract

There is disclosed a global infrastructure that would help change the world's political landscape. Utilizing the distributed technology of end-user voting tools—installed on computers, cell phones, and other digital devices across the globe—this new infrastructure would facilitate a viral virtual democracy process identified as distributed voting. When integrated with the centralized management capabilities of a Voting Management Server into a Direct Democracy Framework, this process can dovetail into petitioning, registration, congress, and ratification. Such a system makes it clearly possible to represent the will of the people far more effectively than the often slow-moving voting systems that serve us today, either by providing a conduit of the people's will to existing representative governments or, where appropriate, by facilitated governance by direct democracy.

Description

REFERENCE TO RELATED APPLICATION

This patent application claims the benefit of U.S. Provisional Application No. 61/059,120 filed on 5 Jun. 2008, the disclosure of which is incorporated herein by reference in its entirety.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile preproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

1. Field of the invention

This invention relates to method and process for removing inefficiencies and barriers to entry from the direct democratic process, making direct democracy a more fundamental component of everyday life in society.

2. Description of Related Art

With today's technology a single email is sent and resent and can eventually end up arriving in a multitude of different inboxes. Using this principle, there is disclosed a voting tool that can be used to quickly reach multitudes of individuals. For example, the user interface of the voting tool includes a checkbox to allow recursive voting; when this feature is selected, users receiving an initiative have the ability to forward it on to a user list of their own choosing. Those users in turn would be able to forward it on to users of their choosing and so on. In this manner, it's possible for an initiative to spread out to vast numbers of individuals within a few iterations of the process. For example, if ten people are asked to respond to an initiative, and they in turn each ask ten more people, and the process is continued for ten cycles, the initiative will reach millions of people, a number which is far more than the practical limits of the number of people who would have access to the appropriate technology to participate in this voting tree.

What is needed is a process that allows an end user voting tool to generate a counter-initiative (an initiative that automatically records a vote to oppose the original initiative in conjunction with a vote to support the counter-initiative) or an amended initiative, and still allow the user to record a vote of support or no opinion to the original initiative.

Through the constant exchange of initiatives, counter-initiatives, and amended initiatives, the contribution of everyone in the voting tree will be absorbed to ensure that the very best available thinking is included in the final output of the process.

SUMMARY OF THE INVENTION

The method of voting disclosed is a software tool that can be integrated into an email or instant messaging application that has the following capabilities:

Instead of allowing recipients to respond to the sender with a message of their own, recipients can only respond in support, opposition, or no opinion. This message will be called an initiative. The tool then provides the ability to record a tally of the responses that are received, effectively tracking votes for each initiative.

The tool also includes a checkbox to allow recursive voting; when this feature is selected, users receiving an initiative have the ability to forward it on to a user list of their own choosing. Those users would, in turn, be able to forward it on to users of their choosing, and so on. As responses are sent back up the voting tree created by this recursive process, the tally of incoming responses is calculated and passed back along the tree to the original sender. Note that the voting roster itself is not sent to the original sender, just the end tally. As the process proceeds, the original author of the initiative ends up collecting a total tally of all the votes cast against the original initiative; that tally is then sent back out through the tree so that all users receive constant updates on the votes for and against the initiative as it grows.

The tool allows users to launch counter initiatives and amended initiatives of their own. An amended initiative allows support for the original initiative, whereas a counter initiative automatically includes a vote against the original initiative. As these derivative initiatives move through their own voting trees, they carry with them the original initiative on which they are based as attachments.

The tool also supports the automatic submission of a petition by defining a pre-defined voting management server to which to send a copy of the initiative once a specific voting threshold is passed. Notification of the initiation of a petition would flow through the voting tree, allowing other voters to participate in the petition.

The tool also uses a voting management server which combines the functionality of current web based voting servers with an email server to provide several unique capabilities as follows:

The voting management server provides an internet browser based version of the previously described end user voting tool.

The server also hosts open forums, in which users could subscribe to a specific topic and automatically receive all initiatives submitted to the forum. The server similarly hosts petitions of successful initiatives, To support large scale petitions, voting management servers have the ability to distribute petitions across multiple servers.

The server can also replicate the capabilities of software distribution servers in updating client based end user voting tools.

Confirming and registering the identity of a voter is also provided by the voting management server. This process would allow the Direct Democracy Framework to replicate the security found in traditional voting systems.

The voting management server allows for a statistical sampling of voters to be selected so that, in case of particularly important initiatives, those voters could be selected to attend a congress.

Finally, these two technology components are brought together in a five step framework that provides the solution with the flexibility to meet the needs of any size of organization. The first step is always performed; then, based on the level of importance of the initiative in question, any of the additional steps that follow may be added:

A. Distribute voting is the first step; it is supported exclusively by the end user voting tool.

B. Petition is the second step in the process; it is supported by the voting management server.

C. Registration is the third step; it is supported by the voting management server.

D. Congress, the fourth step, occurs when a random selection of delegates from the list of registered voters is asked to attend a physical event and confirm their voting record.

E. Ratification is the fifth and final step in the process; in this step, direct democracy initiatives are incorporated into traditional democratic legislatures through their own standard voting procedures.

The foregoing has outlined, rather broadly, the preferred feature of the present invention so that those skilled in the art may better understand the detailed description of the invention that follows. Additional features of the invention will be described hereinafter that form the subject of the claims of the invention. Those skilled in the art should appreciate that they can readily use the disclosed conception and specific embodiment as a basis for designing or modifying other structures for carrying out the same purposes of the present invention and that such other structures do not depart from the spirit and scope of the invention in its broadest form.

BRIEF DESCRIPTION OF THE DRAWINGS

Other aspects, features, and advantages of the present invention will become more fully apparent from the following detailed description, the appended claim, and the accompanying drawings.

FIGS. 1-8 Illustrative Recursive Voting

FIG. 1 shows Initiative Creation

FIG. 2 shows First Level Response

FIG. 3 shows First Level Voter Update

FIG. 4 shows Second Level Send

FIG. 5 shows Second Level Response

FIG. 6 shows Second Level Response Received

FIG. 7 shows Second Level Updates

FIG. 8 shows Level Updates Reach Second Level

FIGS. 9-28 are End User Voting Flowcharts

FIG. 9 is a flow chart of Main Program Loop;

FIG. 10 is a flow chart of Process User Input;

FIG. 11 is a flow chart of Create New Initiative;

FIG. 12 is a flow chart of Search Initiatives;

FIG. 13 is a flow chart of Display Initiative;

FIG. 14 is a flow chart of Edit Existing Initiative;

FIG. 15 is a flow chart of Send Existing Initiative;

FIG. 16 is a flow chart of Recursive Send Process;

FIG. 17 is a flow chart of Vote on Initiative;

FIG. 18 is a flow chart of Voter Response Process;

FIG. 19 is a flow chart of Voter Update Generation Process;

FIG. 20 is a flow chart of Process Inbox Messages;

FIG. 21 is a flow chart of Initiative In-processing;

FIG. 22 is a flow chart of Voter Response In=processing;

FIG. 23 is a flow chart of Vote Update In-processing;

FIG. 24 is a flow chart of Update User Profile;

FIG. 25 is a flow chart of Voter Management Server Message In-processing;

FIG. 26 is a flow chart of Send Petitions;

FIG. 27 is a flow chart of Petition Status Change Process; and

FIG. 28 is a flow chart of Petition Signature Process.

FIGS. 29-42 are Voting Management Server Flowcharts

FIG. 29 is a flow chart of Main Program Loop;

FIG. 30 is a flow chart of Process Administrator Requests—Part 1;

FIG. 31 is a flow chart of Process Administrator Requests—Part 2;

FIG. 32 is a flow chart of Group Administration Process;

FIG. 33 is a flow chart of User Administration Process;

FIG. 34 is a flow chart of Petition Administration Process;

FIG. 35 is a flow chart of Forum Administration Process;

FIG. 36 is a flow chart of Server Configuration Process;

FIG. 37 is a flow chart of Auto Process Inbox;

FIG. 38 is a flow chart of Auto Process Membership Request;

FIG. 39 is a flow chart of Auto Process Petition Request;

FIG. 40 is a flow chart of Auto Process Petition Signature or Link Request;

FIG. 41 is a flow chart of Admin Inbox Process; and

FIG. 42 is a flow chart of USER Details Process.

DETAILED DESCRIPTION OF THE INVENTION

Introduction

There is disclosed a global infrastructure that would help change the world's political landscape. Utilizing the distributed technology of end-user voting tools—installed on computers, cell phones, and other digital devices across the globe—this new infrastructure would facilitate a viral virtual democracy process identified as distributed voting. When integrated with the centralized management capabilities of a Voting Management Server into a Direct Democracy Framework, this process can dovetail into petitioning, registration, congress, and ratification. Such a system makes it clearly possible to represent the will of the people far more effectively than the often slow-moving voting systems that serve us today, either by providing a conduit of the people's will to existing representative governments or, where appropriate, by facilitated governance by direct democracy.

The End User Voting Tool

Envision a software tool, perhaps integrated into the email or instant messaging application in use today, that—instead of allowing recipients to respond with a message of their own—only allows them to respond in support, opposition or no opinion. Such a tool might be very handy for making extremely quick group decisions, such as where to meet our friends for dinner or whether or not to approve the latest bylaw in a home owners association. Individuals would be able to author something they would like a group or organization to decide on—here referred to as an initiative—and select recipients from their contact lists to gather their input.

Communication related to the initiative could take advantage of various communication methods including, email networks, cell phone data networks, and the Internet. Within 10 to 15 minutes, responses would begin to come back and a list of people supporting and opposing the decision would emerge. Group actions could then move forward based on the simple and democratic process driving them. Such a tool could be called simply an End User Voting Tool. It is the first of two pieces of technology that are envisioned as part of the larger concept of the Direct Democracy Framework that is discussed in this document.

Given the constraints of a tool of this nature, perhaps installed in a personal computer, a laptop computer, personal digital assistant or a cell phone, it becomes a practical solution for groups of perhaps a hundred people or less to make decisions effectively and consider those decisions final.

The Global Reach of Recursive Voting

With today's technology, a single email is sent and resent and can eventually end up arriving in millions of different inboxes. This principle can affect the reach of the End User Voting Tool if security concerns are put aside for a second. Imagine that the user interface of the End User Voting Tool includes a checkbox to allow recursive voting; when this feature is selected, users receiving an initiative have the ability to forward it on to a user list of their own choosing. Those users in turn would be able to forward it on to users of their choosing and so on. In this manner, it's possible for an initiative to spread out to vast numbers of people within a few iterations of the process. For example, if you ask 10 people to respond to an initiative, and they in turn each ask 10 more people—a process that continues for 10 cycles—the initiative in question will reach ten billion people—more than the population of our globe and far more than the practical limits of the number of people who would have access to the appropriate technology to participate in this voting tree.

The process by which people connect to the voting tree might also be accelerated by allowing users to transmit an initiative to an open forum in which other interested parties could subscribe and add themselves to the voting roster. Undoubtedly, users would also use conventional communication techniques such as email, instant messaging, chats, or just meetings over a cup of coffee to exchange dialogue about the initiatives outside the voting process itself.

New ideas could then become integrated into the process by allowing the End User Voting Tool to generate a counter-initiative (an initiative that automatically records a vote to oppose the original initiative in conjunction with a vote to support the counter-initiative) or an amended initiative (still allowing the user to record a vote of support or no opinion to the original initiative). Through the constant exchange of initiatives, counter-initiatives, and amended initiatives, the contribution of everyone in the voting tree would be absorbed to ensure that the very best available thinking is included in the final output of the process. In this process of group thinking the true benefits of the End User Voting Tool can be realized.

FIGS. 1 through 8 graphically illustrate an example of recursive voting. First, an initiative is created. In this case, illustrated is an example in which an initiative is first sent to five other users, FIG. 1. The next step involves the first-level recipients of the initiative sending back their responses, FIG. 2. In the third step in the process, once the votes have been received by the initiating end user voting tool, the vote count can automatically be sent out to the first level in the appropriate voter update packages, FIG. 3. At this point in the process, the voting cycle is completed assuming that no recursive voting is desired. For the purposes of illustration, five additional steps have been added to show how a second level is added to the voting tree. This happens when a first-level recipient initiates recursive voting (in this case, Recipient 1), FIG. 4. In the fifth step of the process, recipients in the second level of the tree can now vote. Their responses are sent back to the first level in the form of voter response packages. Although additional votes have been cast, the vote tally has not changed because the newly placed votes have not yet reached the author of the initiative, FIG. 5. The next step consists of the updates from the second level reaching the author and joining the total vote count. This step is automated. At this point, the vote tally now changes, FIG. 6. The seventh step is simply the automated update of the vote tally back to the first level, FIG. 7. Finally, in the automated eighth step, the total vote count reaches the second level, FIG. 8. The process is complete until the status of the initiative changes, any recipient in the tree chooses to change his or her vote or perhaps a recipient initiates further recursive voting.

The Five Steps of the Direct Democracy Framework and the Role of the Voting Management Server

The End User Voting Tool might be very handy if we are looking to make decisions in groups of perhaps a hundred individuals or less. However, larger groups—or even any group where we incorporate recursive voting into the system and create the voting tree previously described—may be vulnerable to fraud and corruption and may not be counted on as a final and reliable electoral process.

To solve this problem, we must combine cultural and organizational components with technology to achieve a workable solution. With that said, let's consider the possibility that the voting process we have described serves as the first of five process steps of the Direct Democracy Framework, a system to support the creation of ideas and law that any individual in the world can initiate. By creating a bright idea and asking our friends and colleagues to support it as well as allowing them to invite their own friends and colleagues to in turn support it, we have now tossed our creative energies into the ring of democratic thinking.

Step 1—Distributed Voting

We can think of this distributed voting process as the first of the five process steps in the Direct Democracy Framework. If our idea is good, then we might find that we get a large number of supporting votes; we might then decide to take the second step and submit our initiative for petition to one or more organizations.

Step 2—Petition

To create a virtual petition, we would simply check another box on our end user tool that indicates our ability to petition the initiative. In parallel, we would indicate where we are sending our petition—perhaps to a Direct Democracy Portal hosted by our local town council, our fantasy football league, or even a Global Democratic Union of Humanity. The hosting organization might also host open forums that allow initiatives to spread to users who are proactively interested in a given topic but may not have been contacted yet by someone in the voting tree for a given issue. The technical system that hosts this petition might be thought of as a Voting Management Server; it serves as the second piece of technology required in this process. In addition to hosting petitions and open forums, the Voting Management Server would also serve other purposes, some of which will be discussed later.

The petition process would be simple and similar to the paper petition process with which most people are familiar. An electronic record of the initiator's identity would be sent to the Voting Management Server while the fact that the initiative in question was now being petitioned would simultaneously be transmitted out across the voting tree created when we launched the initiative. Voters further up the tree would receive notification that the initiative they previously supported or opposed was being petitioned; they would then have the opportunity to automatically or manually sign the petition for or the petition against the initiative as well as forward the petition to the users to whom they originally forwarded the initiative.

To support large-scale petitions, Voting Management Servers would have the ability to distribute petitions across multiple servers. A small organization might host a petition on a single Voting Management Server whereas a global institution gathering millions of votes might collect the petition through hundreds or even thousands of interconnected Voting Management Servers. Over time, the petition would grow. The number of people supporting an initiative or opposing the initiative would be tracked, and the sponsoring agency would be able to make a determination—at a point it deems appropriate—to take further action, which might simply be to act on the petition immediately or perhaps move to the third step in the Direct Democracy Framework.

Step 3—Registration

In the third process step in the proposed Direct Democracy Framework, our virtual system moves into the brick-and-mortar realm and begins to mimic how representative democracy is orchestrated in our modern world. For those organizations that require authentication of user voting, such as larger governments or other large public or regulated institutions, we could ask users to register their direct democratic activities. During this process a user would physically visit a site that facilitates direct democracy registration, which could be set up at local libraries and schools and administered by competent and neutral groups—similar to those who administer voter registration in the current democratic system. In fact, the direct voter registration process and the traditional voter registration process could easily be integrated into a single activity.

Once registered, the users would then confirm, in a secure environment provided by a Voting Management Server—perhaps at a terminal located directly in the registering agencies office—all of their positions on all of the direct democratic initiatives in which they were involved. This could be facilitated in a very trouble-free manner by allowing direct democracy participants to forward their registration data ahead of time, followed by simply proving their identity and confirming their positions during the registration process itself.

Through the registration process, participants in the Direct Democracy Framework would also gain the ability to participate anonymously, as they do in most representative democracies. Their votes and petitions could be tied not to their complete identity, but to a registered voter identification that protects their privacy. Interestingly, once they have concluded the registration process, users of the Direct Democracy Framework will have voted in a system that includes all the same security and verification components of a traditional representative democracy. Instead of voting for individuals, however, they have voted for direct initiatives. The Voting Management Server could also easily produce a paper ballot during the registration process that replicates the audit trail of traditional voting systems.

Once a voter is registered, digital signature technology could be used to authenticate future voting activities in future petitions. With the third step in the process completed, the relevant agencies would again have the opportunity to act upon registered direct voting or—if a further level of validation and a final confirmation vote were required—move to the forth step.

Step 4—Congress

The next step would leverage the ability of the Voting Management Server to create a statistically valid sampling lottery and randomly select delegates. In this process, a limited number of the registered voters would be selected to appear as delegates to a congress to validate the registered vote. When attending the congress, which could be as short or as long as required and could involve as many locations and delegates as appropriate, the delegates would simply reiterate their voting positions. Through this process, a final and conclusive confirmation of the will of the people would be conducted. Perhaps only the largest of voting organizations, such as national or global direct democratic initiatives, would require a congress of this fashion.

Step 5—Ratification

Finally, we must recognize that, although a Global Direct Democracy becomes a possibility with the implementation of the Direct Democracy Framework, it will not emerge overnight. In fact, many decades may pass before the Direct Democracy Framework serves as the primary tool of government anywhere. But, even during this period, the Direct Democracy Framework will be able to provide an infrastructure that supports and enhances the democratic process throughout the world. As such, the fifth and final step of the Direct Democracy Framework—ratification—is critical. It is in this step that the parallel existence of direct democracy and representative democracy is facilitated.

During ratification the appropriate conventional government bodies and non-governmental entities would confirm the legitimacy of the initiatives sent to them through the direct process and write into law the process by which these initiatives would be enforced. Ratification might take place by individual legislative voting on each initiative, gaining sufficient momentum to warrant inclusion into law, or it might take place by constitutional process, whereby a government defines criteria such as the percentage of the voting population that has voted on an initiative, the percentage of supporting votes, and the longevity of the initiative as criteria for automated ratification.

Of course, not all of these steps are mandatory. It would depend on the particular protocols of the organization in question as to what steps were required. In the case of initiatives seeking to become global law, all five steps would likely take place.

End User Voting Tool: Requirements Definition

The End User Voting Tool is the tool responsible for the first step in the Direct Democracy Framework process; the distributed voting and more importantly, is the tool that each individual user of the framework uses to create, send and view initiatives as they move through the process. It is therefore important to document the core functionality of this tool that is used to implement the Direct Democracy Framework. The following table defines those features:

Functional Requirements

Name	Description	Implementation Notes
Create	The user should be able	See below flowcharts (9),
Initiative	to create and edit a direct	(10), (11), (13), (15)
	democracy initiative a
	manner that is as intuitive
	and easy as composing
	an email then (optionally)
	send the initiative out to
	selected recipients
Edit Initiative	The user should be able	See below flowcharts (9),
	to find and edit an	(12), (13), (14), (15)
	existing direct democracy
	initiative a manner that is
	as intuitive and easy as
	updating a draft email
	then (optionally) send the
	initiative out to selected
	recipients
Send Initiative	The user should be able	See below flowcharts (9),
	to find and send an	(12), (13), (15)
	existing direct democracy
	initiative a manner that is
	as intuitive and easy as
	sending a draft email
Vote on	The user should be	See below flowcharts (9),
Initiative	receive a sent direct	(20), (21), (13), (17), (18)
	democracy initiative and
	vote on it in a manner as
	intuitively as responding
	to an email the
	resulting information
	should be sent back to
	the original author of the
	initiative
View Vote	The user should be able	See below flowcharts (9),
Tally	to find a direct	(12), (13)
	democracy initiative and
	review the current vote
	tally
Send Initiative	The user should be able	See below flowcharts (9),
(Recursive)	to find and send an	(12), (13), (15)
	existing direct democracy
	initiative to additional
	users (if permitted by the
	author)
	in a manner that is as
	intuitive and easy as
	forwarding an email
Petition	The user should be able	See below flowcharts (9),
Initiative	to petition an initiative	(20), (22), (19), (26)
	either automatically
	based on achieving a
	certain voting Quorum or
	manually through an
	easy confirmation
	process
Sign Petition	A user who has	See below flowcharts (9),
	previously voted on an	(20), (23), (28)
	initiative which has
	subsequently been
	petition should be send a
	signature to the petition
	in an intuitive way
Create and	The user should be able	See below flowcharts (9),
Send Counter	to attach existing	(10), (11), (13), (15)
Initiatives and	initiatives to an existing
Amended	initiative and, in the case
Initiatives	of counter initiatives,
	automatically register
	a vote against them
Vote on	The user should receive	See below flowcharts (9),
Initiatives	a sent direct democracy	(20), (21), (13), (17), (18)
including	initiative together with
Amended and	attached initiatives and
Counter	be able to vote on all
Initiatives	initiatives in the
	package
Set, Update	The user should be able	See below flowcharts (9),
and Maintain	to set, update and	(10), (24)
User	maintain user profile
Profile	information and
Information	automatically generate
	the appropriate updates
	and
	messages to associated
	Voting Management
	Servers

End User Voting Tool: Message Data Structures

The end-user voting tool technically enhances the typical email client software tool in a similar manner as a calendar software package enhances the same solution. A calendar tool adds specific message types, such as calendar event invitations and calendar event replies, adds a user interface to view and edit the user's calendar and then defines underlying process by which those elements interact; similarly, the end-user voting tool adds specific message types that can be sent, an associated end-user interface and certain new underlying processes. The new message types defined are either utilized in response to the end user's direction or driven by the automation within the end-user voting tool (described later in this document).

The discussion of these message types is critical to technically defining the framework. Three specific message types are required and used by the End User Voting Tool during the distributed voting process, with additional ones needed by the Voting Management Server and interaction with it. The message types needed by the End User Voting Tool are: Initiative Packages, Voter Response Packages, and Voter Update Packages. It should also be noted that in addition to being sent between End User Voting Tools, these message packages form the records within the internal database structure of the End User Voting Tool. Referred to as the repository this database stores all the required information the tool needs to function. The following sections will examine these three message types and in further detail.

Initiative Package

The Initiative Package is a message generated by the end-user voting tool when the original author starts the process of gathering votes on a Direct Democracy Framework initiative. The user enters the data of choice into a user interface screen that looks similar to an email program's “send message” screen. The specific look and feel of the screen is defined by the specific software developer. The Initiative Package can also be resent by other users when recursive voting is employed (described in more detail below). However, under these circumstances, unlike email, the Initiative Package cannot be altered, merely forwarded with changes made only to certain fields.

The package support, the inclusion of the following data:

Data
Element Name	Type of Data	Implementation Notes
Message Type	System-defined indicator	Generated by the system
	states that this is an	when the user selects the
	Initiative Package	option to
		send or resend an
		initiative
Initiative ID	A unique identifier for the	Includes sufficient data to
	initiative	ensure it is always a
		unique
		number and can never be
		duplicated by any other
		end-user
		voting tool at any time this
		field never changes after
		creation
Title	String field labeling the	Entered by author and
	initiative	does not change after the
		author
		sends the initiative
		making it active
Content	Appropriate content data	Written by original author,
	in various formats, such	the content cannot be
	as Text, HTML,	changed
	Rich Text	once the initiative is sent
		by the author making it
		active
Date/Time Sent	Date and Time	Automatically generated
	Information	by the tool does not
		change after
		the initiative is first sent by
		the author
Recipients	List of the recipients of	Selected by author or
	the initiative	sender; can also include
		forums or
		mailing lists and it only
		includes the immediate
		recipients of
		the message; previous
		recipients in recursive
		voting are not
		included meaning that this
		field is cleared and
		repopulated
		with new recipients each
		time resent
Attachments	File attachments	Any additional documents
		needed and cannot be
		added or
		deleted once initiative is
		sent and made active.
		Related
		initiatives can be attached
		as required
Recursive	An integer between zero	Entered by the user to
Voting Levels	and unlimited	control recursive voting
Permitted		cannot be changed once
		the initiative is
		sent by the author
Recursive	An integer between zero	Identifies the number of
Voting Levels	and unlimited	levels removed from the
Used		original
		author of the initiative and
		used to control the growth
		of the
		tree on recursive voting
		this field automatically
		increases by one each
		time the
		initiative is received by
		another level in the voting
		tree
Sender	Sender's	Automatically
	electronic contact	added by the system, is
	address (typically email)	the author the first
		time the system is sent,
		changes when the
		initiative is sent
		recursively with the
		original sender being
		stored to the
		repository and associated
		to this initiative, facilitating
		the
		delivering of Voter
		Response Packages to
		the correct sender
Author	Author's electronic	This field would be
	contact address (typically	different than the sender
	email)	in the case of
		recursive voting and is an
		optional field it would not
		change
		once the initiative is sent
		by the author
Voting	Date and time	Indicates the time by
deadline	information	which a response is
		required to be
		included in the vote
Minimum	A time period ranging	Defines the amount of
Update	from zero or instant to	time that a responder has
Response	some upper limited—	to wait in
Delay	most likely no more than	order to send an updated
	a few hours	Voter Response Package
		after
		sending the first response
		package; this is used to
		manage
		data transmission
		requirements of the
		framework
Digital	Boolean field that	Optional feature that may
Signature	indicates whether a	be implemented in some
Required	digital signature is	versions
	required or	of the software
	not in the response
Required	A field that identifies the	Selected by the author
Memberships	membership(s) that are	and linked to membership
	required in order to	certificates
	vote in this particular	issued by a Voting
	initiative	Management Server this
		field would not
		change after being sent
		by the author
Required	A fields that identifies the	Security certificates would
Security	security certification(s)	be issued by Voting
Certifications	required in order	Management Servers
	to vote on this	based on security scans
	initiative	and software
		updates performed by the
		Voting Management
		Server this
		field would not change
		after being sent by the
		author
Attached	Boolean field that	Created by author when
Initiatives	identifies whether or not	the initiative is created
	this initiative has any	would not
	attached initiatives or	change after being sent
	not.	by the author
Voter Update	The initial Initiative	All data included in the
Data	Package, also contains a	Voter Update when the
	complete copy of the	initiative is
	Voter Update Package	first sent out subsequently
		Voter Update Packages
		are sent
		by themselves to avoid
		resending redundant data
Allow	Identifies whether a	Used for large initiatives
secondary	petition can be sent to a	to allow distribution of
petition servers	users own preferred	petition
	petition server or not	data across a large
		number of servers,
		secondary servers can
		link into the primary
		petition servers (see
		below).
Other Data	As needed	As defined and required
		by the specific software
		developer

Voter Response Package

When the Initiative Package is received by another End User Voting Tool, the recipient sees the initiative in a very similar manner as when viewing a normal email. However, instead of allowing the recipient to respond to the initiator with a message of his or her own, the tool only allows the recipient to respond in support, in opposition, or with no opinion. (Other voting formats may be supported as well, but they are not discussed in detail here.) The Voter Response Package is the message that is sent back, either in response to the user making or changing the vote or in response to incoming recursive voting.

Thus, it can be sent either by the user or automatically. At a minimum, it supports the inclusion of the following data:

Data
Element Name	Type Data	Notes
Message Type	System-defined indicator	Generated by the system
	that this is a Voter	when the user selects the
	Response Package	option to send a certain
		response
Initiative ID	A unique identifier for the	Is linked to the original
	initiative
Date/Time Sent	Date and time	Automatically generated
		by the tool
Sender	Sender's electronic	Automatically added by
	contact address, in this	the system
	case the recipient of the
	initiative who is
	responding (typically
	email)
Voter Response	Selection as determined	Automatically added by
	by the voting format of	the system
	the initiative
Digital Signature	Optional field providing	May not be supported by
	the digital signature of the	all versions of the
	sender	software
Recursive Votes	An integer between zero	Tallies up the additional
Supporting	and a ten-digit number	votes received through
Initiative		recursive voting and
		sends them on to the
		next level
Recursive Votes	An integer between zero	Tallies up the additional
Not Supporting	and a ten-digit number	votes received through
Initiative		recursive voting and
		sends them on to the
		next level
Required	A field that confirms the	Linked to membership
Membership	membership(s) that are	certificates issued by a
Certificates	required in order to vote	Voting Management
	in this particular initiative	Server
Required Security	A fields that confirms the	Security certificates
Certificates	security certification(s)	would be issued by
	required in order to vote	Voting
	on this initiative	Management Servers
		based on security scans
		and software updates
		performed by the Voting
		Management Server
Petition Status	A field that records	Managed automatically
	whether the petition	by the tool based on
	status for each petition of	outbound and inbound
	this Initiative for this user	messages to the Voting
	status would be not-sent,	Management Server
	sent, confirmed
Other Data	As needed	As defined and required
		by the specific software
		developer

Voter Update Package

The third and final message type required to support the distributed voting step in the Direct Democracy Framework is the Voter Update Package. This message type is automatically generated by the End User Voting Tool when the votes tally or status of the initiative changes. Its purpose is to keep all recipients of the initiative updated in regards to the total vote of the initiative. It is therefore resent by all users who have participated in recursive voting to their own recipients. It also supports the petition process (described later). It contains the following data:

Data
Element Name	Type Data and Notes	Notes
Message Type	System-defined indicator	Automatically generated
	that is a Voter Update	by the tool periodically as
	Package.	updates are necessary
Initiative ID	A unique binary identified	Is linked to the original
	for the initiative
Date/Time Sent	Date and time	Automatically generated
		by tool
Sender	Sender's electronic	Automatically added by
	contact address—in this	the system
	case, the sender of the
	initiative or the recipient
	one level up who is
	resending via recursive
	voting (typically email)
Total Votes	An integer between zero	Tallies up the total votes
Supporting	and a ten-digit number	received through all
Initiative		voting and sends that
		number out to all
		recipients
Total Votes	An integer between zero	Tallies up the total votes
Not	and a ten-digit number	received through all
Supporting		voting and sends that
Initiative		number out to all
		recipients
Voting Status	Identifies the current	Automatically managed
	voting status of the	by the voting process
	initiative as draft (cannot	from the
	yet be voted on), active	author's End User Voting
	(open for voting) or	Tool
	closed (voting is
	completed)
Petition Status	Like the voting status, the	Either modified manually
	petition status determines	when the initiative is
	where the petitioning	petitioned or
	process stands statuses	automatically when the
	include pre-petition,	quorum is reached
	petition in progress,
	petition-closed
Registered	Like the voting status, the	Controlled by the
Voting Status	registered voting status	sponsoring agency
	determines where the	through the Voting
	registered voting process	Management Server
	stands statuses include
	pre-registered voting,
	registered voting in
	progress, registered
	voting-closed
Extended	A selection field that	Software developers
Initiative	indicates additional	need to define standards
Status	status information about	for the types of initiative
	the initiative (extended	status their version
	status types might	supports.
	include options such as
	in-process, passed,
	cancelled, expired, in
	congress, pending
	ratification, and ratified.)
Petition	Contains a list of	Is defined by the author,
Location(s)	locations of Voting	if he or she wishes to
	Management Servers to	submit a successful
	which the initiative has	initiative to some type of
	been petitioned	organization for
		consideration
Quorum	Integer	The total number of votes
		required before a
		initiative is considered
		valid. Maybe used to
		automatically trigger a
		petition.
Other Data	As needed	As defined and required
		by the specific software
		developer

By incorporating all three of these voting packages into a recursive voting process, we can reach any size of audience in a relatively trouble-free manner.

End User Voting Tool: User Configuration

In addition to retaining message data regarding initiatives, the repository also stores certain information that controls the function of the End User Voting Tool. This is referred to as configuration data. The following table defines the configuration data needed to implement the core functionality of the End User Voting Tool:

End User Voting Tool Configuration Elements

Data
Element Name	Type Data and Notes	Notes
Owner Contact	Contains multiple fields	Linked to the contact
Data	recorded appropriate	database so that user
	data about the owner	data can easily be sent
	such as name, address,	as appropriate
	phone number, email
	address, etc
Membership(s)	Lists organizations and	Links to Voting
	the associated Voting	Management Servers for
	Management Servers	Petitions and Registered
	for which the end user is	Voting
	registered or is
	registering each
	organization listed would
	include a current
	membership status such
	as applied, accepted,
	registered, not-active
Minimum	The setting that	Initially defined by the
Required Delay	determines the delay	user, would be very low
Setting	setting associated with all	for high
	outbound initiatives and	performance server
	defines the delay setting	based End User Voting
	for outbound voter	Tools and very high for
	responses and voter	low bandwidth devices
	updates
Auto Display	Determines whether or	Set by the user
Setting(s)	not user automatically
	votes on inbound
	initiatives automatically
	displays inbound
	initiatives and if initiatives
	that have just been voted
	on are displayed
Auto Petition	Defines whether or not	Set by user
Settings	the user automatically
	submits petitions
	signatures or should be
	requested by the tool to
	send petition
	signatures
Default	Initiative Template	Multiple templates can be
Initiative Data	defines the default field	supported
	entries for a newly
	created initiative
Preferred	Identifies a location	Set by user
Petition Server	where Petition signature
	are sent when a
	preferred or secondary
	petition signature server
	is allowed
Other Data	As needed	As defined and required
		by the specific software
		developer

End User Voting Tool: Additional Notes

Having discussed the requirements of the End User Voting Tool, the core data structures it uses (with additional structures defined below), and the process flow utilized, it is important we close the discussion of this component of the Direct Democracy Framework by notating some other important aspects of this tool.

Data Transmission Capacity Management

An important issue addressed is the accumulation of massive amounts of data being generated if recursive voting allowed all data associated with an initiative—including every user's identification data and vote—to be passed on through the voting tree. Therefore, to protect both the users' privacy and the technical viability of the system, as the earlier example and data structures indicate, we limit the size of the Voting Response Package to only the most critical data. Initiators receive the votes of all users to whom they sent the initiative directly as well as the total tally of all the votes collected. They do not receive a complete list of all voters as such a list could not be built until the petition and registration process of the Direct Democracy Framework (described below).

Data Transmission Frequency Management

Another issue addressed is the impact that even small Voter Response Packages might have on the communications network if the frequency of their transmission rate is too high. This problem is alleviated through simple response delays incorporated into the tool. For example, requiring a 10-minute delay before an updated Voter Response Package or Voter Update Package is transmitted would significantly reduce the quantity and frequency of packages being sent across the communications network. This time delay could be defined by the end user based on the resources available and impact to the system and network in which the end-user voting tool is being operated. An end-user voting tool embedded in a high performance server might not need such a delay, whereas an end-user voting tool sitting on a cell phone might be best served by a long delay. All recipients of an initiative would be notified of the minimum delay associated with the sender's device and would set the delay for that initiative to the higher value of their own delay setting and the setting of the initiative.

Even with this delay mechanism included, a massive volume of users can be reached and the most distant response would still arrive in a matter of hours. Most would agree this is a very reasonable amount of time to begin gathering millions—or even billions—of votes from across the globe. Such heartbeat control of the frequency of transmissions would consequently reduce network load significantly.

Voting Frequency Management

The end-user voting tool ensures that a user can only vote on an issue once by tracking the unique initiative identification and the identity of the user who sent the initiative to users. Subsequent attempts by others to reach the same user on that initiative result in a response that signals the user previously supported, opposed, or indicated no opinion; this process occurs in the background so users are not bothered by seeing the same initiative repeatedly unless they choose to review the initiative again and change their response.

Broken Voting Tree Branch Management

Finally, the last issue to note that we have tackled above involves determining what happens when a branch of the voting tree becomes broken or disconnected—a problem that results in the downstream recursive voting portion of the voting tree linked to the disconnected recipient not being able to reach the initiator so that a complete and accurate tally of the votes is maintained. In determining an approach to this challenge several approaches were reviewed.

One approach is simply to allow broken branches to continue to grow as they normally do and recognize that—like any distributed system—our voting tree will be imperfect. Ultimately, a strong initiative that reaches the petition or registration phase carries a certain media awareness with it that enables users who become disconnected and do not hear about the petition through the voting tree to become informed about what was happening and send in their petitions anyway.

Another approach is to rely on the timestamp of the Voter Update Package sent from the initiating end-user voting tool. We can subsequently restrict recursive voting to being initiated only after an indication is received down the voting tree that determines the original vote has most likely already been tallied. This can be done by waiting to send out recursive votes until the timestamp of the latest Voter Update Package has aged by at least the send delay setting multiplied by the number of levels removed from the initiator. This control mechanism could stunt the growth of any broken branches of the voting tree until the breach is reconnected, thereby preventing new users from becoming connected to the broken branch of the tree. This method is discussed in more detail below.

Finally, perhaps the most complicated method for handling broken branches involves allowing those areas of the voting tree to reconnect to the tree through an alternate path. This could be facilitated by allowing open forums built into the voting tree to be passed down the voting tree. With this information, a branch that is unable to pass its tally up could instead connect to any of the listed open forums and pass its tally up that way. The part of the tree that has lost the branch could, after a certain period of time, remove the tally of the disconnected branch from its own tally. As a result, the vote count is correctly maintained while reaching the initiator through a different route.

Calculating Distribution Timeframes

An interested technical aspect of recursive voting to explore is the timeframes required for a tree to grow, which can be performed by analyzing the method of broken branch management we chose to use and then determining the number of levels in the tree in question. For example, as we have used the Voter Update Package timestamp method to control the growth of the tree, the time required for each layer to be added to the tree is calculated as follows:

Time to add level=Time Delay Setting×(1+(total levels in tree×2))

By utilizing this formula, we can develop the following table defining the time required to build voting trees based on the number of levels in the tree:

	Approximate Average
	Recipients per Send to	Time Required to Build
	Reach Ten Billion	Tree based on 10-
Tree Levels	Voters	Minute Response Delay
1	Ten Billion	10 Minutes
2	100,000	1 Hour
3	2,000	2 Hours, 10 Minutes
4	300	3 Hours, 40 Minutes
5	100	5 Hours, 30 Minutes
6	47	7 Hours, 40 Minutes
7	27	10 Hours, 10 Minutes
8	18	13 Hours
9	13	16 Hours, 10 Minutes
10	10	19 Hours, 40 Minutes

As this table indicates, this methodology enables us to reach the entire world's population—even if each sender is only contacting an average of ten recipients in less than a day. This is the amazing power of recursive voting.

Voting Management Server: Requirements Definition

To recap the role of the Voting Management Server it is the tool responsible for the second through fourth steps in the Direct Democracy Framework process the; petition, registration and congress and also provides a server based version of the End User Voting Tool. It is therefore critically important to document the core functionality of this server system that is required to implement the Direct Democracy Framework. The following table defines those features:

Functional Requirements

Name	Description	Implementation Notes
Web based End	The Voting Management	See End User Voting
User Voting Tool	Server must provide a	Tool flowcharts
functionality	multi user web based
	End User Voting Tool
	environment that is
	intuitive and provides all
	the functionality
	discussed above
Register Users	The Voting Management	See below flowcharts (9),
	Server administrator	(10), (13), (17), (18)
	must be able to accept
	and approve requests for
	membership(s) on the
	Voting Management
	Server
Create New	The Voting Management	See below flowcharts
Petitions	Server administrator	(9), (10), (14), (17), (19)
	must be able to accept
	and approve requests for
	petitions from existing
	members either
	automatically or by
	manual approval
Receive and Accept	The Voting Management	See below flowcharts
Petition	Server administrator	(9), (17), (20)
Signatures	must be able to accept
	and approve requests for
	petitions from existing
	members either
	automatically or by
	manual approval
Register Initiative	The Voting Management	See below flowcharts
	Server administrator	(9), (10), (14)
	must be able to assign
	an existing petitioned
	initiative into the voter
	registration process
	either automatically or by
	manual approval
User Registration	The Voting Management	See below flowcharts (9),
	Server administrator	(10), (13)
	must be able to accept
	the in-person identity
	verification of users and
	assign them registered
	status
Registered Voting	The Voting	See End User Voting
	Management Server	Tool flowcharts
	administrator must be
	able to grant access to
	End User Voting Tool
	functionality in a secure
	location to
	allow users to re-vote in
	a secure registered
	environment
Congress Selection	The Voting Management	See below flowcharts
	Server administrator	(9), (10), (14)
	must be able to assign
	an existing registered
	initiative for selection of
	delegates for a
	congress
Congressional	The Voting Management	See End User Voting
Voting	Server administrator	Tool flowcharts
	must be able to grant
	access to End User
	Voting Tool functionality
	in a secure location to
	allow users to re-vote in
	a secure registered
	environment during a
	congress
Delegate Check-in	The Voting Management	See End User Voting
	Server administrator	Tool flowcharts
	must be able to accept
	the in-person identity
	verification of delegates
	and assign them
	check-in status during a
	congress
Ratify Initiative	The Voting Management	See below flowcharts
	Server administrator	(9), (10), (14)
	must be able to assign
	an existing
	registered initiative into a
	ratified status
Create New Forums	The Voting Management	See below flowcharts
	Server administrator	(9), (10), (12)
	must be able to accept
	and approve requests for
	open forums from
	existing members either
	automatically or by
	manual approval
Manage Existing	The Voting Management	See below flowcharts
Users	Server administrator	(9), (10), (13), (22)
	must be able to search
	for an update existing
	user profiles including
	security access,
	membership, forums and
	profile data
Manage Existing	The Voting Management	See below flowcharts
Groups	Server administrator	(9), (10), (12)
	must be able to search
	for an update existing
	groups including security
	access, membership,
	forums and profile data
Manage Existing	The Voting Management	See below flowcharts
Petitions	Server administrator	(9), (10), (14)
	must be able to search
	for an update petitions
	including status
Manage Existing	The Voting Management	See below flowcharts
Forums	Server administrator	(9), (10), (15)
	must be able to search
	for an update existing
	Forums including
	Initiative Status

Voting Management Server: Message Packages

In this section of the document we will describe all the data structures of the message types that are used when interacting with the Voting Management Server. There are in all eight message packages that we need to discuss and they are as follows:

Voting Management Server Membership Request Package

The Voting Management Server Membership Request Package is sent by an End User Voting Tool to request a user be added, group be added or membership status of a user be changed. It is sent automatically by the End User Voting Tool in response to the user making changes to the user configuration. The package supports, at a minimum, the inclusion of the following data:

Data Element Name	Type Data and Notes	Notes
Message Type	System-defined indicator	Automatically generated
	that is a Voter	by the tool based on End
	Management Server	User
	Membership Request	Voting Tool user
		configuration changes
User Contact Data	Contains multiple fields	Linked to the contact
	recorded appropriate	database from End User
	data about the owner	Voting Tool
	such as name, address,
	phone number, email
	address, etc
Membership(s)	Lists organizations and	Groups would be
	the associated Voting	configured on the Voting
	Management Server for	Management Server
	which the end user is
	requesting a membership
	or status change
Status Request(s)	Specifies the status	Would then be validated
	change requested such	by the administrator of
	as application, extension,	the Voting Management
	cancelation, etc	Server
Time and Date	Time and Date of	Generated by End User
	Request	Voting Tool when sent to
		Voting Management
		Server
Certificates	Attaches any security	Provided by this or other
	certificates that may be	Voting Management
	required to get	Servers
	membership
Digital Signatures	Attaches digital	Provided by this or other
	Signatures if required	Voting Management
		Servers
Other Data	As needed	As defined and required
		by the specific software
		developer

Voting Management Server Membership Request Response Package

The Voting Management Server Membership Request Response Package is sent by the Voting Management Server either automatically when a Voting Management Server Membership Request Package is processed by the server, or when the server administrator manually responds to the request. The package supports, at a minimum, the inclusion of the following data:

Data Element Name	Type Data and Notes	Notes
Message Type	System-defined indicator	Generated by Voting
	that is a Voter	Management Server
	Management Server	based on either
	Membership Request	automated membership
	Response	assignment or
		Administrator
		authorization
Membership(s)	Lists organizations and	Groups would be
	the associated Voting	configured on the Voting
	Management Server for	Management Server
	which the end user is
	requesting a membership
	or status change
Status Request	Specifies status change	Would then be validated
	granted or denied in this	by the administrator of
	response	the Voting Management
		Server
Time and Date	Time and Date of	Generated by Voting
	Request	Management when sent
		to End User Voting Tool
Certificates	Attaches any security	Provided by this Voting
	certificates assigned as	Management Servers
	part of this process
Other Data	As needed	As defined and required
		by the specific software
		developer

Voting Management Server Petition Request Package

The Voting Management Server Petition Request Package is sent by the End User Voting Tool either automatically when an initiative passes its quorum or manually at the request of an end user. It is the step that progresses an initiative from step one to step two in the Direct Democracy Framework Process. The package supports, at a minimum, the inclusion of the following data:

Data
Element Name	Type Data and Notes	Notes
Message Type	System-defined indicator	Generated by End User
	that is a Petition Request	Voting Tool either
		manually or automatically,
		when Quorum is achieved
		in voting numbers
Initiative	The complete Initiative	Provided by the End User
Package	Package being petitioned	Voting Tool as part of the
		Petition Request
Time and Date	Time and Date of Petition	Generated by End User
	Request	Voting Tool at time of
		send
Other Data	As needed	As defined and required
		by the specific software
		developer

Voting Management Server Petition Request Response Package

The Voting Management Server Petition Request Response Package is sent by the Voting Management Server either automatically when a Voting Management Server Petition Membership Request Package is processed by the server, or when the server administrator manually responds to the request. The package supports, at a minimum, the inclusion of the following data:

Data
Element Name	Type Data and Notes	Notes
Message Type	System-defined indicator	Generated by Voting
	that is a Petition Request	Management Server
	Response	either
		automatically or at the
		request of the
		Administrator
Initiative	The id of the Initiative in	Provided by the End User
Package id	question	Voting Tool as part of the
		Petition Request
Time and Date	Time and Date of Petition	Generated by Voting
	Request	Management Tool at time
		of send
Status	Status of Petition as a	Generated by Voting
	result of this request	Management Server
		either
		automatically or at the
		request of the
		Administrator
Other Data	As needed	As defined and required
		by the specific software
		developer

Voting Management Server Petition Signature Package

The Voting Management Server Petition Signature Package is sent by the End User Voting Tool either automatically when the End User Voting Tool receives and processes a Voter Update Package that indicates the initiative has gone into petition or manually at the request of an end user. The package supports, at a minimum, the inclusion of the following data:

Data
Element Name	Type Data and Notes	Notes
Message Type	System-defined indicator	Generated by End User
	that is a Petition	Voting Tool when user
	Signature	signs
		petition
Initiative	The id of the Initiative in	Provided by the End User
Package id	question	Voting Tool as part of the
		Petition Request
Time and Date	Time and Date of Petition	Generated by
	Request	Voting Management Tool
		at time of send
Vote	Indicates whether	Generated by End User
	Signature opposes or	Voting Tool when the user
	supports initiative	signs the
		petition
Certificates	Contains any security	Generated by this or other
	certificates that were	Voting Management
	required to authenticate	Servers
	signature to this server	originally
Other Data	As needed	As defined and
		required by the specific
		software developer

Voting Management Server Petition Signature Response Package

The Voting Management Server Petition Signature Response Package is sent by the Voting Management Server when a Voting Management Server Petition Signature Request Package is acknowledged. The package supports, at a minimum, the inclusion of the following data:

Data
Element Name	Type Data and Notes	Notes
Message Type	System-defined indicator	Generated by Voting
	that is a Petition	Management Server
	Signature Response	automatically
Initiative	The id of the Initiative in	Provided by the End User
Package id	question	Voting Tool as part of the
		Petition Request
Time and Date	Time and Date of Petition	Generated by Voting
	Signature Request	Management Tool at time
	Response	of send
Confirmation	Provides confirmation of	Generated by Voting
	whether signature	Management Server
	opposes or supports	when the user signs the
	initiative	petition
Other Data	As needed	As defined and required
		by the specific software
		developer

Voting Management Server Petition Link Request Package

The Voting Management Server Petition Link Request Package is sent from one Voting Management Server to another when a petition is sent to a preferred Voting Management Server during a petition process. The package supports, at a minimum, the inclusion of the following data:

Data
Element Name	Type Data and Notes	Notes
Message Type	System-defined indicator	Generated by Voting
	that is a Voting	Management Server
	Management Server	automatically
	Petition Link Request
	Package
Initiative Package	The id of the Initiative in	Provided by the End User
id	question	Voting Tool as part of the
		Petition Request
Time and Date	Time and Date of Voting	Generated by Voting
	Management Server	Management Tool at time
	Petition Link Request	of send
	Package
Server Address	Information identifying	Generated by Voting
	the server that is	Management Server
	requesting the petition	when it sends the
	link	Package
Other Data	As needed	As defined and required
		by the specific software
		developer

Voting Management Server Petition Link Request Response Package

The Voting Management Server Petition Link Request Response Package is sent from one Voting Management Server to another when a petition is sent to a preferred Voting Management Server during a petition process. It confirms receipt of the link. The package supports, at a minimum, the inclusion of the following data:

Data
Element Name	Type Data and Notes	Notes
Message Type	System-defined indicator	Generated by Voting
	that is a Voting	Management Server
	Management Server	automatically
	Petition Link Request
	Response Package
Initiative Package	The id of the Initiative in	Provided by the End User
id	question	Voting Tool as part of the
		Petition Request
Time and Date	Time and Date of Voting	Generated by Voting
	Management Server	Management Tool at time
	Petition Link Request	of send
	Response Package
Confirmation	Information confirming	Generated by Voting
	(alternatively denying)	Management Server
	the link to the petition	when it sends the
		Package
Other Data	As needed	As defined and required
		by the specific software
		developer

Voting Management Server: Server Configuration

In addition to retaining message data regarding initiatives, the Voting Management Server repository must also store certain information that controls the function of the Voting Management Server. This is referred to as server configuration data. The following table defines the configuration data needed to implement the core functionality of the Voting Management Server:

Voting Management Server Configuration Elements

Data Element Name	Type Data and Notes	Notes
Auto Process	Multiple fields that	Enter by Voting
Setting(s)	defined whether requests	Management Server
	for new users, new	administrator to define
	groups and new group	how the server should
	membership requests are	react to inbound
	approved automatically,	messages
	denied automatically or
	manually processed
Other Data	As needed	As defined and required
		by the specific software
		developer

The following notes apply to the above Voting Management Server flowcharts:

(a) The Forum Manager is a session of the End User Voting Tool running automatically, so that the Forum itself votes “no opinion” on all received initiatives, and automatically sends recursive voting to every member of the group associated with the Forum.

Additional Features (Not Included in Documented Core Functionality)

As the technical overview is now complete, it is of value to spend some time discussing the additional technical capabilities provided by the Direct Democracy Framework. Although these capabilities are not discussed in detail here, a few examples are introduced in order to demonstrate the potential flexibility of this system.

Integration and Automation

An important capability of the Direct Democracy Framework is its ability to automate the interactions of other technologies. Such integration uses APIs for the end-user voting tool and the Voting Management Server, which enables the framework to define potentially complex voting rules (e.g., unanimous support or majority support combined with a yes vote of named key stakeholders) with other technologies to automate certain key processes.

A simple scenario might be the automated scheduling or cancelation of a calendar event, based on the approval or disapproval of attendees, or a local government that proactively implements democratically controlled electronic speed limits on local streets. Another far more serious scenario might be the automated activation of lethal force capability with the unanimous vote of a set of well-trained security officers monitoring an emerging security threat. As military forces around the world increasingly rely on unmanned combat systems, such capabilities might become critical.

Weighted Voting

Another powerful feature for the Direct Democracy Framework could be the implementation of weighted voting. This feature would work by allowing the author to designated an initiative as a weighted initiative then apply a particular percentage weight to each recipient. When recursive voting is utilized, the percentage assigned to a particular recipient could then be broken down by that recipient to their own list of recipients.

Such a feature might be very valuable in the financial services industry where the voting on a particular issue is weighted by the number of shares or percentage of ownership. A given public company could send a stockholder initiative to all shareholders, then if a given stockholder happened to be a mutual fund, that fund could then forward to fund member based on the number fund shares they owned.

Variable Format Voting

Although the greatest value of the Direct Democracy Framework might be its ability to enable voting on issues in a simple support/do not support/no opinion format, nothing is preventing the framework from enabling additional voting formats. Multiple-choice surveys or multi-question initiatives could be added through a custom voting format configured by the initiative author or selected from a group of templates. In such a scenario, information for articulating the custom voting format would be sent along with the initiative for each end-user voting tool receiving it to decode and present information to the voter in the appropriate format.

Bundled Initiatives

Another important technical feature of the Direct Democracy Framework is its ability to bundle initiatives together. It may be important for a user to receive not only the initiative, but also other initiatives linked to it. Through this mechanism, the Direct Democracy Framework supports the amended initiatives and counter-initiatives discussed in the original document.

Initiative Templates

The technical concept of an initiative template consists of a standard format for the creation of an initiative. This could include the formatting of content, allowable attachments, pre-defined quorum required and other attributes. Templates could be created by organizations that participate in the direct democracy framework and could be designed to facilitate easier petition, registration and ratification processing of the initiative in question.

Dynamic Initiatives

A dynamic initiative would be one that focuses not on achieving an accurate vote at a certain point in time, but rather tracking a vote over a specific period of time. This would be implemented by allowing the End User Voting Tool to either record each individual transaction, or just recording the vote tally periodically at given time intervals. An example of a dynamic initiative might be one for example that tracks the approval rating of a certain political figure over time.

Vote Transaction Audit Trail

It is also a possibly valuable addition to the end user voting to permit it to track activities that the end user performs. This might be critical in highly secure or regulated voting environments. The voting activity audit trail could also be a source of data to create dynamic initiatives.

End User Voting Tool Replication, Backup and Software Updates

For users who wish to take advantage of the performance security and redundancy that can be built into an End User Voting Tool embedded into a voting management server, yet also take advantage of the convenience of a client device based End User Voting Tool, the Direct Democracy Framework could allow the configuration of replicated End User Voting Tools.

In this structure, one or more End User Voting Tools could be configured to manage the data associated with a single user and automatically forward data sent and received from each copy of the software to each other. This might be thought of as something very similar to the email configuration of someone using both an email server and a client based device to access the same email account.

This capability could easily be expanded to support the backup of data on an End User Voting Tool and the updating of the software on those tools.

Content Management

Another important role provided by the Voting Management Server is to store a repository of initiatives and their associated attachments that have been submitted to it—either in its forums or by petition—and their status.

This would form a searchable database that would also be capable of automatically updating itself based on voter activity and date changes. Effective dates and expiration dates could be employed to automatically change the status of an initiative. This creates a virtual ‘book of law,’ allowing users to search and review proposed, current, and obsolete laws for a given institution or government.

In addition, when the web based End User Voting Tool is employed, the content management features of the Voting Management Server can help make much more efficient use of storage space and vastly accelerate the time required to distribute initiatives through the use of a centralized content repository.

In this scenario, Initiative Packages would have key data elements such as content and attachments replaced by pointers to a centrally managed content repository. This would mean that any given attachment or content component that was references many times by initiatives on the server would only have to exist once. An initiative could be written and sent to hundreds or even thousands of users, and the content would only need to be replicated when a user whose End User Voting Tool did not reside on the server itself received the initiative.

These content management capabilities leverage the existing technologies associated with internet-based content management.

Subscriber Notifications

In addition to subscribing to open forums, users of the Direct Democracy Framework would also be able to create profiles on the Voting Management Servers allowing them to receive initiatives of their choosing. This might include any initiative submitted to an open forum, only initiatives that are petitions, only registered initiatives or perhaps even only initiatives having gained a certain level of votes, petition signatures, or registered votes.

Enforcing Security

The primary purpose of the five steps of the Direct Democracy Framework is to create an environment that is flexible and yet secure enough to support a democratic process on any scale. There are additional technical features that the Voting Management Server can provide to enhance and streamline the implementation of effective security. These are discussed in the next section.

Additional Security Features of the Direct Democracy Framework (Not Included in Documented Core Functionality)

The following describes the various security features that can be integrated into the technology of the End User Voting Tool and the Voting Management Server. These features supplement rather than replace the security inherent in the five steps of the Direct Democracy Framework.

Initiative Validity

Certificate, encryption and hashing technologies could be used to ensure that an initiative is valid when it is received by an End User Voting Tool. If somehow an initiative became corrupted or changed and the content of the initiative did not hash correctly when compared by an appropriate algorithm to the initiative id, the End User Voting Tool would not allow a user to vote on it.

Digital Signature

As mentioned earlier in the document, during the registration phase, the digital signatures can optionally be attached to Voter Response Packages in order to ensure that the user's identity is valid.

Required Membership

The required membership feature of the Direct Democracy Framework would work by having initiatives labeled in accordance with the organizational membership required in order to vote on them.

It would be implemented by allowing Voting Management Servers to issue certificates for registered membership in an organization, and adding a field to the Initiative Package & Voter Response Package that include a field for identifying required

Required Security Certification

Implemented in an identical manner to the membership feature discussed above, a required security certification feature, would identify the level of security that's successfully implemented in the End User Voting Tool being used. This security level would be established by updating, scanning and auditing of the End User Voting Tool by a Voting Management Server very similar to how virus scanning software and software distribution servers work today.

Centralized Voting Tree Implementation

By leveraging membership and/or security certification to require all users within a given organization to utilize an End User Voting Tool embedded into a secure and high performance server or set of servers, we are creating a highly secure and centralized voting tree. In this environment, response delays as well as the requirement to utilize the additional four steps of the Direct Democracy Framework could be eliminated. This could create an extremely fast and efficient mechanism for making formal democratic decisions within secure environments.

Security Fences

In the above example of the centralized voting tree implementation, it would further be possible to configure Voting Management Servers to prevent initiatives having certain membership or security restrictions to actually leave a server. Instead where a user outside a server was addressed, they could be sent an invitation to register with the organization managing the server in question. This feature could allow organizations to institute voting on classified or confidential items.

This would be extremely convenient of users working in jobs requiring high security or confidentiality. They could use a single End User Voting Tool for all their voting activity and rely on security fences to keep important initiatives inside their secure environment. Security fences would compliment not replace other electronic security measures. For example a security fence sits above and beyond standard firewall security that would exist in a secure network.

Claims

1. A method of voting comprising the steps of:

creating an initiative which requires a response of support for the initiative, rejection of the initiative, or no opinion to the original initiative for transmission to selected recipients;

editing said initiative prior to transmitting to said selected recipients;

sending said edited initiative to said selected recipients;

allowing said selected recipients to send said initiative to other recipients for a vote;

sending a vote response from said selected recipients back to the creator; and sending said initiative to other recipients for a vote;

transmitting a vote response from said other recipients back to said selected recipients; and

sending back to the creator of the initiative the responses from the other recipients to the initiative wherein a preponderance of support responses is needed for the initiative to be submitted for petition to one or more organizations.

2. The method of claim 1 further comprising the step of creating a petition upon receiving a preponderance of support for the initiative;

transmitting said petition to a hosting organization such as a voting management server;

transmitting with said petition the initiator's identity to said voting management server.

3. The method of claim 2 further comprising the step of notifying each of said selected recipients who received the initiative that the initiative that they previously supported or opposed is now being petitioned.

4. The method of claim 3 further comprising the step of notifying selected recipients who received the initiative that is now being petitioned that they have the opportunity to automatically or manually sign the petition for or the petition against the initiative.

5. The method of claim 4 further comprising the step of notifying the selected recipients who received the initiative that they can forward the petition to those whom they originally forwarded the initiative.

6. The method of claim 5 wherein said voting management server transmits the petition across multiple serves

7. The method of claim 6 wherein the number of persons supporting or opposing the petition is tracked and the voting management server, based of the results obtained, can proceed to require authentication of user voting.

8. The method of claim 7 wherein, where authentication of user voting is required, said voters are requested to register by physically visiting a site that facilitates direct democracy registration.

9. The method of claim 8 wherein said registration is administered by competent neutral groups.

10. The method of claim 9 wherein said registered users can confirm all of their positions on all of the initiatives in which they were involved in a secure environment provided by a voting management server.

11. The method of claim 10 wherein the registered users can participate anonymously.

12. The method of claim 11 wherein the registered users, instead of voting for individuals, have voted for direct initiatives.

13. The method of claim 12 wherein said voting management server creates a statistically valid sampling lottery and randomly selects a limited number of voters to appear as delegates to a congress to validate the registered vote.

14. The method of claim 13 wherein the validated registered vote is ratified by the appropriate conventional government bodies.

15. The method of claim 13 wherein non-government entities confirm the legitimacy of the initiatives sent to them and write into law the process by which these initiatives would be enforced.