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

- BlackBerry Limited

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.

Skip to: Description  ·  Claims  ·  References Cited  · Patent History  ·  Patent History
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 to FIG. 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 designated 100. System 100 can include a network 110, a public land mobile network (PLMN) 120, one or more financial service providers 130 and 140, client devices 150, 160, and 170, a wireless access point 180, and a service development platform 200.

Network 110 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. Network 110 can also communicate with PLMN 120, which is also referred to as a wireless wide area network (WWAN) or, in some cases, a cellular network.

System 100 can include a number of financial service providers, for example, financial service providers 130 and 140. Financial service providers 130 and 140 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 platform 200 can bill a user of client device 150 for downloading a particular server-based service, and can elect to receive payment from financial service provider 130.

System 100 can include a number of client devices, for example, client devices 150, 160, and 170. Client devices 150, 160, and 170 can be, for example, smartphones, tablets, netbooks, desktop computers, and laptop computers. One or more client devices 150, 160, and 170, can be coupled to the service development platform 200, via the network 110. In some embodiments not shown one or more client devices 150, 160, and 170 are directly coupled to service development platform 200. Client devices 150, 160, and 170 can include devices equipped for cellular communication through PLMN 120, devices equipped for Wi-Fi communications using wireless access point 180, or dual-mode devices capable of both cellular and communications using network 110, or any combination thereof. Wireless access point 180 can be configured to WLANs that operate in accordance with one of the IEEE 802.11 specifications. For example, client device 170 is coupled wirelessly to network 110 using wireless access point 180, and client device 150 is coupled to network 110 via PLMN 120. Client devices 150, 160, and 170, can be equipped for Wi-Fi communications.

Client devices 150, 160, and 170 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 one client device 150, 160, and 170, this is for simplification purposes only and, unless noted otherwise, is not meant to limit the described embodiments in any way.

Service development platform 200 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 platform 200 can be implemented on a single computer, or in some instances be distributed across a plurality of computers. In some embodiments not shown, portions of service development platform 200 can operate on one or more of client devices 150, 160, and 170. Service development platform 200 can be coupled to one or more of client devices 150, 160, and 170 via network 110. In some embodiments not shown, service development platform 200 is directly coupled to one or more client devices 150, 160, and 170. Additionally, development platform 200 can be coupled to one or more financial service providers 130 and 140 via network 110.

FIG. 2 is a block diagram depicting example service development platform 200. As illustrated, service development platform 200 includes an interface module 210, a catalog module 220, a billing module 230, a communication module 240, and a data storage module 250. It is appreciated that one or more of these modules can be deleted, modified, or combined together with other modules.

Interface module 210 displays graphical user interfaces (GUIs) allowing a user of a client device (for example, client devices 150, 160, and 170) to interface with service development platform 200. Interface module 210 can display a service distribution GUI that displays one or more SBSs available to download from service development platform 200. SBSs can include location based services, communication services, fixed mobile convergence services, device management services, etc., or any combination thereof. FIG. 3 illustrates an example service distribution GUI 300 generated by service development platform 200. Service distribution GUI 300 displays one or more featured SBSs 305, 310, and 315. Featured SBS are part of an SBS catalog maintained by service development platform 200. The SBS catalog is a searchable collection of SBSs compiled by service development platform 200. 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, featured service 315. Featured SBSs can include an SBS name 320, a name of the SBS provider 325, short SBS description 330, an SBS icon 335, an SBS price 340, an SBS rating 345, or some combination thereof. Service distribution GUI 300 can also display a listing of the top free SBSs 350, top paid SBSs 355, or both. In some embodiments, top free SBSs 350 and top paid SBSs 355 can include one or more of the SBSs that are the most downloaded. Alternatively, top free SBSs 350 and top paid 355 can include one or more of the SBSs that have the highest user reviews. The SBSs displayed in top free SBSs 350 and top paid SBSs 355 are part of the SBS catalog. Additionally, in some embodiments, service distribution GUI 300 can include a search field 360. Search field 360 allows a user to enter one or more search terms. Service development platform 200 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” into search field 360, service development platform 200 could return one or more location based weather services that are indexed in the SBS catalog, for example, featured service 305. Additionally, service distribution GUI 300 can include a catalog button 365. When selected catalog button 365 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 using service distribution GUI 300, interface module 210 can display information related to the selected server-based service via a selected service distribution GUI. FIG. 4 illustrates an example selected service distribution GUI 400 generated by interface module 210. Selected service distribution GUI 400 can display an SBS name 405, category path 410, an SBS provider 415, an SBS icon 420, an SBS description 425, a recommended SBS section 430, a related SBS section 435, a distribution platform section 440, a purchase option section 445, a checkout button 450, a ranking value 455, a review link 460, or some combination thereof.

