Filtering messages based on pruning profile generated from pruning profile schema

According to an embodiment, a method of providing data by a software application is provided. The method may include retrieving a selected pruning profile. Next a result message is received from a service host based on a request message transmitted to the service host from a client. The content of the result message is then filtered based on the retrieved pruning profile. Finally, the filtered result message is sent to the client.

FIELD

The present application generally relates to network-based applications.

BACKGROUND

Modern network-based applications can rely on the transfer of large amounts of information. As applications become more complex, the variety and amount of information that can be transferred has greatly increased. Compounding this, newly available, interesting types of information can be dramatically larger in size than older, traditional types of information. For example, video, location and map imagery is much larger in size than traditional textual information.

Firms that operate software applications that supply vast amounts of requested information are always seeking to reduce costs and improve performance. Often, reducing costs by reducing the amount of information produced by software applications can have negative consequences. Increased system resource use, added complexity, and problems associated with supporting a broad variety of client applications can all occur when firms address the problems noted above.

BRIEF SUMMARY

Embodiments described herein relate to providing data by a software application. According to an embodiment, a method of providing data by a software application is provided. The method may include retrieving a selected pruning profile. Next a result message is received from a service host based on a request message transmitted to the service host from a client. The content of the result message is then filtered based on the retrieved pruning profile. Finally, the filtered result message is sent to the client.

According to another embodiment, a system of providing results from a networked software application includes at least one pruning profile and a pruner. The pruner is configured to receive a first result message from a service host based on a request message transmitted to the service host from a client. The pruner is further configured to retrieve a selected pruning profile from the at least one pruning profile, and produce a second result message based on the selected pruning profile and the first result message. Finally, the pruner sends the second result message to the client.

Further features and advantages, as well as the structure and operation of various embodiments are described in detail below with reference to the accompanying drawings.

DETAILED DESCRIPTION OF EMBODIMENTS

The following detailed description refers to the accompanying drawings that illustrate exemplary embodiments. Embodiments described herein relate to providing systems and methods for providing data by a software application. Other embodiments are possible, and modifications can be made to the embodiments within the spirit and scope of this description. Therefore, the detailed description is not meant to limit the embodiments described below.

It would be apparent to one of skill in the relevant art that the embodiments described below can be implemented in many different embodiments of software, hardware, firmware, and/or the entities illustrated in the figures. Any actual software code with the specialized control of hardware to implement embodiments is not limiting of this description. Thus, the operational behavior of embodiments will be described with the understanding that modifications and variations of the embodiments are possible, given the level of detail presented herein.

Overview

Embodiments described herein relate to the interaction between service hosts, application hosts, and clients.

As used herein, “service hosts” can refer to computer servers that host large-scale service applications that are typically served to users over a network. “Service hosts,” for example, can refer to computer systems operating to provide services such as, for example and without limitation, GOOGLE MAPS, GOOGLE EARTH AND YOUTUBE, such services being provided by Google Inc. of Mountain View, Calif.

As used herein, “application hosts” can refer to the computer servers that host applications that use the services described above as a data source for application output. In a non-limiting example, an application executing on an application host can offer a search for restaurants and, as a part of the interface, display data that has been retrieved from a service host, e.g., GOOGLE MAPS.

As used herein, “clients” can refer to computer systems that connect to application hosts and provide an interface to the applications running on such hosts. For example, a computer system having a web browser can connect to the restaurant search application and enable the searching and displaying of the restaurant results. The restaurant results, in this example, originate at the service hosts. The term “client” may also refer to the relationship of an application host to a service host. For example, the restaurant search application host can also act as a client by submitting requests to a maps service host.

As used herein, “messages” broadly refer to the request and response information relayed between the clients and hosts described above. For example, a client sends a message to an application host requesting a restaurant search. After receiving the client message, the application host sends a message to the services host to request information satisfying the search. After receiving the message from the application host, the services host sends a message containing the restaurant search result information. As would be appreciated by one having skill in the art(s), given the description herein, alternative embodiments could be used to enable different applications. For example, the client can be directed by the application host to send a search message directly to the service host, the service host responding with a result message directly sent to the client.

Some embodiments described herein alter the creation, flow and content of the types of messages noted above. By enabling different events, embodiments described herein can beneficially affect application characteristics including performance, efficiency and ease of design/evolution/maintenance.

