US9270759B2 - Method and system for distributing one or more server-based services - Google Patents

Abstract

Presented are systems and methods for distributing server-based services using a service development platform. The service development platform acquires server-based service data associated with a first server-based service, and parses the server-based service data. The service development platform catalogs the parsed server-based service data into a server-based service catalog that contains one or more server-based services different from the first server-based service. Additionally, the service development platform receives a request from a client device for the first server-based service indexed in the server-based service catalog, and provides the first server-based service to the client device.

Description

FIELD

Example embodiments relate to distributing one or more server-based services, and in particular to a system and method to facilitate development, distribution, and monetization of one or more server-based services.

BACKGROUND

Mobile applications often utilize one or more server-based services. A server-based service (“SBS”) can be, for example, a location based service to determine weather, news feeds, billing service to manage transactions for an application, etc. Often application developers are forced to develop SBSs to meet the needs of their application, because there is no efficient way to determine if a similar SBS has been created, and if so, purchase or license that SBS.

Moreover, a server-based service (“SBS”) developer has little visibility of what SBSs have been created by other SBS developers. Thus, an SBS developer can find themselves expending company resources creating a SBS and unintentionally duplicate an existing SBS that was developed by a different SBS developer.

Additionally, SBS developers generally sell or license their SBSs independent from other SBS developers. Without a centralized distribution platform, SBSs can be at a disadvantage in selling or licensing their SBSs to other SBS developers and application developers.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made to the accompanying drawings showing example embodiments of the present application, and in which:

FIG. 1 shows, in block diagram form, an example system utilizing a service development platform;

FIG. 2 is a block diagram depicting example service development platform for development, distribution, and monetization of service development catalogs;

FIG. 3 illustrates an example service distribution graphical user interface;

FIG. 4 illustrates an example selected service distribution graphical user interface;

FIG. 5 illustrates an example server-based service upload graphical user interface; and

FIG. 6 shows a flowchart representing an example method performed on a service development platform for developing, distributing, and monetizing one or more server-based services;

FIG. 7 shows a flowchart representing an example method, performed on a service development platform, for providing one or more server-based services including a requested server-based service to a client device;

FIG. 8 shows a flowchart representing an example method performed on a client device in communication with a service development platform for developing, distributing and monetizing one or more server-based services; and

FIG. 9 shows a flowchart representing an example method, performed on a client device, for acquiring one or more server-based services including a requested server-based service.

DESCRIPTION OF EXAMPLE EMBODIMENTS

The example embodiments provided below describe a service development platform that facilitates development, distribution, and monetization of server-based services. The service development platform provides a central hub for service-based service developers to determine what service-based services are available, and based on what service-based services are available make decisions concerning future server-based service development. Additionally, the service development platform provides a central forum for the server-based service developers to sell their respective server-based services. Moreover, the service development platform can act as a central hub for application developers looking to purchase one or more server-based services to be utilized by their applications (for example, a location based weather service that could be integrated into a weather app on a mobile phone).

In some example embodiments, the service development platform acquires server-based service data associated with a first server-based service, and parses the server-based service data. The service development platform catalogs the parsed server-based service data into a server-based service catalog that contains one or more server-based services different from the first server-based service. Additionally, the service development platform receives a request from an application developer for the first server-based service contained in the server-based service catalog, and provides the first server-based service to the application developer.

In some example embodiments, service development platform utilizes one or more graphical user interfaces to interact with a user. The graphical user interfaces can, for example, be used for displaying one or more server-based services, uploading server-based services to service development platform, selecting one or more server-based services for purchase, etc.

Reference is now made toFIG. 1, which shows, in block diagram form, an example system utilizing a service development platform for developing, distributing, and monetizing server-based services (SBSs), generally designated100.System100 can include anetwork110, a public land mobile network (PLMN)120, one or morefinancial service providers130 and140,client devices150,160, and170, awireless access point180, and aservice development platform200.

Network110 can be, for example, the Internet, an intranet, a local area network, a wide area network, a campus area network, a metropolitan area network, an extranet, a private extranet, any set of two or more coupled electronic devices, or a combination of any of these or other appropriate networks. Network110 can also communicate with PLMN120, which is also referred to as a wireless wide area network (WWAN) or, in some cases, a cellular network.

System100 can include a number of financial service providers, for example,financial service providers130 and140.Financial service providers130 and140 can be banks (e.g., BANK of AMERICA), credit card companies (e.g., VISA, AMERICAN EXPRESS, etc.), financial intermediaries (e.g., PAYPAL), or some other organization that users pay for requested SBSs. For example,service development platform200 can bill a user ofclient device150 for downloading a particular server-based service, and can elect to receive payment fromfinancial service provider130.

