Group Design Project – B202

Product design report

Introduction

Our service acts as a middleman between a venue selling tickets for an event (gig, show, exhibition etc.) and the customer. The customer only has to send a text to us (in a specific format) and they will receive, very quickly (within 5 minutes) a text back. This text has a unique code contained within it which acts as a 'virtual ticket' for that event. The text is simply shown on the door, like a paper ticket and entry to the event is gained.

In order that the code cannot be randomly made up by an unscrupulous customer and shown to try and gain entry, safeguards will be put in place. Firstly the code sent to the customer will be a hash code generated from a unique venue and event ID (chosen by the venue selling the tickets for the event) and a pseudorandom code.

In order to check this code and make sure a code is not used more than once (such as shared between a group of friends) the code will be checked on the door to the venue. The venue will check the code against a database of valid codes issued for that event to make sure it is valid and has not been used before. If these checks fail, the customer can be denied entry to the event.

The check against the database will be carried out through a web interface to our central server, maintained by us. This web interface must have the ability to be used universally by devices, so the venue can choose to use a computer, a PDA, a smart phone etc. (basically any device capable of browsing the web) to check the ticket's validity. This check will be carried out instantly.

This web interface will also be used by the venues to upload the details of events for which they want us to make tickets available. We only act as a middleman to facilitate the selling of the 'virtual tickets'.

The cost to use this service will be free to the venue (in order to get them 'on side' and get venues to join our scheme) but will cost the customer approximately 50 pence (plus the cost of a standard text) to send us the initial text requesting a ticket. This will be taken directly from the customer’s phone credit.
The cost of the ticket will be the same as if they bought it through other means (such as direct from the venue). This should encourage customers to use our service as they are not paying more for the ticket than they would normally and are getting a much higher level of convenience (what could be easier than sending a text?). The 50 pence is a small charge and is transparent to the user, which will cover our running costs and make us our profit.

If the system is successful and venues like our system and would be willing to pay for it, in the future we could start charging the venues a small fee for tickets sold through our service.

The customer will be charged directly to their credit/debit card upon purchasing the ticket. This means they will have to register with us initially to use the service, so that their card details are available to us. Their phone number will be used as a unique identifier which will be tied into their account details.

The other option we had of charging the customer was taking the money directly from their phone credit. However, charging to card alleviates the problem of a customer wishing to buy an expensive ticket for which they do not have enough credit.

Requirements

Requirements pertaining to the performance, functionality and security of the service, from a user’s (either a venue or a customer) perspective:

• 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.
•Ticket should be processed and verified by our system in less than a minute at the venue, in order to obtain speedy entry to the venue.
• All of the tickets (100%) that we send out must be guaranteed to be delivered to the customer’s phone. For example, messages cannot be dropped in times of high network load or when the customer’s phone is switched off or has no signal In these cases, messages 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. The service should send out messages that meet to the standards of the protocol. For example, all text messages sent by our system must be less that 160 characters in length and 140 bytes in size.
•The telephone number used to request a ticker should be no more than 5 digits in length, to make it easy and effortless for the user to remember the number.
• Customer's personal and billing details must be protected in accordance with the requirements of the Data Protection Act 1998. They must be stored securely and protected in transit from their browser to our server when signing up using the web interface.
• Venues must be able to add and edit 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 and edit details on the events, such as ticket price, date, venue and location (town/city) onto our system. These additions and changes should be available to the customer within 15 seconds of submission.
• Venues must be able to use our system to check the authenticity of a ticket presented to them by a customer.

Requirements pertaining to the performance and functionality of the core of our service, this refers to our system (including the database and the various software to interface with this database) and not any third party systems such as SMS gateway providers or credit card processing vendors:



• The system must be able to process a minimum of 1000 requests per minute coming in to our system from our SMS gateway provider. This is to ensure that the response time stays within the five minute bracket even when the system is under a high amount of load.
• The system’s database 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.
• The system must be able to send and receive SOAP communications in the format needed and provided by our SMS gateway provider.
• The system must be able to send and receive HTTPS communications in the format needed and provided by our credit card billing vendor.
• The system must be able to generate a unique code for each ticket sent. These tickets must also be in a specific format for security reasons (to stop them being easily faked).
• The system must be able to mark a ticket as used once it has been used to gain access to an event, in order to prevent fraudulent use of our service (such as one ticket code being shared between a group of people).
• 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 system must be able store the following data about the venues and events: Venue ID, Venue Location, Event ID, Event Time, Event Date.
• The system must be able to store the following customer data: Customer ID, Phone Number, Name, Billing Address.

Use-case Scenarios

Somebody who does not have the time to purchase tickets by the traditional means:

A student is walking in to lectures at university. On his journey, he passes a popular live music venue and notices on a poster that a band he is a fan is of is playing there tonight. He wishes to attend this gig, but he does not have the time to buy a ticket now.

However, he does not have time to buy a ticket later and does not want to risk queuing for a ticket on the door in case they sell out before he arrives. In this case, he simply texts the event and venue details (which are given on the poster), to our service and he quickly receives a ticket for the event. He does not have to worry about being late for his lectures or possibly missing the event.

Somebody who needs a last minute ticket in a hurry:

A young person is on a night out and is drinking in a local bar. Initially he and his friends are undecided about what their plans for that night are. However, they then bump into another group of friends who mention that a popular DJ is playing at a nearby club and that they have tickets to go later that night. Not wanting to be left out, but not wanting to pay extra for buying a ticket on the door (that is if there are even tickets left by the time they get to the club) our customer and his friends wish to acquire a last minute ticket for the event.

They simply text the event details to our service and receive a ticket for the club event within five minutes.

Somebody who has forgotten their ticket for an event:

A person has travelled into the West End of London to see a show at a theatre. They bought their ticket in advance, and have been looking forward to seeing the show. However, when they arrive at the theatre, they realise they have forgotten their ticket!

Disappointed and angry, they either have to go back home to collect the ticket (several hours journey away, so they will miss the show) or attempt to purchase another ticket (which means paying again and the ticket office may even have sold out).

If they had bought their ticket using our service, they would simply need to scroll through their text messages on their mobile phone (which they never forget as they take it everywhere with them) to retrieve the ticket to the show.

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 and 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.

User Surveys

We carried out a user survey to determine whether there would be customers willing to use this service, and if there was, what the target demographic for this product would be. We also wanted to find out whether the pricing we set for our product was acceptable to our target audience. For this purpose we surveyed twenty people, eighteen of whom were students falling under the age group of ’18 - 25’ and the remaining two were under the age group of ‘30+’. A copy of the survey, in Word .doc format is attached.



The way we designed our survey was to first find out how often our audience used SMS. The more frequently they used SMS the more likely they would be to use our service. It was interesting to see that 85% of students used SMS very frequently compared to only 50% people over the age of 30. This gives us a distinct idea of the audience that we need to target.



Now that we have a clear idea of our target audience it is important for us to know what type of event our customers attend the most frequently. This will give us an idea of what venues we need to target in trying getting them to use our service.



From this result we see that clubs are very popular among our target audience with more than 55 % people going clubbing on a weekly basis. Since we will only be targeting special events at clubs, we should not ignore cinema goers as a potential market. Special events at clubs do not happen frequently whereas there are films showing at cinemas very frequently.
The final part of the survey was to find how many people would be willing to use our service and at what price.
Out of the eighteen people under the age group ’18 - 25’, seventeen of them said they would use our service. This is a very positive response indicating the potential demand for our service.

The majority (53%) of our potential customers surveyed think that £0.50 would be a reasonable charge for the convenience offered by this service. A smaller amount of people (23.5%) would pay £0.25 while on the other hand the same amount of people would be willing to pay £1. This ties in with our initial thoughts about the pricing of our service.



From our survey we have found that there is a large potential user base for our service, mostly students between the ages of ’18 - 25’. This constitutes our key demographic. We can conclude from the results of our survey that £0.50 would be a reasonable amount to charge for our service. In light of the above two factors we believe that the service is financially viable and marketable.

Prototyping

For our prototyping we decided to write out key sections of our core program in C# to give an overview of how it would function. Example database queries, written in SQL, are used to show what is being read from and written to the database in each step.

The first step in the program is to access the text messages we have received from our customers. To do this our program will need to copy over the text messages from our SMS gateway provider, TextAnywhere.

This is achieved using one of TextAnywhere's provided functions:

The next step is to turn the received SMS messages into something our program can process. The text messages from TextAnywhere are received as one long string. Each text in this string is delimited through the use of a carriage-return line-feed (CRLF) pair. So firstly, we must separate the individual text messages.

Each text contains various fields. The two we are interested in are the sender's telephone number and the actual body of the text. The fields are separated by commas. The sender's telephone number is used to match the ticket request to a existing customer's account, which uses the customer's telephone number as a unique key to identify the individual customer. The body of the text is important because it contains all the details we need to book a ticket for the customer. So firstly we must extract the various fields and get the data from the two fields mentioned above. Next , we must extract the various parts of the text message which make up the ticket request from the message body.

This function takes the provided String from the API GetTextInbound() function and first splits it by the newline character. It then loops through all the individual text messages and splits the fields by comma to get the individual fields in each text. It then gets each element in the text message body string to extract the data we need to query the databases.

These are then used to query the database for a matching event.:

This is a class with a function that connects to the MySQL database and queries the database using the query supplied as an argument to the function. It then returns the result as an array of strings, one string for each row in the result.

Also shown is the function in the class which inserts data into the database, with the insertion query string given as an argument to the InsertData() function

We then need to generate the ticket code. We must use a function to randomly generate the two random two character strings. The rest of the ticket code is made up from the unique order ID of the ticket plus the event ID. These are extracted from the Orders and Events database respectively.

The first of these functions generates a string of random A-Z characters. The length of the string that is output is given as a integer argument to the function. The function works by converting a randomly generated integer into a character by the character's ASCII code.

The second of these functions builds the ticket code string, by calling the RandomString() function to get the random A-Z portions of the code and using the order ID and the Event ID for the other two parts of the ticket code. Once the code is built, it is inserted into the database using the SQL query shown.

We then need to save the newly generated ticket to the Tickets database, in order that it can be checked at the venue. This is shown above as the SQL query given to the InsertData() function as an argument, but is repeated here for clarity:

Finally, the generated ticket must also be sent to the customer's phone. This is done using a method from TextAnywhere's API:

The 'body' parameter would be the generated ticket code, supplied as an argument to this method.

Attachment	Timestamp	Size
survey.doc	2009-05-29 20:16	45.5 KB