One exemplary alteration of messages performed by embodiments is the pruning of messages originating at service hosts, such pruning reducing the content of generated messages before they are delivered to their destination.FIGS. 1-6below describe different approaches taken by embodiments.

FIG. 1is an example network application architecture100in which embodiments of the present invention, or portions thereof, may be implemented. Network application architecture100includes service hosts110A-B, application host160, clients130A-B and pruner host120, in accordance with an embodiment of the present invention. While the embodiment depicted inFIG. 1shows clients130A-B, service hosts110A-B, application host160and pruner host120, it is important to note that other embodiments can be used to exchange data between any type of computer-implemented data sources and systems.

Service hosts110A-B include services115A-B respectively. Service host110A further includes pruner170A. Pruner host120includes pruner170B and application host160includes application165. Client130A includes browser150operating thereon, such browser150executing browser application135. Client130B includes application140executing thereon. Service host110A, host120, application host160and clients130A-B are all shown as coupled by network101. As used herein, network101can be one or more networks of any type including, but not limited to, local area networks, medium area networks, or wide-area networks, such as, the Internet.

It is important to note that, while services115A-B are depicted as each executing on single service hosts110A-B, services115A-B can operate in a variety of configurations, such configurations including services115A-B spanning multiple depicted and additional service hosts (not shown). Additional computer system configurations are discussed below with the description ofFIG. 8.

In an illustrative, non-limiting, example discussed with reference toFIG. 1, further details regarding the operation of pruners170A-B are provided below, according to an embodiment:

Browser application135is a browser based application operating in browser150operating on client130A. The server-side complement to browser application135is server-based application165operating on application host160. Server-based application165is configured to exchange information with browser application135over network101. An example server-based application165is a restaurant search application.

To provide application functions, browser application135and server-based application165can be configured to use information from services115A-B operating on service hosts110A-B respectively and delivered via network101. Continuing the restaurant search example, to supply geographic information functions to server-based application165, service115A can be used. In this example, service115A is a mapping application, e.g., GOOGLE MAPS.

To request information from services115A-B, both browser application135and server-based application165can generate and send request messages to services115A-B. For example, when a user working on client130A searches for a restaurant, the request can be converted into a request message to be received by service115A.

Services115A-B can be service applications that generate result messages in response to the above-described request messages. In some examples, services115A-B can generate very large result messages in response to a request message. For example, a request message to GOOGLE MAPS for information about a particular restaurant can produce a result message containing address information, pictures, restaurant reviews, and other descriptive characteristics.

In an example, the requesting applications (135,165) do not require the full amount of information available in the result messages generated by services115A-B. For example, a user performing a restaurant search may not want to see pictures or reviews. In this example, the operators of service hosts110A-B may want to limit the amount of information that is sent between service hosts110A-B and network101.

Pruners170A-B can be configured to limit the amount of information in the result messages sent by services115A-B via network101. In an embodiment, pruners170A-B are configured to filter the content messages based on a selected pruning profile.

In embodiments, pruning profiles can use any format that limits the content in a result message. Pruning profiles can be created based on the format of the result messages to be generated by services115A-B. In an embodiment, the format of the result messages can be termed the “schema” of the result message, and the format of a pruning profile can be termed the “schema” of the pruning profile. In an embodiment discussed further with respect toFIG. 3below, the result message schema can be used to create a pruning profile schema, and the pruning profile schema can be used to create a pruning profile. It should be noted that, as used herein, discussion of selection, generation and/or specification of a pruning profile may also apply to embodiments where pruning profile schemas and/or formats are selected, generated and/or specified. In these examples, the selected, generated and/or specified pruning profile schema may be used to create a pruning profile.

One approach used by an embodiment to implement the result message pruning noted above is to require requesting applications (135,160) to specify a pruning profile when sending a request message. For example, server-based application165can specify an address pruning profile for use with a simple restaurant search. A different profile could be used if more information (reviews, pictures, etc.) are needed for users. In a different embodiment, pruners170A-B are configured to automatically select an appropriate pruning profile based on criteria including, for example and without limitation: the schema/format of the request message, the service115A-B to which the request is directed and/or the schema/format of the result message to be produced by the selected service115A-B.

Upon receiving request messages, services115A-B provide result messages to pruners170A-B respectively. Pruners170A-B are also provided with the specified or selected pruning profile noted above.