System100 can include a number of client devices, for example,client devices150,160, and170.Client devices150,160, and170 can be, for example, smartphones, tablets, netbooks, desktop computers, and laptop computers. One ormore client devices150,160, and170, can be coupled to theservice development platform200, via thenetwork110. In some embodiments not shown one ormore client devices150,160, and170 are directly coupled toservice development platform200.Client devices150,160, and170 can include devices equipped for cellular communication throughPLMN120, devices equipped for Wi-Fi communications usingwireless access point180, or dual-mode devices capable of both cellular andcommunications using network110, or any combination thereof.Wireless access point180 can be configured to WLANs that operate in accordance with one of the IEEE 802.11 specifications. For example,client device170 is coupled wirelessly tonetwork110 usingwireless access point180, andclient device150 is coupled tonetwork110 via PLMN120.Client devices150,160, and170, can be equipped for Wi-Fi communications.

Client devices150,160, and170 can include one or more processors (not shown), a memory (not shown), and a data interface (not shown). The processor(s) can be a single or multiple microprocessors, field programmable gate arrays (FPGAs), or digital signal processors (DSPs) capable of executing particular sets of instructions. Computer-readable instructions can be stored on a tangible non-transitory computer-readable medium, such as a flexible disk, a hard disk, a CD-ROM (compact disk-read only memory), and MO (magneto-optical), a DVD-ROM (digital versatile disk-read only memory), a DVD RAM (digital versatile disk-random access memory), or a semiconductor memory. Alternatively, the methods can be implemented in hardware components or combinations of hardware and software such as, for example, ASICs, special purpose computers, or general purpose computers. While portions of the specification only refer to oneclient device150,160, and170, this is for simplification purposes only and, unless noted otherwise, is not meant to limit the described embodiments in any way.

Service development platform200 can include one or more processors (not shown), a memory (not shown), and a data interface (not shown). The processor(s) can be a single or multiple microprocessors, field programmable gate arrays (FPGAs), or digital signal processors (DSPs) capable of executing particular sets of instructions. Computer-readable instructions can be stored on a tangible non-transitory computer-readable medium, such as a flexible disk, a hard disk, a CD-ROM (compact disk-read only memory), and MO (magneto-optical), a DVD-ROM (digital versatile disk-read only memory), a DVD RAM (digital versatile disk-random access memory), or a semiconductor memory. Alternatively, the methods can be implemented in hardware components or combinations of hardware and software such as, for example, ASICs, special purpose computers, or general purpose computers.Service development platform200 can be implemented on a single computer, or in some instances be distributed across a plurality of computers. In some embodiments not shown, portions ofservice development platform200 can operate on one or more ofclient devices150,160, and170.Service development platform200 can be coupled to one or more ofclient devices150,160, and170 vianetwork110. In some embodiments not shown,service development platform200 is directly coupled to one ormore client devices150,160, and170. Additionally,development platform200 can be coupled to one or morefinancial service providers130 and140 vianetwork110.

FIG. 2 is a block diagram depicting exampleservice development platform200. As illustrated,service development platform200 includes aninterface module210, acatalog module220, abilling module230, acommunication module240, and adata storage module250. It is appreciated that one or more of these modules can be deleted, modified, or combined together with other modules.

Interface module210 displays graphical user interfaces (GUIs) allowing a user of a client device (for example,client devices150,160, and170) to interface withservice development platform200.Interface module210 can display a service distribution GUI that displays one or more SBSs available to download fromservice development platform200. SBSs can include location based services, communication services, fixed mobile convergence services, device management services, etc., or any combination thereof.FIG. 3 illustrates an exampleservice distribution GUI300 generated byservice development platform200.Service distribution GUI300 displays one or more featuredSBSs305,310, and315. Featured SBS are part of an SBS catalog maintained byservice development platform200. The SBS catalog is a searchable collection of SBSs compiled byservice development platform200. The SBSs within the SBS catalog can be indexed, for example, by platform (.NET platform, J2EE, etc.), by type of SBS service, by title, by SBS provider, by price, by license associated with the SBS, by ranking, by recommended SBSs, by related SBSs, etc. Additionally, in some embodiments, one or more of the featured SBSs can be a promotional advertisement, for example, featuredservice315. Featured SBSs can include anSBS name320, a name of theSBS provider325,short SBS description330, anSBS icon335, anSBS price340, anSBS rating345, or some combination thereof.Service distribution GUI300 can also display a listing of the topfree SBSs350, top paidSBSs355, or both. In some embodiments, topfree SBSs350 and top paidSBSs355 can include one or more of the SBSs that are the most downloaded. Alternatively, topfree SBSs350 and top paid355 can include one or more of the SBSs that have the highest user reviews. The SBSs displayed in topfree SBSs350 and top paidSBSs355 are part of the SBS catalog. Additionally, in some embodiments,service distribution GUI300 can include asearch field360.Search field360 allows a user to enter one or more search terms.Service development platform200 is configured to reference the SBS catalog using the entered search terms and to provide one or more results to the client device based on the SBS data referenced in the SBS catalog. For example, if a user enters “location based weather service” intosearch field360,service development platform200 could return one or more location based weather services that are indexed in the SBS catalog, for example, featuredservice305. Additionally,service distribution GUI300 can include acatalog button365. When selectedcatalog button365 can open a menu (not shown) illustrating one or more categories that that the user can search. The SBS catalog can include categories like, for example, location based services, news services, fixed mobile convergence services, device management services, etc., etc.

