Abstract:
A computer-implemented method for identifying a new software application to be developed. A computer database is searched for matching keywords that correspond to any of a group of selected keywords, indicative of the new application. The database contains descriptive keywords which are indicative of a set of existing applications. If no matching keywords are found in the database, then a description of the new application is requested from the potential user; the description of the new application is received from the potential user; and the description of the new application is used as a basis for developing the new application.

Description:
RELATED APPLICATIONS 
       [0001]    This application is a divisional application of U.S. patent application Ser. No. 12/852,919, filed Aug. 9, 2010, the disclosure of which is incorporated herein by reference. 
     
    
     BACKGROUND 
       [0002]    Previous systems offer application software to customers but do not provide a way to directly interact with the application development community. In the standard software application store model, developers have only indirect information regarding customer demand. When errors are found by users of the applications, it is often difficult to provide enough information to the developers to reproduce the problems causing the errors. After a problem has been repaired, customers who have experienced the problem are often not informed that the problem has been addressed. 
         [0003]    In standard application store systems, users have to wait for new code releases or software downloads to get access to new application functionality. In addition, standard applications offer limited methods for a user to gain additional processing performance when needed or desired. Standard applications have a fixed processing performance, making processing performance gains a function of either the hardware that runs the application or the specific version of the application. 
       SOLUTION 
       [0004]    An integrated, automated customer-demand-to-application-development process is presented as a single function, reducing software application development risk and introducing a significant new capability for software application development. Unlike standard application stores (for example, the Apple “App Store” or the Microsoft Store), the present software application development system (“application store”) combines diversity of ideas of a software developer community, the ability for users to directly communicate with that community, and in addition, the shopping convenience of an online store. 
         [0005]    For all applications sold through the present application store, customers can directly inform the developers of any problems, submit the input/parameter values that generated the problems, and receive direct notification (both through the application itself and via email) when their problem has been addressed. This process provides application developers the ability to quickly repair and notify only those customers who have an interest in that particular problem&#39;s resolution. For each application sold through the present application store, additional application functionality can be requested and provided, allowing customers direct access to customized software applications from the original software developer. 
         [0006]    The processing performance of applications developed with the present system can be dynamically changed at the request of the customer, with the increased performance being a function of the amount of computational resources provided by the cloud computing environment. Dynamic, real-time application performance changes represent a new capability for on-line applications, 
         [0007]    Allowing customers, developers, and the computing environment the ability to interact as a community makes it possible for developers to create high-quality applications that are desired by customers, and whose performance is dictated by the customer. The interaction that takes place in the present system facilitates the public availability of features needed in a particular application. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0008]      FIG. 1  is a system diagram showing an exemplary system for automating a customer-demand-to-application-development process; 
           [0009]      FIG. 2  is a flowchart showing a set of steps performed in an exemplary embodiment to determine whether a requested application is available; 
           [0010]      FIG. 3A  is a table including exemplary information used to track current market demand for an application; 
           [0011]      FIG. 3B  shows an exemplary ‘Application Description’ screen; 
           [0012]      FIG. 4  shows an exemplary ‘Application Detail’ screen; 
           [0013]      FIG. 5  shows an exemplary ‘Shopping Cart’ screen; 
           [0014]      FIG. 6  shows an exemplary ‘Checkout’ screen; 
           [0015]      FIG. 7  is a flowchart showing a set of steps performed in an exemplary embodiment to implement a request for a change to an application; 
           [0016]      FIG. 8  is a flowchart showing a set of steps performed in an exemplary embodiment to report and repair a ‘bug’ in an application; and 
           [0017]      FIG. 9  shows an exemplary ‘Algorithm Trace’ screen; and 
           [0018]      FIG. 10  is a flowchart showing a set of steps performed in an exemplary embodiment to compare the performance of two applications. 
       
    
    
     DETAILED DESCRIPTION 
       [0019]    In response to customer inquiries, the present application store system uses a search engine and keywords to determine if a needed application exists; if it does not, a demand-based development cycle is initiated in which customers provide their software application requirements directly to application developers. 
         [0020]      FIG. 1  is a system diagram showing high-level components of an exemplary system  100  for automating a customer-demand-to-application-development process. As shown in  FIG. 1 , application store system  100  comprises a marketing and development cloud computing system  101 . A cloud computing system is a group of servers used to offload the processing and/or large-scale data storage from a user&#39;s computer system. Each server in system  101  includes associated memory  104  which includes an application search engine  103 , although the search engine may be external to processor  101 . Server memory includes programs  115  which perform the system software application development and marketing functions described herein. 
         [0021]    Marketing and development cloud computing system  101  is coupled to a database  105  and an ‘application deployment parallel computing cloud’  106  which includes at least one server cluster  107  which provides parallel processing capability for executing customer applications. A plurality of customers (who are also users of the applications described herein) and a plurality of developers access system  101  and other system components via, e.g., an Internet connection  130 , using respective computer systems  108  and  109  (only one of each is shown for clarity). Monitors  110  and  111  provide messages and data entry fields for communication between customers and developers. 
         [0022]      FIG. 2  is a flowchart showing an exemplary set of steps performed in an exemplary embodiment to determine whether a requested application is available. As shown in  FIG. 2 , at step  201 , a list of keywords associated with each application is stored in database file  121  along with the name of the corresponding application. At step  205 , a customer enters, via a screen displaying a system ‘main menu’ on the customer&#39;s computer system  108 , a list of keywords which define, or are associated with, a desired type of application, and then selects a ‘search’ button. The ‘main menu’ screen initially includes a field for entering the list of keywords and a ‘search’ button. At step  210 , when the ‘search’ button is selected, application search engine  103  searches ‘existing application keyword’ table  111  in database  105  for applications matching any of the keywords entered by the customer. Search engine  103  may match some of the keywords with existing applications, while other keywords may not have counterpart matching applications in database  105 . 
         [0023]    At step  215 , the system stores (in database  105 ) the keywords that do not match any existing applications. This information is used to determine new application types. The number of identical or similar keyword requests from different customers defines the potential market size. 
         [0024]    The developers participating in the present system have access to this market-demand information and can create applications to meet the demand, and add the keyword(s) to the keyword list for their applications, or, alternatively, the developers may simply ignore the market-demand information. 
         [0025]    If the keyword search produces no application matches (step  217 ) then the system displays a question asking for a short description of the needed application on an application description screen, at step  220 . The customer then enters a description of the needed application at step  225 , and sends the description and keyword list to system  101  (step  230 ), from which it can be accessed for use by the development community. The customer&#39;s display is then returned to the system main menu. This process allows customers to directly request new applications. The application description entered by the customer is then stored in a ‘new application keyword’ table  112  in database  105 , at step  235 . The application description is then used by one or more of the developers as a basis for, or at least a significant guideline in, developing a corresponding new application. Table 1 below is an example of the new application keyword table  112 . 
         [0000]    
       
         
               
               
               
               
               
             
           
               
                   
                 TABLE 1 
               
               
                   
                   
               
               
                   
                   
                   
                   
                 Functional 
               
               
                   
                 Keyword # 
                 Keyword 
                 Date 
                 Description 
               
               
                   
                   
               
             
             
               
                   
                 1 
                 fft 
                 May 18, 2010 
                 2-dimensional 
               
               
                   
                   
                   
                   
                 Fast Fourier 
               
               
                   
                   
                   
                   
                 Transform 
               
               
                   
                 — 
                 — 
                 — 
                 — 
               
               
                   
                   
               
             
          
         
       
     
         [0026]    In addition to prompting new market areas, keyword information may be used for tracking current market demand. Table 2 in  FIG. 3A  shows an exemplary representation of how the current market demand for an application may be tracked. As shown in  FIG. 3 , information associated with customer-entered keywords may include marketing-related information such as daily and monthly average requests, total sales amounts and number of licenses, retail, wholesale, and per-use license fees, and the number of per-use licenses issued. This information is compiled for each application that matches a particular keyword. 
         [0027]    A market tracking table  110 , stored in database  105 , includes the information shown in Table 2 ( FIG. 3A ), and may show up-to-the-minute market information. Since, in an exemplary embodiment, every keyword in keyword table  112  has an associated list of products with pricing information, the number of users, and sales figures, it becomes possible to create detailed marketing graphs. This information can be used by the development community to determine which products are in demand, and also to set competitive prices for those products. 
         [0028]    If the keyword search (at step  217 ) finds applications that match one or more keywords in the application description submitted by the customer, then an ‘Application Selection’ list  302 , containing a list of matching applications is displayed on an ‘Application Description’ screen  300 , at step  240 .  FIG. 3B  shows an exemplary ‘Application Description’ screen  300  which contains an Application Selection list  302  displaying matching applications and short descriptions thereof. 
         [0029]    At step  245 , the customer may select a an application name in the Application Selection list  302 , and a brief application description is shown for each matching application is then displayed. Application information is stored in database file  115 , and the information for each application references the corresponding application code stored in database file  120  (shown in  FIG. 1 ). A ‘Next Page’ button may be selected (e.g., by left-clicking on the button), to display the next page of applications, if there is more than one page to be displayed. The order in which the applications are displayed is a function of the ‘popularity’ of those applications, as determined by information stored in market tracking table  110 . 
         [0030]    At this point, if the customer finds no applications of interest in the Application Selection list, then the customer can either return to the main menu or select an application for which more information is desired. If a return to the main menu is chosen, then system operation resumes at step  205 . Otherwise, at step  250 , the customer selects an application name in the Application Selection list, and a detailed application description for the selected application is then displayed on an ‘Application Detail’ screen at step  255 . 
         [0031]      FIG. 4  shows an exemplary Application Detail screen  400 . The Checkout button on the Application Detail screen is disabled until an item has been placed in the shopping cart. To place an item into the shopping cart the user Selects the Add to Cart button  405  on the Application Detail screen. If the user wants to try out the application displayed on the Application Detail screen and the number of free uses (field  404 ) is greater than one then the user selects a Free Trial button  402  which activates the application and decreases the number of free uses by one. The number of free uses is set by the developer, during application development. When execution of the application is complete, control is returned to the Application Detail screen. The user can return to the Application selection list by selecting the Return button  406 . Selecting the Return button allows the user to obtain another application. 
         [0032]    A detailed description of the current application is shown when the Application Detail Screen is displayed. If the user wishes to purchase the selected application, then selecting the ‘Add to Cart’ button  405  from the Application Detail screen causes the shopping cart screen  500  to be displayed at step  260 . Selecting the Checkout button  401  from the Application Detail screen causes a Checkout screen (described below with respect to  FIG. 6 ) to be displayed. 
         [0033]      FIG. 5  shows an exemplary Shopping Cart screen  500 . Selecting the ‘Checkout’ button  501  on the Shopping Cart screen causes a Checkout screen to be displayed at step  265 . Selecting the Return button  503  causes the system to return to the Application Detail screen Selecting the ‘Get More Items’ button  502  causes the system to return to the ‘Application Description’ screen  300  displaying Application Selection List  302 . 
         [0034]      FIG. 6  shows an exemplary ‘Checkout’ screen. The only significant differences between selecting the Checkout button versus the Free-trial button are the license period and the price for the item displayed on the Checkout screen. If ‘Free Trial’ is selected, then the price is zero and, instead of a license period, there is a specified number of uses. If the ‘Purchase’ button  601  is selected on the Checkout screen, a ‘Purchase Method’ screen is displayed at step  270 . If the ‘Done’ button  602  is selected, the main menu is returned to. 
         [0035]    The Purchase Method screen comprises one or more buttons which allow a customer to select a purchasing mechanism such as a particular credit card or other payment method. Payment is then made, at step  275 , by selecting the appropriate payment method. Once payment is accepted, the system generates another screen with a client code identifying the client. The customer then selects a ‘Done’ button, which returns the customer to the system main menu. 
         [0036]      FIG. 7  is a flowchart showing a set of steps performed in an exemplary embodiment to implement a request for a functional or other change to an application. Associated with every application provided by the present system is a ‘Startup’ screen (displayed on monitor  110 ) that allows the user to interact with the developer community and request changes to application functionality and report errors. The Startup screen is part of the application interface, and is integrated with the application. The Startup screen is coupled to a communication program which provides a mechanism for communication between a system user and the development community via, for example, an Internet connection  130  (shown in  FIG. 1 ). 
         [0037]    The Startup screen includes a ‘Request Change’ button that allows the user (the customer) to request additional application functionality though a ‘Functionality Change Request’ screen, which includes a field for entering a request for changing particular aspects of the application. At step  705 , once the customer has selected the ‘Request Change’ button and entered the request indicating desired changes to application, the function change information is sent to the developer of the application at step  710 . 
         [0038]    An ‘Administrator’ main screen (displayed on monitor  111 ) is available for use by developers using the present system. When an administrative-level user (“administrator”) in the present system selects a ‘Client Request’ button, a ‘Client Function Request List’ screen is then displayed. The administrator can accept or reject each request. If (at step  715 ) the administrator rejects the request then the system sends an ‘Application Request Rejection’ notice, which includes a reason for the rejection, at step  720 . The developers&#39; messages are displayed on Startup screen, and if the customer&#39;s email address has been entered, (when the change request was made), then the response will also be sent to the entered email address. 
         [0039]    If the administrator accepts the request (i.e., agrees to provide the requested changes) then the system returns an acceptance message to the customer at step  725 , and (after appropriate payment by the customer) a developer then makes the requested changes at step  730 . After the work is completed and the administrator has issued a client publication, the administrator selects a button which causes the system to send a work completion email to the customer at step  735 . 
         [0040]      FIG. 8  is a flowchart showing a set of steps performed in an exemplary embodiment to report and repair a ‘bug’ in an application. The Startup screen includes a ‘Bug’ button. Selecting the Bug button at step  805  causes an Application Error Reporting screen to be displayed, into which the customer enters an application error description and an email address at step  810 . The customer then selects an ‘Enter Data’ button, and the system displays a ‘Applications data Input’ screen. The customer then enters the input data that generated the error at step  812 . The customer then selects a ‘Send’ button which causes the system to send the error description and customer email address to the appropriate developers at step  815 . 
         [0041]    The developer&#39;s Administrator Main screen includes a ‘Bug List’ button. Selecting the Bug List button causes a ‘Bug List’ screen to be displayed at step  820 . At step  825 , the administrator then selects a specific ‘bug’ from a list of outstanding ‘bugs’ to be fixed, which causes an ‘Algorithm Trace’ screen to be displayed at step  830 . 
         [0042]      FIG. 9  shows an exemplary Algorithm Trace screen  900 . The Algorithm Trace screen displays a block diagram  901  of the algorithm of interest that was published as the application whose code contains the reported ‘bug’. The block diagram  901  of the algorithm includes blocks representing modules, such as kernels (blocks  902 ,  903 ,  904 ) and internal algorithms (block  905 ), in the algorithm of interest, and shows data flow between the modules via arrows. 
         [0043]    At step  835 , the input to the algorithm is preset to the input values provided by the customer. The error is then traced by a developer using a ‘Trace’ button  906  to trace the activity and transformations through the kernels (and sub-algorithms) of the application to a specific kernel or internal algorithm at step  840 . If the kernel or algorithm causing the problem was created by the present development organization, then the creator of the faulty code is assigned error repair duties by the administrator. When the problem is repaired so that the data from the customer generates a correct response, the administrator re-publishes the application (at step  845 ), the bug is removed from the Bug list, and an ‘Application Error Repaired’ message is sent to the customer at step  850 , indicating that the reported bug has been fixed. 
         [0044]    In one embodiment, applications sold via the present method have a performance enhancement bar on the associated Startup screen. After the appropriate parameters are entered into the application, a Performance Enhancement Slider Bar becomes active. The Slider bar initially shows the processing time with a price of $0.00. This processing time can be decreased at a cost. Moving the Slider bar causes the processing time estimate to decrease while also increasing the cost. When the required performance is entered, the customer can select a Run button. If the price on the Slider bar is greater than zero then the system displays the Checkout screen. The user pays for the performance enhancement, and the system runs the job. If the price is zero then the system runs the job without displaying the Checkout screen. 
         [0045]    Application software can behave differently depending upon datasets and the input parameters used to define the processing performed on that data.  FIG. 10  is a flowchart showing a set of steps  1000  performed in an exemplary embodiment to compare the performance of two applications. When the Application Description screen  300 , which contains an Application Selection list  302 , is displayed, the customer selects two applications (at step  1005 ). The input screens of both selected applications then appear as separate popup windows at step  1010 . The input data is first entered into one window, then into the other window, followed by selecting a ‘Compare App’ button  301  (shown in  FIG. 3B ) at step  1015 . 
         [0046]    Only applications for which there is least one ‘number of free uses’ made available by the developer can be compared. If any ‘free uses’ are available (step  1017 ), the applications are run at step  1020 , and the output of each application is made available in a request data file and/or on an output popup screen at step  1025 . Statistics on the performance of each application are generated and displayed at step  1030 . These statistics may include, for example, minimum performance (e.g., Mb/sec.), minimum price per use, minimum price-to-performance ratio (e.g., $/Mb/sec.), maximum performance (e.g., Mb/sec.), maximum price per use (e.g., $/Mb/sec.), which includes performance booster cost, and maximum price-to-performance ratio (e.g., $/Mb/sec.). If any ‘free uses’ remain (step  1017 ), comparisons can continue until there are no further free uses. 
         [0047]    The above procedure allows a customer to fairly compare two applications, receive back the computed comparison values, and obtain price-to-performance data for each application using the customer&#39;s own dataset. The number of free uses feature allows the developer to limit the total number of free jobs that any particular MAC address consumes, thereby insuring that customers do not abuse the comparison feature.