DevBlog

Over the past few days, we've been making some tweaks to the way in which delivery reports work.

Tweak 1: Reduced number of report types

The first of these tweaks is that we have reduced the number of reports exposed to you, as customers, for many reports given back to us by network operators have the same meanings for end-users. And so, the reports which you will now be presented with are:

Tweak 2: NEGLCTD reports handled fully

The second of these tweaks is that we will now notify you, using the event handlers that you've specified (e.g. API notification), if any of your messages are neglected. As NEGLCTD is a propietary state and internal, it would not be handled the same way as an external report and you would only come to know by querying the message iself.

This is no longer the case as the NEGLCTD state will be handled as though its source was external, thereby being handled according to your specifications.

Up until today, we've always required that you specify which route, Global I or Global II, that your messages should be sent through at the time of broadcast.

As such, you will be happy to know that this no longer the case as we have now installed a back-end process which will make this decision on your behalf on a message-by-message basis.

In short, this development seeks to make things easier for you by:

• Reducing the number of potential fail points a broadcast may face.
• Saving you from having to separate recipients according to route coverage.

As a result, over the coming days you will notice all traces of the 'route' concept will disappear from our site (i.e. settings pages, knowledge base etc.).

This feature had already been developed for some time, but was due to be launched when TM4B 2.0 went live. Whilst the beta version will be live very soon, the production version of TM4B 2.0 may still be some time away and we've decided to start importing features from TM4B 2.0 into the current version so that the jump to TM4B 2.0 for non-beta users is not as large as it would otherwise be.

If you have any questions, do not hesitate to contact us at any time.

Following on from our last announcement, please be advised that the check_destination routine is being removed from our API's.

This routine was relevant when the concept of routing applied but, with the routing decision now being made through a back-end process, it no longer serves any purpose.

Although we will begin its discontinuation by removing its specifications from the knowledge base, we will officially discontinue the check_destination routine on July 1st 2009. In the meanwhile, we will continue to remind customers using the routine that it no longer servers any purpose.

If you have any questions, do not hesitate to contact us at any time.

In the last of today's important changes, we are no longer providing support for the shared static originator 20170000.

We apologise to customers who had become accustomed to using the originator, but due to a recent issue in the US wherein the activities of one customer on a shared US short code caused the potential access of other customers to be jeopardised, we no longer want to be in a position where one or more network providers decided to block all messages coming from 20170000 (and thereby many of you).

The cost of a static originator is only a one-time fee of £40, so if you would like to continue enjoying the lower message pricing which the use of static originators bring, you will be required to purchase your own, unique, static originator.

If you any questions, please do not hesitate to contact us at any time.

Just over 2 weeks ago we announced to you that the network through whom we routed our Global II France-bound messages planned to increase the cost of delivery to France and that such an increase would make Global II more expensive for our customers than Global I.

Since then, we've done our level best to source reliable routing that would allow us to continue providing Global II support for France at our current rates (or even rates lower than that of the increase) and we regret to inform you that this has not been possible.

As a result, as of now, France is being removed from our Global II coverage list and that all France-bound messages being routed through Global II will be redirected through Global I. This will ensure that, although the cost of messaging will increase, that your applications and services will not break.

There is no doubt that the difference in price in using Global I will be of great annoyance (due to the difference in price), but this was best decision we could make in the interest of our customers./

If you have any queries, please do not hesitate to contact us at any time.

If you ever wanted to add reply capabilities to your messaging service(s) whilst being on a tight budget, you would have found yourself in a difficult situation. On the one hand, dedicated numbers are too expensive (costing several hundred pounds) and, on the other hand, shared numbers are impractical (requiring users to begin their replies with keywords).

As of today, however, this is no longer the case as we've introduced a value-added service that makes true reply capabilities much more affordable.

How does it work?

Once subscribed, you will be given access to a group of inbound Virtual Mobile Numbers for South Africa, Australia, Spain, Ireland and the UK (with more numbers planned for the future). All you then need to do is set the originator of your outbound messages to any one of these numbers and replies sent back will be forwarded to your account.

How much does it cost?