After a specific server-based service is selected usingservice distribution GUI300,interface module210 can display information related to the selected server-based service via a selected service distribution GUI.FIG. 4 illustrates an example selectedservice distribution GUI400 generated byinterface module210. Selectedservice distribution GUI400 can display anSBS name405,category path410, anSBS provider415, anSBS icon420, anSBS description425, a recommendedSBS section430, arelated SBS section435, adistribution platform section440, apurchase option section445, acheckout button450, a rankingvalue455, areview link460, or some combination thereof.

SBS name405 corresponds to the name associated with the selected SBS, for example, “Weather Location Service.”Category path410 displays the location of the selected SBS within the SBS catalog maintained byservice development platform200. For example, the “Weather Location Service” is located within the “Location Based” services category in the SBS catalog, and specifically, within a subcategory relating to “Weather” services. In some embodiments,SBS name405 corresponds to the data entered into an SBSname input field505 described below with respect toFIG. 5.

SBS provider415 can correspond to the name of the entity that is providing the SBS, the developer of the service, the owner of the service, etc. In this example, “Weather Location Service” is provided by “The Weather Company.” In some embodiments,SBS provider415 corresponds to the data entered into an SBSprovider input field515 described below with respect toFIG. 5.

SBS icon420 is an icon associated with the selected SBS. In some embodiments, the entity who uploaded the service to servicedistribution platform200 chooses the icon. In other embodiments,service distribution platform200 selects an icon to be associated with the SBS. In some embodiments,SBS icon420 corresponds to the icon uploaded into an SBSicon input field520 described below with respect toFIG. 5.

SBS description section420 can include a textual description of the selected SBS. For example,SBS description section420 can include information relating to functionality of the service, key points relating to the SBS, suggested uses for the SBS, real time status information, links to other related information, types of platform it can deployed on, other dependent SBS, etc. In some embodiments,SBS description section420 corresponds to the data entered into an SBSdescription input field525 described below with respect toFIG. 5.

Some SBSs operate only in conjunction with one or more different SBSs. For example, a weather SBS can require one or more SBSs relating to humidity, sunrise and sunset, visibility estimates, etc. Selectedservice distribution GUI400 includes recommendedSBS section430 that displays any SBSs that are recommended for use with the selected SBS.Interface module210 can determine if any SBS are recommend for use with the selected SBS, for example, by referencing the SBS data associated with the selected SBS in the SBS catalog. InFIG. 4, the Weather Location Service has no recommended services. In some embodiments, not shown,interface module210 automatically adds a purchase option that includes purchase information of both the selected server-based service and any server-based service displayed in recommendedSBS section430. In some embodiments, the user is prompted to purchase any recommended SBSs on checkout. In some embodiments, recommendedSBS section430 corresponds to the data entered into a recommendedservice input field530 described below with respect toFIG. 5.

Additionally, selectedservice distribution GUI400 can display one or more related SBSs inrelated SBS section435. Related SBSs are those that servicedevelopment platform200 indicates the user would be interested in based in part on the type of selected SBS being viewed. The related SBSs can automatically be determined byservice development platform200. For example,service development platform200 can analyze purchase history data to determine other SBSs that are generally purchased by users who purchase the selected SBS being viewed, and then display these other SBSs inrelated SBS section435. In some embodiments,service development platform200 determines related SBSs by listing other SBSs that perform similar functionality, by listing other SBSs within the same category, by listing other SBSs developed by the same SBS provider of the selected SBS, etc. In some embodiments,related SBS section435 corresponds to the data entered into a relatedSBS input field535 described below with respect toFIG. 5.

SBSs are generally configured to operate on specific platforms such as J2EE based platform or .Net platform but can be made generic too to run on any open source or proprietary platform. Selectedservice distribution GUI400 can includedistribution platform section440.Distribution platform section440 displays one or more platforms on which the selected SBS can operate. For example, the Weather Location Service inFIG. 4 can be purchased to operate on either on a .NET platform or some other platform (for example, J2EE, etc.). For SBSs that only operate on a single platform, selectedservice distribution GUI400 automatically selects the distribution platform displayed indistribution platform section440. In some embodiments,distribution platform section440 corresponds to the data entered into a distributionplatform input field540 described below with respect toFIG. 5.

Selectedservice distribution GUI400 can also includepurchase option section445.Purchase option section445 can include one or more purchase options associated with the selected SBS. Purchase options can include, for example, a onetime fee, a per use fee, period billing, a per license fee, and free download, or some combination thereof. The onetime fee is a fee that the user is charged only once, to obtain access to the selected SBS. Period billing is a fee type where the user is charged for use of the selected SBS at periodic intervals, for example, daily, monthly, annually, etc. The per use fee is a fee that the user is charged every time the selected SBS is used. The per license fee is a fee associated with the number of licenses sought for the particular service. Free download allows the user to receive the service without having to pay a fee. In some embodiments,purchase option section445 corresponds to the data entered into a purchaseoption input field545 described below with respect toFIG. 5.