Based on the received pruning profile, pruners170A-B limit/filter/prune the content of the result message. Continuing the restaurant search example, having received the address pruning profile noted above, pruner170A can filter out all of the non-address information in the initial result message provided by service115A.

The filtered result message can be provided by pruners170A-B to the respective requesting application. For example, browser application135can receive and display the pruned result message showing only address results.

This example of a restaurant search is illustrative and not intended to limit the invention. As would be apparent to a person skilled in the art given this description, other approaches to providing data to clients130A-B from service hosts110A-B can be used by different embodiments without departing from the spirit and scope described herein.

As would also be appreciated by one having skill in the relevant art(s), given the description herein, in different embodiments, one or more steps of the example provided above may not be performed, may be performed differently from the steps described above, may be performed in combination with additional steps, and may be performed in a different order than the order described.

In a variation of the above, instead of browser application135and server-based application165generating and receiving messages, in another embodiment, application140is an application installed and operating on client130B. In this example, application140is a “thick-client” application that is configured to generate messages and send them directly to services115A-B, without the involvement of application host160. An example application140is GOOGLE EARTH. The operation then proceeds as described above.

In another variation, in an embodiment depicted inFIG. 1, service115B and pruner170B can be implemented on different computer systems (e.g., service host110B and pruner host120, respectively). In another embodiment, the scalability of service115B can be beneficially affected by having multiple pruner hosts120with multiple pruners170B (not shown) coupled to service host110B. Service115B can then provide results without the system overhead of filtering, such filtering being performed by additional distributed systems. As would be appreciated by one having skill in the relevant art(s), given the description herein, many benefits, including performance, simplification of management, can result from the division of functions described herein.

The depiction of the embodiment of pruner170B deployed in host120inFIG. 1provides an illustrative example of potential physical and logical placements of pruners170A-B generally. It should be noted that limiting the content of result messages can be performed at many different points in network application architecture100. For example, pruners170A-B can provide the pruning functions described above when placed in application host160and clients130A-B. Different physical and logical placements of pruners170A-B are depicted inFIG. 2below.

As noted with the description ofFIG. 1, the functions of pruners270A-E can be distributed to different components of network application architecture. Embodiments described herein can use any combination of pruners270A-E, either individually or in combination. The selection of which of pruners270A-E to use at a given time can be based on different considerations, including performance, efficiency, and cost savings.

For example, pruners270C-E operate on client230in the operating system (270C), client application240(270D) and in browser250(270E). This client-side placement differs from the server-side implementation embodiments discussed above. In an embodiment, client (270C-E) and server side implementations (270A-B) of pruner logic can be configured to beneficially interact.

FIG. 3depicts an example process for creating pruning profile schema330from message schema310, according to an embodiment. Message schema310is processed using build rule320, such processing resulting in pruning profile schema330. As used generally herein, “message schema” refers to the format of a message, such format describing the content and organization of the different pieces of information that can be included in the message, and pruning profile schema refers to the format of a pruning profile, such format describing the content and organization of the different pieces of information that can be pruned using the profile. In an embodiment, pruning profile schema330is generated from message schema310using build rule320, and pruning profiles340A-B are generated from pruning profile schema330. In another embodiment, pruning profile340A can be generated directly from message schema310using build rule320.

An embodiment of build rule320can specify the information to be filtered by pruning profile330. Using standard build rules320can allow different types of pruning profiles to be created from a variety of message schemas. For example, applying an address build rule to a restaurant message schema (e.g., address, pictures, reviews, menus) can result in a pruning profile schema that can be used to generate pruning profiles that limit result messages to address information of restaurants. Applying the same build rule to a personal information message (e.g., name, address, phone number, occupation) can similarly result in a result message limited to the address information of selected people.

In an embodiment, analyzing the code of a client software application can deduce which message fields from message310the client application will require, and based on this analyzing, a pruning profile schema or pruning profile can be generated to satisfy the determined client requirements. In a variation of this client analysis, in an embodiment, a client application can have an internal routine that analyzes the information required by the client application and builds a pruning profile or pruning profile schema based on an analysis of message schema310. Some embodiments using the client analysis approach above do not require build rules320to create pruning profile schemas330or pruning profiles340A-B.