SBS name 405 corresponds to the name associated with the selected SBS, for example, “Weather Location Service.” Category path 410 displays the location of the selected SBS within the SBS catalog maintained by service development platform 200. 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 name 405 corresponds to the data entered into an SBS name input field 505 described below with respect to FIG. 5.

SBS provider 415 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 provider 415 corresponds to the data entered into an SBS provider input field 515 described below with respect to FIG. 5.

SBS icon 420 is an icon associated with the selected SBS. In some embodiments, the entity who uploaded the service to service distribution platform 200 chooses the icon. In other embodiments, service distribution platform 200 selects an icon to be associated with the SBS. In some embodiments, SBS icon 420 corresponds to the icon uploaded into an SBS icon input field 520 described below with respect to FIG. 5.

SBS description section 420 can include a textual description of the selected SBS. For example, SBS description section 420 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 section 420 corresponds to the data entered into an SBS description input field 525 described below with respect to FIG. 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. Selected service distribution GUI 400 includes recommended SBS section 430 that displays any SBSs that are recommended for use with the selected SBS. Interface module 210 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. In FIG. 4, the Weather Location Service has no recommended services. In some embodiments, not shown, interface module 210 automatically adds a purchase option that includes purchase information of both the selected server-based service and any server-based service displayed in recommended SBS section 430. In some embodiments, the user is prompted to purchase any recommended SBSs on checkout. In some embodiments, recommended SBS section 430 corresponds to the data entered into a recommended service input field 530 described below with respect to FIG. 5.

Additionally, selected service distribution GUI 400 can display one or more related SBSs in related SBS section 435. Related SBSs are those that service development platform 200 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 by service development platform 200. For example, service development platform 200 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 in related SBS section 435. In some embodiments, service development platform 200 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 section 435 corresponds to the data entered into a related SBS input field 535 described below with respect to FIG. 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. Selected service distribution GUI 400 can include distribution platform section 440. Distribution platform section 440 displays one or more platforms on which the selected SBS can operate. For example, the Weather Location Service in FIG. 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, selected service distribution GUI 400 automatically selects the distribution platform displayed in distribution platform section 440. In some embodiments, distribution platform section 440 corresponds to the data entered into a distribution platform input field 540 described below with respect to FIG. 5.

Selected service distribution GUI 400 can also include purchase option section 445. Purchase option section 445 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 section 445 corresponds to the data entered into a purchase option input field 545 described below with respect to FIG. 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 select checkout button 450. After checkout button 450 is selected, interface module 210 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, selected service distribution GUI 400 can include a ranking value 455. A predetermined time after a selected SBS is purchased, service development platform 200 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, ranking value 455 is based on one or more reviews of the selected SBS. Selected service distribution GUI 400 can also display a review link 460 to one or more reviews associated with ranking value 455. Review link 460 can be text based or be an icon. In this embodiment, review link 460 is text based and indicates the total number of reviews. After a user selects review link 460, service distribution platform 200 is configured to display a GUI (not shown) listing one or more reviews associated with the selected SBS.

In some embodiments, service distribution platform 200 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 to service distribution platform 200. Interface module 210 is additionally configured to display an SBS upload GUI to facilitate uploading SBS data to the SBS catalog. FIG. 5 illustrates an example SBS upload GUI 500 generated by interface module 210. SBS upload GUI 500 can display an SBS name input field 505, a key word input field 510, a suggested catalog location input field 512, an SBS provider input field 515, an icon input field 520, an SBS description input field 525, a recommended SBS input field 530, a related SBS input field 535, a distribution platform input field 540, a purchase option input field 545, an SBS upload input field 550, an submit button 555, or some combination thereof.