In some embodiments, each of the purchase options presented to the user will have an associated license. In some embodiments, the license can be the same for each purchase option. In alternate embodiments, when a plurality of purchase options are displayed each purchase options can have different licensing restrictions. For example, the license associated with a free download can be different with the license associated with a monthly fee.

Once a purchase option and distribution platform are selected, a user can selectcheckout button450. Aftercheckout button450 is selected,interface module210 displays to the user a checkout GUI (not shown) that allows the user to confirm the purchase information, enter billing information, and provide other information needed to complete the transaction.

In some embodiments, selectedservice distribution GUI400 can include aranking value455. A predetermined time after a selected SBS is purchased,service development platform200 can be configured to automatically contact (for example, send an email) the purchaser of the selected SBS and ask them to provide a review. In this embodiment, rankingvalue455 is based on one or more reviews of the selected SBS. Selectedservice distribution GUI400 can also display areview link460 to one or more reviews associated with rankingvalue455.Review link460 can be text based or be an icon. In this embodiment, review link460 is text based and indicates the total number of reviews. After a user selectsreview link460,service distribution platform200 is configured to display a GUI (not shown) listing one or more reviews associated with the selected SBS.

In some embodiments,service distribution platform200 can be configured to act as a central hub to distribute one or more SBSs to other service developers and to application developers. For example, a server-based service (SBS) developer can upload and make for sale a news feed SBS toservice distribution platform200.Interface module210 is additionally configured to display an SBS upload GUI to facilitate uploading SBS data to the SBS catalog.FIG. 5 illustrates an example SBS uploadGUI500 generated byinterface module210. SBS uploadGUI500 can display an SBSname input field505, a keyword input field510, a suggested cataloglocation input field512, an SBSprovider input field515, anicon input field520, an SBSdescription input field525, a recommendedSBS input field530, a relatedSBS input field535, a distributionplatform input field540, a purchaseoption input field545, an SBS uploadinput field550, an submitbutton555, or some combination thereof.

The user can enter a name of the SBS (for example, Weather Location Service) into SBSname input field505. Likewise, the user can enter a company name (for example, The Weather Company) to be affiliated with the SBS being uploaded into SBSprovider input field515. In some embodiments (not shown), SBSprovider input field515 can contain one or more sub-fields for company contact information. Additionally, the user usingicon input field520 can upload an icon to be affiliated with the SBS to be uploaded.

The user can additionally enter one or more key words into keyword input field510. After the SBS has been uploaded intoservice distribution platform200, the data entered into keyword input field510 is linked to the SBS that was uploaded. Such that a search performed by a user (for example, using search field360) using one or more of the entered key words can causeservice distribution platform200 to display the uploaded SBS as one of the results.

Additionally, the user can enter a suggested SBS catalog location using suggested cataloglocation input field512. In some embodiments, this is a drop down menu displaying the list of available categories in the SBS catalog which the SBS to be uploaded can potentially be associated with. Categories can include, for example, mobile services, location based services, fixed mobile convergence services, device management services, etc. A specific category-subcategory combination references a particular location within the SBS catalog. Additionally, within each category, there can be one or more subcategories, and within each subcategory there can be one or more additional subcategories, and so on, until an adequate level of description is reached. For example, within the SBS catalog there can be a location based services category, and within this category there can be a weather related subcategory, a news related subcategory, etc. Additionally, in some embodiments, a SBS being uploaded can be associated with a plurality of categories, subcategories, or some combination thereof.

The user can additionally enter a description of the SBS to be uploaded using SBSdescription input field525. For example, SBSdescription input field525 can include information relating to functionality of the service, key points relating to the SBS, suggested uses for the SBS, real time status information, links to other related information, types of platform it can deployed on, other dependent SBS, etc.

As discussed above, some SBSs operate potentially only in conjunction with one or more different SBSs. SBS uploadGUI500 includes recommendedSBS input field530 for any SBSs that the SBS to be uploaded potentially needs for operation. The user can enter any SBSs that are recommended for use with the SBS to be uploaded.

Additionally, in some embodiments, SBS uploadGUI500 is configured to include relatedSBS input field535. The user can enter one or more related SBSs into relatedSBS input field535. In embodiments not shown, any related SBS are automatically determined byservice distribution platform200 and not by the user. For example,service development platform200 can be configured to analyze purchase history data to determine other SBSs that are generally purchased by users who purchase the selected SBS being viewed. In some embodiments,service development platform200 is configured to determine related SBSs by listing other SBSs that perform similar functionality, by listing other SBSs within the same catalog, by listing other SBSs developed by the same developer of the selected SBS, etc.

The user can enter different platforms that the SBS to be uploaded is configured to operate with usingdistribution platform input540. As discussed above, SBSs are generally configured to operate on specific platforms such as J2EE based platform or .Net platform but can be made generic too to run on any open source or proprietary platform. In some embodiments not shown,distribution platform input540 contains one or more subfields specific to different operating systems, such that the user only has to select the appropriate operating system.

