Patent Application
20130035060
All cellular phone networks worldwide use a portion of the radio frequency spectrum designated as Ultra High Frequency for the transmission and reception of their signals. The sets of frequency ranges within this band that have been allocated for cellular phone use vary worldwide, but are generally grouped by standards. Each standard defines the carrier frequency ranges and channel access method used by compatible radio communication technologies. For example, two predominant standards include Global System for Mobile Communications (GSM) and Code Division Multiple Access (CDMA).
Further, for each standard, mobile devices wishing to access the carrier's network must support radio communication on the carrier frequency ranges transmitted by the carrier's broadcast towers, which varies by country. For example, while common world GSM frequencies include 900 MHz (GSM-900 and its derivatives) and 1800 MHz (DCS-1800), 850 MHz (GSM-850) and 1900 MHz (PCS-1900) are used in North America instead. As a result of these discrepancies, mobile device manufacturers introduced tri-band and subsequently quad-band products, which are designed to accommodate a greater number of common carrier frequency ranges.
Despite these compatibility advances within any given standard, most mobile devices are still limited to supporting a set of frequency ranges within a single standard. For example, a quad-band GSM mobile device will not be compatible with CDMA standards, and vice-versa. This reality is not only costly to manufacturers, who must release iterations of their products for various standards, but detrimental to consumers as well, who must limit their selection to devices compatible with their choice of carrier. Furthermore, this carrier selection can be limiting in its own right, often preventing usage of compatible hardware beyond the geographical boundaries of the carrier itself.
Although technology advances and increased competition have meant more choices of service provider (carrier) have become available, one problem is that users are unable to switch frequently between service providers to take advantage of better rates or better service. It would be desirable to have a means to perform this switching with less hassle to users. Frequent switching would also allow providers to allocate spectrum bandwidth to users and/or applications with the specific need for that bandwidth (and/or more willingness to pay at competitive rates).
According to a first aspect of the invention, a method is provided for acquiring bandwidth on a mobile device. A bid for bandwidth service for the mobile device is formed, which includes: a bandwidth requisition; a plurality of service criteria (each with a weighting factor); and at least one limiting condition for the bandwidth requisition. The bid is submitted to a plurality of service providers. Upon receiving a response from at least one of the service providers, the response is automatically evaluated by using the weighting factors to compute a score. The scores are compared and the best scoring response that meets the at least one limiting condition is chosen, and a transaction is entered into with the service provider to acquire the bandwidth service on the mobile device (according to the service criteria).
Note that the scoring can be done locally on the device or remotely (e.g. may be tabulated by the service provider based on the user's stated preferences—therefore, returned in the “response”—or may be tabulated by a third party intermediary system—such as the central bidding server referred to below).
At least one of the service criteria, weighting factors, and limiting conditions is preferably entered by the user. At least one of the bandwidth requisition, service criteria, and limiting conditions is preferably automatically formulated by the mobile device.
A maximum price may be entered by the user as a limiting condition, and/or a desired price may be one of the service criteria (that has its own weighting factor).
Frequency range may be a limiting condition.
Preferably, the service criteria includes at least one of price, performance, quality of service, reliability, and availability of required bandwidth.
The service criteria may include a service provider desirability index. This may be based on the user's subjective assessment (e.g. based on the user's past experience with the service provider). Alternatively, the service provider desirability index may be assigned based on other objective or subjective factors. One factor may be the user's preferred customer status with that service provider (e.g. membership in a loyalty program where the user gets points or preferred rates). In one embodiment, the service provider desirability index may be assigned based on polling data retrieved from social media.
The user may also assign certain service providers a preferred service provider status (or this may be automatic based on past experience or transactions of the user or other users with this service provider). Preferred service provider status may be a limiting condition, or it may be one service criteria to be weighted among others.
In one embodiment, the service criteria and limiting conditions are retrieved from service criteria and limiting conditions previously entered by the user. In this case, the pre-entered service criteria and limiting conditions may simply be verified by the user when the bid is made (need not be re-entered) (or this verification may be simply skipped altogether, and the service can be transacted more or less automatically after the service criteria and limiting conditions are entered once by the user).
The bandwidth requisition may be automatically formulated based on a service request from the user (e.g. where the service request is a request for a voice or data operation on the mobile device). In one embodiment, the bandwidth requisition is automatically formulated at periodic intervals during a voice or data operation.
The bandwidth requisition may also be automatically formulated in the event of a failure of or poor performance during a voice or data operation.
Transacting with the service provider preferably comprises providing a payment. This payment can be in the form of one or more credits. Providing the payment may include providing authorization to deduct from a payment method. This payment may be pre-authorized before the bandwidth requisition.
In one embodiment, the bid is submitted to a plurality of service providers via a central bidding server, which intermediates bids from a plurality of users of mobile devices. The responses may be received from the service providers via the central bidding server, and some or all of the transaction may also occur via the central bidding server.
The process may repeat, e.g. if no response is received that meets the service criteria and the limiting conditions. The process may repeat until a response is received, or a minimum score is reached. In a competitive bidding embodiment (with multiple users seeking bandwidth through bids submitted to the central bidding server), the process may repeat with an incrementally increased desired price (within the user's pre-set maximum price limiting condition).
Systems and methods disclosed herein provide an improved service to mitigate at least some of the aforementioned disadvantages of the current methodology.
The system is comprised of clients, which in embodiments are mobile devices as well as software residing in the mobile device, and the backend servers of mobile data service providers (also known as “spectrum”or “bandwidth”, “providers” or “carriers”). In one embodiment, the system also includes a central bidding server that arbitrates interactions between client and providers. The method involves interactions between the client, provider and, in some embodiments, the bidding server. This method defines a process in which a central bidding server performs real-time evaluation of available spectrum providers on behalf of clients in order to bid for data transfer usage in exchange for credits.
Before embodiments of the invention are explained in detail, it is to be understood that the invention is not limited in its application to the details of the examples set forth in the following descriptions or illustrated drawings. The invention is capable of other embodiments and of being practiced or carried out for a variety of applications and in various ways. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting.
It should also be noted that the invention is not limited to any particular software language described or implied in the figures and that a variety of alternative software languages may be used for implementation of the invention.
Many components and items are illustrated and described as if they were hardware elements, as is common practice within the art. However, one of ordinary skill in the art, and based on a reading of this detailed description, would understand that, in at least one embodiment, the components comprised in the method and tool are actually implemented in software.
As will be appreciated by one skilled in the art, the present invention may be embodied as a system, method or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.
Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. Computer code may also be written in dynamic programming languages that describe a class of high-level programming languages that execute at runtime many common behaviors that other programming languages might perform during compilation. JavaScript, PHP, Perl, Python and Ruby are examples of dynamic languages. Additionally computer code may also be written using a web programming stack of software, which may mainly be comprised of open source software, usually containing an operating system, Web server, database server, and programming language. LAMP (Linux, Apache, MySQL and PHP) is an example of a well-known open-source Web development platform. Other examples of environments and frameworks in which computer code may also be generated are Ruby on Rails which is based on the Ruby programming language, or node.js which is an event-driven server-side JavaScript environment.
The program code may execute entirely on the client device, partly on the client device, as a stand-alone software package, partly on the client device and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
A device that enables a user to engage with an application using the invention, including a memory for storing a control program and data, and a processor (CPU) for executing the control program and for managing the data, which includes user data resident in the memory and includes buffered content. The computer may be coupled to a video display such as a television, monitor, or other type of visual display while other devices may have it incorporated in them (iPad). An application or a game or other simulation may be stored on a storage media such as a DVD, a CD, flash memory, USB memory or other type of memory media or it may be downloaded from the internet. The storage media can be inserted to the console where it is read. The console can then read program instructions stored on the storage media and present a user interface to the user.
In some embodiments, the device is portable. In some embodiments, the device has a display with a graphical user interface (GUI), one or more processors, memory and one or more modules, programs or sets of instructions stored in the memory for performing multiple functions.
It should be understood that although the term application has been used as an example in this disclosure in essence the term may also apply to any other piece of software code where the embodiments of the invention are incorporated. The software application can be implemented in a standalone configuration or in combination with other software programs and is not limited to any particular operating system or programming paradigm described here. Thus, this invention intends to cover all applications and user interactions described above as well as those obvious to the ones skilled in the art.
The computer program comprises: a computer usable medium having computer usable program code, the computer usable program code comprises: computer usable program code for presenting graphically to the users options for scrolling via the touch-screen interface.
Several exemplary embodiments/implementations of the invention have been included in this disclosure. There may be other methods obvious to persons skilled in the art, and the intent is to cover all such scenarios. The application is not limited to the cited examples, but the intent is to cover all such areas that may be benefit from this invention.
The device may include but is not limited to a personal computer (PC), which may include but not limited to a home PC, corporate PC, a Server, a laptop, a Netbook, a Mac, a cellular phone, a Smartphone, a PDA, an iPhone, an iPad, an iPod, an iPad, a PVR, a set-top box, wireless enabled Blu-ray player, a TV, a SmartTV, wireless enabled Internet radio, e-book readers e.g. Kindle or Kindle DX, Nook, etc. and other such devices that may be used for the viewing and consumption of content whether the content is local, is generated on demand, is downloaded from a remote server where is exists already or is generated as a result. Client devices and server devices (or systems) may be running any number of different operating systems as diverse as Microsoft Windows family, MacOS, iOS, any variation of Google Android, any variation of Linux or Unix, PalmOS, Symbian OS, Ubuntu or such operating systems used for such devices available in the market today or the ones that will become available as a result of the advancements made in such industries.
The rationale for this invention is that when the networks become dumb pipes, users should be able to bid and get voice/data/text etc. from any network that offers the best value to meet their needs.
Users can have many kinds of preferences, they may rank the networks based on reliability, service, speed etc., prefer cheapest or the most reliable, cheapest block of text messages, best value for day time voice minutes etc.
Specifically, mobile devices supporting a wide range of frequency ranges will natively support a process in which acquired credits of predetermined value will be exchanged against data transfer usage, offered from one of many available spectrum providers, dubbed billing services. Providers will be able to offer as many of a number of frequency ranges as they are authorized to represent, at a momentary rate subject to their determination. At ongoing intervals, clients will query available providers and make a determination as to which represents the best available option for current data requirements, based on a predetermined set of criteria, including but not limited to, price, performance, reliability, available bandwidth and past experience. The querying and negotiations for service between client and provider may be direct or intermediated (brokered) by a third party, the bidding server.
The present invention offers numerous useful benefits. Credits will be offered through a variety of channels, at a variety of prices, taking advantage of competitive market forces, as well as promotional and cross-product offers. This process will permit a more open and competitive marketplace in which carriers of all sizes can compete for business within the wireless spectrum. Subsequently, market forces will yield greater competition and choice of carriers, leading to better overall consumer satisfaction. Mobile client device manufacturers will be able to standardize components to support a greater spectrum of frequencies, eventually reducing manufacturing costs while simultaneously reaching a broader range of both consumers and carriers.
In one embodiment of the present invention, the client (through the mobile device) and spectrum provider negotiate directly. This type of scenario is illustrated very simply in
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
In another embodiment and best mode of the present invention, a third party (a central bidding server) intermediates the negotiation between mobile client device user and spectrum provider.
Referring to
Referring to
Requests are preferably sent via piggy back off data, or off voice or in another embodiment can be managed outside of the device as part of billing management. For example the user can use a website to register the device and then bid for whatever is needed either via this site or from the device.
A web interface may be provided for users. However, the user will preferably not need to access the web interface every time a new service request is made. The idea is that a user can set preferences, thresholds, limits, etc. and then the bidding can go ahead when these criteria are met. Once user sets preferences, the whole system can preferably operate more or less invisibly (transparently) to the user (i.e. switching between providers and deducting credits from an account on the fly). At other times, the user may be more involved (e.g. making a choice between equal scoring providers). Preferably, the user can make changes and check on the current status, and be notified of the choices and upcoming events. In one embodiment, the user may get a final user confirmation before a bid is entered or before a transaction proceeds.
Referring to
In any embodiment, whether negotiations between client and provider occur directly or mediated by a central server, the core logic in the bidding process is identical.
In the most typical case, heuristics of the bidding process is such that clients receive competitive service for the lowest number of credits (price).
Credits may be typical monetary instruments or such indirect payments such as “travel miles” or “reward points”. Credits may also include prepaid cash credits, instead of arbitrary credits. Credits that a client has may be kept at an online payment service which holds the credits. These credits can then be accessed, depending on the embodiment, by the spectrum provider or central bidding server. Ultimately, credits are transferred from the client to the provider in exchange for service. Alternatives to credits as payment may be used such as advertisements received by the client in exchange for services.
The actual purchase of data access from a provider may occur at various points (when the credits are purchased, when the credits are “redeemed” to start the service, or after the service is used). In one preferred embodiment, access is realtime on successful bidding. That is, the user is buying data/voice/access based on live marketing conditions in an auction environment. After-user settlement of credits may also occur. A continuous account may be maintained that may be topped up by the user from time to time (or pre-authorized credit card on file).
The financial settlements can be structured various ways. The user may pay the intermediary who pays the providers, or the user may pay the provider(s) directly. Funds may also be pooled and allocated by percentage among the providers.
The agreement between the user and the service provider can be based on terms—an example would be a level of access over a certain time period (like a data plan for a month) or it can be on-demand usage (500 MBs of data, for a certain period e.g. 1 month)—terms and expiry dates and policies should all be part of what gets purchased (i.e. notified/accessible to the user at the time of bidding).
The credits may themselves fluctuate in value in a competitive bidding scenario. The value can thus be based on market conditions. If the user has prepaid with real money, the user's currency account will generally not change in value. However, the relative value of services that are being bid upon can go up (thus resulting in a relative decrease in the purchasing power of the currency/credits).
In one scenario the user may have prepaid a certain amount (say $100) to the operator and each successful bid is adjusted against this balance. Another can be that the user has registered their credit card with the operator and each successful bid is charged against this card.
Users should be able to rank providers (there may be loyalty programs tied to them). The system preferably allows the device user to set limits on what he/she is willing to pay for, and to automatically bid and get access to the best price and fit that is on the market for the services that the user wants (e.g. I want to pay max 10 dollars for 1 GB of data for a month).
The intent of the application is to cover all such combinations and permutations not listed here but that are obvious to the ones skilled in the art. The above examples are not intended to be limiting, but are illustrative and exemplary.
The examples noted here are for illustrative purposes only and may be extended to other implementation embodiments. While several embodiments are described, there is no intent to limit the disclosure to the embodiment(s) disclosed herein. On the contrary, the intent is to cover all alternatives, modifications, and equivalents obvious to those familiar with the art.
This application claims priority from U.S. Provisional Application No. 61/513,824 filed on Aug. 1, 2011, which is incorporated by reference in its entirety herein.
| Number | Date | Country | |
|---|---|---|---|
| 61513824 | Aug 2011 | US |