The user can enter a name of the SBS (for example, Weather Location Service) into SBS name input field 505. Likewise, the user can enter a company name (for example, The Weather Company) to be affiliated with the SBS being uploaded into SBS provider input field 515. In some embodiments (not shown), SBS provider input field 515 can contain one or more sub-fields for company contact information. Additionally, the user using icon input field 520 can upload an icon to be affiliated with the SBS to be uploaded.

The user can additionally enter one or more key words into key word input field 510. After the SBS has been uploaded into service distribution platform 200, the data entered into key word input field 510 is linked to the SBS that was uploaded. Such that a search performed by a user (for example, using search field 360) using one or more of the entered key words can cause service distribution platform 200 to display the uploaded SBS as one of the results.

Additionally, the user can enter a suggested SBS catalog location using suggested catalog location input field 512. 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 SBS description input field 525. For example, SBS description input field 525 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 upload GUI 500 includes recommended SBS input field 530 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 upload GUI 500 is configured to include related SBS input field 535. The user can enter one or more related SBSs into related SBS input field 535. In embodiments not shown, any related SBS are automatically determined by service distribution platform 200 and not by the user. For example, service development platform 200 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 platform 200 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 using distribution platform input 540. 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 input 540 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 purchase option input field 545. Purchase option input field 545 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 upload input field 550. 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 purchased service development platform 200 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 upload GUI 500 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 submit button 555. After submit button 555 is selected, interface module 210 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 using service distribution platform 200. 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, the service distribution platform 200 can condition uploading an SBS on a 10% cut of every sale made using service distribution platform 200.

Referring back to FIG. 2, interface module 210 can be coupled to catalog module 220, billing module 230, communication module 240, and data storage module 250.

Catalog module 220 is configured to analyze and parse information obtained from SBS upload GUI 500 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 by service development platform 200. 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 module 220 parses information in one or more of the input fields of SBS upload GUI 500 to determine the correct placement of the uploaded SBS within the SBS catalog. For example, catalog module 220 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 module 320 can be further configured to compare the parsed information with the information entered into suggested catalog location input field 512 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 module 220 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 module 220 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 module 220 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 module 220 is configured to store the uploaded SBS, using for example, data storage module 250. Catalog module 220 can be coupled to interface module 210, billing module 230, communication module 240, and data storage module 250.

Billing module 230 is configured to monitor accounts for one or more users of service development platform 200. After a user purchases an SBS, billing module 230 is configured to determine what percentage of the purchase price is received by an entity controlling service development platform 200 and what percentage of the purchase price is directed toward the SBS provider. Billing module 230 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 to service development platform 200. 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 using service development platform 200. Billing module 230 is configured to communicate with one or more financial service providers (for example, financial service providers 130 and 140) to complete the purchase process. For example, the fee paid by a user purchasing a particular SBS can be 100 dollars. Billing module 230 would then coordinate (via communication module 240) with the one or more financial service providers such that the entity controlling server development platform 200 receives 20 dollars (20% of total price) and the SBS provider receives the remaining 80 dollars. Additionally, in some embodiments, billing module 230 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 module 230 can be configured to notify communication module 250 that one or more charges for a SBS have cleared and authorize communications module 240 to provide the SBS to the purchaser (for example, user of the client device) of the SBS. Billing module 230 can be coupled to interface module 210, catalog module 220, communication module 240, and data storage module 250.

Communication module 240 is configured to communicate with one or more client devices (for example, client devices 150, 160, and 170). For example, communication module 240 is configured to allow a user of a remote client device to login into service development platform 200 (for example, using service distribution GUI 300), upload an SBS into service distribution platform 200, purchase an SBS, or some combination thereof. Additionally, communication module 240 is configured to allow communication between service development platform 200 and one or more financial service providers (for example, 130 and 140). In some embodiments, communication module 240 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 module 240 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 module 240 can be coupled to interface module 210, catalog module 220, billing module 230, and data storage module 250.

Data storage module 250 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 module 250 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 into service distribution platform 200, etc. One or more SBSs are stored in data storage module 250 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 to FIGS. 4 and 5. In some example embodiments, data storage module 250 is distributed across one or more network servers. Data storage module 250 can be coupled to interface module 210, catalog module 220, billing module 230, and communication module 240.