The user can select a pricing strategy using purchaseoption input field545. Purchaseoption input field545 can include one or more purchase options associated with the SBS to be uploaded. Purchase options can include, for example, a onetime fee, a per use fee, period billing, a per license fee, and free download, or some combination thereof. The onetime fee is a fee that the user is charged only once, to obtain access to the SBS. Period billing is a fee type where the user is charged for use of the SBS at periodic intervals, for example, daily, monthly, annually, etc. The per use fee is a fee that the user is charged every time the SBS is used. The per license fee is a fee associated with the number of licenses sought for the particular SBS. Free download allows the user to receive the SBS without having to pay a fee.

The user can attach SBS data used to implement the SBS using SBS uploadinput field550. For example, the SBS data can be an executable program module which allows access to SBS. In other embodiments, no SBS data is uploaded. In this embodiment, once an SBS is purchasedservice development platform200 generates a unique transaction number which it provides to the purchaser of and to the provider of the SBS. The purchaser can then use the transaction number to receive service from the SBS provider.

Additionally, in some embodiments not shown SBS uploadGUI500 includes a documentation input field. The documentation input field allows a user to upload documents associated with the SBS to be uploaded. Documentation can be information relating to the proper use of the SBS, compatibility with other SBSs, de-bugging information, license information, etc.

The user completes the upload by selecting submitbutton555. After submitbutton555 is selected,interface module210 displays to the user an upload checkout GUI (not shown) that allows the user to confirm the SBS to be uploaded and provide other information potentially needed to complete the transaction. In some embodiments, the upload checkout GUI also asks the user for licensing information. For example, each of the payment options selected by the user can have a unique license associated with it conditioning the use of the SBS to the terms of the license. Additionally, the upload checkout GUI can be configured to ask the user to agree to a set of license and terms associated with selling their SBS usingservice distribution platform200. In some embodiments, the license and terms can be structured such that the user agrees to pay a certain percentage of each sale to a particular entity. For example, theservice distribution platform200 can condition uploading an SBS on a 10% cut of every sale made usingservice distribution platform200.

Referring back toFIG. 2,interface module210 can be coupled tocatalog module220,billing module230,communication module240, anddata storage module250.

Catalog module220 is configured to analyze and parse information obtained from SBS uploadGUI500 to associate the SBS being uploaded with one or more categories and subcategories in the SBS catalog. A specific category-subcategory combination references a particular location within the SBS catalog. The SBS catalog is a searchable collection of SBSs compiled byservice development platform200. The SBSs within the SBS catalog can be indexed by, for example, platform, type of SBS service, title, SBS provider, price, license associated with the SBS, ranking, recommended SBSs, related SBSs, etc. In some embodiments,catalog module220 parses information in one or more of the input fields of SBS uploadGUI500 to determine the correct placement of the uploaded SBS within the SBS catalog. For example,catalog module220 can be configured to analyze the parsed information for words and phrases like “weather,” “GPS,” “storm,” “can be used with .NET platform or J2EE,” etc. Additionally,catalog module320 can be further configured to compare the parsed information with the information entered into suggested cataloglocation input field512 to determine if the user's suggested placement within the SBS catalog is correct. For example, each catalog location can have certain terms and phrases associated with it more frequently than others.Catalog module220 can be configured to compare the parsed information with terms and phrases associated with different locations within the SBS catalog, and determine one or more locations based on the similarity of the terms and phrases. In some embodiments,catalog module220 can be configured to compare the determined one or more SBS catalog locations with any catalog locations suggested by the user. In some embodiments, if the similarity between the determined and suggested locations are below a predetermined threshold,catalog module220 can be configured to override one or more of the user's suggested SBS catalog locations and index the uploaded SBS data with one or more of the determined SBS catalog locations. After the SBS catalog location has been confirmed,catalog module220 is configured to store the uploaded SBS, using for example,data storage module250.Catalog module220 can be coupled tointerface module210,billing module230,communication module240, anddata storage module250.

Billing module230 is configured to monitor accounts for one or more users ofservice development platform200. After a user purchases an SBS,billing module230 is configured to determine what percentage of the purchase price is received by an entity controllingservice development platform200 and what percentage of the purchase price is directed toward the SBS provider.Billing module230 is configured to determine the fee split between the hosting entity and the SBS provider by referencing the conditions agreed to the SBS provider when the particular SBS service was uploaded toservice development platform200. The fee split can be determined in any number of ways. For example, the SBS provider could have agreed to provide the hosting entity with 20% of any sale of the uploaded SBS usingservice development platform200.Billing module230 is configured to communicate with one or more financial service providers (for example,financial service providers130 and140) to complete the purchase process. For example, the fee paid by a user purchasing a particular SBS can be 100 dollars.Billing module230 would then coordinate (via communication module240) with the one or more financial service providers such that the entity controllingserver development platform200 receives 20 dollars (20% of total price) and the SBS provider receives the remaining 80 dollars. Additionally, in some embodiments,billing module230 merely maintains a running tally of downloads of the SBS and bills the SBS provider periodically (for example, daily, monthly, annually, etc.) for the amount of fees incurred over the specified time period. Additionally,billing module230 can be configured to notifycommunication module250 that one or more charges for a SBS have cleared and authorizecommunications module240 to provide the SBS to the purchaser (for example, user of the client device) of the SBS.Billing module230 can be coupled tointerface module210,catalog module220,communication module240, anddata storage module250.