In an embodiment, pruning profiles340A-B that are generated from a pruning profile schema340must conform to the schema, and can be tested for their conformity. If message schema310changes, pruning profile330can also be changed. The changes to message schema310may or may not affect deployed pruning profiles340A-B. The pruning profile schema conformity testing described above can be used to identify whether pruning profiles340A-B need to be regenerated to match a change to message schema310.

In a non-limiting example, a field is removed from message schema310. Based on this change, pruning profile schema330is also changed. Pruning profiles340A-B are tested for conformity with pruning profile330and determined to be nonconforming, e.g., pruning profiles340A-B specify that the removed field be returned. Because of this determined non-conformity, pruning profiles340A-B are regenerated from the changed pruning profile schema330. In an embodiment, the generation of pruning profile schemas330and pruning profiles340A-B, and the location of pruning profile conformity testing depends on the implementation, occurring, for example at service host110A, pruner host120, application host160or clients130A-B.

As would be appreciated by one having skill in the relevant art(s), given the description herein, the structure described above, with build rules producing pruning profile schemas from various message formats, can be used for a wide variety of formats, messages and applications.

FIG. 4depicts the operation of pruner470according to an embodiment. Pruner470receives original result message410and pruning profile430. Pruning490is an operation that combines original message410and pruning profile430, resulting in pruned result message440.

In an exemplary embodiment, pruner470receives original result message410from service115A fromFIG. 1. Original result message410is termed “original” because it has not been pruned/filtered. In an embodiment, original result message410contains the full amount of information able to be produced by service115A in response to a request message.

Pruner470also receives pruning profile430. During the depicted pruning490step, pruning profile430is used to reduce the content of original result message410, resulting in pruned result message440.

In an exemplary embodiment, the messages used are “protocol buffers” or “protobufs” provided by Google Inc. of Mountain View, Calif. Google Protocol Buffers allow the design of structured messages using a domain-specific language. A .proto source file is created and passed through a Google-provided tool to generate source code for a target language. An interpreter is created that encodes/decodes the structured data messages. Different embodiments described herein may use different approaches to prune protobufs (or similar messages for a different service provider) for beneficial results.

FIG. 5is an example network application architecture500, such architecture having different potential placements and usage of pruning profiles550A-D, according to an embodiment. Service host510includes pruning profile550C and service515. Host520A includes pruning profiles550A-B and pruner560A, and host520B includes pruner560B. Applications530A-D are shown, with530A-C being coupled to host520A and applications530C-D coupled to host520B. Application530D includes pruning profile550D.

In different embodiments, pruning profiles can be stored and accessed using a variety of methods.FIG. 5depicts pruning profiles550A-B stored on host520A and pruning profile550C stored on service host510. In embodiments, pruners560A-B can access required profiles from different components in network application architecture500. For example, if application530D submitted a request message that specified pruning profile550A, pruner560B would retrieve the requested pruning profile550A from host520A. The retrieved pruning profile550A would be used to prune the result message from service515before delivery to application530D.

Pruning profile550D, stored with application530D, depicts an example wherein a pruning profile is submitted by an application along with the request message. In some embodiments described above, a request message is sent by an application along with a reference to a particular stored pruning profile. In this example, application530D, when sending a request message to service515, also includes pruning profile550D with the request. Using this approach allows application developers to flexibly utilize the pruning capabilities of embodiments described herein.

In another embodiment, application developers are able to develop their own pruning profiles (e.g.,550D), but instead of sending the profile with each request, application developers can deploy their pruning profiles on hosts520A-B and service host510. In this example, application developers can design their own custom pruning profiles while having the performance benefit that results from the server-based deployment.

FIG. 6is an example network application architecture600, such architecture having pruning profile generator670, according to an embodiment. Service host610includes service615, and host620includes pruning profile generator670, pruning profile650and pruner660. Application630is coupled to host620and sends request message635to host620.

In the embodiment ofFIG. 3, pruning profile330was generated based on build rule320. In the embodiment ofFIG. 5, pruning profiles550A-D are described as stored on network components.FIG. 1illustrates an embodiment where different pruning profiles are created specifically for the requirements of applications135,140. In each of these embodiments, the pruning profiles can be created in advance of the receipt of request messages.

In an embodiment depicted inFIG. 6, pruning profile generator670receives request message635from application630. Request message635can be in a format that describes the information that is wanted from service615. Based on request635and the service615to which the request is directed, pruning profile generator670generates pruning profile650. When service615produces a result message in response to request message635, the result message is pruned by pruner660using the newly created pruning profile650. Pruning profile650can be stored for future use as well. In this example, the developers of application630are able to benefit from a custom-designed pruning profile650, but without having to design the custom pruning profile.

