Just to give you a bit more clarity on how BREW pricing to the content
provider, and how the general production and payment process works, here is
what happens for any developer, whether developing for KDDI or another
carrier, regardless of market:
Basic revenue model:
The content provider pays out a mandatory 20% share of the charges to
the consumer (these charges are divided between Qualcomm (licensing fee) and
the carrier).
The carrier has the discretion to add an additional 25% to the base
price of the application (e.g., you price your BREW app at Y500 per month,
KDDI has the option of addition up to Y125 to the price of the app). The
carrier keeps the entirety this additional price. In truth, they do not
usually add a large amount to the total price, but they had the discretion
to do so.
Most of the services work on either unlimited license (you pay once),
timed (monthly, weekly) or a per-use model. Qualcomm sends a check to the
content provider for the usage of their services at the end of each month.
The company has an intranet that allows you to track in real time the usage
of your apps. Also, when you release an app for one carrier (e.g., KDDI),
it is then viewed on a carrier intranet that makes it available for
potential usage on other carrier networks (e.g., if you publish an app for
KDDI, there is the potential that vivo (a Brazilian carrier) will contact
you to use the service for its customers - which opens up a whole new
revenue stream and relationship you'd have never known was possible.
I think there are also some advantages to BREW that may not be entirely
evident to those working mostly in the Japanese market:
A more simple development process. BREW application development specs are
more standardized then J2ME - I know that in Japan, you know pretty much
exactly what the minimum hardware/software design specs are going to be (as
they are tightly controlled by the carriers) but in other markets, they're
frankly all over the map and call for a great deal of tweaking. BREW apps
are more standardized, which makes them somewhat more simple.
BREW makes it much more simple to track and get paid for usage. Again, in
Japan, this has not been as much of a problem as in the US, but it does
represent the first time that a mobile software standard has been developed
with a easily accessible accounting backend built into the software.
US developers have been very happy with the results thus far, on the whole.
Now, there are a few other caveats:
there aren't that many developers for BREW - usually, J2ME,being an open
standard, is pretty simple to find people to develop applications for it -
BREW however, has a comparatively limited number of developers. The
developers usually ask for a share of the revenue you receive (around
10-30%), though you can find companies that will develop opn a one off
basis.
In the end its worth it to develop in-house.
You're stuck for the time being to the CDMA world. Though a phone does not
need to be CDMA to be BREW compliant, that's been the way its shaped up in
the short term. There's no BREW development in Europe in any real sense at
this time, and until the handset manufacturers or carriers in te EU get
behind it - which is not extremely likely in the short term.
Mark
On 7/6/03 11:37, "dc" <dc@gamelet.com> wrote:
>
> on kddi pricing, my understanding is that for brew the split is kddi =
> takes 20% whereas for java contents they take 9% (excluding bad debt - =
> unlike docomo).
> however, QCOM are in this equation taking part of the extra slice, not =
> all kddi.
>
> the basic motivation for kddi is that all the cdma phones basically use =
> qcom chipsets, which seem to be specced lower than the configurations =
> coming out for other networks here. hence java, side by side, looks much =
> worse on kddi phones. brew being native cuts through this and looks =
> better. You pay for it in dev cost and certification headaches.
>
> however, i don't quite understand technically why kyocera or panasonic =
> can't come up with a hardware configuration that includes the qc =
> baseband part but similar capabilities to their docomo devices, eg app =
> co-processor. QC announced recently they will provide the co-processor =
> configuration but are cdma parts so much more complex to design a device =
> around than PDC that the makers could not do it themselves?
>
> /dc
>
> // > Is Kddi's take higher with BREW, is that their motivation for=20
> // not having a
> // > jvm on top of brew?
> // =20
> // I can't say for sure, but it seems that the model won't follow=20
> // the US one. For=20
> // a starter, most probably no fee to receive the QUALCOMM stamp=20
> // (the BREW app=20
> // review by Q. people).
> // =20
> // And I have heard nothing of a different pricing from various=20
> // meeting with KDDI=20
> // people. So I'm not too worried about that. It's more the added=20
> // dev cost !
> // =20
> // > Any one use J2BRIDGE that lets Java developers run and test J2ME
> // > applications on BREW enabled platforms. It makes the=20
> // generation of MOD and
> // > MIF files seamless to Java developers and allows them to use the =
> BREW
> // > Emulator and AppLoader to run and download Java applications to =
> BREW
> // > devices????
> // No, but we will look into that. Thanks for the pointer.
> // =20
> // Let's unite ! :|
> // =20
> // Mathieu
> // =20
> // =20
> // This mail was sent to address dc@gamelet.com
> // Need archives? How to unsubscribe? =
> http://www.appelsiini.net/keitai-l/=20
> // =20
>
>
> This mail was sent to address mark@consect.com
> Need archives? How to unsubscribe? http://www.appelsiini.net/keitai-l/
>
>
--
Mark Frieser
Consect
+1 917 855 2669
Join 300 High Level Wireless Executives for a day of networking, case
studies and technology solutions at the Global Wireless Summit, Los Angeles
on December 3-4, 2003.
For more information on attending and sponsorship, visit our website at
http://globalwirelesssummit.com/la
--
A successful man is one who can lay a firm foundation with the bricks others
have thrown at him.
--David Brinkley
Received on Mon Jul 7 03:09:09 2003