Communication module240 is configured to communicate with one or more client devices (for example,client devices150,160, and170). For example,communication module240 is configured to allow a user of a remote client device to login into service development platform200 (for example, using service distribution GUI300), upload an SBS intoservice distribution platform200, purchase an SBS, or some combination thereof. Additionally,communication module240 is configured to allow communication betweenservice development platform200 and one or more financial service providers (for example,130 and140). In some embodiments,communication module240 is configured to generate a unique transaction identifier after an SBS has been authorized to be provided to the purchaser of the SBS. The transaction identifier can be, for example, a unique alphanumeric string of characters that are associated with the transaction.Communication module240 can be further configured to provide the transaction identifier to the client device and one or more SBS providers. The client device can then provide the transaction number to the SBS provider of the purchased SBS. The user can then use the transaction identifier to receive service from one or more of the SBS providers. In some embodiments, each SBS has a unique transaction identifier. While in other embodiments, the transaction number is associated with one or more of the purchased SBSs.Communication module240 can be coupled tointerface module210,catalog module220,billing module230, anddata storage module250.

Data storage module250 includes a database, one or more computer files in a directory structure, or any other appropriate data storage mechanism, such as a memory.Data storage module250 stores, for example, user profile information, one or more SBSs, descriptive information relating to stored SBSs, an SBS catalog, billing information, etc. User profile information can include, for example, name, place of employment, work phone number, home address, billing preference, identities of SBS uploaded intoservice distribution platform200, etc. One or more SBSs are stored indata storage module250 and are indexed in a searchable SBS catalog. Additionally, each of the stored one or more SBSs can include associated descriptive information. For example, SBS name, icon, SBS description, recommended SBS, related SBS, etc., as discussed above in reference toFIGS. 4 and 5. In some example embodiments,data storage module250 is distributed across one or more network servers.Data storage module250 can be coupled tointerface module210,catalog module220,billing module230, andcommunication module240.

Each ofmodules210,220,230, and240 can be software programs stored in a RAM, a ROM, a PROM, a FPROM, or other dynamic storage devices, or persistent memory for storing information and instructions.

FIG. 6 is a flowchart representing an example method performed on a service development platform for developing, distributing, and monetizing one or more SBSs. While the flowchart discloses the following steps in a particular order, it is appreciated that at least some of the steps can be moved, modified, or deleted where appropriate.

Instep605, SBS data is acquired. SBS data can include an SBS name, one or more key words, a suggested SBS catalog location, an SBS provider name, an SBS icon, an SBS description, one or more recommended SBSs, one or more related SBSs, distribution platform information, purchase options, SBS documentation, an SBS program, or some combination thereof. The SBS data can be acquired when a client device uploads SBS data to one or more servers hosting the service development platform. In some embodiments, the data can be uploaded using one or more GUIs, for example, SBS uploadGUI500.

Instep610, the acquired SBS data is parsed and instep615 the parsed SBS data is cataloged in an SBS catalog. The SBS catalog is a searchable collection of SBSs compiled by the service development platform. The SBSs within the SBS catalog can be indexed, for example, by platform, by type of SBS service, by title, by SBS provider, by price, by license associated with the SBS, by ranking, by recommended SBSs, by related SBSs, etc. The service development platform analyzes the parsed information for words and phrases like “weather,” “GPS,” “storm,” “can be used with .Net platform or J2EE,” etc. A specific category-subcategory combination references a particular location within the SBS catalog. The service development platform compares the parsed SBS data with terms and phrases associated with different categories and subcategories within the SBS catalog. The service development platform determines one or more locations to associate the SBS based on the similarity of the terms and phrases with the parsed SBS data. In some embodiments, the service development platform compares the parsed information with any suggested SBS catalog locations to determine if one or more of the suggested locations are correct. For example, each SBS catalog location can have certain terms and phrases associated with it more frequently than others. In some embodiments, if the similarity between one or more of the determined and suggested locations are below a predetermined threshold the service development platform overrides one or more of the suggested SBS catalog locations and indexes the acquired SBS data in one or more of the determined SBS catalog locations.

Instep620, the service development platform provides the SBS catalog to a client device. The SBS catalog can be provided in the form of one or more GUIs, for exampleservice distribution GUI300. Instep625, a request is received for an SBS in the SBS catalog. For example, the client device can request a particular SBS for purchase using selectedservice distribution GUI400. Additionally, in some embodiments, the user can also purchase one or more additional SBSs to concurrent with the requested SBS. Instep630, the service development platform provides the one or more SBSs including the requested SBS.

FIG. 7 is a flowchart representing an example method, performed on a service development platform, for providing one or more SBSs including the requested SBS to a client device. While the flowchart discloses the following steps in a particular order, it is appreciated that at least some of the steps can be moved, modified, or deleted where appropriate.

