Abstract:
An apparatus, method, and system for federating grant management, project management, and funding in a web-based environment are disclosed. The apparatus, method, and system may include a module for receiving an electronic submissions of at least one grant proposal, a module for pestablishing a permission structure governing access to the at least one grant proposal, a module for providing a virtual collaboration space for the review process of the at least one grant proposal, a module for tracking a funding amount for the at least one grant proposal, a module for measuring statistical information based on parameters associated with the at least one grant proposal, and a module for generating reports based on the measured statistical information.

Description:
CLAIM OF PRIORITY UNDER 35 U.S.C. §119   
       [0001]    This application claims the benefit of and priority to U.S. Provisional Patent Application No. 61/482,964, titled “Method and System for Data Management and Development-Cycle Optimization,” filed May 5, 2011, the disclosure of which is hereby incorporated in its entirety by reference herein. 
     
    
     BACKGROUND 
       [0002]    1. Field 
         [0003]    Aspects of the present invention generally relate to data management systems, and more particularly to methods and systems for managing scientific research grants and optimizing product development cycles. 
         [0004]    2. Introduction 
         [0005]    Biomedical research is funded through private foundations that were formed to address specific biomedical problems (e.g., Duchenne Muscular Dystrophy (DMD)). To receive grant funding through foundations typically requires a scientist to reach out to foundations one at a time and submit proposals through their independent systems. For example, there are approximately 60 foundations funding DMD research throughout the world. So for a scientist to reach all sixty of them is a slow and tedious process because the scientist will have to submit the proposal sixty times, and the proposal requirements of each foundation are usually different. 
         [0006]    Further, the grant proposal review process between foundations is suboptimal because the foundations have limited or no knowledge of what other foundations are funding. This leads to the problem of a duplication of effort and funding. Such duplication is often times a result of a scientist submitting grant proposals to more than one foundation. Because there currently is no system that catalogs funding for proposals, some proposals may become overfunded, resulting in a depletion of funds for other worthy proposals. 
         [0007]    The confidentiality agreements that authors (e.g. scientists) and reviewers (e.g. foundations) traditionally use prevent disclosure to third parties and, therefore, prevent a collaborative review process. Scientific advisors and other reviewers are a valuable resource that can be more effective in a federated, collaborative review system. 
         [0008]    When foundations do collaborate in a co-funding process, a lack of transparency between the foundations may result in a lack of trust between the foundations, which may result in a slower than necessary money transfer process for co-funding a particular proposal, thus slowing the pace of biomedical research. 
         [0009]    Therefore, there exists an unmet need in the art for a system and method for federating scientists and foundations on a single platform that facilitates the grant proposal submission process, grant proposal tracking, grant management, grant funding, reporting, and inter-foundation collaboration. 
       SUMMARY 
       [0010]    According to an aspect of the present invention, a method may include detecting a user attempt to access a confidential proposal space, determining whether a status of the user is one of a denied access status, a pending access status, and a granted access status, denying access to the user if the status of the user is one of the denied access status or the pending access status, and transferring the user to the confidential proposal space if the status of the user is of the granted access status. 
         [0011]    According to another aspect of the present invention, an apparatus may include a permission structure module configured to detect a user attempt to access a confidential proposal space, determine whether a status of the user is one of a denied access status, a pending access status, and a granted access status, deny access to the user if the status of the user is one of the denied access status or the pending access status, and a proposal module configured to transfer the user to the confidential proposal space if the status of the user is the granted access status. 
         [0012]    According to yet another aspect of the present invention, a system may include means for detecting a user attempt to access a confidential proposal space, means for determining whether a status of the user is one of a denied access status, a pending access status, and a granted access status, means for denying access to the user if the status of the user is one of the denied access status or the pending access status, and means for transferring the user to the confidential proposal space if the status of the user is the granted access status. 
         [0013]    According to yet another aspect of the present invention, a computer program product may include a non-transitory computer-readable medium having control logic stored therein for causing a computer to perform proposal access screening, the control logic including code for detecting a user attempt to access a confidential proposal space, code for determining whether a status of the user is one of a denied access status, a pending access status, and a granted access status, code for denying access to the user if the status of the user is one of the denied access status or the pending access status, and code for transferring the user to the confidential proposal space if the status of the user is the granted access status. 
         [0014]    According to yet another aspect of the present invention, a method for federating grant management, project management, and funding in a web-based environment may include receiving an electronic submissions of at least one grant proposal, establishing a permission structure governing access to the at least one grant proposal, the permission structure permitting only third parties that have been granted authorization to view the at least one grant proposal to collaborate in a review process of the at least one grant proposal, providing a virtual collaboration space for the review process of the at least one grant proposal, tracking a pledge amount for the at least one grant proposal, tracking a funding amount for the at least one grant proposal, measuring statistical information based on parameters associated with the at least one grant proposal, the parameters including the pledge amount and the funding amount of the at least one grant proposal, and generating reports based on the measured statistical information. 
         [0015]    It is understood that other aspects of the invention will become readily apparent to those skilled in the art from the following detailed description, wherein various aspects of the present invention are shown and described by way of illustration only. As will be understood, the present invention is capable of other and different variations and its several details are capable of modification in various other respects, all without departing from the scope of the invention. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0016]    These and other sample aspects of the disclosure will be described in the detailed description and the appended claims that follow, and in the accompanying drawings, wherein: 
           [0017]      FIG. 1  is an example block diagram illustrating a simplified system for federating authors and reviewers via a portal, in accordance with aspects of the present invention; 
           [0018]      FIG. 2  is an example block diagram illustrating a system for registering authors and reviewers via the portal, in accordance with aspects of the present invention; 
           [0019]      FIG. 3  is an example block diagram illustrating a system for managing a proposal access permission structure between authors and reviewers via a dashboard, in accordance with aspects of the present invention; 
           [0020]      FIG. 4  illustrates an example flow diagram of a method for accessing a proposal, in accordance with aspects of the present invention; 
           [0021]      FIG. 5  illustrates an example flow diagram of a method for pledging funds to and funding a proposal, in accordance with aspects of the present invention; 
           [0022]      FIGS. 6A-6D  illustrate example screen shots of a registration process in accordance with aspects of the present invention; 
           [0023]      FIGS. 7A-6F  illustrate example screen shots of a proposal submission process in accordance with aspects of the present invention; 
           [0024]      FIG. 8  illustrates an example screen shot of a dashboard space in accordance with aspects of the present invention; 
           [0025]      FIGS. 9A-9D  illustrate example screen shots of a proposal space in accordance with aspects of the present invention; 
           [0026]      FIG. 10  depicts a computer system for implementing various aspects of the present invention; and 
           [0027]      FIG. 11  is a block diagram of various example system components, in accordance with aspects of the present invention. 
       
    
    
       [0028]    In accordance with common practice, the various features illustrated in the drawings may be simplified for clarity. Thus, the drawings may not depict all of the components of a given apparatus or method. In addition, like reference numerals may be used to denote like features throughout the specification and figures. 
       DETAILED DESCRIPTION 
       [0029]    Various aspects of the present invention are described below. It should be apparent that the teachings herein may be embodied in a wide variety of forms and that any specific structure, function, or both being disclosed herein may be merely representative. Based on the teachings herein one skilled in the art should appreciate that an aspect disclosed herein may be implemented independently of any other aspects and that two or more of these aspects may be combined in various ways. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects set forth herein. In addition, such an apparatus may be implemented or such a method may be practiced using other structure, functionality, or structure and functionality, in addition to or other than one or more of the aspects set forth herein. An aspect may comprise one or more elements of a claim. 
         [0030]    As used in this application, the terms “component,” “module,” “system” and the like are intended to include a computer-related entity, such as but not limited to hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computing device and the computing device can be a component. One or more components can reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. In addition, these components can execute from various computer readable media having various data structures stored thereon. The components may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets, such as data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal. 
         [0031]    Furthermore, various aspects are described herein in connection with a terminal, which can be a wired terminal or a wireless terminal. A terminal can also be called a system, device, subscriber unit, subscriber station, mobile station, mobile, mobile device, remote station, remote terminal, access terminal, user terminal, terminal, communication device, user agent, user device, or user equipment (UE). A wireless terminal may be a cellular telephone, a satellite phone, a cordless telephone, a Session Initiation Protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device having wireless connection capability, a computing device, or other processing devices connected to a wireless modem. 
         [0032]    Various aspects of the present invention solve the above-identified needs, as well as others, via devices, methods, and systems capable of federating scientists and foundations on a single platform that facilitates the grant proposal submission process, grant proposal tracking, funding, reporting, management and inter-foundation collaboration. 
         [0033]      FIG. 1  is an example block diagram illustrating a system  100  for federating authors and reviewers via a portal. The system may include a plurality of user types, such as authors  104   a - n  and reviewers  106   a - n  that may interface with portal  102  through one or more access terminals in communication with the portal  102 . 
         [0034]    Authors  104   a - n  are individuals that may submit proposals  108   a - n  and reviewers  106   a - n  are individuals who review and fund the submitted proposals  108   a - n.  Via the portal  102 , the authors  104   a - n  may, for example, request funds for their proposals as well as document any work (e.g., research results, publications, etc.) related to their proposals. The authors  104   a - n  may be scientists, principal investigators, or any individual authorized access to the portal  102 . On the other side of the portal  102  are the individuals who review the proposals, typically foundations otherwise referred to herein as reviewers. 
         [0035]    Reviewers  106   a - n  may be individuals who are members of foundations or any individual who is required to participate in the grant proposal review process to successfully execute, e.g., a biomedical research funding mission. It should be noted that the distinction between user types (i.e., authors  104   a - n  and reviewers  106   a - n ) is made for clarification purposes only and is not a limitation. For example, an author may qualify as a reviewer, and a reviewer may qualify as an author. 
         [0036]    The portal  102  is configured to function as a hub for grant proposal submission, management, review, and funding, as well as for facilitating communication and collaboration among its users. 
         [0037]      FIG. 2  is an example block diagram illustrating a system  200  for registering authors and reviewers via the portal  102 . In order to access dashboard  220  where author  104  and reviewer  106  may submit and review proposals, the author  104  and reviewer  106  may be required to first register with the dashboard  220 . 
         [0038]    For the author  104 , registration commences when the author  104  triggers a registration event when interfacing with registration module  202  of the portal  102 . For example, the registration event may be triggered by the author  104  clicking an “author” registration hypertext link on an access terminal that is in communication with the portal  102 . 
         [0039]    Once the registration event is triggered, the registration module  202  may prompt the author  104  to proceed through several registration steps. For example, the registration module  202  may first prompt the author  104  to review a legal overview that informs the author  104  of several documents the author  104  will have to agree to complete the registration process. For example, these documents may be a terms and conditions, a general confidential disclosure agreement (CDA), and a proposal related CDA. The registration module  202  may then receive an acknowledgement from the author  104  regarding the legal overview and may then proceed to display a form requesting the author  104  to provide profile information. For example, the form may include text fields where the author  104  may provide the author&#39;s name, address, work history, and other information similar to that typically included in a resume or a curriculum vitae. 
         [0040]    When the registration module  202  detects that the author  104  has provided information in all of the required text fields and submitted the profile information form, the registration module  202  may progress to the next registration step. For the next registration step, the registration module  202  may display to the author  104  a terms of use agreement with an option to accept or decline. If the registration module  202  detects a selection indicating acceptance of the terms of use agreement, the registration module may progress to the next registration step; otherwise, if the registration module  202  detects a selection indicating a refusal, the registration module  202  may redirect the user  104  out of the registration process. 
         [0041]    During the next registration step, the registration module  202  may prompt the author  104  to execute a general CDA. The general CDA may protect any proprietary methods or systems implemented within the system  100  and also broadly cover any confidential information that either the users may be exposed to while using the system  100 . The general CDA may also designate all grant proposal related information submitted to the system  100  as confidential, thus classifying any information in a grant proposal as de facto confidential. In order to execute the general CDA, the author  104  may be required to enter a digital signature by, for example, typing their name and title in a text field and selecting an acceptance indicator. Once the registration module  202  detects the submission of an executed general CDA, the registration module  202  may generate a document in a portable file format (e.g., Portable Document Format (PDF)) that will include the digital signature. The registration module  202  may then store the document in a profile of the author  104  such that author  104  and other registered members of the dashboard  220  may be able to view and confirm that the author  104  has executed the general CDA document. 
         [0042]    After execution of the general CDA, the registration module  202  may transmit an access request including at least the profile information of the submitted registration information to an administration module (not shown). The administration module may analyze the profile information submitted by the author  104 , and may determine, based on the profile information, whether to provide the author  104  with access to dashboard  220 . It should be noted that the administration module may include an algorithm for verifying the legitimacy of the profile information either automatically or with assistance from a user. Once the administration module confirms the legitimacy of the profile information, it may transmit a command to the registration module  202  to grant access to the author  104 . Once the registration module  202  receives the command, it may generate and provide the author with unique access credentials to access the dashboard, such as a username and password. 
         [0043]    The reviewer  106  may register via the registration module  202  to gain access to the dashboard  220  in much the same way as the author  104 . Some differences, for example, may relate to the commencement of registration and the profile information requirement for the reviewer  106 . For example, the reviewer  106  may trigger the registration event by clicking a “reviewer” registration hyperlink on an access terminal that is in communication with the portal  102 . Also, the required profile form to be submitted by the reviewer  106  may include additional text fields, such as those for inputting a name and address of the foundation represented by the reviewer  106 . Based on the foundation information provided in the profile form, the registration module  202  or the administration module may create a unique access account for the foundation, including a username and password. 
         [0044]    After the author  104  receives the username and password, the author  104  may use the login information to access the dashboard, as well as create and submit a proposal. 
         [0045]    The author  104  may commence submission of a proposal by triggering a submission process, which may be triggered by the author  104  clicking on an “add a proposal” link on a navigation bar in the dashboard  220 , for example. The proposal submission process may be controlled by a proposal submission module  210 . 
         [0046]    When the author  104  triggers the proposal submission process, the proposal submission module  210  may detect the trigger and display to the author  104  a plurality of tabs, each of which serves a specific function in the proposal submission process. The proposal submission tabs may include a permission tab  212 , a profile tab  214 , a summary tab  216 , and a submission tab  218 . 
         [0047]    The permission tab  212  may provide to the author  104  a list of every prospective reviewer, e.g., every individual that is associated with a foundation, such as the foundation head, legal staff, scientific advisors, etc., that is registered with the dashboard  220 . Each reviewer entry may show a photograph of the reviewer, the reviewer&#39;s education, specialization and country of origin, for example, among other relevant information. For example, the permission tab  212  may provide a link out to each reviewer&#39;s profile so that the author  104  may determine if an individual reviewer has a conflict of interest or may be a competitor. The permission tab  212  may also identify the reviewers by foundation or disease type, for example, as well as by what the reviewer&#39;s role is in the respective foundation. Based on this information, the author  104  may be able to categorize and sort the reviewers, and have the ability to indicate those reviewers that should be granted access to the proposal and those reviewers that should be denied access to the proposal. Once the author  104  makes any desired reviewer access designations, the author  104  may proceed to the next tab, which may be the profile tab  214 . 
         [0048]    The profile tab  214  allows the author  104  to further refine and update the author&#39;s profile by inputting additional information in the provided text fields, such as further technical capabilities or expertise. The author  104  may choose to update the profile or proceed to the next tab, which may be the summary tab  216 . 
         [0049]    The summary tab  216  may include text fields and other input fields (e.g., radio buttons) where the author  104  may provide basic information that summarizes the proposal. For example, the summary tab  216  may include text fields for information such as a title of the proposal, categories related to the proposal, intended start and completion dates of the project being undertaken under the proposal, amount requested, suggested mechanism of action, target population tags, and abstract. One or more of the text fields may also inquire whether the author  104  is willing to acknowledge foundations in publications related to the proposal. 
         [0050]    The fields for inputting the start and the completion dates of the proposed project may be configured to generate a calendar for inputting the dates. Moreover, the calendar may be integrated with a project management system, such as a Gantt chart, which may be used to track any and all dates related to the project proposal. The Gantt chart may be integrated with a calendar and timeline that can be made available to authors or reviewers that have been granted access to the proposal contents. 
         [0051]    The information provided by the author  104  in the summary tab  216  may be used to associate category tags (e.g., pre-clinical therapeutics, quality of care, diagnostics) with the proposal that provide a greater categorical resolution to the projects. These category tags may allow reviewers to better understand the context of the research and to more easily search proposals of interest. 
         [0052]    The submission tab  218  may provide the author  104  with an ability to upload, preview, and submit the grant proposal. The submission tab  218  may also provide instructions and requirements for a format of the proposal. For example, the submission tab  218  may instruct the author  104  to prepare the proposal in a PDF format, as well as include specific information in the proposal, such as a title, abstract, introduction, detailed budget, specific aims and references. The submission tab  218  may also require the proposal to include additional information, such as links to unpublished data, unique expertise, assumptions, collaborators, as well as information for grant management purposes, such as deliverables, milestones, cost reports and a disbursement schedule for funding. 
         [0053]    The proposal may be uploaded by any standard means. For example, the author  104  may trigger an uploading process by activating a file source browser within the submission tab  218 , selecting a source of the proposal document, and uploading the proposal by activating an upload radio button, or similar means. The submission tab  218  may also provide the author  104  with an ability to preview the proposal prior to submitting it, or to save the proposal as a draft without submitting. Once the author  104  chooses to submit the proposal, the author  104  may do so by activating a submit trigger (e.g., submit radio button), at which point the submission tab  218  may prompt the author  104  to confirm the submission of the selected proposal. 
         [0054]    Once the author  104  confirms submission of the proposal, the proposal submission module  210  may generate and assign a unique identification (ID) number to the proposal, generate and record the date and time of the submission, as well as prompt the author  104  with a text field for the author&#39;s name and title, which when entered by the author  104 , may finalize the submission process. The name and title that the author  104  enters may be used by the proposal submission module  210  to populate a proposal-related CDA, which may later be used as a confidentiality agreement between the author  104  and each of the reviewers  106 . 
         [0055]    After the author  104  finalizes the submission of the proposal, the proposal submission module  210  may securely store the proposal in a storage module (not shown) and generate a proposal entry for the submitted proposal in a form of a digital proposal card  108 , which may include various information identifying the proposal and reflecting the funding status of the proposal. 
         [0056]    For each user (e.g., author  104 , reviewer  106 ) that has completed the registration process and obtained their unique access credentials, a dashboard module  220  may generate a unique dashboard space specific to that user. The dashboard space provides a secure and dynamic environment that is accessible only via the corresponding access credentials. When an author  104  or a reviewer  106  logs on to the portal  102  using their access credentials, the dashboard module  220  will display the dashboard space to the user on the user&#39;s respective access terminal. 
         [0057]    The dashboard module  220  may display the digital proposal card  108  on the dashboard space belonging to the author  104 , as well as on dashboard spaces belonging to those reviewers  106  to whom the author has granted access to the proposal in the permission tab  212 . 
         [0058]    Each of the proposal cards  108  may show, e.g., the unique ID of the proposal, a photograph of the author  104 , a link to the user&#39;s profile, indicate the user&#39;s position and the institution the user works for, as well as the user&#39;s country of origin by way of a flag image, for example. In addition, the proposal card  108  may display a number of unique views representing the number of different users that have accessed the proposal and a number of total views that represents the total number of times the proposal has been accessed. The card  108  may also display the number of comments in an author forum and/or a reviewer forum specific to the proposal. Furthermore, the proposal card  108  may display a progress bar that indicates the pledge status of the proposal, such as anywhere from zero to one hundred percent complete, or greater than one hundred percent. The proposal card  108  may also indicate the number of backers (i.e., number of foundations that have pledged funds to the proposal), the amount of pledges, the dollar amount of the pledges, and the requested dollar amount for the proposal. All of the information provided on the proposal card  108  may be intended to provide an at-a-glance summary of the funding status of the proposal. 
         [0059]    The author  104  may access the proposal through the proposal card  108 . If the author  104  has submitted multiple proposals, the author  104  may see a proposal card  108  for each one of those proposals on the author&#39;s respective dashboard space. If the author  104  also happens to be a reviewer  106 , the author/reviewer may also be able to see proposal cards  108  for other authors&#39; proposals that the author/reviewer is authorized to access. 
         [0060]    As previously mentioned, when a reviewer  106  logs on to the portal  102  using access credentials, the reviewer will be presented with a unique dashboard space. Upon entry into the dashboard space, the reviewer  106  may be presented with one or more proposal cards  108 . At this point, the proposal cards  108  display only limited information, e.g., they may not display or link to any confidential information (such as title, project summary, proposal, etc.). The reason that the reviewer  106  may not have access or permission is because the author  104  may not yet have given the reviewer permission to do so. The proposal cards  108 , however, will include a link that, once clicked, may trigger a permission structure module  222  to establish a means for the reviewer  106  to directly contact the author  104  to request permission to view the proposal corresponding to the proposal card  108 . For example, the permission structure module  222  may generate an alert or email directed to the author  104  that informs the author  104  that a reviewer  106  is requesting access to a specific proposal. 
         [0061]    If the reviewer  106  requests access to the proposal through a link on the proposal card  108 , and the author  104  grants the reviewer  106  access to the proposal, then the reviewer  106  may receive an alert or e-mail indicating that the reviewer  104  now has permission to access the proposal. Alternatively, the author  104  may independently invite the reviewer  106  through the permission structure module  222 . 
         [0062]    It should be noted that, upon submission of a proposal by the author  104 , the permission structure module  222  may retrieve the list of reviewers  106  to whom the author  104  has granted permission to view the proposal in the permission tab  212 , and transmit alerts to the reviewers on that list. 
         [0063]    When the reviewer  106  is granted permission to view a proposal, the corresponding proposal card  108  displayed in the dashboard space of the reviewer  106  may show additional information about the proposal (e.g., title of the proposal). The proposal card  108  may also provide the reviewer  106  with the ability to access the project proposal, such as via a hyperlink or similar means. When the reviewer  106  clicks on the hyperlink to access the proposal for the first time, the permission structure module  222  may generate a proposal-related CDA and may prompt the reviewer  106  to sign the proposal-related CDA. In order to proceed to the proposal, the reviewer  106  must execute the proposal-related CDA by typing the reviewer&#39;s name in a designated field on the proposal-related CDA. Once the proposal-related CDA is executed, the permission structure module  222  may grant the reviewer  106  full access to the proposal. 
         [0064]      FIG. 3  is an example block diagram illustrating a system  300  for managing a proposal access permission structure between authors and reviewers and accessing a proposal via a dashboard module. 
         [0065]    As shown in  FIG. 3 , the portal  102  may include a proposal module  320 . The proposal module  320  may be configured to generate a proposal space that facilitates review, management and funding of proposals. For example, for each submitted proposal, a proposal module  320  may generate a unique proposal space specific to that proposal. The proposal space provides a secure and dynamic environment that is accessible only via the author of that proposal and any reviewers that have been granted access to that specific proposal and have executed the proposal-related CDA for that proposal. The generated proposal space, however, may differ somewhat depending on whether the author  104  of the proposal or the reviewer  106  is accessing the proposal space. 
         [0066]    When an author  104  of the proposal enters the proposal space, the proposal module  320  may display to the author  104  a plurality of tabs, each of which may serve a specific purpose in the proposal management and review process. For example, the proposal space tabs may include a permission tab  308 , an author profile tab  310 , a summary tab  312 , a main tab  314 , an author forum tab  316 , and a backers tab  322 , among other tabs. 
         [0067]    In addition to the tabs, the proposal space may include other features, such as a progress bar showing a percentage of how much of the total requested amount has been pledged, a pledge function that allows the author  104  to pledge funds to his own proposal, as well as a pledge edit function, which allows the author  104  to edit a previously made pledge. 
         [0068]    The permission tab  308  may display a set number, such as three categories of reviewers. The first category may be a denied access category  302 , which lists those reviewers that have not yet been given permission by the author to view the proposal. The reviewers listed under the denied access category  302  could, for example, include a competitor or someone with a potential conflict of interest, or the author  104  may not yet know that this reviewer exists. Reviewers listed in the denied access category  302  may be unable to access the proposal space. Furthermore, any reviewers that have been granted access to the proposal space may be unable to contact or discuss the proposal with the reviewers listed in the denied access category  302 . 
         [0069]    The second category of reviewers may be a pending access category  304 , which may list those reviewers that have been given permission by the author to view the proposal but have not yet executed the proposal-related CDA. This list may include photographs of these reviewers and links out to their profiles, among other attributes. Reviewers listed in the pending access category  302  may be unable to access the proposal space. Furthermore, any reviewers that have been granted access to the proposal space may also be unable to contact or discuss the proposal with the reviewers listed in the pending access category  304 . 
         [0070]    The third category of reviewers may be a granted access category  306 , which may list those reviewers that have permission from the author  104  to view the proposal and have also executed the proposal-related CDA. Reviewers listed in the granted access category  306  may access the proposal space and may also be able to contact or discuss the proposal with the other reviewers listed in the granted access category  306 . 
         [0071]    It should be noted that the categories and lists of reviewers in the permission tab  308  may be utilized by the permission structure module  222  to manage access to the proposal space and may ensure that only reviewers that are listed under the granted access category  306  are permitted to enter the proposal space. 
         [0072]    The author profile tab  310  may include a profile of the author of the proposal. The author profile tab  310  may include resume or a curriculum vitae information that were previously submitted during the registration process and refined during the proposal submission process. The author profile tab  310  may also include e-mail addresses, and may have links out to other websites. 
         [0073]    The summary tab  312  may include basic information that the author has entered in the author&#39;s respective summary section during proposal submission. For example, the summary tab  312  may include the title, the pledging status, the amount of money pledged, the category of the proposal, suggested mechanism of action, target population, tags, start and completion dates, budget, and the abstract, among other attributes. 
         [0074]    The main tab  314  may include the proposal that the author uploaded and submitted during the proposal submission process. For example, the main tab  314  may include a PDF of the proposal, which may be viewed, printed, or downloaded by the user browsing the main tab  314 . 
         [0075]    The author forum tab  316  may include a forum specifically intended for discussion of the proposal between the author and the reviewers. The author forum may be in a form of a threaded message board. For example, if a reviewer has questions for the author, the reviewer can post the questions in the author forum. Comments posted to the forum may include the poster&#39;s photograph, name, a link out to the poster&#39;s profile, the poster&#39;s position in the foundation, as well as the poster&#39;s country of origin, among other attributes. Only the author and those designated under the granted access category  306  may read, post and reply to posts on the forum. The comments on the forum may be edited and deleted. 
         [0076]    The reviewer forum tab  318  may include a forum specifically intended for discussion of the proposal exclusively among reviewers who have been granted access to the proposal space. The author of the proposal may not have access to the reviewer forum tab  318 . Moreover, the reviewer forum tab may not be displayed in the author&#39;s proposal space—it may be available only to the reviewers. The reviewer forum may be in a form of a threaded message board. Excluding the author from the reviewer forum provides the reviewers with an opportunity for a candid, critical review that the reviewers may share with each other but not with the author. The reviewer forum allows for crowd sourcing of scientific advisors. For example, when a scientific advisor from one foundation leaves a comment on the reviewer forum, the comment can be shared with any other foundation or foundation member that has been granted access to the proposal as a reviewer. 
         [0077]    The backers tab  322  may include a list of individuals that have actually pledged funds to the project proposal and may provide an updated status of the pledges and funding. The backers tab  322  may list the backers with their profile photograph and brief biography that may include a link that allows a user access to the backer&#39;s profile. The backers tab  322  may also show how much each backer has pledged and may indicate the status of the funding. The backers tab  322  may also include a field where the author or a liaison may be able to indicate if funding from the sources that pledged the funds has been received. 
         [0078]    The proposal space may also include a pledge module  324  that may be activated by having a user click on or otherwise select a pledge link. When activated, the pledge module  324  may display to the user a pledge space that may include various information regarding the pledge, such as the total proposal budget, the total amount requested by the author, and a summary of the sum of the pledges that had already been provided by other users, among other attributes. The pledge space may also include a field where the user may enter a pledge amount. The user may enter a pledge amount and trigger a pledge submission by, for example, clicking or otherwise selecting a submit button. At this point, the pledge module  324  may activate a comment box where the user who just triggered the pledge submission may leave a comment associated with that pledge. The user may fill in the comment and click a button to submit the pledge and comment together. The pledge comment may be directly associated with the user who made the pledge and may be displayed in the pledge space with the pledge information for the user. Once the submission is made, the pledge module  324  may update the pledge related information throughout the proposal space. For example, the pledge module  324  may update the backers tab  322  to list the new user that made the pledge as a new backer. Also, the proposal card  108  on the dashboard space may be updated with the new pledge amount. For example, the progress bar on the proposal card  108  that indicates the percent funded may be updated to reflect the new pledged amount. 
         [0079]    Every time a pledge is submitted or edited, an alert may be transmitted by the pledge module  324  to the author and the reviewers that have been granted access, indicating the user making the pledge and the pledged amount for the project proposal. 
         [0080]    The pledge space and the backers tab  322  may include a pledge status indicator for each of the individuals that have pledged funds. The submission of a pledge is recorded as well as the transfer of the money either to the liaison or to the author may also be recorded by the pledge module  324 . The liaison or author may then indicate whether or not the pledged amounts have been received. The indication may be reflected in a pledge status field as either “pending” if the pledge has not yet been funded, or “fulfilled” if the pledge has been funded. 
         [0081]    The dashboard module  220  may include a billing and invoicing module  326 , which may provide for the ability to transfer electronic funds between the reviewers and the liaison or author. For example, the reviewers (e.g., foundations) may electronically transfer money to the liaison (e.g., via credit card, PayPal, or other means) and then the liaison can disburse the transferred amount by check or through the billing and invoicing module  326  to the author. 
         [0082]    The dashboard module  220  may also include a report module  328 , which may generate summary reports including with various statistical information, such as the number of active proposals in the portal  102 , the total amount of funds requested through the portal  102 , the total amount pledged through the portal  102 , and the total number of registered users. The report module  328  may generate reports on any measurable statistic within the portal  102 . The reports may be available to users through different permissions. 
         [0083]    The dashboard module  220  may additionally include a project management module  330  that may facilitate the management of grant proposals within the portal  102 . For examples, for each proposal, the proposal start and stop dates entered by the author  104  during registration may be incorporated into a project scheduling chart, such as a Gantt Chart, by the project management module  330 . Various other budget, scheduling, and task-related information may be provided by the author and similarly incorporated in to the project scheduling chart by the project management module  330 . 
         [0084]    The project management module  330  may be integrated with a calendar so that start dates of particular aims scheduled by the author may show up as a date on a calendar. Other information may be included in the calendar, such as information for drug seminars, fund-raising events, etc. Deliverables and milestones, such as publications and other project-related events that occur throughout the lifetime of the project proposal may be also displayed on the calendar, such as a timeline, and the project-scheduling chart associated with the proposal, among other events/milestones. 
         [0085]    The project management module  330  may function in tandem with the report module  328  to provide any generated reports to users through the permission structure module  222 . For example, if the reviewer has been granted access, the reviewer can see all this information within the report; whereas if the reviewer has not been granted access, the confidential information will be invisible to the reviewer. 
         [0086]    The dashboard module  220  may also include a chat module  332  that may be used by authors and reviewers to contact other registered users through an alphabetical list. 
         [0087]    The dashboard module  220  may also include a messaging module  344  that may be used by authors and reviewers to contact other registered users through a link associated with each user&#39;s profile. 
         [0088]    The dashboard module  220  may also include a feedback module  334  that allows all registered users to provide feedback by capturing an image of the dashboard space, proposal space, or any other displayed environment within a web browser along with an Internet Protocol (IP) address of the user. 
         [0089]    The dashboard module  220  may also include a help module  336  that may include entries describing each module and component of the portal  102 , and that may allow users to annotate those entries and “vote up” entries. The help module  336  may thus provide an ability to crowd source helpful information about the portal  102 . 
         [0090]    The dashboard module  220  may also include a public module  338 , which may allow authors to create a public version of proposals that may be published on a public platform, such as a web page that is accessible to the public. For example, if an author chooses to create a public version of the author&#39;s proposal, that proposal may be displayed on the public platform where the public may have the opportunity to pledge funds to as well as fund the proposal. The funding may be documented and reported to the authors and the authorized reviewers by the public module  338 . The reviewer/foundation funding for the published proposal may also be reported on the public platform. 
         [0091]    The combined amount of funding that the foundations/reviewers may provide and the funding that the public may provide represents the total funding. This merging of private and public funding may be represented on a progress bar on the proposal card  108 , which may have a sum of these two numbers indicated in two different colors in the same bar. 
         [0092]    Aspects of the invention may include an application of game theory to measure contributions by each participant. For example, the dashboard module  220  may include a game theory module  340  that may process parameters, such as an amount of funding pledged or contributed by each user, a number of user comments, a rating of the comments, a number of proposals each user has reviewed or submitted, etc. The game theory module  340  may measure all analytics and report these measurements to the respective users to provide incentive for more participation. 
         [0093]    The dashboard module  220  may also include a sponsorship module  342  that may allow each of the foundations to serve as a channel or portal to the portal  102 . This may be achieved by having the sponsorship module  342  generate an application that may be remotely integrated into the foundations&#39; own portals or websites, and that allows the foundations to display advertisements related to the portal  102 . Such a sponsorship module  342  may allow increase in the reach and therefore an increase in value of the portal  102 . 
         [0094]      FIG. 4  illustrates an example flow diagram of a method  400  for accessing a proposal. As shown in  FIG. 4 , in block  402 , an attempt to access a proposal may be detected. For example, the permission structure module  222  may detect a reviewer  106  attempt to access a proposal through a proposal card  108 . 
         [0095]    In block  404 , a determination may be made as to whether the user attempting to access the proposal is within a denied access category for the proposal. If the user is within the denied access category, the process may proceed to block  406 , otherwise the process may proceed to block  416 . For example, the permission structure module  222  may search for the reviewer within the list of reviewers in the denied access category  302 . 
         [0096]    In block  406 , an access request prompt may be generated for submission by the user to the author of the proposal. For example, the permission structure module  222  may generate a prompt to the reviewer attempting access indicating that the reviewer does not have permission to access the proposal and inquiring whether the reviewer would like to request permission from the author to access the proposal. 
         [0097]    In block  408 , a determination is made as to whether the request for access has been submitted by the user. If so, the process proceeds to block  410 , otherwise, the process proceeds to block  402 . For example, the permission structure module  222  may remain in standby while the reviewer either accepts or declines to send the permission request to the author. 
         [0098]    In block  410 , the request for access to the proposal may be transmitted to the author. For example, the permission structure module  222  may transmit an email or an alert to the author indicating that the reviewer is requesting access to view the proposal. 
         [0099]    In block  412 , a determination may be made as to whether an authorization for the user to access the proposal has been received from the author. If the author authorizes access, the process proceeds to block  414 ; otherwise, the process proceeds to block  402 . For example, the permission structure module  222  may receive authorization from an author permitting the reviewer to access the proposal, or a refusal denying the reviewer access to the proposal. 
         [0100]    In block  414 , the user may be designated with the pending access status. For example, the permission structure module  222  may toggle the permission status of the reviewer for this particular proposal as “pending access,” and list the reviewer in the pending access category  304 . The process may then proceed back to block  402 . 
         [0101]    In block  416 , a determination may be made as to whether the user attempting to access the proposal is within a pending access category for the proposal. If the user is within the pending access category, the process may proceed to block  418 ; otherwise the process may proceed to block  426 . For example, the permission structure module  222  may search for the reviewer within the list of reviewers in the pending access category  304 . 
         [0102]    In block  418 , a proposal-related CDA may be generated with a prompt for the user to execute. For example, the permission structure module  222  may generate a proposal-related CDA with a text filed for the reviewer to enter the user&#39;s name and/or signature and other information and thereby execute the CDA. 
         [0103]    In block  420 , a determination may be made whether the user executed the proposal-related CDA. If so, the process may proceed to block  422 ; if not, the process may proceed to block  402 . For example, the permission structure module  222  may detect an acceptance of the proposal-related CDA by detecting a reviewer&#39;s name typed into a text field and a submittal action. 
         [0104]    In block  422 , the proposal-related CDA may be stored and displayed in the user&#39;s and author&#39;s respective profiles. For example, the permission structure module  222  may store the proposal-related CDA in server storage and also display the CDA in the author&#39;s profile as well as the reviewer&#39;s profile. 
         [0105]    In block  424 , the user may be designated with granted access status. For example, the permission structure module  222  may toggle the permission status of the reviewer for this particular proposal as “granted access,” and list the reviewer in the granted access category  306 . The process may then proceed back to block  402 . 
         [0106]    In block  426 , a determination may be made as to whether the user attempting to access the proposal is within a granted access category for the proposal. If the user is within the granted access category, the process may proceed to block  428 ; otherwise the process may proceed to block  402 . For example, the permission structure module  222  may search for the reviewer within the list of reviewers in the granted access category  304 . 
         [0107]    In block  428 , the user may be transferred to the proposal space, and the process may end. For example, the permission structure module  222  may grant the reviewer access, via the proposal module  320 , to the secure proposal space that includes all information related to the proposal. 
         [0108]      FIG. 5  illustrates an example flow diagram of a method for pledging funds to and funding a proposal. As shown in  FIG. 5 , the process may begin with block  502 , where a determination may be made as to whether a pledge trigger has been detected. If so, the process may proceed to block  512 ; otherwise, the process may proceed to block  504 . For example, a pledge module  324  may detect an indication of a pledge submittal attempt, such as when a pledge link has been clicked. 
         [0109]    In block  504  a determination may be made as to whether funding trigger has been detected. If so, the process may proceed to block  506 ; otherwise, the process may proceed to block  502 . For example, the pledge module  324  may detect an indication of a fund transfer towards a proposal budget, such as when an author or a liaison for the author clicks on a pledge funded link. 
         [0110]    In block  506 , a funding form may be generated. For example, the pledge module  324  may generate a funding space with a text field for entry of the funded amount. 
         [0111]    In block  508 , a funded amount may be submitted, and the process may proceed to block  510 . For example, the pledge module  324  may detect an entry and submission of a funded amount. 
         [0112]    In block  510 , the funded and pledged amounts for the proposals may be updated, and the process may proceed to block  518 . For example, the pledge module  324  may update the pledged and funded amounts to reflect the submission of the funded pledge. This tool may be used to track the transfer of money between users including, for example, reviewers, liaisons, and authors or authors&#39; institutions. 
         [0113]    In block  512 , a pledging form may be generated. For example, the pledge module  324  may generate a pledge space with a text field for entry of the pledged amount. 
         [0114]    In block  514 , a pledged amount may be submitted, and the process may proceed to block  516 . For example, the pledge module  324  may detect an entry and submission of a pledged amount. 
         [0115]    In block  516 , the pledged amounts for the proposals may be updated, and the process may proceed to block  518 . For example, the pledge module  324  may update the pledged amounts to reflect the submission of the new pledge. 
         [0116]    In block  518  the funded and pledged amounts for the proposals may be updated throughout the proposal space, and the process may end. For example, the pledge module  324  may update, via the proposal module  320 , all instances representing the pledged and funded amounts to reflect the submission of the pledged and/or funded amounts. For example, one of the instances of the pledged and funded amounts that may be updated are those displayed on the project card  108 . 
         [0117]      FIGS. 6A-6D  illustrate example screen shots of a registration process in accordance with aspects of the present invention. 
         [0118]      FIGS. 7A-6F  illustrate example screen shots of a proposal submission process in accordance with aspects of the present invention. 
         [0119]      FIG. 8  illustrates an example screen shot of a dashboard space in accordance with aspects of the present invention. 
         [0120]      FIGS. 9A-9D  illustrate example screen shots of a proposal space in accordance with aspects of the present invention. 
         [0121]    Aspects of the present invention, as well as programming functions performed via a separate terminal, may be implemented using a combination of hardware, software and firmware in a computer system. In an aspect of the present invention, the invention is directed toward one or more computer systems capable of carrying out the functionality described herein. An example of such a computer system  600  is shown in  FIG. 10 . 
         [0122]    Computer system  600  includes one or more processors, such as processor  604 . The processor  604  is connected to a communication infrastructure  606  (e.g., a communications bus, cross-over bar, or network). Various software aspects are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the invention using other computer systems and/or architectures. 
         [0123]    Computer system  600  can include a display interface  602  that forwards graphics, text, and other data from the communication infrastructure  606  (or from a frame buffer not shown) for display on a display unit  630 . Computer system  600  also includes a main memory  608 , preferably random access memory (RAM), and may also include a secondary memory  610 . The secondary memory  610  may include, for example, a hard disk drive  612  and/or a removable storage drive  614 , representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive  614  reads from and/or writes to a removable storage unit  618  in a well-known manner. Removable storage unit  618 , represents a floppy disk, magnetic tape, optical disk, etc., which is read by and written to removable storage drive  614 . As will be appreciated, the removable storage unit  618  includes a computer usable storage medium having stored therein computer software and/or data. 
         [0124]    Alternative aspects of the present invention may include a secondary memory  610  and may include other similar devices for allowing computer programs or other instructions to be loaded into computer system  600 . Such devices may include, for example, a removable storage unit  622  and an interface  620 . Examples of such may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an erasable programmable read only memory (EPROM), or programmable read only memory (PROM)) and associated socket, and other removable storage units  622  and interfaces  620 , which allow software and data to be transferred from the removable storage unit  622  to computer system  600 . 
         [0125]    Computer system  600  may also include a communications interface  624 . Communications interface  624  allows software and data to be transferred between computer system  600  and external devices. Examples of communications interface  624  may include a modem, a network interface (such as an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communications interface  624  are in the form of signals  628 , which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface  624 . These signals  628  are provided to communications interface  624  via a communications path (e.g., channel)  626 . This path  626  carries signals  628  and may be implemented using wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link and/or other communications channels. In this document, the terms “computer program medium” and “computer usable medium” are used to refer generally to media such as a removable storage drive  614 , a hard disk installed in hard disk drive  612 , main memory  608 , secondary memory  610 , and signals  628 . These computer program products provide software to the computer system  600 . The invention is directed to such computer program products. 
         [0126]    Computer programs (also referred to as computer control logic) are stored in main memory  608  and/or secondary memory  610 . Computer programs may also be received via communications interface  624 . Such computer programs, when executed, enable the computer system  600  to perform the features of the present invention, as discussed herein. In particular, the computer programs, when executed, enable the processor  610  to perform the features of the present invention. Accordingly, such computer programs represent controllers of the computer system  600 . 
         [0127]    In an aspect of the present invention where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system  600  using removable storage drive  614 , hard drive  612 , or communications interface  624 . The control logic (software), when executed by the processor  604 , causes the processor  604  to perform the functions of the invention as described herein. In another aspect of the present invention, the invention is implemented primarily in hardware using, for example, hardware components, such as application specific integrated circuits (ASICs). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s). 
         [0128]      FIG. 11  shows a communication system  700  usable in accordance with aspects of the present invention. The communication system  700  includes one or more accessors  702 ,  704  (also referred to interchangeably herein as one or more “users” or “members”) and one or more terminals  706 ,  708 . According to one aspect, data for use in accordance with the present invention is, for example, input and/or accessed by accessors  702 ,  704  via terminals  706 ,  708 , such as personal computers (PCs), minicomputers, mainframe computers, microcomputers, telephonic devices, or wireless devices, such as personal digital assistants (“PDAs”) or a hand-held wireless devices coupled to a server  710 , such as a PC, minicomputer, mainframe computer, microcomputer, or other device having a processor and a repository for data and/or connection to a repository for data, via, for example, a network  712 , such as the Internet or an intranet, and couplings  714 ,  716 ,  718 . The couplings  714 ,  716 ,  718  include, for example, wired, wireless, or fiberoptic links. According to another aspect, the method and system of the present invention may operate in a stand-alone environment, such as on a single terminal. 
         [0129]    While the foregoing disclosure discusses illustrative aspects and/or embodiments, it should be noted that various changes and modifications could be made herein without departing from the scope of the described aspects and/or embodiments. Other aspects will be apparent to those skilled in the art from a consideration of the specification or from a practice of the invention disclosed herein. Furthermore, although elements of the described aspects and/or embodiments may be described in the singular, the plural is contemplated unless limitation to the singular is explicitly stated. Additionally, all or a portion of any aspect and/or embodiment may be utilized with all or a portion of any other aspect and/or embodiment, unless stated otherwise.