In accordance with an embodiment, protobuf (protocol buffer) pruning is a library designed to efficiently trim down protocol buffer data, in a generic way. An embodiment exemplary protobuf pruning works in the following fashion:

1. At build time, a pruning profile schema (for example, a Protobuf Pruning Scheme Description) is generated from the original (to be pruned) protocol file containing the OriginalMessage. This is itself another protocol file.

2. A pruning protocol schema file is filled in with instructions on how to prune the OriginalMessage.

3. At serving time, MessagePruner::Prune( ) is called with the pruning profile schema and a mutable OriginalMessage.

The table below illustrates an example pruning profile schema (also referred to herein as a ‘pruning schema’) (listing.prune.proto) that has been generated from listing.proto:

The table below is an example of how the listing.prune.proto pruning profile schema can be filled in to generate a pruning profile (maps.prune.listing), and how an example original message instance is pruned using the pruning profile:

Eliminating excess result information from service hosts can result in reduced bandwidth costs. Conventional approaches to conditionally eliminating waste from protocol responses can use significant engineering resources.

Over traditional ways to control response contents, pruning can reduce (1) scalability problems as demand for service results increase, (2) confusion with request/response field correspondence, and (3) errors in protocol file filling code.

Consider this example of how message request/response formats can evolve:

A field in a ListingRequest called include_reviews might at first do exactly that, add reviews to ListingResponse, but eventually, it may also come to mean that photos should not be returned because the main Client, such as Client A, does not display photos and reviews at the same time.

Then, a Client B may want to display both, and now an include_photos might be added to ListingRequest.

Typically, Client A now has to be modified to also request photos in the proper situation, and though this is not usually a problem, it may require asking for permissions to modify Client A and timing the release (a new Client A has to roll out before a new ListingServer gets pushed.)

One solution may be to add a potentially confusing field, “include_reviews_and_photos” potentially making the request confusing and unscalable (what does it mean to include_reviews and also include_reviews_and_photos?).

Added to scalability issues is the confusion with field names. For example, a response that contains a field-named photo can have any of these request fields: include_photo, include_photos, include_picture, include_pictures, etc.

And last, the protocol file filler code, which due to a company's extensive use of protobufs can extend over most if not all of the server code, may have significant amounts of conditional statements (e.g., “if (request.include_photo( ) { . . . }”) which can make the code more difficult to read and also add dependencies for the request throughout the codebase.

Embodiments described herein can reduce the significance of many of the above issues, because a response message can be pruned in a separate phase, using a well defined, simple method.

In an embodiment, the characteristics of an isolated, single binary performance (e.g., the generation of the protocol message has to be completed before it gets pruned to its wire size) are measured against the benefits of sending smaller messages across the wire, as well as improved serialization/deserialization time for the smaller sized messages.

Example Build Rule

In an example, the pruning profile schema listed above (listing.prune.proto) is auto-generated via a BUILD rule. Below is an example build rule that can be used to build the pruning profile schema above:

In another embodiment, the build rule above can also use a single build approach.

Example Coding

In an exemplary C++ code that uses maps.Listing, an #include statement may have to be used for the protocol file. For example:#include “maps/frontend/public/maps_syndication.pb.h”

The statements below show an example reference to the pruning protocol def., and the message pruner:#include “maps/frontend/public/maps_syndication.prune.pb.h”#include “maps/util/proto/message_pruner.h”

Below is an example statement to instantiate a pruned protocol and the Listing to be filled in:maps::Listing listing;maps::prune::Listing listing_prune_schema;

Different approaches exist to storing pruning schemes. For example, pruning schemes can be passed in as part of the request (just like regular protobufs) or pruning schemes can be stored with the pruner.

The following is an example of how to call a message pruner:MessagePruner::Prune(listing_prune_schema, &listing);

In some embodiments, the pruning operation is destructive, e.g., the pruned Listing message is not preserved by default. Different embodiments can store the original Listing for later use.