Each of modules 210, 220, 230, and 240 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.

In step 605, 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 upload GUI 500.

In step 610, the acquired SBS data is parsed and in step 615 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.

In step 620, 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 example service distribution GUI 300. In step 625, a request is received for an SBS in the SBS catalog. For example, the client device can request a particular SBS for purchase using selected service distribution GUI 400. Additionally, in some embodiments, the user can also purchase one or more additional SBSs to concurrent with the requested SBS. In step 630, 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 step 705, 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 (step 710). 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 (step 715). 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 (step 720). In step 725, 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 (step 740).

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, in step 730, the service development platform bills the user for the requested SBS. The service development platform then provides the SBS to the user (step 735). 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 (step 740).

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.

In step 805, 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 upload GUI 500. In step 810, the acquired SBS data is transmitted to the service development platform.

In step 815, 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. In step 820, 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 GUI 300 and selected service distribution GUI 400. For example, the user can search for particular services using one or more keywords, browse SBSs by catalog location, etc. In step 825, 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 selected service distribution GUI 400. Additionally, in some embodiments, the user can also purchase one or more additional SBSs concurrent with the requested SBS. In step 830, 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.

In step 905, 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 (step 910). 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. In step 915, 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, in step 920, 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 (step 935).

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, in step 925, the client device facilitates the purchase of the requested SBS. In step 930, 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 (step 935).

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

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 of claim 1, wherein the provided first server-based service can be utilized by an application running on a mobile device.

3. The method of claim 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 of claim 3, further comprising:

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

5. The method of claim 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 of claim 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 of claim 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 of claim 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 of claim 8, wherein the one or more server-based services different from the first server-based service are available for selection.

10. The method of claim 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 of claim 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 of claim 12, wherein the provided first server-based service can be utilized by an application running on a mobile device.

14. The system of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 19, wherein the provided first server-based service can be utilized by an application running on a mobile device.

Referenced Cited
U.S. Patent Documents
6615247 September 2, 2003 Murphy
20030120502 June 26, 2003 Robb et al.
20030237093 December 25, 2003 Marsh
20040034853 February 19, 2004 Gibbons et al.
20040148344 July 29, 2004 Navar
20060253335 November 9, 2006 Keena et al.
20070150480 June 28, 2007 Hwang et al.
20070198360 August 23, 2007 Rogers et al.
20080120599 May 22, 2008 I'Anson
20090187413 July 23, 2009 Abels et al.
20100208875 August 19, 2010 Vandenbulcke et al.
20110010759 January 13, 2011 Adler
20110106914 May 5, 2011 Ke
20110153806 June 23, 2011 Bagasra
20110225636 September 15, 2011 Keith et al.
Foreign Patent Documents
2180630 April 2010 EP
Other references
  • “IBM WebSphere Application Server V7.0 Web Services Guide”—WebSphere, IBM, Aug. 2009 http://www.redbooks.ibm.com/redbooks/pdfs/sg247758.pdf.
  • Extended European Search Report mailed May 10, 2012, for European Application No. 12155927.2.
  • Research in Motion Limited: “BlackBerry App World storefront Vendor portal, Administration Guide,” vol. Version: 2.0, published Apr. 9, 2010. Retrieved from the Internet: URL:http://web.archive.org/web/20100603043819/http://docs.blackberry.com/en/developers/deliverables/15522/Blackberry—app—world—storefront-Administration—Guide--1086301-0409112503-001-2.0-US.pdf (Retrieved Apr. 27, 2012).
  • Canadian Office Action in Canadian Application No. 2,806,110, dated Jan. 27, 2015, 4 pages.
Patent History
Patent number: 9270759
Type: Grant
Filed: Feb 17, 2012
Date of Patent: Feb 23, 2016
Patent Publication Number: 20130218946
Assignee: BlackBerry Limited (Waterloo, Ontario)
Inventors: Michael Scott Colbert (Debary, FL), Vivek Gupta (Frisco, TX)
Primary Examiner: Randy Scott
Application Number: 13/399,140
Classifications
Current U.S. Class: Remote Data Accessing (709/217)
International Classification: G06F 15/16 (20060101); H04L 29/08 (20060101);