The cost of the service is £149 per year (plus VAT if you're in the UK). If you to choose to make payment before next Friday (i.e. May 8th, 2009), a 33% discount will be available, dropping the cost down to just £99.00.

Besides this, there is no "per sms" cost to receive.

How do we purchase?

Simply login to SMS Online and go to the Sales section. From there, click on "Go" within the "Reply Capabilities" section and proceed to make payment.

How long does it take to set-up?

The service will be set up as soon as your payment has been received (i.e. real-time).

If you have any questions, do not hesitate to contact us at any time.

This is an important announcement for customers operating, or intending to operate, messaging services in the US.

As you would already know, the last few years has shown a concerted effort by the US network carriers to manage and regulate the commercial use of SMS in the US, with Common Short Codes (CSCs) playing the central role in their efforts.

When the mandatory status of CSCs was first announced and some networks began blocking messages sent through traditional channels, we took time to try and understand the motives of the carriers. The result of our analysis was that the freshness of the market presented the carriers with an excellent opportunity to put the necessary steps in place that would protect it from suffering the same fate as email with regards to spam (i.e. mobile spam) and that, in the hope they would loosen up over time, we would support them. We therefore removed the US from our Global routes, created a specific route for the US and then a specific Account and insisted on the adoption of CSCs by our clients.

However, 4 years down the line, their insistence of equating business-to-person SMS with "mobile marketing" has only increased, along with the strictness with which they wish to regulate it with.

As a result of this increased strictness, much more time and resources needs to be spent by us and, whilst we definitely don't aim to be the cheapest provider of text-messaging services, we completely disagree with charging such high rates that place business-to-person SMS out of reach for small to medium size businesses.

And so, rather than adopt the excessively high pricing plans adopted by aggregators in the US and then meet certain failure by not having a physical presence in the US, we've decided to pull out of the US CSC market completely.

We are now contacting our interconnect partners to establish non-CSC routes into the US and will also also seek to establish non-CSC ways of receiving SMS in the US. Doing so, we hope, will put business-to-person SMS within reach of many SMB's that don't require complete Tier 1 coverage.

We would like to advise our customers that the interconnect partner through whom we route our Global II France-bound messages has informed us that the cost of termination will be increasing in the first week of May.

Unfortunately, this increase will make Global II more expensive than Global I and there is a very high likelihood that our best course of action would be to remove France from the Global II coverage.

We are currently testing an alternative route as a way of avoiding this, but we just wanted to warn our customers in case this did happen.

If you have any questions or would like to help us test this new route, please let us know.

We would like to announce several changes to both our coverage and delivery rates.

To begin with, 69 countries have been added to Global I and 10 countries have been added to Global II. This is, of course, good news to customers which provide global services as well those who were forced into using either route due to route unavailability as these additions bring a greater freedom to choice between routes.

Conversely, 9 countries have been removed from our coverage altogether. For some time, we had been trialling the use of another (well-known) aggregator for numerous destinations, but their level of support eventually became lower than what our customers expect of us.

Obviously, we're not happy about removing these countries so abruptly, but the damage is minimal; the reachability of 4 countries was never made public and the traffic of the remaining 5 was negligible (less than 850 messages in over a year). In normal circumstances, we would establish a new route to such destinations and increase the delivery rate if need be, but these destinations are not supported through our existing interconnect agreements.

The last set of changes is that of major overhaul on delivery rates affecting almost every destination besides the UK. Out of 212 changes, 64 related to decreases and 148 relate to increases. We're also not happy about increases (especially during a recession), but the weakened pound has caused our costs to increase and we hope that they will offset by the comparative strength which other currencies enjoy against the pound.

We've put up a sortable Microsoft Excel spreadsheet which lists all the changes so that you can easily identify those changes which affect you. It can also be exported to CSV if need be.

Keeping quality and reliability as the most important factors, we will continue striving to increase our reach and reduce delivery rates.

We are happy to announce that the following networks have been added to our network coverage:

• Colombia
  • Móvil S.A.
  • Telfónica Móviles Colombia
• Sierra Leone
  • Comium
• UAE
  • Du
• Belarus
  • BelCel JV (CDMA)
  • MTS
  • Belaruskaja Setka Telekamunikacyj

Additionally, Belarus has been added to the coverage of Global I at a base delivery rate of 3.5 credits per SMS.

We have, as of today, made 2 sets of price changes which effect Greece & Guadeloupe.

These changes in delivery rates both relate to increases:

• Greece: From 3.3 credits to 4.7 credits via Global II and 3.9 credits to 5.0 credits via Global I
• Guadeloupe: From 3.3 credits to 6.0 credits via Global II and 3.5 credits to 6.2 credits via Global I

These price changes have come about through recently developed levels of instability in terminating to these countries. In normal circumstances, we would aim to give more additional notice on price changes, however reliability is our priority and these price changes have now taken effect.

As of today, US Cellular has been added to the list of US networks which we can reach.

All standard rated services have already been approved and the added coverage is automatic.

We have a new Australian Long Number which we are providing shared access to. This number is much easier to remember (0448 222 777) and should go a long way in helping secure the participation of mobile users in your interactive applications.

We have also introduced a new German Long Number with shared access (0177 178 4108) and have added dedicated German numbers to our portfolio of receiving numbers.

Although we have, for some time, stopped making changes to the existing service, we have just made made a very subtle change which *will* go noticed by a few of our customers.

This subtle change is that we are now dividing customer accounts into US & Global accounts. We've already begun asking new customers which type of account they would like during registration and we've also changed the status of accounts which are obviously orientated around the one of the other.

Once the new service goes live, we'll also offer accounts for other regions as well, and the sole purposes behind these changes are to (1) simplify the service for our users and (2) let us create region-based offerings.

What this means, at present, is that US Accounts can only be used to send & receive SMS in the US (purchasing their credits in USD), whilst Global Accounts are used for messaging operations in other countries (purchasing their credits in GBP).

And, of course, the small minority of customers with operations in both are required to maintain 2 separate accounts.

As mentioned, this change will go unnoticed by most of our customers, but if you have any queries relating to it, then please do not hesitate to ask.

Our entire service has been undergoing redevelopment since mid-2006 and we are happy to say that it will be ready for relaunch in the very near future.

The new service facilitates vast improvements in terms of accessibility, usability, competitiveness etc. and will see the launch of an online community and a section dedicated to integration.

Although many of the new features can be considered the produce of customer feedback, we also plan on taking a much more responsive approach to the opinions, complaints and wants of our customers.

As such, whilst the new site is not yet launched, we want to take this opportunity to ask our customer base to give us as much feedback as possible so that we can either cater for the feedback prior to launch or, at least, leave our horizons open for a response some point in the future.

So, if you have any feedback which you feel will make our service better than our competition, please let us know by visiting http://www.tm4bhelp.com/cc.

We would like to advise our customers that terminating networks Orange Caraibe in Martinique and Medi Telecom in Morocco have imposed blocks on an interconnect partner which we use to reach them on MT delivery via Global II.

As an immediate remedy for Medi Telecom, we are redirected all Global II traffic terminating in Morocco to the Global I messaging route. As for, Orange Caraibe, our interconnect partner is making efforts to have this action reversed.

Until these issues are resolved, these two networks are being removed from our publicised coverage and we shall provide further notification as developments take place.

We would like to take this opportunity to, once again, stress upon our customers the importance of ensuring that all MT traffic are protected from unwanted messages. This means that the permission of mobile users need to be obtained according the regulations of their countries and that simple opt-out mechanisms are also provided which mobile users are made aware of.

Over the past few days, a handful of customers have experienced a lack of responsiveness from our servers and, whilst we have frantically tried to understand the root problem behind it, we were unable to. Then today, our services were unavailable for almost 2 hours.

Following last month's downtime, it is indeed very embarrassing to experience a further case of down-time in such a short period and an explanation is necessary.

To begin with, ollowing last month's unexpected downtime, we took many steps to increase the reliability of our services. Part of these steps involved relocating our servers to, what is considered to be, one of the best data-centres in the world. However, as it would happen, even the best have unexpected problems as described by the following 3 messages from the Chief Network Administrator:

We can only but apologise for this loss in reliability and unexpected downtime. We chose to locate our servers in the Cedar Falls data-centre because it is one of, if not, the best in the world and will continue to maintain our servers there, taking this as a one-off occurrence.

We also request customers to inform us should they experience any problems.

Customers terminating messages in France will be happy to know that it has been added to our Global I messaging route.

Although the delivery rate (of 5.8 GB credits) is slightly higher than on Global II, it provides the added support of dynamic originators (i.e. originators created on the fly) as well as numeric originators which are otherwise not possible via Global II.

Kuwait is no longer being supported via Global II and support via Global I has been introduced.

The reason behind this change is a combination of (1) an unacceptably high price increase for the Global II messaging route and (2) a recently acquired ability to route via Global I at a lower price.

The base rate of delivery to Kuwait is now 4.2 GB credits and all messages being sent via Global II will automatically be directed via Global I.

As of today, we have become one of very few service providers that can boast coverage of New Zealand's Telstra network. Additionally, the base rate of delivery via Global I has been reduced from 3.5 GB credits to 3.4 GB credits.

Not much can be said! The network operator Info Quest in Greece has been added to the network coverage of both global routes.

As part of numerous changes to pricing and coverage that will be taking place over the next few weeks, we would like to inform customers that Italy is no longer available through the Global II messaging route.

In reality, it is still available, but the cost of delivery via Global II now matches that of Global I and it doesn't make sense that the cost of messaging with a static originator should be the same as that with a dynamic originator.

Please note that, although Italy has been removed from our Global II coverage, customers who are used to terminating Italian messages via Global II can continue to do so as they will automatically be forwarded via Global I.

Customers who interact with our service using our main server's IP Address should know that we have moved to a different server in a new hosting environment and that the front-end IP Address has changed.

The new IP Address is 64.38.41.12 and, although the old IP Address will continue to work for a limited period of time (approximately 1 week), such customers are advised to modify their applications immediately. We would also recommend customers to interact with our domain name (i.e. tm4b.com) as opposed to an IP Address.

Customers will also be happy to know that our new hosting environment benefits from significant improvements in:

• Upgraded hardware that should be reflected in performance.
• Physical security for safeguarding our services and data.
• Environmental control features to maximise reliability.
• Redundant systems to maximize connectivity and uptime.

We look forward to continuously improving our services to meet your needs.

Customers will be happy to know that our much anticipated US PSMS program is about to go live.

Whilst our program has been certified by almost all US Carriers, T-Mobile is currently suffering from a back log of around 25 days which is effecting all service providers.

Initially, our PSMS program will be based on one-time events on the following price points:

• $0.50
• $0.50
• $0.75
• $0.99
• $1.49
• $1.99

Although PSMS reporting facilities will only be available on our new site (which is due to go live in June), customers that would like to start using the service from now should contact us through the Contact Centre

As of this morning, Email-to-SMS users will have noticed some obvious changes in the way that Email-to-SMS Broadcasts are handled and we'd like to list them here:

The first change is that the delivery reports of ALL Email-to-SMS Broadcasts are being sent back to the email addresses from which they were sent. Previously this was an optional feature, but it has now become a standard.

The second change is that the subject line can now be used to match our broadcast confirmations and delivery reports with your original Email-to-SMS Broadcasts.

Up until now, the subject line was used to provide the TM4B Username and the Email-to-SMS Password. However, with this new development, Email-to-SMS users can now insert the Email-to-SMS Password within the message body and use the subject line to hold something meaningful that can keep our responses in relevant context.

So, if "Mrs Jackson Appointment Reminder" was used as the subject of an Email-to-SMS Broadcast, you can expect our confirmation to look like "Re: Mrs Jackson Appointment Reminder [ACCEPTED]" and a delivery report to look like "Re: Mrs Jackson Appointment Reminder [DELIVRD]".

Email-to-SMS users who wish to make use of this feature no longer need to include the TM4B Username within their broadcasts as only the Email-to-SMS Password is required.

The third change is that, in those cases when an Email-to-SMS Broadcast is rejected, we will provide a full list of reasons for the failure. Previously, one error was sufficient to trigger an error message and prevent the remainder of the Email-to-SMS Broadcast from being processed. However, in those cases when more than one error has existed, you would have been required to fix the first error to find the next and so on. This is no longer the case as all errors will be reported simultaneously.

The fourth change is that we will not be sending error messages in response to those Email-to-SMS Broadcasts in which none of the required values can be found. This is because the "email2sms" address has found its way on the list of email spammers and our mail servers are wasting their resources sending error messages in response to junk mail. Due to the ease with which an Email-to-SMS Broadcast can be made, it is highly unlikely that a real Email-to-SMS User would ever send a message that did not contain any of the required values and we feel that this is a good way to handle those junk emails which get through our spam filters.

The fifth change is that the 'msg' parameter has been renamed 'message' for the sake of verbosity as Email-to-SMS Broadcasts are made by humans and not machines.

The last change is that all of the emails which we send you in response to Email-to-SMS Broadcast have been re-written to be more 'human' and ensure maximum clarity.

All of these changes are geared towards making Email-to-SMS the easiest way for desk staff to send and receive SMS with mobile users and, through your feedback, we look forward to making more improvements in this respect.

Although new screenshots have been uploaded and the "how to" has been changed, the old ways of using "msg" and providing credentials in the subject line can continue for the foreseeable future.

Customers terminating traffic in the UAE will be happy to know that Etisalat is now, once again, reachable to us through our Global I messaging route.

Whilst the previously installed block has not yet been resolved, we are now routing Global I messages through another interconnect partner who's channel to the UAE is fully open.

This change, however, has seen a slight increase in the base delivery rate from 3.5 GB credits to 3.8 GB credits. When the existing blocks are removed (which we hope to take place in the coming weeks), we will be able to reduce the delivery rate back down to its original price.

Although the messages of our customers have not been spam-related, we remind customers to ensure that any traffic being sent to any destination network complies with the relevant regulations of the destination countries and that messages are only sent to recipients who have requested them.

We would like customers to know that the recent problem surrounding the UK Receiving Numbers has been fixed and they are fully live again.

This has taken the attention of our entire support team and we apologise (a) for the downtime caused to those customers using UK Receiving Numbers and (b) for those customers that could not receive a support levels as high as usual.

One interesting point, for those customers that may (sometimes) feel unhappy about our decision not to provide tele-support, is that a time like this is an excellent example of when the attention of certain members of staff need to be directed towards issues which hold paramount importance over other (comparatively) less important issues.

We are dedicated to the highest levels of support and the use of the Contact Centre for customer communications makes this possible.

We would like to advise customers that, due to problems which we are still trying to resolve, we are unable to receive MO SMS through our UK receiving numbers.

MO SMS are reaching the Network Operators and are being forwarded in our direction but we are, for reasons which we are not yet able to establish, not able to receive them.

We can only but apologise about the inconvenience(s) which are being caused and would like customers to know that we are working around the clock to understand and resolve this matter.

Unless otherwise requested by affected customers, all of the messages which should have been handled during this time will be handled when the numbers come back online.

We would like to advise customers that we are currently experiencing issues delivering SMS to the Etisalat network in the United Arab Emirates.

This blockage is effecting the Global I messaging route and all UAE messages are being diverted to Global II. This means that messages are still being delivered, except that the originator of the messages is being changed to the communal originator '20170000'.

We are progressing this issue with our interconnect partner and shall advise you further when the problem is resolved, or give further updates as they become available.

Please be assured we are endeavouring to resolve this problem as soon as possible.

Customers will be happy to know that, in addition to Visa Card, we are now accepting payment by MasterCard, Maestro, American Express, Switch, Solo, Delta & Visa Electron.

Furthermore, customers will be even happier to know that the handling fees have been reduced from 5.3% to 3.9%.

We are, however, implementing a Card Verification Program in which customers (wishing to pay using the above-mentioned cards) will have to first verify that they are the owners of the card.

In the long run, we are looking to tie the LowBal Notification system with an automated payment procedure to make sure that customers always maintain a positive credit balance.

Meanwhile, customers that would like to have their cards verified and begin using them for online payments, should contact Sales & Admin.

It gives us great sorrow to inform customers that we are no longer offering Long Numbers based in France.

Whilst we offered these numbers to our customers in good faith, it has now come to reality that the up-stream network made these numbers available to us without realising the requirements that increased demand and usage would place on them.

The result of this mis-realisation was that, on two separate occasions in the last 4 months, a total of 3 numbers were terminated prematurely without any notice. On both occasions, we were assured that such an error would not take place again, but a fourth number has again been prematurely terminated.

Although this is a major set-back for us and our customers, we cannot stand to offer a service which is unreliable and we have decided to discontinue formal support of these numbers and approach the French MO market through common short codes.

Although existing French Long Numbers can still be used in this unpredictable situation, customers are advised to discontinue their leases voluntarily in exchange for a refund and preferential prices on our French short code program when it is launched.

Customers will be happy to know that Telecom New Zealand has been added to our coverage for New Zealand. This addition applies to both of our Global routes and does not effect the delivery rates in any way.

Developers should be aware that API-Client Routines now include three new parameters with all requests.

Any questions or feedback should be directed to our Technical Staff.

We would like to announce a few changes to our MT coverage/pricing which take immediate effect.

• United Kingdom: Both Global routes now support Cable & Wireless (Jersey) and Jersey Airtel.
• Pakistan: Global II now supports Telenor and the delivery rate has been increased to 3.6 credits. Unfortunately, however, Global I support for Pakistan has been removed completely.
• Nigeria: Global II now supports Globacom.
• French Polynesia: Due to the ongoing downtime, support for French Polynesia has been removed from Global II.

We are happy to inform customers using our shared 70589 program in the U.S. that T-Mobile has removed their suspension and the messages are now being sent/received through the T-Mobile network without any problems.

Network carriers in the U.S. are very serious about ensuring that their mobile messaging industry is protected and, to that effect, they do not hesitate to suspend/terminate short code programs which they see go against their rules & regulations.

Fortunately, in our case, the suspension was due to a misunderstanding which was resolved immediately, but occurrences like these should sound as a warning and remind us about the importance of providing mobile messaging services which are carrier compliant.

We would also like to take this occasion to announce that we have increased the annual cost of subscription services on the 70589 program from $49.00 per year to $99.00. Whilst this new rate may not necessarily be in-line with our low cost policies, we hope that it will help ensure only serious content providers to make use of services which are shared with other users.

Customers using our shared short code program 70589 should be aware that it is under a temporary suspension placed by T-Mobile. For one reason or the other, which we are in the process of establishing, they have caught feeling that our program is non-compliant with their rules & regulations.

We are currently discussing the issue with them and aim to resolve it as quickly as possible. Meanwhile, this means that we are unable to receive MO SMS from, or send MT SMS to, T-Mobile subscribers through the shared 70589 program.

Customers should be made aware that delivery to French Polynesia is temporarily unavailable due to the sole terminating network placing a block on our interconnect partner due to SPAM reports from their subscriber base.

We are making every effort to have this route re-opened through an alternate interconnect partner and will keep customers notified of updates as they happen.

As promised in mid-December, the price increase applied to delivery to the United Arab Emirates has been discontinued and the original delivery rate of 3.5 GB credits has been re-instated.

In brief, Etisalat began blocking the SMS of one of our interconnect partners used to reach this destination and, to maintain up-time, we had to find an alternative (which was more expensive).

However, extensive discussions were held with Etisalat, who explained their reasons for implementing blocking. They stressed that (1) SMS should not be of a spam nature, (2) that care should be taken with regards to the content of messages causing concern or offence to their subscriber base and (3) they were concerned with the frequency with which some companies sent marketing messages to their subscriber base.

It is extremely important for clients to ensure that any traffic being sent to any destination network complies with the relevant regulations of the destination countries and that messages are only sent to recipients who have requested them. Furthermore, in the context of delivery to the Etisalat network, clients should give full consideration to the concerns of Etisalat for traffic that they are routing to this network.

Although our original routing is now live again, with the original lower rate of delivery, we must remind customers that action may be taken against any client found to be in breach of our Usage Policy which may include suspension or termination of their account and possible legal action.

We apologise for any inconvenience experienced during this temporary increase in delivery rates and we wish our clients all the best with their messaging programs.

We are now offering the ability to receive mobile originated SMS through 10 digit long numbers based in Ireland.

These are based on the Orange network and benefit from the international roaming agreements that Orange has with other network operators around the world. Irish mobile users can reach them through their local format (e.g. 0871234567), whilst mobile users outside of Ireland address them in their full MSISDN format (i.e. +353871234567).

We are happy to be one of very few companies able to offer such numbers and are leasing them at an annual cost of £399.00 (dedicated) and £39.00 (shared).

Customers who wish to set up demo keywords for testing purposes may contact Sales & Administration at any time.

Following the introduction of Irish long numbers, we have reduced the cost of dedicated keywords on shared French & Australian numbers to help us provide a discount system which spreads over all of our shared long numbers.

Up until today, the cost of a dedicated keywords on a French or Australian long number was £49.00 per year, whilst keywords on other long numbers were leased at £39.00 per year. As of today, however, the leasing cost of keywords on any long number is £39.00.

Furthermore, we have also introduced a discount system so that keywords can be leased on multiple numbers and benefit from repeat purchase discounts. The discount system is as follows:

So, in addition to reducing prices, we are also (a) making it affordable for customers to provide the same keywords on multiple numbers and (b) allowing resellers to reduce their prices or increase their profit margins.

Lastly, to take into recent purchases at the higher rates, we will be issuing 1,000 gift credits to those customers who purchased keywords on Australian and/or French long numbers in the last month who will be notified by email.

We would like to announce a price increase on dedicated keywords on our UK Short Code and, simultaneously announce, that we have introduced a discount system for repeat purchases of the same.

The current leasing cost for one dedicated keyword on our UK Short Code is £149.00. However, with effect from January 1st 2007, this cost will increase to £249.00 per year. Existing customers, who are currently leasing their keywords at the old rate, are not effected by this increase as we will continue to lease out their existing keywords at the same rate with which they began.

At the same time, we are happy to announce that we will also be offering discounts that increase with purchase volume and are not restricted by time. That is to say, customers can purchase keywords at different stages in their relationship with us and receive discounts after different thresholds have been passed (as opposed to saying 'buy so many keywords at the same time and receive X% discount').

With this system, which is already in place with our US Short Code, only the first 3 keywords cost £249.00 - the next 7 keywords are reduced to £149.00 each and every keyword purchased after that is reduced to only £29.00:

This discount system provides an excellent alternative to dedicated short codes because the level of commitment required is minuscule and the immediate use of hundreds of keywords only would necessitate a dedicated short code.

Please remember that this price change takes effect on Monday January 1st 2007 and customers leasing keywords before then will be happy to know that their lower-rated keywords will still contribute to their volume thresholds for future discounts.

Also, this announcement coincides with a new routine to our SMS API which allows for the availability of keywords to be queried and customer feedback, as always, is warmly welcomed.

We have added a new routine to the TM4B SMS API v2.1 through which the availability of keywords can be checked on all the receiving numbers with which we provide shared access.

This addition has been made to coincide with the discount system added to dedicated keywords on our UK Short Code and will allow companies with messaging platforms that base themselves on that of TM4B to allow their customers to query the availability of their own desired keywords.

The name of the routine is "Check_Keyword" and its specifications can be found here.

Meanwhile, we are in the process of developing v2.2 of the TM4B SMS API and would kindly request customers to forward us their "wish lists" for additions and modifications to the existing SMS API. We would also like developers to know that we are looking to provide more comprehensive support for 3rd party integration and are welcoming any suggestions in that regard.

Taking immediate effect, Croatia has been added to the Global I messaging route with both of its mobile network operators included within the network coverage.

The standard delivery rate is 5.5 credits, which brings the real cost of delivery anywhere between 4.0 - 5.5 pence per SMS depending on the size of individual purchases.

The standard delivery rate for the following destinations/routes have changed with immediate effect and we apologise for our inability to notify customers in advance.

Although the new rate for the UAE via Global I is temporary, all but 4 out of 5 changes relate to increases.

Changes to Global II

Changes to Global I

In between December 21st 2006 and January 3rd 2007, the registration process which all static originators must go through will be temporarily interrupted.

Unfortunately, this is due to the third parties which this process depends upon and we would like customers to know, in advance, that any static originators which are still pending at the beginning of this period will not be progressed until its end. Similarly, the registration process for any new static originators purchase during that period will not begin until January 3rd 2007.

Customers using our USA Direct messaging route should know that, in order to keep all subscription services 100% carrier compliant, we will be unsubscribing all mobile numbers which have been disconnected from their respective network operators.

Network operators recycle their numbers on a frequent basis and, obviously, they want to ensure that a user who is given a recycled number is not inadvertently subscribed to a service which they know nothing about. They therefore maintain a strict policy in this regard and any short code program which fails to comply with this request will be terminated by the relevant operator.

It even makes sense to a content provider that its messages should not (wastefully) be delivered to a number that has been disconnected or to someone that did not request them and unsubsribing such numbers ensures that this does not take place.

From a technical perspective, whenever such unsubscriptions take place, content providers will be notified in the same way as an "opt out" (according to their settings) and their subscription logs will contain the descriptive explanation.

We wish our USA Direct customers the best success with their subscription services and we are happy to have taken away most of the responsibility which carrier compliance entails.

We have introduced a new policy and associated mechanism which further helps TM4B Customers to make sure that their funds are not wasted unnecessarily.

Although we already do all that we can to save customer credits through our unique Number Validation Process, there are many invalid messages which escape and incur the cost of message submission even though they fail actual delivery.

However, of these messages, a few thousand each year are zero-rated which means that their submission does not incur any cost.

Our new policy, therefore, is to not charge our customers for the submission of such messages. But, as such instances are exceptional, they can only be identified at each month's end and so this process of zero-rating can only be done through credit refunds at the end of each calendar month.

We have already begun the process of refunding all such messages which exist on our system, the oldest of which dates back to March 2006 and customers to whom such refunds apply will receive email notifications as well as a listing in the miscellaneous section of their purchase history.

The South American country 'Uruguay' has been added to the international coverage of both our Global I and Global II messaging routes.

The cost of delivery ranges between 2.41p-5.00p, the full details of which can be viewed on:

http://www.tm4b.com/sending-sms/message_pricing/index.php?this_country=Uruguay

The pricing system of French Long Numbers has been changed from Euros (EUR) to Great British Pounds (GBP) to help compare the cost of receiving numbers and avoid any possible confusion.

The result of this is that the cost of a dedicated long number in France is now £499.00 GBP and a dedicated keyword on the same is £49.00.

We are no longer providing support for messages being delivered to the US through the Global I messaging route.

This is on account of the strict rules and regulations which have been applied by the US network operators who insist upon:

1. Short codes – Every MT SMS must be sent using a registered short code as its originator.
2. Short code programs – The types of services, message flows, opt-in and opt-out procedures that a short code is used for must be registered with every carrier on which the service runs.
3. Explicit permission – Every message sent to a US mobile user must have his/her explicit permission which must be obtained through his/her mobile device.

Please note that we will still continue to attempt message delivery because of the difficulty in differentiating between Canadian & US messages, but the US has been removed from our coverage lists and we will not be able to provide technical support for any issue relating to delivery in the US via Global I.

Customers who wish to launch a carrier-compliant program in the US, but find the above requirements too expensive and time-consuming, should contact us for more details about our shared short code program.

We are very happy to announce that we will soon be offering the ability to receive mobile originated SMS through long numbers based in France.

These are 11 digit numbers (e.g. 06123456789) based on the Orange network and provide several benefits over French Short Codes:

1. The sender's MSISDN is known and not masked by the network operators.
2. These numbers benefit from the international roaming agreements that Orange has with other network operators and can be accessed from outside France in their MSISDN format (i.e. +336123456789).
3. The red tape surrounding these numbers is much lower.
4. A dedicated number can be set up within 2 - 3 working days.

These numbers will be available from Monday 18th Septmber at an annual rate of €699.99 EUR for dedicated numbers and €59.99 EUR for dedicated keywords on shared numbers.

However, customers placing their orders before Friday 15th September will be able to enjoy a discount of €100.00 EUR bringing this cost down to €599.99 EUR and such purchases can take place at any time through the online "Sales" section.

For further information about these numbers or to have a temporary keyword set-up for testing purposes, please contact Sales & Administration.

We would like customers to know that we are discontinuing the "default country code" setting on messages sent through the SMS API.

Although this setting has simplified messaging through the Email to SMS and Web2SMS services, it has confused many SMS API users in their initial development phases.

As usual, the discontinuation is being done in a manner which will prevent client applications from breaking:

• Phase #1: To disallow this feature on accounts in which it is not used.
• Phase #2: To discontinue this feature completely.

Phase #1 has already taken place and Phase #2 is due to take place on Friday 8th Septermber 2006. Customers using this feature on the SMS API should make sure that they have adjusted their applications before the complete discontinuation date of 08/09/2006.

Annoyingly, T-Mobile (USA) has, once again, rescheduled their upcoming planned maintenance - the details on the original notice have been modified to reflect these.

We apologise for the further inconvenience, but there is not much we can do except to let our customers know.

We have added a new API-Client routine to our SMS API which extends our LowBal Notification system so that remote client applications can be notified when an account's credit balance drops down to/below a pre-specified level.

Although we provide two other methods of knowing an account's balance programmatically, these have either been mis-used, out of customer's reach or inadequate for certain needs:

1. The existing Client-API check_balance routines can be used to query an account's balance. However, having found that some customers query their balance every minute of every day.
2. In response, as part of SMS API v2.1, we added the new balance as part of our response to the broadcast routine. However, upgrading to v2.1 is voluntary and, even then, there are occassions when customers connect from different servers and this information may not always be useful when found by one of them

Our assumption in querying an account's balance is to know whether it has dropped down to a certain level and this task is already fulfilled by the LowBal Notification system. As such, we hope that this addittion to our SMS API will make things easier for our customers.

The details of the new routine can be found here and any comments/bugs should be forwarded to Technical Support.

We are happy to announce that we are now offering permanent discounts to customers that make heavy use of our shared US short code for one-time events. For such customers, these discounts will bring the cost of dedicated keywords down to $49/year as follows:

• The first 3 keywords will remain at a cost of $499 per year each.
• The next 7 keywords will be offered at a cost of $249 per year each.
• All keywords after that will be made available for the low cost of $49 per year each.

There will be no special effort required by our customers to claim these reduced prices as their availability will depend on the total number of dedicated keywords existing simultaneously on our shared US short code (with at least 3 months left before they expire).

Any queries relating to this should be forwarded through our Contact Centre.

We would like to advise customers that T-Mobile has rescheduled the second phase of their planned maintenance from August 23rd to August 30th.

The full (modified) details of the maintenance can be found here.

To help customers ensure that they do not suffer from loss of service upon the completion of a product's service period, we have added an additional page to SMS Online which shows all of an account's products & services which are limited by expiry dates.

The page, which forms part of the newly created 'Sales' section, includes description of the relevant products & services along with the date upon which they are due to expire and the number of days left until they expire.

Although we do send two reminder emails on the approach of an impending expiry, this page will help customers plan forward in case they are unavailable during that time.

For the month of August, we are offering existing customers with discounted rates on dedicated keywords as follows:

This limited promotion, which will end on the last day of August 2006, is due to the fact that we are no longer able to offer customers with access to the shared TM4B keywords (which we used to offer free-of-charge) and aims at helping customers adopt an alternative.

In accordance with the rules, regulations and best practices of the mobile messaging industry, inbound numbers (for receiving SMS) and the keywords which they use must now be supplemented with a description of the service which they are being used to provide.

Furthermore, in the case of dedicated numbers, keywords can only be used to provide sub-deriviative services which the dedicated number is registered to provide and, in the case of dedicated keywords, secondary keywords can only be used to provide sub-deriviative services which the dedicated keyword is registered to provide.

Unfortunately, however, this means that we can no longer provide shared access to the 'TM4B' keyword which we have (until now) been giving free access to on various numbers.

Although we are required to immediately discontinue our support for existing message receivers that use the TM4B keyword, we are taking two steps to help our customers adjust their services accordingly:

1. We are delaying the discontinuation of existing TM4B-based message receivers until the last day of August 2006 - this is to protect our customers' services/applications from being 'cut' without alternative measure being adopted.

2. We are offering customers with discounted rates on dedicated keywords on receiving numbers - this is because TM4B-based message receivers were previously offered free-of-charge.

Details relating to the reduced prices can be found in this post and customers with dedicated numbers/keywords allocated to their account will be contacted seperately for descriptions of the services which they are using them to provide.

We would like to forewarn customers that T-Mobile will be performing planned maintenance on their network on the dates and times noted below. We apologize for any inconvenience this may cause.

We are happy to announce that our shared program using the short code 70589 has gone live, providing organisations with an opportunity to provide mobile messaging services in the US without investing the time and money required by dedicated short code programs. Using the 70589 program, subscription services will cost only $49/year and keywords for one-time events will cost only $499/year, both of which can be provisioned immediately.

Although we will be doing our best over the next two weeks to provide detailed information surrounding mobile messaging in the US market along with the detailed information about the different options available, we have put together a very short document which briefly outlines mobile messaging in the USA.

During this time, any enquiries should be submitted through our Contact Centre and we will endeavour to respond as fast as we can.

As of today, we are no longer accepting cheque as a method of payment because it has given rise to unexpected and unnecessary delays to the purchase process.

We will, however, be adopting the payment mechanism offered by MoneyBookers.com who do accept cheques.

Although we are always ready to provide customer support as quickly as possible, we recommend customers to use the Knowledge Base as the first point of reference as it can easily provide an immediate resolution to most issues.

And so, to help customers find the information that they're looking for in a fast and efficient manner, an advanced search facility has been added which retrieves relevant results in the fastest possible time.

Although search criteria can be modified by visiting the search page itself, a search box has been added to the top-right hand section of the entire HelpDesk for easy access.

Customers that experience any errors using the facility, receive results that are not relevant or would simply like to see an improvement should let us know through the Contact Centre.

Customers will be happy to know that we are now providing incoming numbers based in Australia. These are 'long' numbers based on the Telstra network, which means they can be reached by mobile users from around the world - those outside of Australia would include the dialling code for Australia whilst, for local users, it would be in its local form.

Receiving SMS on these numbers is completely free and the annual costs are:

• £49.00 for a dedicated keyword on a shared number.
• £449.00 for a randomly chosen dedicated number.
• £889.00 for a vanity-style dedicated number.

Dedicated keywords can be provisioned immediately (see this tutorial) and dedicated numbers require 1 - 3 working days (see this tutorial).

Prior to today, message credits would last for 12 months from the date of purchase, but we have decided that this policy should be discontinued.

Customers will therefore be happy to know that, as of today, message credits will no longer expire.

We are happy to announce that we have attained 100% network coverage for Italy & Ireland on both of our Global messaging routes.

The only networks which were, until now, unreachable were the Hutchison 3G networks. However, these are now fully-supported.

Whilst we have been able to improve our European network coverage, our support for Central/South America has suffered slightly.

Support for Argentina, Martinique & Mexico has been discontinued on the Global I messaging route (but still available on Global II) and the Brazillian networks Claro & Nextel are no longer reachable through Global I.

Foruntately, however, these destinations receive hardly any traffic and these set-backs will hardly be felt by our existing customer-base.

As customers will already know, support for Unicode messaging via Email-to-SMS last week and, in the name of simplicity, the character encoding of Email-to-SMS emails was used to differentiate between Unicode and plain text.

However, as there may be occasions in which a UTF-8 Email-to-SMS message may only contain plain text, treating it as Unicode would cause the maximum character length to be reduced to 70 characters unnecessarily.

So, from now on, in addition to checking the character encoding of the email body, the actual characters of the message will also be checked to see if the SMS needs to be in Unicode or if plain text will suffice.

Customers do not need to make any modifications and this is just an announcement to explain this new future.

We are offering a series of discounts for the first set of users who purchase dedicated keywords on our newly launched US Short Code 70589.

For those that don't know, dedicated keywords make it possible to receive SMS on shared numbers and are considerably more affordable than leasing out a dedicated number.

Although the cost of each keyword is $499 USD per year, we are offering the following discounts on the first year of lease for the first set of buyers (i.e. those who place their order in this month of July):

• Frst 10 customers will receive a 50% discount, bringing the cost down to $250.
• Second 10 customers will receive a 40% discount, bringing the cost down to $300.
• Remaining customers will receive a 25% discount, brining the cost down to $375.

Customers can check the availibility of their desired keywords through SMS Online, but should contact Sales & Administration to take advantage of these discounts which are limited in their availibility.

This offer is for July 2006 only.

The first change, as ironic as it may be, is that the 'Discontinuations' category has been discontinued. This is because many modifications also include discontinuations and we believe that combining them together makes more sense. As such the 4 posts which previously formed the Discontinuations section have now been re-filed under Modifications.

The second change, is the introduction of a Promotions category in which we will inform our existing & potential customers of any special offers that may be taking place along with their particulars.

Although the default notification period for the new Promotions category will also be weekly, we are sending a special notification today as our first offer (which is for existing users only) as it is based on a 'first come, first serve' basis and we want all of our customers to have an equal chance of benefitting.

Following the introduction of Unicode messaging and the ability to fix the Expiry Date & Time of MT SMS, the Email-to-SMS facility now provides support for both of these features.

Unlike our SMS API or Web-to-SMS, the expiry date & time in Email-to-SMS messages is provide as hours and minutes (e.g. 1h55 - 1 hour and 55 minutes). This is in line with the intended use of the Email-to-SMS service, i.e. to provide desk staff with the simplest method of sending SMS.

Support for Unicode messaging now means that customers speaking different languages from all over the world can now use their email clients to send SMS in their own languages. No extra steps are required... when a UTF-8 email is received, it is treated as a Unicode message.

We would also like to remind Email-to-SMS users that, whilst it will always be possible to send one message to multiple recipients, it is no longer possible to send multiple messages to multiple recipients. This was announced on 27 May 2006 and has taken effect today.

For more details, please see the Change Notes.

For more details, please see the Change Notes.

Customers wishing to deliver more than textual information will be happy to know that we have, as of today, introduced technical provision for 8-bit Binary SMS.

Unlike plain text and Unicode, the use of binary data requires the use of external specifications (such as that belonging to Nokia's Smart Messaging and EMS) and so, whilst we will do our best to provide a detailed section within our Knowledge Base, we will not be providing technical support for issues that relate to coding/encoding etc.

Sending binary SMS has been made very simple and can take place through the most recent release of our SMS API (v2.1) and the Web-to-SMS facility of SMS Online.

1. SMS API v2.1 has been released today in 'beta', providing support for a host of improved functionality that has been introduced in recent times. Its stability is of a sufficient level to make its release public, but we are keeping it in 'beta' to provide customers with an opportunity to give their feedback.
   
   Although SMS API v2.0 will remain in service for the foreseeable future, we recommend customers to upgrade to SMS API 2.1 in order to benefit from all the new developments which can be viewed here in the Knowledge Base.
2. The PDF version of the SMS API Technical Manual has been discontinued in favour of a dedicated section within the Knowledge Base. This, we hope, will allow us to provide other useful resources within a single environment, including responses to customer queries.
3. As outlined at the beginning of June, we have discontinued the use of the HTTP POST method on all of our Client-API routines.

Any questions/feedback relating to these changes should be forwarded to Technical Support and the subject title "SMS API 2.1" should be used for those that relate to it.

In line with our desire to make things as simple as possible, the Transaction ID has been removed from the authorisation process associated with PayPal payments.

From now on, PayPal payments can be authorised using the authorisation code alone and, as each code is unique, our back-end will use it as the identifier to locate the associated payment.

Also, customers requesting the re-sending of their authorisation code are now presented with a drop-down list of payments awaiting authorisation which removes the need of logging into the PayPal account to locate our Transaction ID.

As announced in late May, we have changed the format of MT broadcastID's and MO smsID's. The new formats are as follows:

• MT SMS - Begin with the 2 letters "MT" followed by 10 digits (e.g. MT0017295001).
• MO SMS - Begin with the 2 letters "MO" followed by 10 digits (e.g. MO0000557958).

Although we had intended on providing an interface through which old smsID's could be converted into new ones, we have not done so on the assumption that customers may not need this.

In any case, we will be keeping the old smsID's in an archived format and any customer requiring a conversion should contact Technical Support.

As described here, all three of our Client-API routines are now using both HTTP Post & HTTP Get to communicate with customer servers.

The next three weeks will act as a 'weaning' period to give customers a chance to migrate from the previous use of HTTP Post to the new use of HTTP Get and customers should adopt the use of HTTP Get before Monday June 26th 2006 to avoid any disruption of service.

Any customers experiencing any difficulties with their switch should contact Technical Support.

Customers should be aware that we will be changing the type of HTTP request used in our API-Client routines from POST to GET and this will effect the following (HTTP based) routines:

• Delivery report forwarding
• MO Forwarding using a URL
• MO Responding using a URL for content

This change is being made for two reasons. Primarly, it appears that some servers have been configured in such a way that they do not accept HTTP requests using the POST method. Furthermore, to account for developers of all levels, the GET method allows an application to be developed, checked and modifed more easily as our requests can be simulated through the address bar of an internet browser.

To give customers enough time to modify their applications and avoid any disruption of service, we will be implementing this change according to a two step process:

1. From Monday June 5th 2006, our HTTP requests will be made using both methods simultaneously and, from this point, applications will be able to accept the values being passed by either method.
2. From Monday June 26th 2006, our HTTP requests will be made using the GET method only and, by this time, all applications must be able to accept the values passed through this method.

Any questions relating to this change should be forwarded to our technical staff.

We have, as of yesterday, begun the successful implementation of Unicode messaging which enables transmission of text and symbols from all of the world's writing systems via SMS.

This means that we can now support all of the world's living languages including, for example, Arabic, Chinese & Greek. Customers should be aware, however, that a maximum length of 70 characters applies to Unicode messages, as opposed to 160 characters for plain text messages.

The implementation of Unicode messaging has begun with the Web-to-SMS facility and will next be included in SMS API v2.1 which is due for release this month.

Customers wanting to learn more about Unicode should begin with Wikipedia followed by the Unicode Consortium website.

Our messaging platform now facilitates long messaging in a total of 4 different ways and have already been made available to both Email-to-SMS and Web-to-SMS messages.

The first, and more important, of the new methods is 'concatenation'. This instructs receiving handsets to re-assemble long messages programmatically and has been released to coincide with the implementation of Unicode as a key to overcoming the length restriction from which it suffers.

The second is the 'three dots' method whihc adds an ellipsis to the end of each (except the last) SMS to signify that the message is 'to be continued'.

Furthermore, each of the four methods can now be implemented on a 'strict' or 'graceful' basis, with the latter ensuring that individual words are not split between SMS.

The settings for customers who previously used 'SMS Numbering' have been maintained and the Knowledge Base has been expanded to include a dedicated section belonging to Long Messaging.

Any questions relating to its implementation should be forwarded to our technical staff.

The Web-to-SMS messaging facility has undergone a service upgrade in which several features have been added, whilst trying to keep it as simple as possible.

Most importantly, it now includes full support for every implementation of long messaging, which can also be de-activated completely. It also includes support for the recent implementation of Unicode in which customers simply need to select the data type value as 'Unicode' and paste their message without performing any conversions.

Furthermore, all of the different settings which apply to Web-to-SMS broadcasts can be pre-saved as defaults and over-ridden, if necessary, during individual broadcast. Those who seldom change their settings can also have the settings hidden by default and make them visible for real-time changes.

Customers wanting to get a better understanding of the different changes should login and simulate a broadcast and any questions should be forwarded to our technical staff.

This is just a brief reminder to all customers that the previously announced price & routing changes have taken effect from 00:00 this morning. As a reminder, these changes are as follow:

Changes to Global II

Also, the following countries are no longer be available via II:

• French Guiana
• Reunion
• Barbados

Changes to Global I

Furthermore, the following destinations will are no longer available via Global I:

• Macao
• Saudi Arabia
• Croatia

As part of a complete change in direction with regards to our intended launch of a new type of account for US customers, we have changed the names of our existing messaging routes:

• 'First Class' has been renamed 'Global I'.
• 'Business Class' has been renamed 'Global II'.

Although these changes have been incorporated into the new version of our SMS API, which is soon to be released, they do not affect the existing service in any way and customers can continue to submit messages as they have been doing previously.

Our Knowledge Base and DevBlog have already been updated to reflect these changes and customers will be notified well in advance if we decided to discontinue the use of old names/codes completely.

As customers should already know, the objective of the Email-to-SMS facility is to provide the fastest & easiest way of submitting messages using nothing other than an email client such as MS Outlook.

This simplicity was previously achieved by defining all mandatory values in the body of the email message using a simple/non-technical lay-out, e.g:

From - OurCompany
To - 4479562**236, 447951292**1
Msg - Don't forget our appointment on Friday at 5pm.
Route - Business

In addition to the default country code, this simplicity has now been enhanced even further by allowing for a default originator and a default messaging route to be pre-saved, thereby reducing the values required to just recipients' numbers and the message body, e.g:

To - 079562**236, 07951292**1
Msg - Don't forget our appointment on Friday at 5pm.

These settings will be of particular use to the larger organisations as less instruction needs to be given to staff and the originator can be pre-set through the main account.

It is also worth noting that the default settings can be over-ridden by including them within the Email-to-SMS message body.

As an additional basic setting, a frequently used messaging route can now be saved for use on Web-to-SMS messages.

This new setting should simplify the message-sending process, even if just a little, and we hope that customers are happy to know we do whatever we can to make things easier for them.

This setting has been given its own category within the Knowledge Base which contains tutorials on how to activate and how to de-activate the default messaging route.

With a view to simplifying the Email-to-SMS facility as much as possible for human (as opposed to programmatic) use, the ability to send multiple messages to multiple recipients will be discontinued at the end of June.

This feature was originally provided to make the Email-to-SMS facility as functional as possible. However, with the introduction of the SMTP version of our SMS API, the overall theme of the Email-to-SMS facility has been changed to ease & simplicity.

Customers will still be able to send single messages to multiple recipients, as this can be expected of non-programmatic use, and customers who use the Email-to-SMS service to send multiple messages to multiple recipients should migrate to the SMTP version of our SMS API before 1 July 2006.

We would like to bring our customer's attention to the fact that we will be changing the format of broadcastID's and smsID's as follows:

1. MT SMS
   The existing format of broadcastID's (i.e. 32 alphanumeric characters) is going to be replaced with the 2 letters "MT" followed by 10 numeric characters (e.g. MT0017295001) and this will therefore effect the smsID's of MT SMS (e.g. MT0017295001-1).
2. MO SMS
   The existing format of MO smsID's (i.e. 32 alphanumeric characters) is going to be replaced with the 2 letters "MO" followed by 10 numeric characters (e.g. MO0017295001).

These changes are due to take place on 7 June 2006 and we are bringing this to the attention of our customers, especially users of our SMS API, because of the way in which customers may be handling/parsing smsID's; applications which would not be able to parse these new formats should be modified before the switch date so that either format is acceptable.

For a temporary period, we will also put in place a "lookup" tool which will return the new equivalent of old smsID's and details of this will follow at the time when the switch has been made.

The nature of SMS delivery between network operators and mobile devices is such that a store-and-forward methodology is used. Part of this methodology involves holding on to SMS that can't be delivered (most commonly due to the receiving handset being inactive) and re-attempting delivery repeatedly for the duration of the message's life (also known as its 'validity period').

Previously, when submitting SMS to the network operators, we have always set the validity period to the maximum possible (i.e. 3 days) to give receiving handsets the maximum opportunity to receive the messages that we transmit.

However, feedback from our customers has suggested that the ability to set a validity period that is less than the maximum would be very useful for certain occasions:

• To prevent the possibility of messages being delivered during anti-sociable hours.
• To promote events or offers that also have their own validity periods.

• To keep words such as 'today' and 'tomorrow' within context.

We have therefore begun to provide our customers with the ability to set the validity period of their MT SMS under the (more easily-understood) label of 'Expiration Date/Time'.

At present, this ability is only available for messages being submitted through SMS Online's Web-to-SMS facility, but will also become available in SMS API v2.1 which is soon to be released.

The Knowledge Base has been expanded to include a section dedicated to the Expiration Date/Time and any questions should be directed through our Contact Centre.

We would like to inform customers that there will be 84 adjustments taking place to the rate of message delivery on 1st June 2006. Whilst we are happy to announce that 44 relate to a decrease in price, we are regretful to state that the remaining 40 relate to an increase.

As the majority of price increases will be taking place on the Global I messaging route, we would like to console customers who terminate messages to these Global I destinations that many of them have now become available via Global II at the same (or lower) rate at which they currently exist.

We would also like customers to know that, except for 3 increases which took place in January, these are the first increases to take place in three years and we hope that future changes will relate to decreases only.

Changes to Global II

Changes to Global I

As of today, the following destinations have been added to our Global II messaging route:

Furthermore, the following destinations have been added to our First Class messaging route:

We would like to notify all of our customers that, as of June 1st 2006, the following countries will no longer be available on the Global II route:

• French Guiana
• Reunion
• Barbados

Furthermore, the following destinations will no longer be available on the Global I route:

• Macao
• Saudi Arabia
• Croatia

Customers should note that this does not mean that these countries can no longer be reached, for they have also been included within today's newly added destinations on their alternative routes. For example, although Reunion will no longer be reachable via Global II, it has now become available via Global I.

Customers who terminate messages in these countries should acknowledge the changes in their applications and day-to-day messaging before 1st June 2006 to prevent messages from being neglected.

Due to the increasingly fraudulent use of PayPal's payment solution, two changes have been made which relate to the way in which we accept payments made via PayPal. Whilst these measures will not cause any harm to legitimate PayPal users, they will prevent fraudsters from abusing credit cards and PayPal accounts which do not belong to them.

The first is that we are no longer accepting payments from non-Verified PayPal members. Being Verified means that the account holder has confirmed his/her identity with PayPal by following simple steps such as confirming your bank account or posession of a credit card.

The second is that PayPal payments must now be 'authorised' by PayPal members themselves through an authorisation code which is sent to them via email following the 'completion' of a payment.

Non-Verified PayPal members who enjoy the speed and ease with which PayPal payments can be used are kindly requested to visit the PayPal website (www.paypal.com) and have themselves 'verified' as soon as possible. Furthermore, a dedicated section relating to PayPal has been added to the Knowledge Base and taking a few moments to read the following external sources may also be useful:

• Protect Yourself from Fraudulent Emails (PayPal website)
• Phising (Wikipedia - the free encyclopaedia)

We apologise to customers attempting to make a payment via PayPal today; the PayPal option was temporarily disabled whilst these developments were taking place.

In preparation for new developments that are about to take place, specifically our new connections with US carriers, the MinBal Notifier has received a few modifications.

The most obvious change is that the MinBal Notifier has been renamed as LowBal Notifier as 'low' is a more suitable/representative word than the word 'minimum' (which suggests the lower end of a scale which cannot be passed).

Also, a few cosmetic changes have been made to its settings page in SMS Online and the LowBal Notifer for existing accounts now has the heading "GBP LowBal Notifier". This is in preparation for a new type of balance for message credits purchased in US Dollars and more information will be provided about this when the new balance goes live.

Lastly, its dedicated section within the Knowledge Base has also been changed to take these new developments into consideration.

To simplify the development of dynamic two-way applications, the SMS Auto-Responder can now be used to return content generated from a remote web-server.

Prior to this addition, the essence of interactive applications has been restricted to the combination of API-Client and Client-API interactions. And, whilst we still recommend experienced developers to continue that way, this new approach simplifies the whole structure of two-way applications greatly.

Non-experienced developers can now have interactive two-way applications set up within minutes as all that is now required is to process an HTTP request and print the dynamic content to screen.

As a simple example, the message body "London Weather" would be passed over using HTTP Post (e.g. "msg=London+Weather"). The application would then, through its own means, print the dynamic content to screen (i.e. London's weather), e.g. "As usual, the weather in London is cold and rainy! Thanks for your message."

Our messaging platform will then retrieve the content printed to screen and send it back to the original sender using the least expensive route.

Please note that, although this method of developing interactive applications is very fast and easy, we still recommend experience developers to develop according to the SMS API, combining API-Client and Client-API interactions (i.e. receive an MO SMS, buffer it, query the most suitable route for the response and then respond to it).

A tutorial 'How to activate/configure an SMS Responder using content from a URL' has also been added to the Knowledge Base for those that wish to use this feature.

Customers in the Middle East will be happy to know that network coverage for Saudi Arabia has been improved so that both of its network operators, Saudi Telecom Company (AL JAWAL) and Etihad Etisalat Company (Mobily), are within our reach.

This improved coverage, which takes immediate effect, is on the Business Class route and the standard delivery rate for MT SMS terminating in Saudi Arabia is 3.3 credits/sms.

We would also like to take this opportunity to announce that the Global I coverage of Saudi Arabia is due to end by June 1st 2006. We have only ever termianted a hand-full of MT SMS in Saudi Arabia through the Global I route, most likely due to the incomplete coverage which was offered for it.

Please visit our main site for more information on the network coverage and pricing for Saudi Arabia.

For all of our automated message-sending processes, we have introduced a new process which chooses the most suitable messaging route:

• MinBal Notifications
  As 'tm4b.com' is used as the originator of SMS MinBal Notifications, routing preference is given to Business Class as it is less expensive.
• SMS Forwarding
  To preserve the originator of MO SMS as far as possible, routing preference is given to Global I.
• SMS Responses
  If the specified is static, routing preference is given to Global II as it less expensive. Otherwise, to preserve the originator as far as possible, routing preference is given to Global I.

In addition to minimising the cost of messaging, this new process simplifies the configuration of these applications as the messaging route no longer needs to be considered. Furthermore, in the case of SMS Responses, the previous rigidity of selecting one route restricted the potential network coverage to that route only; with this new process, the combined network coverage of both routes have been made available.

Whilst the TM4B HelpDesk has been running silently for the benefit of a few Beta testers, the 'Help' icon that can now be seen throughout SMS Online indicates that the HelpDesk has become publicly available and that the out-dated 'Online Help' is no more.

This icon, which can now be seen on almost every page of SMS Online, is used in fact a link to provide relevant help about the page on which it is located. So clicking on it will open up a new browser window and take you to the relevant section within the Knowledge Base.

For those that are new to the HelpDesk, its purpose is to centralise customer support for two soon-to-be-launched services (Text-Messaging 4 Me and 70589.INFO), but more importantly to improve the customer care for users at the TM4B Bulk SMS Gateway.

The HelpDesk is still in Beta which means that it is not perfect! However, we feel that it is ready to be made publicly available and we appreciate the customer feedback which will help us to perfect it and we look forward to improving it in every way possible.

Good news for our existing and future customers is that we are in the process of launching a new type of account dedicated for the USA.

Admittedly, whilst our current cost of delivery to the USA is very low, our existing network coverage does not include two of the USA's largest network carriers. While this may not be an issue for some customers, it is for most.

The reason why these carriers could not be included is due to incompatibility issues resulting from their use of CDMA & TDMA as opposed to GSM (which is what we use). However, we are now establishing direct connections to the US through which we will overcome this barrier.

These new connections will enable to us to provide full coverage of all the Tier 1 carriers, which we will present as a new type of account. With the new account, sales will be made in US Dollars and, most excitingly, we will be providing two-way SMS through US-based short codes.

We are just waiting on one or two network connections to be finalised and for our main website (www.tm4b.com) to be modified and then the new account will be publicised.

Following the recent upgrade of our database server, unexpected difficulties were encountered whilst restoring Contact Lists and temporary upload data in which field names contained non-alphabetic characters.

We have therefore added an additional validation rule to the definition of field names which prohibits non-alphabetic characters from being used.

We kindly ask customers to rename the fields of their Contact Lists before the end of June 2006.

We do apologise for the short notice, but this upgrade was not due to take place for a few weeks. It has been brought forward out of necessity to maintain the integrity of our data and has been allocated the least busy time.

SMS Dialogue is a tool through which you can monitor communications with your contacts on an individual basis. It combines all of a contact's MO & MT SMS in chronological order along with any information that might be saved about him/her in your Contact Lists.

Following the decision to charge additional fees for the use of our value-added Extensions, SMS Dialogue has undergone a thorough revision:

• It now has a 'full-screen' option which removes the left-hand menu and makes more space for the actual dialogue.
• A lot of information which 'clogged' up the dialogue has been removed and it has been made more cosmetically attractive.
• It now includes the country of the contact, even if he/she has not been saved in a Contact List.
• Clicking on the status of the message now leads to the full overview of the message. If the SMS was an MT, the overview would be a Broadcast Analysis and, if the SMS was an MO, the overview would be the View Message aspect of the inbox.

As the online delivery reports page can be used to show all of a single account's delivery reports on-screen, searches can sometimes return 10's and 100's of thousands of delivery reports in one go and presenting these on a single page can obviously take a lot of time.

We have therefore added on-screen pagination for results that exceed 500 in quantity. This means that only 500 delivery reports are shown per page and clickable links pointing to each set of 500 are presented at both the top and bottom of the screen.

It is also worth mentioning that the best way of viewing large quantities of delivery reports is to download them in CSV format and view them offline on your desktop.

Whilst we have no control over the time it takes to transfer data from a client to our server, we have been able to reduce the time needed to analyse data and add it to the relevant database.

We've also improved the way in which upload errors are reported. Previously, error codes would be given and errors would have to be 'dug' out using validation rules as a guideline.

But now, this responsibility has been taken on by the new uploading mechanism which presents errors in plain English along with references as to where they exist. For example:

• This file appears to be empty.
• This file has xxx lines too many.
• The field name xxx contains non-alphabetic characters.
• The field name xxx is longer than 50 characters.
• etc.

Although these improvements have been made, clients should still do their best to ensure their data is valid beforehand to save time and frustration, for which information can be found in the File Upload section of the Knowledge Base.

In most (if not all) cases, traditional address books restrict users to pre-determined fields like gender and age. However, the requirements of each of our clients differs greatly and, for this reason, we provide our users with the unique ability of defining the structure of their own Contact Lists.

As a part of continuous improvement, we have made a few developments which make the use of Contact Lists faster and easier.

• Previously, users attempting to delete a field name or a delete a contact would be taken onto another page that summarised what was to be deleted along with an "Are you sure?" confirmation message. The confirmation message now shows immediately, without the need to load up an additional page, thereby requiring less time.
• The way in which structures are modified has also been simplified. Each of the different ways in which a structure can be modified (i.e. to rename, add or delete a field) has been separated from the other completely. This should avoid any potential confusion which existed when they were integrated with each other.

We are always keen to hear any suggestions on how improvements can be made. If you have any, then please let us know.

As each of our Extensions is quite unique, the only real way to appreciate their value is to actually try them out one-by-one. For this reason, new users are given a trial period in which access to all of the Extensions is free of charge, during which 'LIMITED' is shown as the status besides each extension.

Previously, a customer would be considered as an 'old' customer according to how many MT SMS messages were sent and would no longer have free access to the Extensions at that point. However, we found that one broadcast could easily prevent a customer from ever knowing how useful each extension was and so the way in which customers are considered to be old or new is now determined by date.

The free trial period now lasts 28 days from the date of registration and does not take message-sending into consideration. Furthermore, 'old' customers who missed the chance to trial any of the extensions can request additional trial periods by submitting a support ticket.

Whilst many of our clients use the Email-to-SMS service to send MT SMS programmatically, it is actually intended for large organisations that want to provide their staff with the simplest possible means of communicating via SMS.

Previously, multiple recipients had to be separated using the pipe character (i.e. ' | '). For example:

To - 4479562182|4479562123|15043265896|3321235564987

However, the pipe character appears to be considered as 'strange' by many people because it is not commonly used day-to-day life.

So, as part of a few changes intended to make the Email-to-SMS service as simple as possible, recipient numbers can now be separated through the use a of commas (i.e. ' , ') as well. For example:

To - 4479562182,4479562123,15043265896,3321235564987

More can be learned about Email-to-SMS by visiting its dedicated category within the Knowledge Base.

Until now, the "Tools" section of SMS Online has been used to contain several value-added applications. However, whilst we have been providing these applications at no extra cost, they have played their part in taxing our resources (e.g. development, support, maintenance, database etc.).

So, in order to maintain, improve and increase such value-added applications, we have been faced with two options:

1. Increase the cost of messaging to cover the cost of these applications.
2. Separate the cost of these applications from the cost of messaging.

In favour of our low-cost messaging policy and to account for customers that do not use these applications, we have decided to discontinue the "Tools" section and create, in its place, a paid-for section called Extensions.

However, in order to continue providing delivery reports free-of-charge, the 'Message Tracking' tool has been converted into a section called 'Delivery Reports' and moved over the 'Send & Receive' section.

Similarly, the 'MinBal' notifier has been moved over to the 'Settings' section so that customers can continue to receive low balance notifications at no extra cost.

In addition to the recent restructuring of 'Tools' into 'Extensions', the old Message Tracking tool has been replaced by a new section entitled 'Delivery Reports'.

More significantly, however, the ability to download delivery reports in CSV format has been added free-of-charge.

Although the Broadcast Analysis extension provides in-depth analyses of message broadcasts in real-time, the 'download as a CSV' option now makes it possible to conduct analyses offline using spreadsheet software.

Visit the Knowledge Base to read the tutorial that explains how to download delivery reports in CSV format.

As mentioned in the post mentioning the discontinuation of 'Tools' we have launched a new section within SMS Online called 'Extensions'.

Through this new section, we aim to provide customers with value added applications that will enhance their use of SMS and to lease them for an annual fee of £29.95 each.

Extensions which are immediately available are SMS Dialogue, Broadcast Analysis and Duplicate Finder. Furthermore, extensions within our development pipeline include SMS Voting and SMS Optin.

Furthermore, the KnowledeBase now includes a section devoted to Extensions.

Following the provision of an extra 10 days, SMS API v1.0 has been discontinued and, from now on, all requests for SMS API v1.0 will be return a message explaining that it has been taken offline and that it has been replaced by v2.0.

As of SMS API v2.0, upgrades will only require slight modifications to requests made and, other than these, customers can continue to use older versions without upgrading.

Until now, our MSISDN validation process has taken into account:

• non-numeric characters
• leading 0's
• country codes

However, new validation rules have now been added that also take the length of a recipient's MSISDN into account.

From now on, if a recipient's MSISDN is less than 8 or more than 20 digits long, its associated message will be 'neglected'. This means that, instead of being processed at cost, the message will be given a NEGLCTD status and users will not be charged for the message.

These validation rules have put in place following recent clarification from upstream suppliers that we are not charged for such messages and that they simply 'fail' them at no cost. As such, we have updated the delivery state of all such messages within our database to reflect this and have issued credit refunds to those customers who submitted such messages in the past.

Details of such credit refunds, if applicable, can be viewed by visiting the "Sales" section of SMS Online.

These changes effect Mobile Terminated SMS being sent via Global I, as follows:

Although we have provided sufficient forewarning and several reminders that SMS API v1.0 was to be discontinued today, our log files show that several applications are still using v1.0 for connectivity.

So, to avoid 'breaking' our customers' applications, the discontinuation date has been pushed forward to January 10, 2006.

Furthermore, SMS API v1.0 has been modified to send out an automated email to the account holder each time a request is made through it - whilst this may cause annoyance, it is to encourage the immediate upgrading to SMS API v2.0.

If you have not already upgraded to SMS API v2.0, please do so immediately.