Product design video presentation

Attachment

Timestamp

Size

Requirements

User Requirements

• The time to respond with a ‘virtual ticket’ to an initial text requesting a ticket should be less than five minutes. This means that the ticket should be delivered to the customer’s phone within this time. All database querying, credit card transactions and sending out of the ticket by our system should be done in this time in order for the ticket to reach the customer within five minutes. To meet this requirement, we need to use a service offered by the mobile telephone operators that give our messages priority in times of high load upon the mobile telephone network.
•Ticket should be processed in less than a minute at the venue
One of the main selling points of our system is the speed in which entry to a venue can be obtained. The processing of the ticket at the venue is crucial to this. The tickets we will be providing through our service are in digital form as opposed to the conventional paper form. This raises the problem of having to verify the ticket through interaction with our system, which could potentially add a significant delay to being granted entry to the venue. We must therefore aim to reduce this time which is why we have set this requirement.
• All of the tickets (100%) that we send out must be guaranteed to be delivered to the customer’s phone, as it is a product that they have paid for. In order to do this, we need to look into solutions provided by the mobile telephone operators that offer guaranteed delivery of the text message. Messages cannot be dropped in times of high network load or when the customer’s phone is switched off or has no signal, so the message must be stored for retransmission later.
• The service must be able to be used by all mobile phones that support sending and receiving SMS messages. Therefore the service must fully comply with the SMS protocol. This means it should be able to receive, and more importantly send, texts that comply with this protocol. This puts certain restraints upon our service. For example, all ‘virtual tickets’ (text messages) sent by us must be less that 160 characters in length and 140 bytes in size.
•The text number should be no more than 5 digits
Usability is a key factor in any service. It has to be as easy and effortless as possible to use our service otherwise users would have no justification for using it. An SMS short code would be ideal for our service as these are just five digits long. This length helps the user remember the number thus easing the effort required to use the service.

System requirements

• The system must be able to process a minimum of 1000 requests per minute. This is to ensure that the response time stays within the 5 minute bracket even when the system is under a high amount of load.
• The system must be able to hold a minimum of 10,000 events for each day without crashing or slowing down. This requirement is important for the expansion of the system in the long term, so any database software used must be able to cope with these demands.

Security requirements

I will now talk about 3 major security requirements
Our first security requirement is that we need to ensure that the tickets can only be used once to eliminate fraudulent use of our service. An example would be a group of people all trying to use the same tickets to get entry into the venue. Venues must be able to mark ticket as used on our system to avoid this situation.
• Customer's personal and billing details must be protected in accordance with the requirements of the Data Protection Act 1998.
• Customer's personal and billing details must be protected in transit from their browser to our server when signing up using the web interface.

Venue requirements

• The most important is that Venues must be able to add events to the system in order that our service can make tickets to these events available to the customer. The venue must be able to add details on the events, such as ticket price, date, venue and location (town/city) onto the database stored on our system.

• Venues must be able to remove or edit events that they have previously added onto the system, if the event has been cancelled or details such as date and ticket price have changed.

• Our third venue requirement is that our database should be updated within 15 seconds of the venue submitting details of the events. Because the venue will need to constantly add events to our database, we will provide them with a user friendly web interface to update their own events. These events will be published on the database and will be available to users within 15 seconds of the system updating itself. This keeps users updated about live events as soon as it is available.

• Venues must be able to check the authenticity of a ticket presented to them by a customer. In order to do this they must be able to verify the ticket against our system.

Miscellaneous

•The system should receive delivery status within a minute of the user receiving the ticket.
It is important that we have confirmation that the customer has received the e-ticket from us as proof for future reference. We will implement this on our system to make it work exactly like mobile phone delivery reports. This works by first sending the e-ticket to the user and as soon as the user receives the ticket on their phone, we will instantly get a delivery message status. We aim to receive this delivery information in under a minute. If the mobile phone is turned off we will not receive a confirmation until the device is turned on.
• The system must be able to store and process a variety of different data types, such as alphanumeric text strings, integers, floating point numbers and hash encrypted data.
•The whole system should be automatic
For our service to be successful the speed at which a ticket is delivered must be kept to a minimum. To reduce delays the human intervention in the ticket processing including the booking, sending and verification of the ticket must be kept to a minimum. Another benefit of this is reduced costs; less staff assisting in this process means that there is less cost in maintaining the system. Our requirement therefore is that at no stage during the ticket processing must there be any human intervention; the booking, sending and verification of the ticket should be completed entirely by the computer system.

