CA2463071A1 - Mobile classified ads system and method using short message system (sms) and/or multimedia message system (mms) - Google Patents
Mobile classified ads system and method using short message system (sms) and/or multimedia message system (mms) Download PDFInfo
- Publication number
- CA2463071A1 CA2463071A1 CA 2463071 CA2463071A CA2463071A1 CA 2463071 A1 CA2463071 A1 CA 2463071A1 CA 2463071 CA2463071 CA 2463071 CA 2463071 A CA2463071 A CA 2463071A CA 2463071 A1 CA2463071 A1 CA 2463071A1
- Authority
- CA
- Canada
- Prior art keywords
- ads
- matched
- server
- subscriber
- database file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Landscapes
- Mobile Radio Communication Systems (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The system is composed of any number of mobile subscribers using any type of mobile devices connecting through sms/mms to a central database server setup by any service provider. It uses the most popular mobile messaging application sms/mms for the purpose of classified ads. The system is independent of mobile operators but use the sms/mms services of mobile operators. The system is made up of two components: a client component and a server component. The client component resides in any person's mobile device. It provides user s with data manipulation means and data communication means. The data manipulation means include having all the necessary information built-in the system to provide it with: (a) Means to compose any number and type of new ads/want ads with contact information and optional multimedia show (picture, audio, and/or video) especially mobil e devices with built-in cameras, give each ad/want ad (1) a unique record number automatically generated by the system, (2) a specific transaction code based on user's selected transaction type (ad or want ad), (3) a specific category code based on user 's selected category of ad/want ad, and (4) a specific set of data fields that are specific for every ad transaction and category to be filled by the user, and store all those ads/want ads as arecord set in a database file called the ads database file inside the mobile device's non-volatile memory. (b) Means for browsing the ads database file for viewin g, modifying, or deleting any existing ad from the ads database file of the mobile device's n on- volatile memory. (c) Means for storing the received downloaded matched ads in a database file called the matched ads database file inside the mobile device's non-volatile memory. (d) Means for browsing the matched ads database file for viewing all the stored matched ads, selecting a specific one and calling the contact to discuss the matched ad details, and finally either keeping or deleting the matched ad from the matched ads database file on the mobile device's non-volatile memory. (e) Means for resetting the ads and matched ads database files from the mobile device's non-volatile memory. The data communication means include: (f) Means for uploading or sending any valid outdated ad/want ad using sms/mms from any subscriber's ads database file of his/her mobile device's n on- volatile memory to that subscriber's ads database file on the centralized sms/mms enabled database server. A specific command code is included with the ad record numb er and the ad data in the upload message to identify a new ad from a modified or delete d existing ad. (g) Means for downloading or receiving any number of matched ads, of a specific ad number or for all ads, from any subscriber's matched ads database file on th e centralized database server to that subscriber's matched ads database file on his/her mobile device's non-volatile memory. The server component resides on the centralized database server. It also provides the server with data manipulation means and data communication means. The data manipulation means include: (a) Means for storing, browsing, and maintaining all the new or modified ads/want ads received by the server from all mobile subscribers in the network. The server maintains a separate ads database file for each subscrib er that is an enact copy of his/her mobile device's ads database file when uploaded by tha t subscriber. Each ad/want ad is identified by its ad record number and each subscriber is identified by its mobile phone number, which are two pieces of information included in the received message. (b) Means for searching all subscribers ad records in the centraliz ed database server for matched ads when a new or modified ad/want ad for any subscriber reaches the server. When a new ad/want ad is received the server starts searching for al l matched ads right away. When a modified ad/want ad is received, the server first deletes allthe old matched ads it can find on the server, then starts searching for all newly matched ads it can find. (c) Means for storing all found matched ads for each subscriber in a separate matched ads database file on the server, waiting to be downloaded by that subscriber when he/she wishes to do so. (d) Means for deleting an ad/want ad from the a ds database file of a subscriber, and delete all correspondent matched ads from the matched ads database files, when a deleted ad/want ad command reaches the server from th at subscriber. (e) Means for resetting the ads and matched ads database files o f any subscriber when the specific command from that subscriber reaches the server . (f) Means for automatically cleaning the database server of all invalid, old, and deleted matched ads records. (g) Means for automatically deleting every matched ad record of the server once it is downloaded by the user. (h) Means for automatically compacting all subscribers matched ads database files in the case their number of rec
Description
Description Field of the invention The field of the invention is the combination of two fields: The mobile/cellular networks using sms/mms and The classified ads fields. The classified ads industry is well known in most newspapers and magazines, voice-mail systems and computer-based systems, and recently the Internet. One disadvantage of alI those methods is that the user has to be stationaryand can't be on the move while preparing or searching for an ad.
The newspaper/magazine is still the oldest approach and has many disadvantages. For the person placing a new ad, modifying or deleting an existing ad, he/she has to contact one or multiple newspapers and communicate to them via phone, computer, or in person what he,~she want to do and has to wait the next day's issue for i:he new ad to be placed or for the modifications or deletion of the existing ad to take effect. For the person searching for an ad, he/she has to get many newspapers/magazines, go through pages and pages of classified ads to find what he/she is looking for. If the user did not find anything in the first day, he/she has to get next day's newspapers/magazines and may have to go through all the same set of ads to reach just few new ones since ads are not generally segregated based upon newly placed ones.
[US5283731 ] An attempt has been made to address some of the limitations of newspapers classified ads system through the use of voice-mail systems and computer-based systems using Interactive Voice Response (IVR) and using the Public Switched Telephone Network (PSTN), but all those systems are complex, require the need of a fixed line touch tone telephone, and the user does not get any visual of the ad whether text or image, all the user get is a voice description of the ad. Also, searching for a match is much slower than the proposed system.
[EPl 182893] Another attempt has been made in the mobile industry through the use of mobile terminal-controlled hierarchical information retrieval using sms. This system also has many disadvantages. The first disadvantage is apparent if the number of levels of the hierarchy is high a large number of sms messages get sent back and forth between the subscriber (user) and the network which may increase the user's mobile phone bill as well as the system is inefficient in wasting an entire sms message for only one word selection of a menu or submenu. Most of the mobile applications use this technique where the user engage in an interactive sms session that may last for half an hour or more and each sms transmission present the user with a list of choices to choose from. This type can be beneficial in simple applications like m-voting where the user has to choose from a list of candidate names but would be inefficient and costly in a classified ad system where a certain amount of information need to be transmitted to give the user a clear idea about the item in the ad. Another disadvantage is that this technique does not suggest in any way the transmission of pictures and/or audio/video clips with the sms text which is important in a classified ad system.
The Internet is also a well known and huge media for classified ads but you need first to have an Internet account with an ISP in addition to paying fir the phone bill.
When you place ads on a web site your ads are stored at that web site and not locally in your computer, so you are not in full control and you may not have access to the site all the time because of technical difficulties. Also, when you are searching for a match, you fill a form and the web site presents you with all matched ads which rnay be a large number of ads you have to go through before reaching what you looking for. If you modify your search criteria a little you may get the same set of ads that you have looked at before.
There is no way of excluding the ads that you have looked at before.
Another disadvantage with Internet systems is that there are two steps of communication involved compared with one step of the proposed system. With Internet systems, Stepl The user contact the web server to download the form to be filled. Step2: The user fills the form and sends it to the web server which stores the information in the database file.
With the proposed system, the specific forms are stored on the mobile device's memory . ,. =,..a., , . ... . ekey,Ha7F~ ~.xe.S'. ,v w "~Y9~:..~ r ,zs~.'.r'~"ZP~b ,'~"wfa rdtk C~_nf'~:y .,T,g "frT.9"s'3',~k~' mTfi~i -3.'~sp,Fra," ~ Y. :. ~.
, ~",.~,..~'$A~SFS<S~k2: ~.: a~t'zCtHt~. f~RSCR~;:~M. ~w~asw~:.~.
~.m~.n~axrcmwarxavxaaw".,rw_~.z...mra.~
itself so there is no need to contact the server to download any form. Steel :
The user calls the required form from memory, fills it with the information, and then sends it to the server to be stored in the database file.
Description of the preferred embodiments The worldwide popularity of the mobile devices is driving the rapid explosion of this industry. Today's mobile devices have a lot more features, are faster, have a lot more memory, and have audio/video capabilities. This rapid increase in mobile devices capabilities is allowing for the rapid development of mobile applications, which are becoming very popular as well. One of the most popular mobile applications nowadays is text messaging or short message system or sms for short, arid recently multimedia message system or mms for short. Few years ago this invention would not be possible to be implemented because mobile devices were limited in capabilities, but with the increased capabilities and power of today's mobile devices this invention is very possible to implement.
The system is designed in the English language, but can easily be supported and translated in any other language. Also, the system is designc;d without any security protection against hacking and unauthorized access but security can be implemented on the system once it is online because it is very important to make the system fault tolerant and secure it against external unauthorized attacks.
In this document a mobile device can be any processor based portable device that has mobile/cellular phone card capabilities of any type and inch~de but is not limited to mobile/cellular phones, smart phones, 3'd generation phones, PDAs, and laptops.
In addition, the terms users) and subscribers) are used interchangeably in this document to refer to the same thing which is/are the users) of the mobile devices) who possess/rent any mobile phone numbers) from any mobile operators) and subscribed in any type of mobile services. Also, the terms clients and mobile devices are used interchangeably in this document and an ad will refer to an ad or a want ad.
In the preferred embodiments of this invention the system i;> composed of any number of mobile subscribers using any type of mobile devices and a central database server setup by any service provider. Every mobile device and the central database server are provided with data manipulation means and data communication means as described in the abstract of this document.
The proposed system puts the user in full control of his/her ads and has full access to create any new ads, modify or delete any existing ads anytime and while on the move without the need to go back to any newspaper or magazine. The user is also presented with the option of taking a picture and/or audio/video clip of the presented item especially mobile devices with built-in cameras, and combines it with the text description of the item, which is not available with the hierarchical retrieval system using srns.
[Fig 1 ] shows the flow chart of the main system functions for mobile devices.
It shows the data manipulation functions and data communication functions of the system.
[Fig 2] shows the three main data field types used by the system, how they are stored inside the database file, how they are read from the database file and assembled in a sms/mms message format to be sent, and how they are received in an sms/mms message format and then disassembled to be written in the database :file.
Every category of ads is given two code numbers that are the same on all clients and server, and is divided into many data fields. The first code is the transaction code and identify if it is an ad or a want ad and the second code identify the category itself. The order and type of the data fields is identified by those two ad code numbers.
When creating or composing a new ad, the user will select the transaction type whether it is an ad or a want ad, and select the ad category/subcategory, which will identify those two ad code numbers that will be stored into the first and second fields of the ad record, then the system stores all the data fields based on their types. Every data field type is stored differently in the ads database.
There are three main types of data fields used. Text data fields are used to enter plain text and can be either numerical or alphanumerical. This type of data is stored in the database file as text. Exclusive choice groups are used to choose only one item out of a list of many items presented. This type of data is stored in the database file as short integer that represents the selected choice of the user. Multiple choice groups are used to choose multiple items out of a list of many items presented. This type of data is stored in the database file as a Boolean array where a true value at a specific position in the array represents a box that is checked by the user and a false value at a specific position in that array represents a box that is not checked by the user.
To make the system suitable for sms/mms, the system is designed in a way to minimize the amount of data transferred between clients and the server. To do that, every category's data fields that have a short list of choices to choose from will use choice groups (either exclusive or multiple) and the data fields that have an exhaustive list of choices will use text fields. In this way, for the data fields using choice groups, instead of sending the actual text, the number representing that particular user choices) will be sent instead. By using the same specific lists between clients and server, receiving the numbers(s) representing the choices) will be enough for the receiver to determine the actual choice(s).
Text data fields where the user type text data in, the system is designed to have some sort of provision for typing errors. As we know people will make mistakes in typing or users sometimes spell words differently. The system is able to find matches even with a predictable and acceptable number of typing errors.
Before sending an ad in a sms/mms message between clients and server, the system needs to compose the sms/mms text message out of the ad data stored into the ads database file.
First, the system will read the stored transaction and category codes from the ad record to identify the transaction and category of that ad, which in turn will identify the order and type of all the data fields of that ad that will follow. A special character ExlSep, the transaction code, ExlSep, and the category code, are then translated into text string and are appended into the sms/mms text message (including the transaction and category codes into the sms/mms message will make the receiving party identify the transaction and category of the received ad and predict the order and type of that ad's data fields).
Once the system reads the transaction and category codes it can then predict the order and type of all the data fields. Next, a special character separator is inserted before each data field. Each character separator and its corresponding data field are then translated into text string and are then appended into the sms/mms message. This process continues until all data fields are read from the ads database file. The character separator inserted before each data field type is different for every data field type. Those character separators are used by the receiver to identify the type of data fields and be able to extract the data from the received sms/mms message. Text data fields use a TxtSep character.
Exclusive choice group data fields use ExISep character. Multiple choice group data fields use MulSep character. Those special characters are defined and chosen to be not from the printable characters set so they will not conflict with any user entered text.
In the case of exclusive choice group data field types, the short integer number that is stored in the ads database file is read then translated into a text string representation before getting appended to the sms/mms message. In the case of the multiple choice group data field types, the Boolean array that is stored in the ads database file is read then translated into a text string of 1's and 0's based on the values in the Boolean array before getting appended to the sms/mms message. In the case of text data field types, the data is taken as is, because it is akeady text string, and get appended to the sms/mms message.
By the end the sms/mms message will Iook Like a long text string that include the ExISep character separator, the transaction code, the ExISep, the category code of the ad, a character separator that separates each data field based on its type, and then the data field itself, and so on until a1I data fields of that ad are included. When more than one ad is included into the sms/mms message, a special character separator called the record separator RecSep is included to separate each ad record. At the end the whole sms/mms message is encapsulated into a StartOfMessage and EndOflvlessage special character separators that will mark the start and end of the sms/mms message. Finally, a CRCSep with the crc code is appended at the end of the message.
When the receiving party receives an sms/mms message that contain an ad or many ads data, it first removes the CRCSep and checks the cre code. If the cre checks OK, then it removes the StartOfMessage and EndOfMessage special character separators that encapsulates the whole srns/mms message, and reads the content of the message.
It then removes the RecSep and reads the content of one ad record data. It then reads the first and second ExlSep that are used for the transaction and category codes. Once it reads those two codes, it can predict the order and type of all data fields of that ad. It then reads each character separator and reads the data field associated with it. It then translates each data field into its original type and stores it into the ads database file as it was originally stored on the mobile device's ads database file. Once it finish parsing the first ad, it then takes the next ad, if more than one ad is included in the sms/mms message, and treats it in the same way.
[Fig 3] shows the flow chart of creating or composing a new ad from the list of categories offered by the system with optional multimedia show and storing it as a record in the ads database file on the mobile device's memory.
The optional multimedia show can be a picture, an audio or a video clip as long as the total turns message will not exceed the 100KB limit. The multimedia show can be selected from a list of picture, audio and/or video files stored in the mobile device memory or can be taken on the spot with the built-in microphone and/or camera.
The system is designed to include all the main categories of popular classified ads and at the same time generalized to easily add any new category in the future. The main categories include: Personals, Products, Employments, and General Ads used for General Service Announcement Ads, or any other type of Ads. Every main category is divided into ads which are used to present what you have for sale/re;nt or other, and want ads which are used to search for something you need to buy/rent or other. The Products main category includes the most popular subcategor~ies like: Real Estates, Lands, Vehicles, Furniture, Computers, Mobile Devices, Books/CDs/DVDs, and General Products which is used to describe any product item not included in the popular Products subcategor~ies list.
The flow chart of Fig 3 starts with the user requesting to corrrpose a new ad from the system. A new ad number or record number is given by the system, and then the user is provided with the list of main categories and subcategories of ads to choose from. The user then needs to specify the type of ad whether it is an ad or a want ad.
After that the user is presented with a list of data fields specific to the chosen category to be filled.
Every data field can be any of the three main types of data fields mentioned earlier in Fig2. Data fields that are mandatory to be filled by the user are marked with a *. The other data fields that are not marked with a * are not mandatory meaning they may be filled by the user or may be left blank. The user is provided with the option to add an optional multimedia file or use the microphone of the mobile device to record an audio clip and/or use the camera of the mobile device to take a picture or record a video clip right on the spot to be included with the new ad. The user then has the option of discarding or saving the new ad in the ads database file. If the user chooses to save the new ad, then a system check is done to make sure all mandatory fields are filled before saving the new ad. If one or more mandatory fields are not :filled, the user is informed that the system can't save the new ad until he/she fills all mandatory fields. If all mandatory fields axe filled, the system will create a new record and stores all the information entered by the user into the new record of the ads database file according to the specifications mentioned in Fig2. If the user chooses to discard the new ad, then all the data entered by the user will be lost.
[Fig 4] shows the flow chart of browsing the database files. There are two database files:
The ads database file and the matched ads database file. Every existing ad in the ads database file can be viewed, modified, and/or deleted whereas every downloaded ad in the matched ads database file can only be viewed and/or deleted but the function logic are the same whether performed on the ads or the matched ads database file, that's why it is represented as a single flow chart.
When the user browse the downloaded matched ads from the matched ads database file, he/she can look at the content of each ad, and if desired use the contact information to phone the person to discuss further details. If the user did not desire this particular ad, he/she has the option to delete that ad or leave it in memory and look at the next downloaded matched ad in the matched ads database file.
The flow chart of Fig 4 starts with the user requesting to browse the selected database file for the purpose of viewing any of the stored ads or matched. ads, modifying any of the stored ads only, or deleting any of the stored ads or matched ads. The system first checks whether the selected database file is empty or not. If the file; is empty, the system ends the request with a message informing the user that the database file is empty. If the file is not empty, then the system reads and displays the first ad record from the database file and presents the user with a menu of commands to choase from. The user can move backward using the previous command to move from one ad record to the previous ad record. The user can also move forward using the next command to move from one ad record to the next ad record. The system also cycle through the record set when it reaches the first or the last ad record. If the system reaches the first ad record and the user issued the previous command, then the system will read and display the last ad record. Also, if the system reaches the last ad record and the user issued the next command, then the system will read and display the first ad record. When any ad record is on display, the user can change any information of any data field and save the modifications with the single modify command at any time. The modify command is only available for the ads and not the matched ads records. When any ad record is on display and the user issued the delete command, that particular ad record is deleted and the system advance to the next ad record.
If no more ad records exist in the database file then the system will end the browsing function. The user can choose to exit the browsing function at any time.
[Fig 5] shows the flow chart of resetting the ads database file. When the user issues this command, the system will delete the ads database file and recreate an empty file on the mobile device's memory. The system will also create a communication thread to send the Delete Ads Database or Reset command to the server to make sure that the ads database file for that subscriber is also reset on the server so it is always an exact copy of the subscriber's database file.
If the user issued this command then quits from the system before receiving an acknowledgment from the server confirming that the reset operation is performed on the subscriber files on the server, the system will save a flag to make sure the command issued before is not lost. The next time the user starts the system and issues the same Reset command, the system checks the saved flag, resend the Reset command and wait for the acknowledgment from the server.
.: , .., _ .,ro..~,...~ . <". ~.. ..~, ~L.~.,~m s a ~.:.xa....~ _ ~e,.rzx", s ~.~.".,~; :z,xi~.~.'.,a~-a;~.~ ~.a~r~raw~.rr~u"~~.rs~a,.~..: °.~~.-...... »" . ~ .n ,..~,..~........._....-."......,~.
[Fig 6] shows the flow chart of resetting the matched ads database file. When the user issues this command, the system will delete the matched ad s database file and recreate an empty file on the mobile device's memory. No command is sent to the server in that case because there is no need for the matched ads database file to be an exact copy of the one on the server.
[Fig 7] shows the detailed flow chart of the mobile device's data communication functions which includes uploading ads and downloading matched ads.
Since the communication functions of the system (upload ads and download matched ads) use sms/mms messaging, this will entail increasing the user's phone bill. To keep the user in control of his/her bill, those communication functions are designed as user issued commands so the user is always the initiator of all communication operations.
Every communication from the user's mobile device to the central database server is created using a separate thread. This technique will ensure the separation between the data manipulation functions and the communication functions and does not allow a pending transmission to lock the mobile device's resources. The user is able at anytime to browse all the database files inside the mobile device's memory, make phone calls, play games, run any other application, and do any other function. of his/her mobile device whether or not it is engaged in sending an ad or receiving a matched ad.
All the communication operations between the clients and the server use some techniques to ensure data integrity during data transmission. Those techniques include the use of a special code called the crc code that is calculated from the content of the message and appended at the end of it. The sender sends the message with the crc code and is put in a waiting acknowledgment state. The purpose of this crc code is to make sure the data is intact while in transmission so there are no transmission errors. This may happen especially if the data passes across an electromagnetic field while in the air. When the receiver receives a message, it recalculates that crc code from the content of the message it receives and compares it against the crc code contained at the end of the message. If both codes match, this proves to the receiver that the data (content of the message) is intact and there were no errors during transmission. The receiver then accepts the data and sends a positive acknowledgment back to the sender. When the sender receives the acknowledgment, it takes appropriate action. If there was errors in transmission, the receiver discard the message and does not send an acknowLedgrnent or if the acknowledgment was lost and did not reach the sender, in both those cases the sender at that point will assume the pending transmission was unsuccessful and times out. The user is allowed to manually retransmit the same message again at their convenience time.
The first communication operation is allowing the user to upload the content of one specific ad identified by its ad number or the option of uploading all ads at once (if the mobile device is able to handle long sms messages) using sms/mms to the central database server. Only newly created ads, modified or deleted ads are valid for the upload operation. Existing ads that have been updated on the server and have not been modified AYkT: ..."~S81 r...~X.:yy:4 .: ~4~~AFa?u:acYXYFIfa ,.'.yi!CR-.iv~lY~.'.F'.s;'kaifa:~ypq"~xi»~pp.;;~~"s~;y.P.D»v~..
"i'r~'~w~m~~vm..o.......~... i.w.~mvn..
-.. ' '%~?aY~i'ux'~~Y :. ~&wpY.Ae.S F~:2KU:lr~xy.. ~.rn:.muyrwsw.,.va...~.-"w..r or deleted in any way are not valid for the upload operation. The second communication operation is allowing the user to request a certain number of matched ads to be downloaded from the central database server to his/her mobile device's non-volatile memory. Two options are available: the user can request a certain number of matched ads for a specific ad number or for all ads altogether. Every ad is downloaded with its contact information, is assigned a unique record number, and is stored in a matched ads database file separate from the user's ads database file on the mobile device's non-volatile memory.
The flow chart of Fig 7 starts with the user selecting the communication operation he/she wants to perform. If the user chose the first communication operation which is uploading a valid ad or all valid ads data to the subscriber files on the server to update his/her files on the server, then the user selects the desired ad number or all ads. The system checks the validity of the ad numbers) then reads the ad(s) data from the ads database file and prepare the sms/mms message to be sent. If sms is used, only ads with no multimedia shows can be sent. If mms is used, then ads with or without multimedia shows can be sent. Preparing the sms/mms message involves reading each field data and type and inserting the proper character separator type between each meld data to create the text container of the sms/mms message. If a multimedia show is included with the mms message then it will constitute the multimedia container of the mms message.
Then, a new thread is created to send the srns/mms message (there is a peer thread at the server that receives the sent ad(s) data in sms/mrns format which is explain$d in Fig 10). This new thread waits for a certain amount of time, called the timeout parameter, to receive am acknowledgment from the server to confirm the reception of the sms/mms message. If an acknowledgment is received from the server within the timeout limit, the new thread flags the sent ads in the ads database file, so they will not be sent again unless those ads are modified by the user, and then the new thread terminates. If the new thread times out before receiving an acknowledgment from the server, the sent ads are not flagged, so they are still valid to be sent again when selected by the user, and then the new thread terminates. If the user chose the second communication operation which is requesting the download of a certain number of matched ads, for a specific ad number or for all ads, then the user will specify how many matched ads to download and for which ad number. The system will then prepare a small sms message that contain a poll command with the user specified parameters to poll the server to download the requested number of matched ads for the particular ad number specified or for all ads. The system then created a separate communication thread to send the request to the server. This new thread function is to just send the request and then terminates immediately without waiting an acknowledgment from the server. The reason for that is since the poll command does not carry any vital information in case it is lost. The user can always send another request to the server and eventually one of them will reach the server.
[Fig 8] shows the flow chart of the receiving matched ads from the server and storing those matched ads as records in the matched ads database file on the mobile device's non-volatile memory so the user can browse them later at his/he;r convenience time.
This is created as a separate non ending thread that starts when the system starts and ends when the system is terminated by the user. In this way the mobile device is always ready to receive a matched ad at any time. When the user sends a .request to the server to download a specific number of matched ads (the second communication function of Fig7) the server responds to the request by sending the requested number of matched ads (there is a peer thread at the server that prepares and sends the matched ads in sms/mms format which is explained in Fig 12 and called the Send Matched Ads Thread), the thread of Fig 8 is the thread at the mobile device that will receive the matched ads from the server and store them in the matched ads database file.
The flow chart of Fig 8 starts with a connection in the idle state waiting to receive a matched ad from the server. When the system detects a message at the specified port of the connection, the system will first reads the message content and server address. Then, the system will make the crc checks to see if there were any transmission errors in the message. If there were errors, the system will discard the received message and goes back into the idle waiting state. If the crc checks OK, then the system will check if the server address is OK. If the server address is not valid, the system also discards the message and goes back to the idle waiting state. If the server address is valid, then the system will check if the received matched ad is a duplicate one meaning an exact copy of that same matched ad was previously downloaded and is still stored in the matched ads database file on the mobile device's memory. If it is a duplicate record, then the system will also discards the message and goes back into the idle waiting state. if it is not a duplicate record, then the system will process and parse the message by reading and separating all the different data fields and types and stores each field data according to its type in a new matched ad record into the matched ads database file and then goes back into the idle waiting state.
The central database server is also presented with data manipulation means and data communication means. The description of those means can also be taken from the abstract of this document.
The server is assigned one or multiple rnobile/cellular network phone numbers) that are special reserved numbers) that axe usually assigned to service providers. In case there are multiple reserved phone numbers to reach the server, all those numbers need to be leading to the same server machine which is maintaining all the subscriber database files.
The system can be expanded in the future to include multiple servers connected together through special WAN links or through the Internet so subscribers can access the system from their desktop machines while at home or in office anct have an Internet access.
[Fig 9] shows the flow chart of the main maintenance functions of the central database server. Those functions include open, close, and display any subscriber account information and open, close, and display any sms/mms idle message connection that is waiting to receive ads from any subscriber's mobile device.
~:.
The flow chart of Fig 9 starts with the server initializing and opening all subscriber database files and initializing and opening all sms/mms message connections and puts those connections in the idle waiting state ready to receive any sms/mms ads messages from any subscriber on the network. Next, the server initializes all necessary background threads that are responsible to perform most of the server background operations. Then, the server presents the administrator with a menu that shows all the different account and connection maintenance functions. When the administrator issue the command to terminate the server system, the server system will first close all sms/mms message connections to block the system from receiving any further ads from any subscriber. Next, the server waits all outstanding threads and processes that are still in the system to finish their processing functions. Then, the server system will close all subscriber account database files.
The server is responsible for the maintenance of all subscriber files. Each subscriber is assigned an account number that is equal to his/her mobile device's phone card number.
The account is created on the server on the first communication attempt from the subscriber mobile device to any of the server's reserved phone number(s).
Each subscriber account includes:
1. One database file for storing ads and this fill; is updated any time the subscriber upload any number of new or modified ads to the server.
The newspaper/magazine is still the oldest approach and has many disadvantages. For the person placing a new ad, modifying or deleting an existing ad, he/she has to contact one or multiple newspapers and communicate to them via phone, computer, or in person what he,~she want to do and has to wait the next day's issue for i:he new ad to be placed or for the modifications or deletion of the existing ad to take effect. For the person searching for an ad, he/she has to get many newspapers/magazines, go through pages and pages of classified ads to find what he/she is looking for. If the user did not find anything in the first day, he/she has to get next day's newspapers/magazines and may have to go through all the same set of ads to reach just few new ones since ads are not generally segregated based upon newly placed ones.
[US5283731 ] An attempt has been made to address some of the limitations of newspapers classified ads system through the use of voice-mail systems and computer-based systems using Interactive Voice Response (IVR) and using the Public Switched Telephone Network (PSTN), but all those systems are complex, require the need of a fixed line touch tone telephone, and the user does not get any visual of the ad whether text or image, all the user get is a voice description of the ad. Also, searching for a match is much slower than the proposed system.
[EPl 182893] Another attempt has been made in the mobile industry through the use of mobile terminal-controlled hierarchical information retrieval using sms. This system also has many disadvantages. The first disadvantage is apparent if the number of levels of the hierarchy is high a large number of sms messages get sent back and forth between the subscriber (user) and the network which may increase the user's mobile phone bill as well as the system is inefficient in wasting an entire sms message for only one word selection of a menu or submenu. Most of the mobile applications use this technique where the user engage in an interactive sms session that may last for half an hour or more and each sms transmission present the user with a list of choices to choose from. This type can be beneficial in simple applications like m-voting where the user has to choose from a list of candidate names but would be inefficient and costly in a classified ad system where a certain amount of information need to be transmitted to give the user a clear idea about the item in the ad. Another disadvantage is that this technique does not suggest in any way the transmission of pictures and/or audio/video clips with the sms text which is important in a classified ad system.
The Internet is also a well known and huge media for classified ads but you need first to have an Internet account with an ISP in addition to paying fir the phone bill.
When you place ads on a web site your ads are stored at that web site and not locally in your computer, so you are not in full control and you may not have access to the site all the time because of technical difficulties. Also, when you are searching for a match, you fill a form and the web site presents you with all matched ads which rnay be a large number of ads you have to go through before reaching what you looking for. If you modify your search criteria a little you may get the same set of ads that you have looked at before.
There is no way of excluding the ads that you have looked at before.
Another disadvantage with Internet systems is that there are two steps of communication involved compared with one step of the proposed system. With Internet systems, Stepl The user contact the web server to download the form to be filled. Step2: The user fills the form and sends it to the web server which stores the information in the database file.
With the proposed system, the specific forms are stored on the mobile device's memory . ,. =,..a., , . ... . ekey,Ha7F~ ~.xe.S'. ,v w "~Y9~:..~ r ,zs~.'.r'~"ZP~b ,'~"wfa rdtk C~_nf'~:y .,T,g "frT.9"s'3',~k~' mTfi~i -3.'~sp,Fra," ~ Y. :. ~.
, ~",.~,..~'$A~SFS<S~k2: ~.: a~t'zCtHt~. f~RSCR~;:~M. ~w~asw~:.~.
~.m~.n~axrcmwarxavxaaw".,rw_~.z...mra.~
itself so there is no need to contact the server to download any form. Steel :
The user calls the required form from memory, fills it with the information, and then sends it to the server to be stored in the database file.
Description of the preferred embodiments The worldwide popularity of the mobile devices is driving the rapid explosion of this industry. Today's mobile devices have a lot more features, are faster, have a lot more memory, and have audio/video capabilities. This rapid increase in mobile devices capabilities is allowing for the rapid development of mobile applications, which are becoming very popular as well. One of the most popular mobile applications nowadays is text messaging or short message system or sms for short, arid recently multimedia message system or mms for short. Few years ago this invention would not be possible to be implemented because mobile devices were limited in capabilities, but with the increased capabilities and power of today's mobile devices this invention is very possible to implement.
The system is designed in the English language, but can easily be supported and translated in any other language. Also, the system is designc;d without any security protection against hacking and unauthorized access but security can be implemented on the system once it is online because it is very important to make the system fault tolerant and secure it against external unauthorized attacks.
In this document a mobile device can be any processor based portable device that has mobile/cellular phone card capabilities of any type and inch~de but is not limited to mobile/cellular phones, smart phones, 3'd generation phones, PDAs, and laptops.
In addition, the terms users) and subscribers) are used interchangeably in this document to refer to the same thing which is/are the users) of the mobile devices) who possess/rent any mobile phone numbers) from any mobile operators) and subscribed in any type of mobile services. Also, the terms clients and mobile devices are used interchangeably in this document and an ad will refer to an ad or a want ad.
In the preferred embodiments of this invention the system i;> composed of any number of mobile subscribers using any type of mobile devices and a central database server setup by any service provider. Every mobile device and the central database server are provided with data manipulation means and data communication means as described in the abstract of this document.
The proposed system puts the user in full control of his/her ads and has full access to create any new ads, modify or delete any existing ads anytime and while on the move without the need to go back to any newspaper or magazine. The user is also presented with the option of taking a picture and/or audio/video clip of the presented item especially mobile devices with built-in cameras, and combines it with the text description of the item, which is not available with the hierarchical retrieval system using srns.
[Fig 1 ] shows the flow chart of the main system functions for mobile devices.
It shows the data manipulation functions and data communication functions of the system.
[Fig 2] shows the three main data field types used by the system, how they are stored inside the database file, how they are read from the database file and assembled in a sms/mms message format to be sent, and how they are received in an sms/mms message format and then disassembled to be written in the database :file.
Every category of ads is given two code numbers that are the same on all clients and server, and is divided into many data fields. The first code is the transaction code and identify if it is an ad or a want ad and the second code identify the category itself. The order and type of the data fields is identified by those two ad code numbers.
When creating or composing a new ad, the user will select the transaction type whether it is an ad or a want ad, and select the ad category/subcategory, which will identify those two ad code numbers that will be stored into the first and second fields of the ad record, then the system stores all the data fields based on their types. Every data field type is stored differently in the ads database.
There are three main types of data fields used. Text data fields are used to enter plain text and can be either numerical or alphanumerical. This type of data is stored in the database file as text. Exclusive choice groups are used to choose only one item out of a list of many items presented. This type of data is stored in the database file as short integer that represents the selected choice of the user. Multiple choice groups are used to choose multiple items out of a list of many items presented. This type of data is stored in the database file as a Boolean array where a true value at a specific position in the array represents a box that is checked by the user and a false value at a specific position in that array represents a box that is not checked by the user.
To make the system suitable for sms/mms, the system is designed in a way to minimize the amount of data transferred between clients and the server. To do that, every category's data fields that have a short list of choices to choose from will use choice groups (either exclusive or multiple) and the data fields that have an exhaustive list of choices will use text fields. In this way, for the data fields using choice groups, instead of sending the actual text, the number representing that particular user choices) will be sent instead. By using the same specific lists between clients and server, receiving the numbers(s) representing the choices) will be enough for the receiver to determine the actual choice(s).
Text data fields where the user type text data in, the system is designed to have some sort of provision for typing errors. As we know people will make mistakes in typing or users sometimes spell words differently. The system is able to find matches even with a predictable and acceptable number of typing errors.
Before sending an ad in a sms/mms message between clients and server, the system needs to compose the sms/mms text message out of the ad data stored into the ads database file.
First, the system will read the stored transaction and category codes from the ad record to identify the transaction and category of that ad, which in turn will identify the order and type of all the data fields of that ad that will follow. A special character ExlSep, the transaction code, ExlSep, and the category code, are then translated into text string and are appended into the sms/mms text message (including the transaction and category codes into the sms/mms message will make the receiving party identify the transaction and category of the received ad and predict the order and type of that ad's data fields).
Once the system reads the transaction and category codes it can then predict the order and type of all the data fields. Next, a special character separator is inserted before each data field. Each character separator and its corresponding data field are then translated into text string and are then appended into the sms/mms message. This process continues until all data fields are read from the ads database file. The character separator inserted before each data field type is different for every data field type. Those character separators are used by the receiver to identify the type of data fields and be able to extract the data from the received sms/mms message. Text data fields use a TxtSep character.
Exclusive choice group data fields use ExISep character. Multiple choice group data fields use MulSep character. Those special characters are defined and chosen to be not from the printable characters set so they will not conflict with any user entered text.
In the case of exclusive choice group data field types, the short integer number that is stored in the ads database file is read then translated into a text string representation before getting appended to the sms/mms message. In the case of the multiple choice group data field types, the Boolean array that is stored in the ads database file is read then translated into a text string of 1's and 0's based on the values in the Boolean array before getting appended to the sms/mms message. In the case of text data field types, the data is taken as is, because it is akeady text string, and get appended to the sms/mms message.
By the end the sms/mms message will Iook Like a long text string that include the ExISep character separator, the transaction code, the ExISep, the category code of the ad, a character separator that separates each data field based on its type, and then the data field itself, and so on until a1I data fields of that ad are included. When more than one ad is included into the sms/mms message, a special character separator called the record separator RecSep is included to separate each ad record. At the end the whole sms/mms message is encapsulated into a StartOfMessage and EndOflvlessage special character separators that will mark the start and end of the sms/mms message. Finally, a CRCSep with the crc code is appended at the end of the message.
When the receiving party receives an sms/mms message that contain an ad or many ads data, it first removes the CRCSep and checks the cre code. If the cre checks OK, then it removes the StartOfMessage and EndOfMessage special character separators that encapsulates the whole srns/mms message, and reads the content of the message.
It then removes the RecSep and reads the content of one ad record data. It then reads the first and second ExlSep that are used for the transaction and category codes. Once it reads those two codes, it can predict the order and type of all data fields of that ad. It then reads each character separator and reads the data field associated with it. It then translates each data field into its original type and stores it into the ads database file as it was originally stored on the mobile device's ads database file. Once it finish parsing the first ad, it then takes the next ad, if more than one ad is included in the sms/mms message, and treats it in the same way.
[Fig 3] shows the flow chart of creating or composing a new ad from the list of categories offered by the system with optional multimedia show and storing it as a record in the ads database file on the mobile device's memory.
The optional multimedia show can be a picture, an audio or a video clip as long as the total turns message will not exceed the 100KB limit. The multimedia show can be selected from a list of picture, audio and/or video files stored in the mobile device memory or can be taken on the spot with the built-in microphone and/or camera.
The system is designed to include all the main categories of popular classified ads and at the same time generalized to easily add any new category in the future. The main categories include: Personals, Products, Employments, and General Ads used for General Service Announcement Ads, or any other type of Ads. Every main category is divided into ads which are used to present what you have for sale/re;nt or other, and want ads which are used to search for something you need to buy/rent or other. The Products main category includes the most popular subcategor~ies like: Real Estates, Lands, Vehicles, Furniture, Computers, Mobile Devices, Books/CDs/DVDs, and General Products which is used to describe any product item not included in the popular Products subcategor~ies list.
The flow chart of Fig 3 starts with the user requesting to corrrpose a new ad from the system. A new ad number or record number is given by the system, and then the user is provided with the list of main categories and subcategories of ads to choose from. The user then needs to specify the type of ad whether it is an ad or a want ad.
After that the user is presented with a list of data fields specific to the chosen category to be filled.
Every data field can be any of the three main types of data fields mentioned earlier in Fig2. Data fields that are mandatory to be filled by the user are marked with a *. The other data fields that are not marked with a * are not mandatory meaning they may be filled by the user or may be left blank. The user is provided with the option to add an optional multimedia file or use the microphone of the mobile device to record an audio clip and/or use the camera of the mobile device to take a picture or record a video clip right on the spot to be included with the new ad. The user then has the option of discarding or saving the new ad in the ads database file. If the user chooses to save the new ad, then a system check is done to make sure all mandatory fields are filled before saving the new ad. If one or more mandatory fields are not :filled, the user is informed that the system can't save the new ad until he/she fills all mandatory fields. If all mandatory fields axe filled, the system will create a new record and stores all the information entered by the user into the new record of the ads database file according to the specifications mentioned in Fig2. If the user chooses to discard the new ad, then all the data entered by the user will be lost.
[Fig 4] shows the flow chart of browsing the database files. There are two database files:
The ads database file and the matched ads database file. Every existing ad in the ads database file can be viewed, modified, and/or deleted whereas every downloaded ad in the matched ads database file can only be viewed and/or deleted but the function logic are the same whether performed on the ads or the matched ads database file, that's why it is represented as a single flow chart.
When the user browse the downloaded matched ads from the matched ads database file, he/she can look at the content of each ad, and if desired use the contact information to phone the person to discuss further details. If the user did not desire this particular ad, he/she has the option to delete that ad or leave it in memory and look at the next downloaded matched ad in the matched ads database file.
The flow chart of Fig 4 starts with the user requesting to browse the selected database file for the purpose of viewing any of the stored ads or matched. ads, modifying any of the stored ads only, or deleting any of the stored ads or matched ads. The system first checks whether the selected database file is empty or not. If the file; is empty, the system ends the request with a message informing the user that the database file is empty. If the file is not empty, then the system reads and displays the first ad record from the database file and presents the user with a menu of commands to choase from. The user can move backward using the previous command to move from one ad record to the previous ad record. The user can also move forward using the next command to move from one ad record to the next ad record. The system also cycle through the record set when it reaches the first or the last ad record. If the system reaches the first ad record and the user issued the previous command, then the system will read and display the last ad record. Also, if the system reaches the last ad record and the user issued the next command, then the system will read and display the first ad record. When any ad record is on display, the user can change any information of any data field and save the modifications with the single modify command at any time. The modify command is only available for the ads and not the matched ads records. When any ad record is on display and the user issued the delete command, that particular ad record is deleted and the system advance to the next ad record.
If no more ad records exist in the database file then the system will end the browsing function. The user can choose to exit the browsing function at any time.
[Fig 5] shows the flow chart of resetting the ads database file. When the user issues this command, the system will delete the ads database file and recreate an empty file on the mobile device's memory. The system will also create a communication thread to send the Delete Ads Database or Reset command to the server to make sure that the ads database file for that subscriber is also reset on the server so it is always an exact copy of the subscriber's database file.
If the user issued this command then quits from the system before receiving an acknowledgment from the server confirming that the reset operation is performed on the subscriber files on the server, the system will save a flag to make sure the command issued before is not lost. The next time the user starts the system and issues the same Reset command, the system checks the saved flag, resend the Reset command and wait for the acknowledgment from the server.
.: , .., _ .,ro..~,...~ . <". ~.. ..~, ~L.~.,~m s a ~.:.xa....~ _ ~e,.rzx", s ~.~.".,~; :z,xi~.~.'.,a~-a;~.~ ~.a~r~raw~.rr~u"~~.rs~a,.~..: °.~~.-...... »" . ~ .n ,..~,..~........._....-."......,~.
[Fig 6] shows the flow chart of resetting the matched ads database file. When the user issues this command, the system will delete the matched ad s database file and recreate an empty file on the mobile device's memory. No command is sent to the server in that case because there is no need for the matched ads database file to be an exact copy of the one on the server.
[Fig 7] shows the detailed flow chart of the mobile device's data communication functions which includes uploading ads and downloading matched ads.
Since the communication functions of the system (upload ads and download matched ads) use sms/mms messaging, this will entail increasing the user's phone bill. To keep the user in control of his/her bill, those communication functions are designed as user issued commands so the user is always the initiator of all communication operations.
Every communication from the user's mobile device to the central database server is created using a separate thread. This technique will ensure the separation between the data manipulation functions and the communication functions and does not allow a pending transmission to lock the mobile device's resources. The user is able at anytime to browse all the database files inside the mobile device's memory, make phone calls, play games, run any other application, and do any other function. of his/her mobile device whether or not it is engaged in sending an ad or receiving a matched ad.
All the communication operations between the clients and the server use some techniques to ensure data integrity during data transmission. Those techniques include the use of a special code called the crc code that is calculated from the content of the message and appended at the end of it. The sender sends the message with the crc code and is put in a waiting acknowledgment state. The purpose of this crc code is to make sure the data is intact while in transmission so there are no transmission errors. This may happen especially if the data passes across an electromagnetic field while in the air. When the receiver receives a message, it recalculates that crc code from the content of the message it receives and compares it against the crc code contained at the end of the message. If both codes match, this proves to the receiver that the data (content of the message) is intact and there were no errors during transmission. The receiver then accepts the data and sends a positive acknowledgment back to the sender. When the sender receives the acknowledgment, it takes appropriate action. If there was errors in transmission, the receiver discard the message and does not send an acknowLedgrnent or if the acknowledgment was lost and did not reach the sender, in both those cases the sender at that point will assume the pending transmission was unsuccessful and times out. The user is allowed to manually retransmit the same message again at their convenience time.
The first communication operation is allowing the user to upload the content of one specific ad identified by its ad number or the option of uploading all ads at once (if the mobile device is able to handle long sms messages) using sms/mms to the central database server. Only newly created ads, modified or deleted ads are valid for the upload operation. Existing ads that have been updated on the server and have not been modified AYkT: ..."~S81 r...~X.:yy:4 .: ~4~~AFa?u:acYXYFIfa ,.'.yi!CR-.iv~lY~.'.F'.s;'kaifa:~ypq"~xi»~pp.;;~~"s~;y.P.D»v~..
"i'r~'~w~m~~vm..o.......~... i.w.~mvn..
-.. ' '%~?aY~i'ux'~~Y :. ~&wpY.Ae.S F~:2KU:lr~xy.. ~.rn:.muyrwsw.,.va...~.-"w..r or deleted in any way are not valid for the upload operation. The second communication operation is allowing the user to request a certain number of matched ads to be downloaded from the central database server to his/her mobile device's non-volatile memory. Two options are available: the user can request a certain number of matched ads for a specific ad number or for all ads altogether. Every ad is downloaded with its contact information, is assigned a unique record number, and is stored in a matched ads database file separate from the user's ads database file on the mobile device's non-volatile memory.
The flow chart of Fig 7 starts with the user selecting the communication operation he/she wants to perform. If the user chose the first communication operation which is uploading a valid ad or all valid ads data to the subscriber files on the server to update his/her files on the server, then the user selects the desired ad number or all ads. The system checks the validity of the ad numbers) then reads the ad(s) data from the ads database file and prepare the sms/mms message to be sent. If sms is used, only ads with no multimedia shows can be sent. If mms is used, then ads with or without multimedia shows can be sent. Preparing the sms/mms message involves reading each field data and type and inserting the proper character separator type between each meld data to create the text container of the sms/mms message. If a multimedia show is included with the mms message then it will constitute the multimedia container of the mms message.
Then, a new thread is created to send the srns/mms message (there is a peer thread at the server that receives the sent ad(s) data in sms/mrns format which is explain$d in Fig 10). This new thread waits for a certain amount of time, called the timeout parameter, to receive am acknowledgment from the server to confirm the reception of the sms/mms message. If an acknowledgment is received from the server within the timeout limit, the new thread flags the sent ads in the ads database file, so they will not be sent again unless those ads are modified by the user, and then the new thread terminates. If the new thread times out before receiving an acknowledgment from the server, the sent ads are not flagged, so they are still valid to be sent again when selected by the user, and then the new thread terminates. If the user chose the second communication operation which is requesting the download of a certain number of matched ads, for a specific ad number or for all ads, then the user will specify how many matched ads to download and for which ad number. The system will then prepare a small sms message that contain a poll command with the user specified parameters to poll the server to download the requested number of matched ads for the particular ad number specified or for all ads. The system then created a separate communication thread to send the request to the server. This new thread function is to just send the request and then terminates immediately without waiting an acknowledgment from the server. The reason for that is since the poll command does not carry any vital information in case it is lost. The user can always send another request to the server and eventually one of them will reach the server.
[Fig 8] shows the flow chart of the receiving matched ads from the server and storing those matched ads as records in the matched ads database file on the mobile device's non-volatile memory so the user can browse them later at his/he;r convenience time.
This is created as a separate non ending thread that starts when the system starts and ends when the system is terminated by the user. In this way the mobile device is always ready to receive a matched ad at any time. When the user sends a .request to the server to download a specific number of matched ads (the second communication function of Fig7) the server responds to the request by sending the requested number of matched ads (there is a peer thread at the server that prepares and sends the matched ads in sms/mms format which is explained in Fig 12 and called the Send Matched Ads Thread), the thread of Fig 8 is the thread at the mobile device that will receive the matched ads from the server and store them in the matched ads database file.
The flow chart of Fig 8 starts with a connection in the idle state waiting to receive a matched ad from the server. When the system detects a message at the specified port of the connection, the system will first reads the message content and server address. Then, the system will make the crc checks to see if there were any transmission errors in the message. If there were errors, the system will discard the received message and goes back into the idle waiting state. If the crc checks OK, then the system will check if the server address is OK. If the server address is not valid, the system also discards the message and goes back to the idle waiting state. If the server address is valid, then the system will check if the received matched ad is a duplicate one meaning an exact copy of that same matched ad was previously downloaded and is still stored in the matched ads database file on the mobile device's memory. If it is a duplicate record, then the system will also discards the message and goes back into the idle waiting state. if it is not a duplicate record, then the system will process and parse the message by reading and separating all the different data fields and types and stores each field data according to its type in a new matched ad record into the matched ads database file and then goes back into the idle waiting state.
The central database server is also presented with data manipulation means and data communication means. The description of those means can also be taken from the abstract of this document.
The server is assigned one or multiple rnobile/cellular network phone numbers) that are special reserved numbers) that axe usually assigned to service providers. In case there are multiple reserved phone numbers to reach the server, all those numbers need to be leading to the same server machine which is maintaining all the subscriber database files.
The system can be expanded in the future to include multiple servers connected together through special WAN links or through the Internet so subscribers can access the system from their desktop machines while at home or in office anct have an Internet access.
[Fig 9] shows the flow chart of the main maintenance functions of the central database server. Those functions include open, close, and display any subscriber account information and open, close, and display any sms/mms idle message connection that is waiting to receive ads from any subscriber's mobile device.
~:.
The flow chart of Fig 9 starts with the server initializing and opening all subscriber database files and initializing and opening all sms/mms message connections and puts those connections in the idle waiting state ready to receive any sms/mms ads messages from any subscriber on the network. Next, the server initializes all necessary background threads that are responsible to perform most of the server background operations. Then, the server presents the administrator with a menu that shows all the different account and connection maintenance functions. When the administrator issue the command to terminate the server system, the server system will first close all sms/mms message connections to block the system from receiving any further ads from any subscriber. Next, the server waits all outstanding threads and processes that are still in the system to finish their processing functions. Then, the server system will close all subscriber account database files.
The server is responsible for the maintenance of all subscriber files. Each subscriber is assigned an account number that is equal to his/her mobile device's phone card number.
The account is created on the server on the first communication attempt from the subscriber mobile device to any of the server's reserved phone number(s).
Each subscriber account includes:
1. One database file for storing ads and this fill; is updated any time the subscriber upload any number of new or modified ads to the server.
2. One database file for staring the record numbers of deleted ads and this file is updated anytime the subscriber upload an ad number that has been deleted from his/her mobile device's memory.
3. One database file for storing matched ads and this file is updated anytime the server receives a new or modified ad and. starts searching all subscriber database files for matched ads.
4. One database file for storing deleted matched ads and this file is updated anytime the subscriber download a matched ad or the server receives a modified ad, deletes old matches and starts looking for new matches.
An administrator is able to open and close any subscriber account on the server while that account files are not busy. The administrator can open a closed account to enable it to receive ads from its mobile subscriber on any of the opened idle connections.
The administrator can also close an opened account to disable it from receiving any ads on any opened idle connection unless that account is reopened by the administrator.
When the account is open, the administrator is able to browse and view the ads and matched ads contents but the administrator is not able to add, modify, or delete any of the ads. A log file is used for each subscriber account that stores all the activities and error messages occurring for that account. This log file allows the administrator to troubleshoot any problems) with any account database files. The log file of any account can be cleared by the administrator at any time. The server is also able to maintain multiple simultaneous sms/mms connections with many subscribers. The system allows an administrator to maintain and manage all those connections by opening, closing, and displaying or looking at the content of those connections. The administrator is able to open a closed connection to enable that connection to receive ads messages again from any subscriber.
The administrator can also close an opened connection (only when that connection is idle) to disable that connection from receiving any ads messages from any subscriber.
Whether the connection is opened or closed, the administrator is able to display or look at the content of the log file of any connection at any time which includes accumulated received messages and error messages that are generated by the system while receiving messages on that connection. There is a log file for each connection. This Iog file allows the administrator to troubleshoot any problems) on any sms/mms message connection.
The administrator can also clear the log file of any connection at any time.
[Fig 10] shows the flow chart of receiving sms/mms ads messages by the central database server. The server is able to maintain multiple simultaneous connections that always stay in the idle state waiting to receive any sms/mms messages from any subscribers on the network.
The flow chart of Fig 10 starts with the server system simultaneously monitoring all idle connections for any incoming sms/mms message from any subscriber. When the server detects a sms/mms message from a subscriber on any connection, it reads the content of the message and the subscriber address. Next, it checks the crc code of the message to verify if there were any errors in transmission. if there were errors, the message is discarded, the server does not send an acknowledgment to the subscriber, and the server goes back to monitoring that connection. The subscriber mobile device will eventually time out. If there were no errors, the server accepts the message and sends an acknowledgment immediately to the subscriber and creates a separate thread for processing the content of the message. The reason of using this technique is that processing a message may take a long time and there is no ~'oint to leave the subscriber waiting an acknowledgment until the server finish the processing cycle, which have the side effect of making the subscriber mobile device always time out unless the time out parameter is setup to a very high number which is impractical. one case is an exception to the acknowledgment rule is when the subscriber requests a download operation. In that case, the subscriber mobile device is not required to wait an acknowledgment from the server and the server does not send an acknowledgment. At that point the message is handed over to the newly created message processing thread which is responsible to process the received sms/mms message and the server goes back to monitoring that connection for any received messages.
[Fig 11 ] shows the flow chart of the message processing thread. It can handle three different types of messages. The first type is a message that includes the content of one or many ads records that the subscriber is uploading to the server. The message processing thread at that point will parse the message to check how many ads are included in the message, to check each ad whether it is a new ad, an existing ad that the user have modified, or an existing ad that the user have deleted. Each one of those cases is handled accordingly. The second type is a message that includes a download request from a subscriber to download a certain number of matched ads, for a specific ad number or for a.,~,~.~,_ . .. ..,~mr.,~ .u ,.',~...~~ i~,~~e,'~~iN
,~'e..;~:,~~a~r~.a.';.~APw,~va~ ,xa-~:.v~ "~5~-~' mw.~..~ ..,. _......
.a~..,n.~.m,.~. .~ ~"~"........~.......~
.mw all ads. The third type is a message that includes a Delete Ads Database or a Reset command to reset that subscriber's account database files.
The flow chart of Fig 11 starts with the server reading the content of the message and the subscriber address. The subscriber address allows the server to recognize whether it is a new or an existing subscriber. If it is a new subscriber, the server will setup the subscriber account by creating the four different account database files described earlier. If it is an existing account, the server will skip the account setup operation. Next, the server will check the content of the message to determine the type of the received message. If the message content is a download request message, then from the content of the message the server will be able to read the parameters which are the requested number of matched ads to be download and if specified in the message the ad number for which to download the matched ads. Next, the server will start reading the matched ads database file selecting only the matched ads for the specified ad number and collects only the specified number of matched ads to download. If the ad number for which to download the matched ads is not specified in the message, then the server collects only the specified number of matched ads for any ad number to download to the subscriber. Finally, the message processing thread will hand over the task of downloading all the collected matched ads to a separate thread called the Send Matched Ads Thread (explained in Fig 12) and then terminates. If the message content is a Delete Ads Database command that was issued and sent by the subscriber to the server, then the server will delete all four account database files for that subscriber and recreate four new account database files. Please note that the Delete Ads Database command can be a stand alone command or can be encapsulated into an ads message. After executing the Delete or Reset command the server need to check if the message contains any encapsulated ads message. If there is an encapsulated ads message it will process it, otherwise the message processing thread will terminate. If the message content is one or more ads messages, then the server need find out how many ads in the message, and for every ad the server need to recognize if it is a new ad, and existing modified ad, or a deleted ad. If it is a new ad, the server will parse the message to read the ad transaction and category codes and all the different data fields and stores the ad in a new record in the subscriber's ads database file on t:he server, and then starts searching for matches for the newly stored ad. If it is an existing modified ad, then the server will parse the message and overwrite the old ad data with the new data, then delete all the old matched ads and starts looking for new matched ads. If it is an existing deleted ad, then the server will delete that ad and all corresponding matched ads it can find.
[Fig 12] shows the flow chart of the send matched ads thread. This thread works together with the thread of Fig 8. This thread is responsible for sending the collected matched ads to be downloaded to the subscriber's mobile device to be stored in its matched ads database file. When this thread finishes sending each matched ad record, it will delete it of the server automatically.
The flow chart of Fig 12 starts once the message processing thread detects a download request type of message from a subscriber, reads the message parameters, collects the selected matched ads to download, then hand over control t;o the send matched ads thread w ..<s->u w, ..,.,. z-c..~:w.."~ .~Jev..::vx..y...
.z'aS,evy'.:i#F%~'~F'K.*.5~.,~mc~~Nha:'b56Y,S~a7y~S::"~reTeveP»3k.'~.,a,,K.~a3.
Y~@aGxi~Svs..uvne-am.m.,w r. , , ., _...., Y, c:;y~L.'~5s...~a~.sw..~-ma.~m..raa..~...a...._..r.~.~.....a.ro (this thread) and terminates. At this point, the send matched ads thread reads the first matched ad record to download, open a matched ad connection with the subscriber (running thread of Fig 8), send the matched ad to that subscriber address, then waits a timed out acknowledgment from the subscriber to acknowledge the correct receipt of that matched ad. If the acknowledgment is received within the time out parameter, then the send matched ads thread will delete the matched ad record .and moves to reading and sending the next matched ad on the list until no more matched ads are waiting to be downloaded. If no acknowledgment is received within the time out parameter, then the send matched ads thread will move to the next matched ad on the list and so on.
The technique of deleting the sent matched ad once its correct reception is acknowledged by the subscriber will ensure that matched ads are not kept at the server for a long time to make room for other matched ad records to be stored and will also ensure that the subscriber will not download the same matched ad twice. p'~ut in some cases the subscriber could have issued two consecutive download requests before the same matched ad record get deleted of the server. The system is able to recognize duplicate matched ad records that are downloaded and does not create new records in the mobile device's memory for such duplicate records but ignores them.
[Fig 13] shows the flow chart of searching all subscriber accounts on the database server for matched ads and if found stores pointers to the matched. ads in all found subscribers matched ads database files.
The flow chart of Fig 13 starts when the server receives a n.ew or modified ad contained within a received message. The subscriber address and the ad data details are considered the current ones. The server reads the subscriber address or account number, then reads the content of the current received ad which includes the ad transaction and category codes and all the ad data fields. Next, the server checks the list of registered subscriber account addresses to make sure it does not compare the ads of the same current subscriber. If it is the same subscriber address, it skips to the next subscriber in the list.
For every subscriber in the list of registered subscribers that does not have the same current address, the server will read every ad from every su.bscriber's ads database file and checks if both ads (the current received ad and the read ad from the ads database file of every subscriber) are an ad and a want ad of the same category. If both ads are not of the same category or if they are of the same category but both are ads or both are want ads, then the server will skip the comparison process and move to the next ad to compare with the current ad. If both ads are of the same category and one is an ad and the other is a want ad, then the server will continue the comparison process and compares all the data fields of both ads. If it fords a match in the current comparison, it stores a pointer in the current subscriber's matched ads database file that points to the read ad of the read subscriber. It also stores a pointer in the read subscriber's matched ads database file that points to the current ad of the current subscriber. This process continues for every new or modified currently received ad for a specific current subscriber until all ads from all the list of registered subscribers are checked. All the matched ads database files of aII
subscriber's that found matches are updated with pointers pointing to its matched twin.
When a new ad is received, it is appended to the ads database file of the subscriber and a search is performed on all subscriber records stored on the server to find any number of matches. Pointers to all matched ads are stored in all subscribers matched ads database files. For example, let's assume the new ad record number is 10 for the subscriber account number 7749675 that originated the message and lea's assume three matches are found for this new ad. The first match occurred with account number 3446662 ad record number 25, the second match occurred with account number 5649898 ad record number
An administrator is able to open and close any subscriber account on the server while that account files are not busy. The administrator can open a closed account to enable it to receive ads from its mobile subscriber on any of the opened idle connections.
The administrator can also close an opened account to disable it from receiving any ads on any opened idle connection unless that account is reopened by the administrator.
When the account is open, the administrator is able to browse and view the ads and matched ads contents but the administrator is not able to add, modify, or delete any of the ads. A log file is used for each subscriber account that stores all the activities and error messages occurring for that account. This log file allows the administrator to troubleshoot any problems) with any account database files. The log file of any account can be cleared by the administrator at any time. The server is also able to maintain multiple simultaneous sms/mms connections with many subscribers. The system allows an administrator to maintain and manage all those connections by opening, closing, and displaying or looking at the content of those connections. The administrator is able to open a closed connection to enable that connection to receive ads messages again from any subscriber.
The administrator can also close an opened connection (only when that connection is idle) to disable that connection from receiving any ads messages from any subscriber.
Whether the connection is opened or closed, the administrator is able to display or look at the content of the log file of any connection at any time which includes accumulated received messages and error messages that are generated by the system while receiving messages on that connection. There is a log file for each connection. This Iog file allows the administrator to troubleshoot any problems) on any sms/mms message connection.
The administrator can also clear the log file of any connection at any time.
[Fig 10] shows the flow chart of receiving sms/mms ads messages by the central database server. The server is able to maintain multiple simultaneous connections that always stay in the idle state waiting to receive any sms/mms messages from any subscribers on the network.
The flow chart of Fig 10 starts with the server system simultaneously monitoring all idle connections for any incoming sms/mms message from any subscriber. When the server detects a sms/mms message from a subscriber on any connection, it reads the content of the message and the subscriber address. Next, it checks the crc code of the message to verify if there were any errors in transmission. if there were errors, the message is discarded, the server does not send an acknowledgment to the subscriber, and the server goes back to monitoring that connection. The subscriber mobile device will eventually time out. If there were no errors, the server accepts the message and sends an acknowledgment immediately to the subscriber and creates a separate thread for processing the content of the message. The reason of using this technique is that processing a message may take a long time and there is no ~'oint to leave the subscriber waiting an acknowledgment until the server finish the processing cycle, which have the side effect of making the subscriber mobile device always time out unless the time out parameter is setup to a very high number which is impractical. one case is an exception to the acknowledgment rule is when the subscriber requests a download operation. In that case, the subscriber mobile device is not required to wait an acknowledgment from the server and the server does not send an acknowledgment. At that point the message is handed over to the newly created message processing thread which is responsible to process the received sms/mms message and the server goes back to monitoring that connection for any received messages.
[Fig 11 ] shows the flow chart of the message processing thread. It can handle three different types of messages. The first type is a message that includes the content of one or many ads records that the subscriber is uploading to the server. The message processing thread at that point will parse the message to check how many ads are included in the message, to check each ad whether it is a new ad, an existing ad that the user have modified, or an existing ad that the user have deleted. Each one of those cases is handled accordingly. The second type is a message that includes a download request from a subscriber to download a certain number of matched ads, for a specific ad number or for a.,~,~.~,_ . .. ..,~mr.,~ .u ,.',~...~~ i~,~~e,'~~iN
,~'e..;~:,~~a~r~.a.';.~APw,~va~ ,xa-~:.v~ "~5~-~' mw.~..~ ..,. _......
.a~..,n.~.m,.~. .~ ~"~"........~.......~
.mw all ads. The third type is a message that includes a Delete Ads Database or a Reset command to reset that subscriber's account database files.
The flow chart of Fig 11 starts with the server reading the content of the message and the subscriber address. The subscriber address allows the server to recognize whether it is a new or an existing subscriber. If it is a new subscriber, the server will setup the subscriber account by creating the four different account database files described earlier. If it is an existing account, the server will skip the account setup operation. Next, the server will check the content of the message to determine the type of the received message. If the message content is a download request message, then from the content of the message the server will be able to read the parameters which are the requested number of matched ads to be download and if specified in the message the ad number for which to download the matched ads. Next, the server will start reading the matched ads database file selecting only the matched ads for the specified ad number and collects only the specified number of matched ads to download. If the ad number for which to download the matched ads is not specified in the message, then the server collects only the specified number of matched ads for any ad number to download to the subscriber. Finally, the message processing thread will hand over the task of downloading all the collected matched ads to a separate thread called the Send Matched Ads Thread (explained in Fig 12) and then terminates. If the message content is a Delete Ads Database command that was issued and sent by the subscriber to the server, then the server will delete all four account database files for that subscriber and recreate four new account database files. Please note that the Delete Ads Database command can be a stand alone command or can be encapsulated into an ads message. After executing the Delete or Reset command the server need to check if the message contains any encapsulated ads message. If there is an encapsulated ads message it will process it, otherwise the message processing thread will terminate. If the message content is one or more ads messages, then the server need find out how many ads in the message, and for every ad the server need to recognize if it is a new ad, and existing modified ad, or a deleted ad. If it is a new ad, the server will parse the message to read the ad transaction and category codes and all the different data fields and stores the ad in a new record in the subscriber's ads database file on t:he server, and then starts searching for matches for the newly stored ad. If it is an existing modified ad, then the server will parse the message and overwrite the old ad data with the new data, then delete all the old matched ads and starts looking for new matched ads. If it is an existing deleted ad, then the server will delete that ad and all corresponding matched ads it can find.
[Fig 12] shows the flow chart of the send matched ads thread. This thread works together with the thread of Fig 8. This thread is responsible for sending the collected matched ads to be downloaded to the subscriber's mobile device to be stored in its matched ads database file. When this thread finishes sending each matched ad record, it will delete it of the server automatically.
The flow chart of Fig 12 starts once the message processing thread detects a download request type of message from a subscriber, reads the message parameters, collects the selected matched ads to download, then hand over control t;o the send matched ads thread w ..<s->u w, ..,.,. z-c..~:w.."~ .~Jev..::vx..y...
.z'aS,evy'.:i#F%~'~F'K.*.5~.,~mc~~Nha:'b56Y,S~a7y~S::"~reTeveP»3k.'~.,a,,K.~a3.
Y~@aGxi~Svs..uvne-am.m.,w r. , , ., _...., Y, c:;y~L.'~5s...~a~.sw..~-ma.~m..raa..~...a...._..r.~.~.....a.ro (this thread) and terminates. At this point, the send matched ads thread reads the first matched ad record to download, open a matched ad connection with the subscriber (running thread of Fig 8), send the matched ad to that subscriber address, then waits a timed out acknowledgment from the subscriber to acknowledge the correct receipt of that matched ad. If the acknowledgment is received within the time out parameter, then the send matched ads thread will delete the matched ad record .and moves to reading and sending the next matched ad on the list until no more matched ads are waiting to be downloaded. If no acknowledgment is received within the time out parameter, then the send matched ads thread will move to the next matched ad on the list and so on.
The technique of deleting the sent matched ad once its correct reception is acknowledged by the subscriber will ensure that matched ads are not kept at the server for a long time to make room for other matched ad records to be stored and will also ensure that the subscriber will not download the same matched ad twice. p'~ut in some cases the subscriber could have issued two consecutive download requests before the same matched ad record get deleted of the server. The system is able to recognize duplicate matched ad records that are downloaded and does not create new records in the mobile device's memory for such duplicate records but ignores them.
[Fig 13] shows the flow chart of searching all subscriber accounts on the database server for matched ads and if found stores pointers to the matched. ads in all found subscribers matched ads database files.
The flow chart of Fig 13 starts when the server receives a n.ew or modified ad contained within a received message. The subscriber address and the ad data details are considered the current ones. The server reads the subscriber address or account number, then reads the content of the current received ad which includes the ad transaction and category codes and all the ad data fields. Next, the server checks the list of registered subscriber account addresses to make sure it does not compare the ads of the same current subscriber. If it is the same subscriber address, it skips to the next subscriber in the list.
For every subscriber in the list of registered subscribers that does not have the same current address, the server will read every ad from every su.bscriber's ads database file and checks if both ads (the current received ad and the read ad from the ads database file of every subscriber) are an ad and a want ad of the same category. If both ads are not of the same category or if they are of the same category but both are ads or both are want ads, then the server will skip the comparison process and move to the next ad to compare with the current ad. If both ads are of the same category and one is an ad and the other is a want ad, then the server will continue the comparison process and compares all the data fields of both ads. If it fords a match in the current comparison, it stores a pointer in the current subscriber's matched ads database file that points to the read ad of the read subscriber. It also stores a pointer in the read subscriber's matched ads database file that points to the current ad of the current subscriber. This process continues for every new or modified currently received ad for a specific current subscriber until all ads from all the list of registered subscribers are checked. All the matched ads database files of aII
subscriber's that found matches are updated with pointers pointing to its matched twin.
When a new ad is received, it is appended to the ads database file of the subscriber and a search is performed on all subscriber records stored on the server to find any number of matches. Pointers to all matched ads are stored in all subscribers matched ads database files. For example, let's assume the new ad record number is 10 for the subscriber account number 7749675 that originated the message and lea's assume three matches are found for this new ad. The first match occurred with account number 3446662 ad record number 25, the second match occurred with account number 5649898 ad record number
5, and the third match occurred with account number 4427 x'88 ad record number 17. At this point, the matched ads database file for the account number 7749675 owner of the present message, will create three new matched ad records. Each one of those records will store three pieces of information. The first record will store: the new ad record number 10, then the first matched account number 3446662, then the record number of the matched ad for this account (25). The second record will store: the new ad record number 10, then the second matched account number 5649898, then the record number of the matched ad for this account (5). The third record will store: the new ad record number 10, then the third matched account number 4427788, then the record number of the matched ad for this account (17). In addition, each one of the rnatchE;d accounts will create one new match ad record. Each one of those record will store: the record number of matched ad for this account (for the first account it is 25), then the account number owner of the message 7749675, then the new ad record number 10 of that account owner of the message. This way the pointers axe cross referenced to all matches in the system, which will double the possibility of one subscriber making the contact with the other subscriber.
When an existing modified ad record is received, the modi,~C~ed data is updated in the same ad record number, then the system will delete all the old rn;atches that it can find in the system, then a new search is performed using the new data to find any new matches as in the new ad case. When an existing deleted ad record is received, the ad record is deleted from the ad database file and the system will also delete all the old matches that it can find in the system. The deleted ad record number is appended to the deleted ad database file to keep track of all deleted ad record numbers.
When the message processing thread reads the matched ads database file to download the requested number of records, it reads the pointers to the original ads, which are stored in the matched ads database files, to be able to read the contents of those matched ads and download them to the subscriber requesting them. In some cases, the original ads may have been deleted by their original owners because the owner did not need them any more. The pointers become pointing to invalid ads. The system will automatically clean the matched ads database file of such records. In some cases, when a subscriber have a certain number of ads stored at the server which are generating some matched ad records for himlher, but he/she is not downloading any matched ad records for a long time, the number of matched ad records for that subscriber will increase gradually and may reach a point where it would be impractical for that subscriber to read all those matched ad records some of which may have been very old. The system set a maximum record number threshold for matched ad records. When a specific subscriber account matched ads database file reach that threshold, the system will automatically delete all the old matched ad records leaving only the new matches.
-,~,~..uK x~,M ~~.:~~~x. .:~: .ws~~,,~::«,~;f.~~~~ . ~,~~,..a~,rv.~~..~a~...~
When an existing modified ad record is received, the modi,~C~ed data is updated in the same ad record number, then the system will delete all the old rn;atches that it can find in the system, then a new search is performed using the new data to find any new matches as in the new ad case. When an existing deleted ad record is received, the ad record is deleted from the ad database file and the system will also delete all the old matches that it can find in the system. The deleted ad record number is appended to the deleted ad database file to keep track of all deleted ad record numbers.
When the message processing thread reads the matched ads database file to download the requested number of records, it reads the pointers to the original ads, which are stored in the matched ads database files, to be able to read the contents of those matched ads and download them to the subscriber requesting them. In some cases, the original ads may have been deleted by their original owners because the owner did not need them any more. The pointers become pointing to invalid ads. The system will automatically clean the matched ads database file of such records. In some cases, when a subscriber have a certain number of ads stored at the server which are generating some matched ad records for himlher, but he/she is not downloading any matched ad records for a long time, the number of matched ad records for that subscriber will increase gradually and may reach a point where it would be impractical for that subscriber to read all those matched ad records some of which may have been very old. The system set a maximum record number threshold for matched ad records. When a specific subscriber account matched ads database file reach that threshold, the system will automatically delete all the old matched ad records leaving only the new matches.
-,~,~..uK x~,M ~~.:~~~x. .:~: .ws~~,,~::«,~;f.~~~~ . ~,~~,..a~,rv.~~..~a~...~
Claims (8)
1. A mobile classified ads system and method using short message system (sms) and/or multimedia message system (mms), involves any number of mobile subscribers using any type of mobile devices connecting through sms/mms to a central database server setup by any service provider. It uses the most popular mobile messaging application sms/mms for the purpose of classified ads. The system is independent of mobile operators but use the sms/mms services of mobile operators. The system is made up of two components:
a client component and a server component.
a client component and a server component.
2. The system and method of claim 1, further describe the client component as a component that resides on any person's mobile device. It provides the user or subscriber with data manipulation means and data communication means.
3. The system and method of claim 1, further describe the server component as a component that resides on the central database server. It also provides the server with data manipulation means and data communication means.
4. The system and method of claim 2, further describe the data manipulation means as having all the necessary information built-in the system to provide it with:
(a) Means to compose any number and type of new ads/want ads with contact information and optional multimedia show (picture, audio; and/or video) especially mobile devices with built-in cameras, give each ad/want ad (1) a unique record number automatically generated by the system, (2) a specific transaction code based on user's selected transaction type (ad or want ad), (3) a specific category code based on user's selected category of ad/want ad, and (4) a specific set of data fields that are specific for every ad transaction and category to be filled by the user, and store all those ads/want ads as a record set in a database file called the ads database file inside the mobile device's non-volatile memory.
(b) Means for browsing the ads database file for viewing, modifying, or deleting any existing ad from the ads database file of the mobile device's non-volatile memory. (c) Means for storing the received downloaded matched ads in a database file called the matched ads database file inside the mobile device's non-volatile memory. (d) Means for browsing the matched ads database file for viewing all the stored matched ads, selecting a specific one and calling the contact to discuss the matched ad details, and finally either keeping or deleting the matched ad from the matched ads database file on the mobile device's non-volatile memory. (e) Means for resetting the ads and matched ads database files from the mobile device's non-volatile memory.
(a) Means to compose any number and type of new ads/want ads with contact information and optional multimedia show (picture, audio; and/or video) especially mobile devices with built-in cameras, give each ad/want ad (1) a unique record number automatically generated by the system, (2) a specific transaction code based on user's selected transaction type (ad or want ad), (3) a specific category code based on user's selected category of ad/want ad, and (4) a specific set of data fields that are specific for every ad transaction and category to be filled by the user, and store all those ads/want ads as a record set in a database file called the ads database file inside the mobile device's non-volatile memory.
(b) Means for browsing the ads database file for viewing, modifying, or deleting any existing ad from the ads database file of the mobile device's non-volatile memory. (c) Means for storing the received downloaded matched ads in a database file called the matched ads database file inside the mobile device's non-volatile memory. (d) Means for browsing the matched ads database file for viewing all the stored matched ads, selecting a specific one and calling the contact to discuss the matched ad details, and finally either keeping or deleting the matched ad from the matched ads database file on the mobile device's non-volatile memory. (e) Means for resetting the ads and matched ads database files from the mobile device's non-volatile memory.
5. The system and method of claim 2, further describe the data communication means as:
(f) Means for uploading or sending any valid outdated ad/want ad using sms/mms from any subscriber's ads database file of his/her mobile device's non-volatile memory to that subscriber's ads database file on the centralized sms/mms enabled database server. A
specific command code is included with the ad record number and the ad data in the upload message to identify a new ad from a modified or deleted existing ad.
(g) Means for downloading or receiving any number of matched ads, of a specific ad number or for all ads, from any subscriber's matched ads database file on the centralized database server to that subscriber's matched ads database file on his/her mobile device's non-volatile memory.
(f) Means for uploading or sending any valid outdated ad/want ad using sms/mms from any subscriber's ads database file of his/her mobile device's non-volatile memory to that subscriber's ads database file on the centralized sms/mms enabled database server. A
specific command code is included with the ad record number and the ad data in the upload message to identify a new ad from a modified or deleted existing ad.
(g) Means for downloading or receiving any number of matched ads, of a specific ad number or for all ads, from any subscriber's matched ads database file on the centralized database server to that subscriber's matched ads database file on his/her mobile device's non-volatile memory.
6. The system and method of claims 2&3, further describe the data communication means as advantageous over Internet Systems in a way that reduce the steps of communication between the clients and the server from two steps in Internet Systems to one step in the proposed system since the specific ad forms are built-in each mobile's client component.
The system can be expanded to include multiple servers connected together through special WAN links or through the Internet.
The system can be expanded to include multiple servers connected together through special WAN links or through the Internet.
7. The system and method of claim 3, further describe the data manipulation means as: (a) Means for storing, browsing, and maintaining all the new or modified ads/want ads received by the server from all mobile subscribers in the network. The server maintains a separate ads database file for each subscriber that is an exact copy of his/her mobile device's ads database file when uploaded by that subscriber. Each ad/want ad is identified by its ad record number and each subscriber is identified by its mobile phone number, which are two pieces of information included in the received message. (b) Means for searching all subscribers ad records in the centralized database server for matched ads when a new or modified ad/want ad for any subscriber reaches the server. When a new ad/want ad is received the server starts searching for all matched ads right away. When a modified ad/want ad is received, the server first deletes all the old matched ads it can find on the server, then starts searching for all newly matched ads it can find.
(c) Means for storing all found matched ads for each subscriber in a separate matched ads database file on the server, waiting to be downloaded by that subscriber when he/she wishes to do so.
(d) Means for deleting an ad/want ad from the ads database file of a subscriber, and delete all correspondent matched ads from the matched ads database files, when a deleted ad/want ad command reaches the server from that subscriber. (e) Means for resetting the ads and matched ads database files of any subscriber when the specific command from that subscriber reaches the server. (f) Means for automatically cleaning the database server of all invalid, old, and deleted matched ads records. (g) Means for automatically deleting every matched ad record of the server once it is downloaded by the user. (h) Means for automatically compacting all subscribers matched ads database files in the case their number of records reach a limit. (i) Means to open, close, and display any subscriber account database files that are not busy being read from or written to.
(c) Means for storing all found matched ads for each subscriber in a separate matched ads database file on the server, waiting to be downloaded by that subscriber when he/she wishes to do so.
(d) Means for deleting an ad/want ad from the ads database file of a subscriber, and delete all correspondent matched ads from the matched ads database files, when a deleted ad/want ad command reaches the server from that subscriber. (e) Means for resetting the ads and matched ads database files of any subscriber when the specific command from that subscriber reaches the server. (f) Means for automatically cleaning the database server of all invalid, old, and deleted matched ads records. (g) Means for automatically deleting every matched ad record of the server once it is downloaded by the user. (h) Means for automatically compacting all subscribers matched ads database files in the case their number of records reach a limit. (i) Means to open, close, and display any subscriber account database files that are not busy being read from or written to.
8. The system and method of claim 3, further describe the data communication means as:
(j) Means for simultaneously maintaining multiple sms/mms connections with multiple subscribers in order to simultaneously receive multiple ads and storing those ads in the appropriate subscriber's ads database files on the server. (k) Means for establishing multiple simultaneous sms/mms connections with multiple subscribers in order to send multiple matched ads in response to any number of subscriber requests to download matched ads. (l) Means to open, close, and display any sms/mms connection that is in the idle waiting state.
(j) Means for simultaneously maintaining multiple sms/mms connections with multiple subscribers in order to simultaneously receive multiple ads and storing those ads in the appropriate subscriber's ads database files on the server. (k) Means for establishing multiple simultaneous sms/mms connections with multiple subscribers in order to send multiple matched ads in response to any number of subscriber requests to download matched ads. (l) Means to open, close, and display any sms/mms connection that is in the idle waiting state.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| LB692804 | 2004-02-26 | ||
| LB6928 | 2004-02-26 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2463071A1 true CA2463071A1 (en) | 2005-08-26 |
Family
ID=34880361
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2463071 Abandoned CA2463071A1 (en) | 2004-02-26 | 2004-04-06 | Mobile classified ads system and method using short message system (sms) and/or multimedia message system (mms) |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2463071A1 (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| MD4033B2 (en) * | 2007-12-20 | 2010-04-30 | Игорь ПОГИРКА | Process for rendering advertising services using the mobile communications |
| CN112272318A (en) * | 2020-07-10 | 2021-01-26 | 北京远景视点科技有限公司 | Method for distributing multimedia material |
-
2004
- 2004-04-06 CA CA 2463071 patent/CA2463071A1/en not_active Abandoned
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| MD4033B2 (en) * | 2007-12-20 | 2010-04-30 | Игорь ПОГИРКА | Process for rendering advertising services using the mobile communications |
| CN112272318A (en) * | 2020-07-10 | 2021-01-26 | 北京远景视点科技有限公司 | Method for distributing multimedia material |
| CN112272318B (en) * | 2020-07-10 | 2022-10-25 | 北京远景视点科技有限公司 | Method for distributing multimedia material |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101080056B (en) | A management method and system of network browser collection folder of mobile terminal | |
| US6442591B1 (en) | Method and system for automatic electronic mail address maintenance | |
| CN101622837B (en) | Sharing of media using contact data | |
| US7676473B2 (en) | Propagation of user preferences to end devices | |
| TW571541B (en) | Electronic messaging system method and apparatus | |
| CN1685684B (en) | Method for archiving multimedia messages | |
| US20080267117A1 (en) | Method and system for linking to content and services for a communication device | |
| US20010005415A1 (en) | Method and apparatus for initiating telephone calls using a data network | |
| CN101132459A (en) | Method for computer remote control by mobile phone | |
| US20060176902A1 (en) | Method of processing a multimedia message, a storage medium, and an associated processing system | |
| KR20010072138A (en) | World wide web access for voice mail and page | |
| CN101184264A (en) | Mobile phone telephone and message anti-disturbance and private communication method and system | |
| CN101068220B (en) | Immediate communication tool-based media file update prompting method and system | |
| CN100518412C (en) | A multimedia message transmission method | |
| US20030140091A1 (en) | Telephone number capture from Web page | |
| CN100342702C (en) | Method for routing electronic messages | |
| CN1812450A (en) | Intelligent mobile telephone incoming call relative information displaying and utilizing method | |
| US20030135647A1 (en) | Web browser control of telephone directories | |
| CN100411457C (en) | System and method capable of ordering mail push | |
| US20010027466A1 (en) | Electronic mail transfer device and system, electronic mail transfer method | |
| CA2463071A1 (en) | Mobile classified ads system and method using short message system (sms) and/or multimedia message system (mms) | |
| CN113727288B (en) | Silence customer service robot based on 5G message | |
| CN106850980B (en) | The method for cleaning and mobile terminal of Email attachment in a kind of mobile terminal | |
| EP1351475B1 (en) | Access to the content of a voice message through a short message | |
| CN109688052B (en) | Mail information and instant message interaction method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Dead |