In step705, the service development platform determines if there are any recommended SBSs associated with a requested SBS. If there are recommended SBSs, the service development system sends a prompt to the client device (step710). The prompt asks the user of the client device if they wish to purchase any of the recommended SBSs as well as the requested SBS (step715). If one or more of the recommended SBSs are to be purchased, then the service development system bills the user for the requested SBS and the one or more recommended SBSs elected for purchase (step720). Instep725, the service development platform provides the purchased SBS and recommended SBSs to the user. For example, the service development platform can make available for download the SBS programs associated with the purchased SBS and the recommended SBSs. In some embodiments, the service development platform generates a unique transaction identifier that is provided to the purchaser of and to the provider of the purchased SBS. The transaction identifier can be for example, unique alphanumeric string of characters that are associated with the transaction. The purchaser can then use the transaction identifier to receive service from one or more SBS providers. In some embodiments, each SBS has a unique transaction identifier. While in other embodiments, the transaction identifier is associated with one or more of the purchased SBSs. The process then ends (step740).

If the user does not elect to purchase any of the recommended SBSs or if there are no recommended SBSs associated with the selected SBS, instep730, the service development platform bills the user for the requested SBS. The service development platform then provides the SBS to the user (step735). For example, the service development platform can make available for download the SBS program associated with the purchased SBS. In some embodiments, the service development platform generates a unique transaction identifier that is provided to the purchaser of and to the provider of the purchased SBS. The purchaser can then use the transaction identifier to receive service from the SBS provider. The process then ends (step740).

FIG. 8 is a flowchart representing an example method performed on a client device in communication with a service development platform for developing, distributing, and monetizing one or more SBSs. While the flowchart discloses the following steps in a particular order, it is appreciated that at least some of the steps can be moved, modified, or deleted where appropriate.

Instep805, SBS data is acquired. SBS data can include an SBS name, one or more key words, a suggested SBS catalog location, an SBS company name, an SBS icon, an SBS description, one or more recommended SBSs, one or more related SBSs, distribution platform information, purchase options, SBS documentation, an SBS program, or some combination thereof. For example, the SBS data can be acquired from a user of the client device. In some embodiments, the data can be acquired using one or more GUIs, for example, SBS uploadGUI500. Instep810, the acquired SBS data is transmitted to the service development platform.

Instep815, the client device requests an SBS catalog from the service development platform. The SBS catalog contains searchable data describing one or more SBSs indexed within the SBS catalog. Instep820, the client device receives the requested SBS catalog. The SBS catalog can be referenced by the client using one or more GUIs, for example,service distribution GUI300 and selectedservice distribution GUI400. For example, the user can search for particular services using one or more keywords, browse SBSs by catalog location, etc. Instep825, the client device requests that an SBS be provided from those SBSs listed in the SBS catalog. In some embodiments, client device requests the SBS using selectedservice distribution GUI400. Additionally, in some embodiments, the user can also purchase one or more additional SBSs concurrent with the requested SBS. Instep830, the client device acquires one or more SBSs, including the requested SBS.

FIG. 9 is a flowchart representing an example method, performed on a client device, for acquiring one or more SBSs including the requested SBS. While the flowchart discloses the following steps in a particular order, it is appreciated that at least some of the steps can be moved, modified, or deleted where appropriate.

Instep905, the client device determines if the service development platform has identified one or more recommended SBSs. If there are recommended SBSs, the client device prompts the user to purchase one or more of the recommended SBSs (step910). The prompt asks the user of the client device if they wish to purchase any of the recommended SBSs as well as the requested SBS. Instep915, the client device receives input from the user that determines whether the user wishes to purchase one or more of the recommended SBSs in addition to the requested SBS, or only the requested SBS.

If one or more of the recommended SBSs are purchased, instep920, the client device downloads the requested SBS and one or more of the recommended SBSs. For example, the client device can download the SBS programs associated with the purchased SBS and the recommended SBSs. In some embodiments, the client device downloads a unique transaction identifier from the service development platform. The transaction identifier can be for example, unique alphanumeric string of characters that are associated with the transaction. The client device can then provide the transaction number to the SBS provider of the purchased SBS. The user can then use the transaction identifier to receive service from one or more of the SBS providers. In some embodiments, each SBS has a unique transaction identifier. While in other embodiments, the transaction number is associated with one or more of the purchased SBSs. The process then ends (step935).

If the user does not elect to purchase any of the recommended SBSs or if there are no recommended SBSs associated with the selected SBS, instep925, the client device facilitates the purchase of the requested SBS. Instep930, the client device downloads the requested SBS. For example, the client device can download the SBS programs associated with the purchased SBS service. In some embodiments, the client device downloads a unique transaction identifier from the service development platform. The client device can then provide the transaction identifier to the provider of the purchased SBS. The user can then use the transaction identifier to receive service from the SBS provider. The process then ends (step935).

Certain adaptations and modifications of the described embodiments can be made. Therefore, the above discussed embodiments are considered to be illustrative and not restrictive.

Embodiments of the present application are not limited to any particular operating system, mobile device architecture, server architecture, or computer programming language.

Claims (20)

What is claimed is:

1. A method comprising:

acquiring server-based service data associated with a first server-based service developed by a first application developer, the server-based service data including one or more purchase options of the first server-based service, the purchase options specified by the first application developer;

parsing the server-based service data on a service development platform;

cataloging the parsed server-based service data into a server-based service catalog that contains one or more server-based services different from the first server-based service;

receiving a request from a client device of a second application developer for the first server-based service indexed in the server-based service catalog, the first server-based service to be used by the second application developer in developing a mobile application;

determining that a purchase transaction of the first server-based service is completed by the second application developer according to the one or more purchase options associated with the first server-based service; and

providing the first server-based service to the client device of the second application developer in response to the determination.

2. The method ofclaim 1, wherein the provided first server-based service can be utilized by an application running on a mobile device.

3. The method ofclaim 1, further comprising:

determining if one or more recommended server-based services are associated with the first server-based service; and

sending a prompt to the client based on the determination.

4. The method ofclaim 3, further comprising:

providing one or more of the recommended server-based services to the client device.

5. The method ofclaim 1, further comprising:

generating a secure transaction identifier;

providing the secure transaction identifier to a user of the client device; and

providing the secure transaction identifier to a server-based service provider associated with the first server-based service.

6. The method ofclaim 1, wherein the server-based service data associated with the first server-based service is uploaded by the first application developer to the service development platform.

7. The method ofclaim 1, wherein cataloging the parsed server-based service data into a server-based service catalog includes:

comparing the parsed server-based service data with terms and phrases associated with categories in the server-based service catalog; and

determining a first server-based service category in the server-based service catalog based on the comparison between the parsed server-based service data and the terms and phrases associated with the categories in the server-based service catalog.

8. The method ofclaim 1, further comprising providing the server-based service catalog to the client device, wherein the server-based service catalog includes the first server-based service for selection.

9. The method ofclaim 8, wherein the one or more server-based services different from the first server-based service are available for selection.

10. The method ofclaim 1, wherein the one or more purchase options associated with the first server-based service comprises one or more of a onetime fee, a per use fee, period billing, a per license fee, and free download.

11. The method ofclaim 1, each of the one or more purchase options associated with the first server-based service have an associated license conditioning use of the first server-based service to terms of the license.

12. A system comprising:

one or more hardware processors;

an interface module operable with the one or more hardware processors and configured to acquire server-based service data associated with a first server-based service developed by a first application developer, the server-based service data including one or more purchase options of the first server-based service, the purchase options specified by the first application developer;

a catalog module operable with the one or more hardware processors and configured to:

parse the server-based service data on a service development platform, and

catalog the parsed server-based service data into a server-based service catalog that contains one or more server-based services different from the first server-based service;

wherein the interface module is further configured to receive a request from a client device of a second application developer for the first server-based service indexed in the server-based service catalog, the first server-based service to be used by the second application developer in developing a mobile application;

a billing module operable with the one or more hardware processors and configured to determine that a purchase transaction of the first server-based service is completed by the second application developer according to the one or more purchase options associated with the first server-based service; and

a communication module operable with the one or more hardware processors and configured to provide the first server-based service to the client device of the second application developer in response to determining that the purchase transaction of the first server-based service is completed.

13. The system ofclaim 12, wherein the provided first server-based service can be utilized by an application running on a mobile device.

14. The system ofclaim 12, wherein the interface module is further configured to:

determine if one or more recommended server-based services are associated with the first server-based service; and

send a prompt to the client based on the determination.

15. The system ofclaim 14, wherein the communication module is further configured to:

provide one or more of the recommended server-based services to the client device.

16. The system ofclaim 12, wherein the communication module is further configured to:

generate a secure transaction identifier;

provide the secure transaction identifier to a user of the client device; and

provide the secure transaction identifier to a server-based service provider associated with the first server-based service.

17. The system ofclaim 12, wherein the server-based service data associated with the first server-based service is uploaded by the first application developer to the service development platform.

18. The system ofclaim 12, wherein the catalog module is further configured to:

compare the parsed server-based service data with terms and phrases associated with categories in the server-based service catalog; and

determine a first server-based service category in the server-based service catalog based on the comparison between the parsed server-based service data and the terms and phrases associated with the categories in the server-based service catalog.

19. A non-transitory computer-readable storage medium storing instructions that, when executed by a service development platform, cause the service development platform to perform a method, the method comprising:

acquiring server-based service data associated with a first server-based service developed by a first application developer, the server-based service data including one or more purchase options of the first server-based service, the purchase options specified by the first application developer;

parsing the server-based service data on a service development platform;

cataloging the parsed server-based service data into a server-based service catalog that contains one or more server-based services different from the first server-based service;

receiving a request from a client device of a second application developer for the first server-based service indexed in the server-based service catalog, the first server-based service to be used by the second application developer in developing a mobile application;

determining that a purchase transaction of the first server-based service is completed by the second application developer according to the one or more purchase options associated with the first server-based service; and

providing the first server-based service to the client device of the second application developer in response to the determination.

20. The computer-readable storage medium ofclaim 19, wherein the provided first server-based service can be utilized by an application running on a mobile device.

Images