Specifications:

In order of importance:

1. The most important aspect of our service is the database management system (DBMS) which will store all the data essential for the service to function properly. The database system will be responsible for storing all of the information that makes the service work – the customer billing details, the events that are available to purchase tickets for, and the tickets issued for these events. Because of the massive amount of data the DBMS will have to hold, and the high performance requirements specified in the service requirements, a powerful and scalable DBMS will have to be used. We have chosen to use MySQL for this purpose. It is extremely powerful, with performance only limited by the hardware it is running on. The size of the database that it can handle is also only limited by the physical constraints of the system as well as the maximum file size of the Operating System (OS) it is running on. With the correct OS, database sizes of over one petabyte (1000 terabytes) are possible. The choice of MySQL as a good choice for high-volume, performance critical applications is evidenced by its use in many e-commerce applications, and large websites such as Facebook and Youtube.

2. The second most important aspect of the system is the technology which will allow our custom-made software to interface with the mobile telephone network, in order that our system and send and receive SMS messages. We will use a third-party provider for this. The third-party will deal with receiving and sending the texts by interfacing with the mobile-phone network, freeing us from worrying about the hardware. We will use TextAnywhere as it has a very good administrative panel to help manage and setup the service. It features a Simple Object Access Protocol API to communicate with our software. The APIs are provided by the company and are very easy to implement. They also provide short numbers, which refers to short 5 digit numbers as opposed to the a full 10 digit phone number.

3. The third most important aspect is charging the customer's credit or debit card. We have chosen to use Sage Pay as they deal with all the sensitive payment details so we don't have to worry about security. Upon customer registration all credit card details are sent to the provider and from thereon we do not have direct access to them. SSL is required for this service and the payment requests are made via HTTPS.

4. The fourth most important aspect of our system will be the the encryption and security used to protect customer's personal information (such as names and phone numbers) to meet our requirements under DPA 1998. To do this we will use the built in MySQL functions DES_ENCRYPT and DES_DECRYPT. This is secure because it must be used in conjunction with a SSL certificate, which is unique to us and independently verified.

5. The fifth most important aspect of the system is protecting our user's data in transit. HTTPS protocol will be used to protect the customer's sensitive personal and billing information in transit from their browser to our web server when signing up to our service. HTTPS combines the usual functions of HTTP and also provides secure public key cryptography using TLS to protect the data in transit.

6. The sixth most important aspect of the system is the scripting or programming language that will allow a web-based interface to dynamically access the DBMS in order to read a write data to it. We have chosen PHP for its well-documented, native support for accessing MySQL databases.

7. The seventh most important factor is that it must produce secure ticket numbers which cannot be faked by using false, randomly generated numbers and letters. For this a specific format will be used. This format is [2 x Random A-Z] [OrderID] [EventID] [2 x Random A-Z], where the random A-Z section is two randomly generated letters. Each letter will be generated randomly from a different seed, for increased randomness. The order ID is the unique order ID of ticket buying transaction, and the event ID is the unique ID of the event the ticket is for. To keep the generated code short enough to quickly check on the door we will truncate both the orderid and eventid to the last 4 digits. Excluding the randomly generated letters this would leave 9999 unique codes per event. In the unlikely event that ten thousand tickets are sold codes will be checked to ensure they do not match up to a previously generated code. Originally we thought about using MD5 encryption generated from the customer and event details, but the string generated is far too long and complex at 128 bits and will make checking a long , cumbersome process. This would be impractical for real would use, although very secure. Although there is no real hashing going on the code will still be unique and people will not be able to generate their own codes.

8. The eighth most important specification of the system is the hardware specifications that will run all the various software and the DBMS at a rate of performance which meets those set out in the requirements. We have decided that a medium-specification server would adequate for this task, as the software and the database have low system overheads. We do however need to ensure system is still responsive under load. A system with 2 x 2.4 GHZ Intel Core 2 Duo, 2 GB RAM and 2 x 250 GB SATA Hard Disks would be good enough for our purposes. If the system reaches a point where it cannot accept any incoming requests, they will queued in a FIFO manner.