FIG. 7illustrates a more detailed view of how embodiments described herein may interact with other aspects. In this example, a method of providing data by a software application is shown. Initially, as shown in stage720inFIG. 7, a selected pruning profile is retrieved. For example, the pruning profile550A may be retrieved by pruner560A ofFIG. 5. At stage730, a result message is received from a service host based on a request message transmitted to the service host from a client. For example, referring toFIG. 5, pruner560A may receive the result message from service515on service host510, such result message based on the request message from application530A. At stage740, the content of the result message is filtered based on the retrieved pruning profile. For example, still referring toFIG. 5, pruner560A may filter the received result message based on retrieved pruning profile550A. Finally, at stage750, the filtered result message is sent to the client. For example, still referring toFIG. 5, pruner560A may send the filtered result message to application530A. After stage770, the method ends.

Example Computer System Implementation

FIG. 8illustrates an example computer system800in which embodiments of the present invention, or portions thereof, may be implemented. For example, portions of systems or methods illustrated inFIGS. 1-7may be implemented in computer system800using hardware, software, firmware, tangible computer readable media having instructions stored thereon, or a combination thereof and may be implemented in one or more computer systems or other processing systems. Hardware, software or any combination of such may embody any of the modules/components inFIGS. 1-6and any stage inFIG. 7. Clients130A-B, service hosts110A-B, pruner host120and application host160can also be implemented having components of computer system800.

If programmable logic is used, such logic may execute on a commercially available processing platform or a special purpose device. One of ordinary skill in the art may appreciate that embodiments of the disclosed subject matter can be practiced with various computer system and computer-implemented device configurations, including smartphones, cell phones, mobile phones, tablet PCs, multi-core multiprocessor systems, minicomputers, mainframe computers, computer linked or clustered with distributed functions, as well as pervasive or miniature computers that may be embedded into virtually any device.

For instance, at least one processor device and a memory may be used to implement the above described embodiments. A processor device may be a single processor, a plurality of processors, or combinations thereof. Processor devices may have one or more processor ‘cores.’

Processor device804may be a special purpose or a general purpose processor device. As will be appreciated by persons skilled in the relevant art, processor device804may also be a single processor in a multi-core/multiprocessor system, such system operating alone, or in a cluster of computing devices operating in a cluster or server farm. Processor device804is connected to a communication infrastructure806, for example, a bus, message queue, network or multi-core message-passing scheme.

Computer system800also includes a main memory808, for example, random access memory (RAM), and may also include a secondary memory810. Secondary memory810may include, for example, a hard disk drive812, removable storage drive814and solid state drive816. Removable storage drive814may include a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like. The removable storage drive814reads from and/or writes to a removable storage unit818in a well known manner. Removable storage unit818may include a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive814. As will be appreciated by persons skilled in the relevant art, removable storage unit818includes a computer usable storage medium having stored therein computer software and/or data.

In alternative implementations, secondary memory810may include other similar means for allowing computer programs or other instructions to be loaded into computer system800. Such means may include, for example, a removable storage unit822and an interface820. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units822and interfaces820which allow software and data to be transferred from the removable storage unit822to computer system800.

Computer system800may also include a communications interface824. Communications interface824allows software and data to be transferred between computer system800and external devices. Communications interface824may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, or the like. Software and data transferred via communications interface824may be in electronic, electromagnetic, optical, or other forms capable of being received by communications interface824. This data may be provided to communications interface824via a communications path826. Communications path826carries the data and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link or other communications channels.

In this document, the terms “computer program medium” and “computer usable medium” are used to generally refer to media such as removable storage unit818, removable storage unit822, and a hard disk installed in hard disk drive812. Computer program medium and computer usable medium may also refer to memories, such as main memory808and secondary memory810, which may be memory semiconductors (e.g., DRAMs, etc.).

Computer programs (also called computer control logic) may be stored in main memory808and/or secondary memory810. Computer programs may also be received via communications interface824. Such computer programs, when executed, enable computer system800to implement the present invention as discussed herein. In particular, the computer programs, when executed, enable processor device804to implement the processes of the present invention, such as the stages in the method illustrated by flowchart700ofFIG. 7discussed above. Accordingly, such computer programs represent controllers of the computer system800. Where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system800using removable storage drive814, interface820, hard disk drive812or communications interface824.

CONCLUSION

Embodiments described herein relate to methods and systems and computer program products for providing data by a software application. The summary and abstract sections may set forth one or more but not all exemplary embodiments of the present invention as contemplated by the inventors, and thus, are not intended to limit the present invention and the claims in any way.

The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the claims and their equivalents.