J2ME, MIDP 2.0 and detecting phone number

[Vagif Abilov]

Hello,

We need to provide access to our services from the mobile phone, so we tried
J2ME and Java applications (Midlets) for mobile phones.
There's one thing we can't figure out: is there any generic way to detect
mobile phone subscriber's number? It does not look so. How then this task is
usually approached? Very often it is necessary to know the MSN (for billing
purposes for example), so I believe this must be a common problem.

Thanks in advance

Vagif Abilov

 

[Darryl L. Pierce]

We need to provide access to our services from the mobile phone, so we
tried J2ME and Java applications (Midlets) for mobile phones.
There's one thing we can't figure out: is there any generic way to detect
mobile phone subscriber's number?

No. There are no APIs in the MIDP to determine the phone number since not
all MIDs are mobile phones.

It does not look so. How then this task
is usually approached? Very often it is necessary to know the MSN (for
billing purposes for example), so I believe this must be a common problem.

You could have the user enter their phone number in a form and store it
locally.

 

[Vagif Abilov]

Thanks,

The problem that to let user enter phone number does not really work if the
number is used in billing purposes. People can enter other people's number,
and they can also swap SIM cards after the number is stored. Too bad.

Best regards
Vagif

 

[Darryl L. Pierce]

The problem that to let user enter phone number does not really work if
the number is used in billing purposes. People can enter other people's
number, and they can also swap SIM cards after the number is stored. Too
bad.

Then you could issue them a key and let that be the way by which you
identify their device.

 

[Darryl L. Pierce]

AFAIK issuing a key is a part of PKI support that MIDP 2.0 has (was not
possible in MIDP 1.0). Is this what you meant?

No. I meant issue them a unique identifier (a key) that they need to use in
order to use your application.

 

[Vagif Abilov]

AFAIK issuing a key is a part of PKI support that MIDP 2.0 has (was not
possible in MIDP 1.0). Is this what you meant?

Thank you

Vagif

 

[Anton Spaans]

One possible key can be the phone's IMEI number (serial number).
This is available on GSM phones and uniquely identifies the phone.
For TDMA/CDMA etc. phones, i don't know how to get this number...

-- Anton.

AFAIK issuing a key is a part of PKI support that MIDP 2.0 has (was not
possible in MIDP 1.0). Is this what you meant?

Thank you

Vagif

 

[Tim Ward]

One possible key can be the phone's IMEI number (serial number).
This is available on GSM phones and uniquely identifies the phone.

The phone, not the user. Plus in many phones the IMEI is not hard-wired as
required by the GSM standards but can be reprogrammed. So it can't even
reliably do the one thing you might have thought it useful for, ie identify
stolen phones.

 

[Anton Spaans]

Many software programs for phones are sold using the phone's IMEI number. I
know, it is possible to reprogram the IMEI, but it is illegal. It is
possible to remove your car's identifcation (VIN) number as well....

If the worry is that a phone may get stolen, then you need to require a
login from the user every time (s)he needs to access the services you sell,
because you can't store login-info (in case it gets stolen).
Maybe a login-id is the safest (note that many phones do not support secure
connections (e.g. https))....

-- Anton

 

[Tim Tyler]

Vagif Abilov wrote:

No. There are no APIs in the MIDP to determine the phone number since not
all MIDs are mobile phones.

Not all MIDP devices have colour screens - and yet there is an API for
dealing with them.

I suspect there is a sensible reason for MIDP devices not giving out
their phone numbers to unsigned MIDlets on an ad-hoc basis, though:
phone numbers are personal information.

 

[Darryl L. Pierce]

One possible key can be the phone's IMEI number (serial number).
This is available on GSM phones and uniquely identifies the phone.

Not from the MIDP. The user would have to manually enter the IMEI number.

 

[Darryl L. Pierce]

Not all MIDP devices have colour screens - and yet there is an API for
dealing with them.

No, but most of them do, so your point is non sequitor.. The MIDP is
intended as the foundation on which many profiles will be implemented.
Having the MIDP be a catch-all for such things as phone numbers from a
mobile is unnecessary; other profile can be implemented to do that.

I suspect there is a sensible reason for MIDP devices not giving out
their phone numbers to unsigned MIDlets on an ad-hoc basis, though:
phone numbers are personal information.

And the MIDP is not intended to be implemented only on mobiles. When
writing an application for a router, of what purpose would such an API
for fetching the mobile number be?

The point is, there are some APIs that would make no sense on a headless
device, such as the gaming APIs. But, those are there since they have
an immediate need and do make sense on other non-mobile devices (though
not on all platforms where the MIDP will be implemented). Something like
an API to retrieve a mobile's number makes no sense *except* on a single
device type, a mobile. What's your iPAQ's mobile number? Your router's?
See my point?

 

[ZMMmike]

I know this thread is old, but here goes. I have a solution for this. It is in the testing process right now. Our concern for this is slightly different than for yours.

We encode (using a simple cipher like 0="r", 1="W", etc) into a class in the jar the phone number. This is done with a php script calling a shell script. We then create a new jar (and jad) and give them a link to it so they can download the application catered to their phone. The unique identifier in the filename is the first six characters of their password hash.

The reason we wanted the application to know what the phone number was so that we can track the information sent to that device. If the phone was stolen, the thief can't steal money or charge the original user for stuff.