9. The ninth most important aspect is the language to write our custom software which will run the system. This is C#. It is very fast to develop in and has a lot of support from the SMS API providers to help integrate it into our program, such as pre-written code samples that interface with their API.

Business Opportunity Analysis:

We have analysed how we think our product will fare in the market. We have based this analysis on three factors. The first of which is

The success of current services which are similar to ours

We have analysed the following three services:
Mobile wallet
Argos product reservation
Orange Wednesdays

The mobile wallet service allows users to pay for items by simply swiping their phones over an RF reader. As with our service, mobile wallet charges the user’s credit card for these transactions. The convenience and simplicity of this is what we are aiming to achieve.
In Japan mobile wallet has been a huge success with several providers offering many variations on what it can be used for. This includes everything from buying tickets for an airplane to an event in a local pub. New trials of the technology are going ahead in the US and France which are being backed by major credit card provider MasterCard. They are also considering expanding these trials to the UK.
The Argos product reservation service allows customers to reserve products and check price and availability. It was released in December 2002 with Argos claiming it was a ‘hit’. Over the Christmas period 46 000 texts were sent to the service. This shows us the popularity of convenient SMS based services over conventional methods.
Orange Wednesdays allows a user to buy two tickets for the price of one. A text containing the keyword ‘FILM’ is sent to a premium SMS number. Orange sends back a reply with a special code which is then shown at the ticket collection office for this offer to work. This service does not really involve any financial transaction between the user and Orange except for the initial charge of the text. Thus Orange acts as a mediator between the customer and the venue much like our service. This shows us that the customer does not mind paying extra for their convenience.
The usage of mobile phones within our target demographic
The use of mobile phones has grown widely over the last decade. 90% of people between the age group 15-34 use mobile phones currently on a regular basis. More than 6.5 billion text messages are sent every month in the UK alone. With network providers offering unlimited text plans SMS has now become a standard for mobile communication
The charges and costs relating to premium SMS

The second factor is The charges and costs relating to premium SMS

The delivery of SMS to a customer’s mobile phone is the backbone of our service. We have to reliably send text messages to customer’s mobile phones at any given time of the day. This cannot be accomplished by a regular SMS service, hence the need for a premium SMS service. Premium SMS offers guaranteed delivery to customer’s mobile phones along with a message delivery status informing us of the exact time the message was received by the customer. Premium SMS also gives us the flexibility to use short codes (which is 4 to 5 digit numbers). This makes it easier to remember than a standard 11 digit mobile phone number.
Premium SMS makes it possible for us to reverse charge the customer 50 pence. This is where we will be making our profit. We will need to setup a dedicated SMS server costing us 795 pounds rental charge per month. Once setup, it will cost us 4.3 pence per text to send to a customer.

The third factor is Mobile Phone Usage

The mobile phone is a core component of our system. A user must have this in order to be able to interface with our service and buy tickets. For this reason we have analysed the trends in mobile phone usage to justify having the mobile phone as such an integral part of our system.
Our analysis points towards an increase in all aspects of mobile phone messaging. This includes SMS, image and video messaging. In 2008 SMS messaging continued to grow with 6.5 billion messages sent across the UK each month. In addition to this browsing the internet through a mobile phone has also increased with iPhone users responsible for 1 in 1000 web pages viewed.
Adding new functionality to mobile phones has become easier for users and increasingly popular. The iPhone’s AppStore is a good example of this. After being launched in July 2008, over 1 billion applications had been downloaded from the service by April 2009.
These facts suggest that the mobile phone is more and more becoming an essential gadget and that users welcome new functionality.

Link to presentation:

Presentation

We also tried to upload to Mosaic. It uploaded successfully, but we could not find it after this.

An older version with spelling mistakes but the same content is available on YouTube.

Part 1: http://www.youtube.com/watch?v=wmUHDcwuDmA
Part 2: http://www.youtube.com/watch?v=FIagv1a7UXE