WO2006088703A2

WO2006088703A2 - Method for providing a comprehensive, searchable database of proposed trips

Info

Publication number: WO2006088703A2
Application number: PCT/US2006/004374
Authority: WO
Inventors: Clyde Mitchell
Original assignee: Clyde Mitchell
Priority date: 2005-02-16
Filing date: 2006-02-07
Publication date: 2006-08-24
Also published as: WO2006088703A3

Abstract

The method and system allows for searching of rides leaving from any point and going to any other point in a given region, country or continent, whether by ground vehicle, aircraft or vessel. The method and system allows for personal preferences such as nonsmoking/smoking preference, drive sharing/non-sharing preference, gender preference (including mixed), and specifying other preferences in comment fields. General preferences specify expense sharing arrangement, departure time, pick-up and drop off points, music preferences, and other concerns. The method and system allow multiple riders, different ride recurrences, and also a rider rating system. Confirmations and reminders are sent to riders before scheduled rides and review security procedures and other details. These confirmations and reminders can be forwarded to enhance security of the ride. Macros will be needed to facilitate searches. Micropayments will be charged to verify users.

Description

METHOD FOR PROVIDING A COMPREHENSIVE, SEARCHABLE DATABASE OF PROPOSED TRIPS

FIELD OF THE INVENTION

[0001] This invention generally relates to a method and system for providing travelers a comprehensive, searchable database to proposed trips spanning any particular region, country or continent. Particularly, it matches travelers with similar travel plans, based on personal traveling preferences and vehicle needs. More particularly, the present invention is directed to software that includes rating and security aspects and facilitates the use of reminders.

BACKGROUND

[0002] In the past, processes that match commuters with similar commutes have provided these riders a convenient method of commuting locally. These previous systems focus their process on "commuting areas" around cities and are therefore best suited for car pooling and local commuting. Travelers who wish to take trips spanning a particular region, country or continent do not benefit from the previous systems.

[0003] In addition, previously known systems do not take into consideration the rider's personal traveling preferences. Previous processes are inflexible and do not provide as many benefits, options or preferences as the present invention. For example, prior processes do not allow a rider to specify a gender or specify different departure times.

[0004] Thus, a need exists to provide a system that matches travelers with compatible travel plans, personal traveling preferences and transportation equipment preferences. Furthermore, the need exists to provide prospective travelers with a safe and flexible system for selecting a suitable match for trips spanning any particular region, country, or continent.

SUMMARY OF THE INVENTION

[0005] A system that matches travelers with compatible travel plans facilitates a convenient and economical ride for all participants. The present invention is a comprehensive regional and continental rideshare database based on advanced database and server technology. The software can cover all of North America and any other region, island or continent. The present invention is not limited to any specific geographical area and can be used for a large or small geographical region. The ridesharing database produced by this software, searchable by origin and destination, date range of departure and gender, offers the only effective continental and regional rideshare database currently available. The software can be applied to vehicles of any type, aircraft, and vessels.

[0006] The software can offer a vast selection of rides up to three months in advance. In addition, while other sites leave rider identity and security to chance, the software provides substantial security, so that a user can be confident about the identity of the person behind the posting and the other riders.

[0007] Also, the software can be accessed from the comfort of a user's own computer, wherever he or she can be, and the site can be instructed to remind a user of new interesting listings.

[0008] The software saves money and time, provides convenience, and improves the environment, by reducing pollution and traffic congestion. The software also provides company to lonely drivers and extra drivers needed for longer rides, reducing the risk of accidents on long drives.

[0009] Finally, the software can be used to move vehicles, vessels or aircraft from any town to any other town in the region or continent. The owner of the device can opt not to go on the ride and make this clear in a comment field. Also, a disabled owner could travel along on such a ride.

[0010] The present invention matches travelers with compatible travel plans, personal traveling preferences and vehicle, aircraft and vessel needs. In return, riders benefit by sharing a convenient ride, sharing travel expenses and saving time. In addition, the region, country or continent also benefits from reduced pollution and reduced congestion of the roads, waterways and sky. The present invention is continent-wide, and the current site covers the USA and Canada, as well as the territories and possessions of each.

[0011] Through the use of a real-time third-party micro-payment system with which the present invention interacts, the present invention can verify that each user is "real", in the sense that each user can have access to credit directly, or through another person with credit. Users cannot be fictitious.

[0012] To further enhance security, the present invention uses user IDs, passwords and

128-bit encryption. The present invention can also collects TD information from each user, including home address, telephone number, email address, birth date, gender, and driver's license number and state. The present invention also collects vehicle information, including make, year, model, license number, state of registration, name of owner, color and condition. In the case of each student, the present invention asks for a student TD number and the name of his or her college and campus name. The invention can be modified to permit the use of other forms of identification, such as passports or identity cards.

[0013] The current invention sends to each rider a detailed email confirmation covering rider contact information and the details of the ride. The ride confirmation also provides many helpful suggestions for the ride, including security recommendations. Each rider can forward the confirmation email to a close friend or parent, to further enhance security.

[0014] The present invention reminds the rider of each accepted ride approximately one day before the ride departs. For rides scheduled more than one week in advance, an additional reminder can be sent one week before the ride departs. Emails can be encrypted.

[0015] These, and other aspects of the present invention, are described in the following brief and detailed description of the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] FIGS. 1-23 are diagrams depicting one implementation of the present system and method regarding a registration process by a rider;

[0017] FIGS. 24-37 are diagrams showing one application of the system in posting a ride;

[0018] FIGS. 38-48 are diagrams depicting the first rider acceptance within the system of the present invention;

[0019] FIGS. 49-68 are diagrams depicting the second rider acceptance within the system of the present invention;

[0020] FIGS. 69-82 are diagrams depicting the third rider acceptance within the system of the present invention;

[0021] FIGS. 83-86 are diagrams illustrating one implementation of accessing a rating system for riders through the system of the present invention; [0022] FIGS. 87-89 are diagrams illustrating one implementation of a ride reminder for the second ride acceptance; and

[0023] FIG. 90 is an exemplary schematic block diagram depicting one embodiment of the system of the present invention.

DETAILED DESCRIPTION

[0024] The many shortcomings of processes previously available to commuters for obtaining ride sharing information can be overcome by the use of the present invention. For example, the previous process such as that found in U.S. Patent Publication 20010056363 to Gantz presents information with a map display of potential ridesharing partners. The present invention, however, does not use a map. The present invention lists rides leaving from a departure town (or area designated by a particular postal code) and going to a destination town (or postal code area). Each area expands beyond the town (or zip code area) inputted, when a full page of rides does not appear. The first search covers only the specific departure town and destination town. Then the wider search occurs.

[0025] The previous process "evaluates" applications filed by users. The current invention takes data from users and automatically presents it to other users. The present process can utilize an ID verification process. An example includes verifying driver's licenses. Examples concerning students include verifying student IDs or adding student face book or direction information.

[0026] The previous process provides an anonymous "communication route" between the users. The present invention, however, does not provide for communication between the users during the ride identification, ride review and ride selection process. Rather, all relevant information is listed at the site and the site communicates to each user. Users cannot communicate until the ride is accepted. Users can communicate directly only after the process completes, i.e., only after the ride poster and fellow user agree to share a ride. Then an email is sent to each user containing the contact information and each user covers the rest of the details.

[0027] The previous process sets specific times. The present invention provides for rides leaving during a range of time, such as in the morning, afternoon and evening. The timing coverage on ride departures of the present invention thus is different.

[0028] The previous process identifies ride originations and destinations as street intersections. The present invention identifies departure and destination areas. Each area can be a town or the area designated by a postal code. Additional details are covered in comment fields in the ride database or left up to the riders, e.g., pickup and drop off points.

[0029] The present invention enables ride posters to specify the preferred gender of the riders for any given ride: women only rides, men only rides, and mixed gender rides.

[0030] The previous process does not provide expressly for multiple riders, or keep track of the number of riders that have chosen a given carpool. The current invention provides for up to, for example at least, ten additional riders on each ride, and keeps track of the number of available positions, and does not permit the acceptance of riders beyond the specified maximum for any given ride. The ride poster can specify the number of additional riders, from one to for example ten.

[0031] The previous process assumes that each of their posted rides leaves each work day, i.e., it is recurring on a daily basis. The present invention covers non-recurring rides and recurring rides. In addition, the present invention allows for recurring rides leaving on a weekly, bi-weekly, monthly, and quarterly basis. Furthermore, the present invention covers rides leaving as late as three months from the date the ride is posted.

[0032] The previous process does not keep track of past carpools, or whether they are accepted. The present invention lists a user's posted rides and past accepted rides, so that a user can keep track of his or her activity.

[0033] The present invention provides for rating riders that travel on a ride including the driver, pilot or captain. Ratings remain stored so a user can review them.

[0034] The present invention effectuates various personal preferences. The ride poster can vary the expense sharing arrangement, set a nonsmoking/smoking preference, set a drive sharing/non-sharing preference, set a gender preference (including mixed gender), and specify other preferences in a general comment field.

[0035] The general preferences could specify the exact departure time, the exact pick-up and drop off points, music preferences, allergy concerns, or any other concern of the ride poster. The user can select a percentage threshold of how high or low a possible match they desire with regards to matching personal preferences of other users in the determination of ride share information. Alternatively, the computer program can determine a specific percentage threshold of matches in determining the ride share information.

[0036] Through the use of a real-time third party micro-payment system the present invention interacts with, the present system can verify that each user is "real". In a sense, the present system verifies that each user can have access to credit directly, or through another person with credit. Users can not be fictitious. [0037] To enhance security, the present invention uses user IDs, passwords, and 128 bit encryption. The present invention also collects ID information from each user, including but not limited to home address, telephone number, email address, birth date, gender, and driver's license number and state. The present invention also collects vehicle information, including but not limited to make, year, model, license number, state of registration, name of owner, color and condition. In the case of each student, the present invention asks for a student ID number and the name of college and campus. The invention can be modified to permit the use of other forms of identification, such as passports or identity cards.

[0038] The process sends to each rider a detailed email, for example, for confirmation covering rider contact information and the details of the ride. The ride confirmation also provides many helpful suggestions for the ride, including security recommendations. Each rider can forward the confirmation email to a close friend or parent, to further enhance security.

[0039] The process reminds the rider of each accepted ride approximately, for example, one day before the ride departs. For rides scheduled more than one week in advance, an additional reminder can be sent, for example, one week before the ride departs. User communications are encrypted for security.

[0040] FIGS. 1-90 illustrate the process of registration, ride posting and ride acceptance.

The example involves three member registrations by three new users, the posting of a ride with space for three passengers by one of the new users, and the acceptance of the ride by three passengers, including two of the new users and an existing member of the website. The invention is not so limited to this example, and it is understood that various combinations involving different amounts of users can exist with the present invention. [0041] Rides Covered

[0042] The software of the present invention is capable of dealing with rides in any region, country or continent, from any city or town to any city or town, or from any area designated by postal code area to any other such area, or any combination thereof. The rides can occur by ground vehicle, such as a car, van, sport utility vehicle or truck, or by aircraft, helicopter or water vessel.

[0043] The software can also cover carpooling and periodic commuting rides. For example, if a rider only travels to a destination on an infrequent basis, the present invention can be utilized. This was one of the shortcomings of the previous attempts to provide ridesharing information. Information was only available to full time commuters that traveled daily to a particular destination. The present invention allows a broader scope of travelers and commuters to utilize its database to access ride sharing information.

[0044] A membership fee can be charged, and a member can be charged for posting a ride or accepting a ride, or both. Fees can also be charged for revising a posted ride.

[0045] Rides by ground vehicle can occur on any territory or island covered by the postal code database provided for any region, country or continent. In the USA, for example, the software covers rides by ground vehicle within Hawaii, Puerto Rico and Guam and any other island or area that is part of the USA or its territories or possessions, including rides requiring ferry trips between land bodies.

[0046] Find-A-Ride Screen

[0047] The "Find A Ride Screen" ("FAR Screen") enables a user to search the list of available rides anywhere within a region, country or continent. See Exhibit Page 5. A user can first select a single date or date range on which he wants to leave. The range can be within one week, two weeks, one month or three months, or any variation thereof.

[0048] The user can be reminded of the departure of any accepted ride one day before the ride is scheduled to depart. For example, an e-mail, fax telephone cal or the like would be sent to all parties involved in the ride share at least one day prior to the appointment.

[0049] The user then enters the town or city of departure and town or city destination.

Alternatively, the user can enter the postal code of the point of departure and/or the postal code of the destination, or a combination can be used.

[0050] The user can also set a gender preference for the ride - all rides, women only rides, men only rides, and mixed gender rides. Preferences can also be set for music type desired, smoking or non-smoking, number of people going on the ride and the like.

[0051] The software then retrieves the rides that have been posted during the date range from the departing town to the destination town, within the gender parameters set by the user. FIG 53.

[0052] Various fields enable the user to determine the following characteristics of the rider posting the ride: smoking habits, if any, college, if for example, the poster is a college student, campus of the poster, preferred departure time, and other criteria listed by the poster of the ride in comment fields, such as age, musical tastes, expense sharing issues, and other personal preferences. See for example FIG 54.

[0053] Neighborhood information can be specified by a ride poster to enable the user to determine from where within a town or postal code the ride poster desires to leave from or end a ride. [0054] Additional Ride Finding Features ^'

[0055] The software enables the user to also see rides leaving from nearby departure points and rides going to nearby destinations, via use of formulas that calculate radii about the departure and destination points. Depending on the embodiment, a user can select the range of the radii about departure and destination points. This feature provides more options to the user on any given day or week or month.

[0056] Currently the formulae are set at a constant of fifty miles. The radii formulae can be revised to vary in length, in proportion to the length of the trip. AU distances are determined using as a basis the latitude and longitude information provided by the postal code databases being used. To speed the software, certain calculations between larger urban areas are pre- calculated and stored as a database, for example see FIG 53. This page shows additional rides arriving at nearby towns.

[0057] The software can also enable the user to program robots to look for certain rides posted in the future and to advise the user of their posting. The user can click on "My Robots" in the left column and give the robot instructions as indicated in FIG 26. The software can enable the user to search for return rides, newly posted rides of interest to the user, and shorter rides that might be combined to reach a further destination.

[0058] Accepting a Ride

[0059] Before the user can see the details of a posted ride, or accept a ride, the user can register with the software.

[0060] The user can view the details of the ride by clicking on the "Ride Details" link.

FIG 54. This occurs after the user registers. The user accepts the ride at the acceptance screen as illustrated for example in FIG 55. The software can then refer the user to a payment processing website ("PPW") to charge the user's credit card or to collect payment in any other manner covered by the PPW. The collection of funds by credit card enables the software to verify the user as the holder of a credit card (or as an authorized user of the credit card). The software collects the charge from the PPW by a funds transfer.

[0061] Should the ride not occur, the software can issue a credit to the user, if the user complains, after review by an authorized officer. The credit can expire after a certain period of time, currently three years. This process can be automated in the future.

[0062] Registration

[0063] Before a user can see the details of a posted ride, or accept a ride, the user can register with the software as a member. The Exhibit pages cover registration by several users. Examples are given in FIGS 12 to 23.

[0064] Also, if none of the posted rides appeal to the user, the user can register with the software and then post a ride with his or her own travel and personal preferences. See for example the depictions in FIGS 7 to 11.

[0065] To register with the software, the user can provide the following information, that includes but is not limited to:

- First and last name

- street address, town, postal code and state

- valid driver's license number and state of issue

- date of birth gender

- primary telephone number

- secondary telephone number (optional)

- college name, campus name, and student E) number (all optional)

- user ID (seven character minimum)

- valid email address - password

- secret question (asked by the software to retrieve the password or to reset it)

- answer to the secret question

[0066] If the user does not complete a required field, then the user is reminded to complete it before the software can allow the user to proceed further. This protocol applies to each required field in the software.

[0067] AU of the above information can be edited at any time by re-logging into the software as a user and giving the relevant password, for example as shown in FIG 21.

[0068] Once a user is registered, a user can see the details of a posted ride, and then accept the ride and pay for it, as described above. Acceptance can occur without reviewing the details of the ride. See for example the depiction in FIG 55. A fee can be charged for registration.

[0069] It is within the scope of the present invention to allow riders who do not have a driver's license. Many commuters would be caning to share a ride with a non-licensed driver in exchange, for example, gas money or toll funds to decrease the ride cost. The software meets the specific needs of this type of rider or commuter by requiring instead the filing of a passport number or other official identification number.

[0070] Posting a Ride

[0071] A registered user, or member, can post rides on the software, for example as shown in FIG 28 - 33.

[0072] Before posting any ride, however, the member can first provide information on the vehicle he or she intends to use. The registrant can provide the following vehicle information, which includes but is not limited to: - vehicle make

- year of vehicle

- model name

- license plate number

- color

- condition (selected from a range, ranging from excellent to dilapidated) state in which the vehicle is registered

[0073] All of the above vehicle information can be edited at any time by re-logging into the software as a member.

[0074] In order to post a ride, a member can list the following information about the ride.

The information includes, but is not limited to:

date of departure leaving time (morning, afternoon, after 6PM local time)

- the number of passengers requested (can be less than ten)

- departure town, city or postal code area

- destination town, city or postal code area whether driving can be shared

- whether the provider of the vehicle can drive expiration date of license smoking terms (no, yes, smoking outside vehicle permitted)

- gender of riders (women only, men only, mixed) the vehicle details indicated above name of actual owner of vehicle

[0075] The software sets certain presumptions about each ride that each rider, including the ride poster, can agree to:

- the ride can leave if at least one person accepts the ride even if the requested number of passengers is higher

- gas used and tolls paid can be shared by the riders, pro rata other costs of the ride are not shared

- the cost of any speeding ticket is borne by the driver at the time

- the ride description can not be modified once the ride is accepted additional riders may accept the ride up to the day before the ride leaves.

[0076] Expense sharing can be modified from the standard protocol by the poster of the ride as seen for example in FIG 28 and 29. [0077] In addition, the following information can be added to the description of any posted ride:

the name of the departure neighborhood (useful when the town or postal code covers a large area) the name of the destination neighborhood

- additional rider preferences, such as exact point of departure (e.g., Third Ave. and East 90^th St.) or point of destination, allergies, music tastes, types of pets that can be traveling) for example as seen in FIG 32.

[0078] Any person who accepts a ride can comply with the restrictions set forth by the poster of the ride, so that the process works simply. Typically, there is no negotiation permitted, although it is within the scope of this invention to provide a negotiation model where restrictions as such can be agreed upon.

[0079] The member is offered a chance to review the ride details and to edit them as seen for example in FIGS 33, 34 and 39.

[0080] The member can modify the ride listing at any time, until the ride is accepted by another party. At that point, the ride can no longer be modified, unless the riders agree directly amongst themselves. This feature is illustrated for example in FIG 40.

[0081] A fee can be charged for posting a ride at the time of the posting, when the poster is ready to approve the posting and accept it as shown in FIG 33.

[0082] A posting can be made up to three months in advance and can be continuously modified until the trip has been accepted by a rider. If no one accepts a proposed ride by the departure date, then the software can issue automatically a credit to post another trip for free. The credit can expire after a certain number of years, currently three years.

[0083] A member can log in and give his or her password before posting any ride, and before editing a posted ride description as shown for example in FIG 25. [0084] Security Features

[0085] The software provides various security features discussed below. First, no information is released to anyone but a member. For a user to become a member, the user can register with the site. Before a person can accept a ride or post a ride, a person can be a member and logged in.

[0086] Once a member accepts a ride, a confirmation email is sent to the ride acceptor and the ride poster, containing the same information. The confirmation email summarizes the details of the ride, including the contact information of each rider (e.g., name, age, email and telephone number(s)). This is seen for example in FIGS 42-44, 71-74, and 75-78.

[0087] In the event that there are multiple passengers, a new confirmation is sent out each time an additional rider accepts the ride, both to the additional rider and to the poster of the ride, for example see FIGS 57 to 60, and 75 to 78.

[0088] The confirmation also contains each rider's drivers license number (truncated to the last four to six digits) and a detailed vehicle description (make, model, year, color, condition) and the vehicle license number. Each driver's license number is truncated to deter identity theft.

[0089] hi the case of each student, the confirmation email includes the relevant college, college campus, and the student's truncated ID (last four to six digits).The confirmation email also contains helpful suggestions for how to proceed safely and securely with the ride.

[0090] The confirmation email strongly suggests that the riders meet briefly in a public place, such as a coffeehouse, prior to the departure date, to verify each other's information and the vehicle. The meeting allows each rider to check the data in the confirmation email against each other rider's actual driver's license and against the actual vehicle. [0091] If the student riders are enrolled at the same college, they can also perform a background check through mutual contacts. Also, student riders can have access to a college website or direction that describes the students and their living groups, and that resource can be used to help verify a rider. Also, students might use a web resource like www.thefacebook.com to check on other riders. Such websites list names of students, their images, their living groups and their friends.

[0092] In the event that there are discrepancies between a rider's posted information and a rider's actual information or the actual vehicle information, the potential ride can be terminated easily, before it leaves, and credits can be issued to the innocent parties.

[0093] Riders are also encouraged to forward their confirmation emails, whether by email or by regular mail, to a close friend, significant other, parent or other relative. Riders are further encouraged to bring along mobile telephones for the ride, and to consider traveling in groups of two or more.

[0094] The above procedures can heighten security substantially, especially compared to existing ride boards, rideshare websites, and public mass transit. This can discourage criminal activity in the ridesharing space.

[0095] In the event any accident or crime occurs, the software and the confirmation emails can enable various parties to assist the authorities in finding the distressed riders and any potential criminals. These parties can include RideCheck, close friends of the riders, significant others of the riders, and parents or other relatives of the riders. [0096] Quality Assurance Features

[0097] The confirmation encourages riders to meet in advance and to settle any remaining details about a ride, such as the actual departure time and pick-up site, along with map, snack, music, headphone and other requirements.

[0098] The software can be used by those with disabilities and infirmities to share rides with members who can drive or provide other assistance on a ride. A disabled person can vary the driving terms and add comments to cover his or her situation as illustrated in FIG 30.

[0099] After the completion of a trip, each rider can rate the other riders as "good" or

"bad", and the software keeps track of these ratings. A person looking for a ride can review the ratings information on a ride poster. Each member can review their ratings for example as shown in FIGS 83 to 86. The software can be modified so that the ride poster can specify a rating. Alternatively, a rate can be set by the software program to achieve the highest quality of riders. The ratings can be searchable. Comment fields can be included to rate other riders.

[00100] The ratings function can help to ensure that each rider behaves in a responsible manner, improving the quality of the rides offered by the software.

[00101] The software can send an inquiry to each rider to encourage him or her to rate the other riders. Comment fields can be included. This grading process will discourage each rider from canceling ride plans, or changing a ride plan after acceptance, or behaving uncivilly. Negative comments can result in a downgrade of a member. Users will be attracted to other users with higher ratings.

[00102] The software can be modified so that an adult without a car can post a proposed ride and so that adults with vehicles can search for such listed rides, in the same manner as the software currently works for rides posted by vehicle owners or bailees. In addition, macros can be added to facilitate the processes of: searching for similar outbound rides (with vehicles and posted by others (whether singly or in combination)); posting recurring similar rides; and searching for return trips (with vehicles).

[00103] Credit and Refund Aspects

[00104] What happens if the ride never happens or if the ride turns out to be unpleasant?

These outcomes can be incorporated into a rider's bad rating, via negative comments made to the software.

[00105] The intent behind the software is to offer a ride, subject to the terms of the description contained in the ride posting and related vehicle description, nothing better and nothing worse. The software also relies on the general good can of the members - i.e., that most of them can apply common sense in their judgment of a ride taken.

[00106] More plainly, if a rider did in fact travel from point A to point B, under the constraints described in the ride posting, in the vehicle as described and subject to the potential failings of such a vehicle, and the costs of fuel and tolls were shared proportionally, and each rider was civil, then the ride should be considered satisfactory and no complaint should be filed.

[00107] The software can issue credits in the following situations to build goodwill with its members:

- A credit can be issued automatically by the software to the ride poster if the posted ride is not accepted by 12:01 AM of the day the ride is scheduled to occur. (At that point the ride cannot be accepted.)

- A credit can be issued if the rider or driver failed to show up on time for a trip (each should wait for at least fifteen minutes). This can be automated. - A credit can be issued to the complaining party if the any rider refused in any material way to comply with the trip description. This can be automated.

[00108] The credit can be either a ride posting fee or a ride acceptance fee, or some other commensurate credit, whichever was paid by the complaining rider.

[00109] Other Points

[00110] The software, through emailing a ride confirmation, advises each rider going on a ride to check to confirm that the age of each rider is over eighteen. The confirmation also tells each rider where the minimum age of 18 is not sufficient. The software informs the riders of the higher age in those states and provinces where the minimum age is higher than 18. This is necessary to ensure the formation of a binding legal agreement as shown in FIG 76.

[00111] The software, through emailing a ride reminder to each rider, reminds the riders of the impending ride. A reminder can be given a day before any ride begins, m the event the ride was posted more than a week in advance, a reminder can be given a week in advance.

[00112] The software contains a contact feature that is automated to lodge certain complaints in certain mailboxes within the software. The software contains a survey feature that can be modified. To conduct surveys of users.

[00113] The software architecture was built using the Java programming language and the

Enterprise Java Beans (EJB) technology with MySQL data base. The server deployment uses JBoss secure server technology, along with a Microsoft Windows firewall operating system and a secure mail server (for example, only port 80 is exposed to the Internet). Access to the software is strictly controlled via user/password assignment and is validated each time access is requested. Similar supporting software can also be used. [00114] SSL certificate encryption, i.e., secure socket layer encryption, is used by the software. A SSL certificate was obtained from Thawte, although the invention is not so limited to this embodiment. The certificate provides 128-bit encryption. Other bit amounts for encryption may be used depending on the embodiment and are within the scope of the invention.

[00115] FIG. 90 is an exemplary schematic block diagram depicting one embodiment of the system of the present invention. Shown in the figure is a server or central processor 100 which schematically represents a network, mainframe computer, server, website, or database. Server 100 is coupled to an institution computer, having a database 112, by a connection 111. For purposes of this description, the term "computer" shall refer to any type of processor, network, server, terminal, mainframe computer, and electronic device, regardless if it is wireless or wire connected. The database may be integral to or separate from the server, depending on the embodiment.

[00116] The server, in one implementation, down loads data profiles of potential ride share users enrolled. The profiles are kept in the institution database. After downloading into the server, the profiles are stored in a database of the central processor (not shown). The profiles include at least one of a surname, an address, a gender identifier, demographic information, personal preferences, and the like. Profiles can be continuously updated by an account user or an administrator. The processor utilizes the profile data to perform at least one application.

[00117] Connection 101 is for one embodiment a data link connected to an account user

102. Such a data link can alternatively be, but is not limited to, an electronic data link, optical fiber connection, wireless data connection or any other known connection used for data transfer, for example, over the Internet. Depending upon the implementation, connection 101 can operate in one or more modes of transmission. For example, such modes include radio frequency transmissions, optical transmission, microwave transmission, digital or analog transmission, or other known data transmission.

[00118] As shown in Fig. 90, an account user computer 101 utilized by an account user is also coupled to the server by the connection 101. The account user includes, for example, any user interested in ride sharing information. The account user has access to the applications stored in the server and is able to display the applications.

[00119] Similarly, as with connection 101, connections 103, 105, 107 and 109 can have various configurations depending upon the implementation. However, the connections need not be the same type, or bear any relation in type or mode, to a particular connection 101 employed in the present invention. For one embodiment, connection 101 is a data link. However, as with connection 101, it is within the scope of the invention to include all other types of communication links known.

[00120] Computers used by potential ride share account users are depicted as blocks 104,

106, 108. Three users are given merely as an example, and in no way limit the amount of ride share account users that can utilize the present invention. The potential ride share users are coupled to the server through connections 103, 105, and 107. An administrator having access to server 100 can monitor and discontinue communications from any account user. Updating the profiles stored in the database is also permitted by the system administrator.

[00121] Fig. 90 further depicts at least one third party vendor computer 110 coupled to the server by a connection 109. This third party vendor computer may or may not be integral with the server 100. In addition, this third party vendor computer may or may not be used with the present invention depending on the embodiment. The third party computer provides services and products to be offered through the server. Such services may include, but are not limited to, a third-party micro-payment system with which the present invention interacts. This third party allows the present invention, in one potential embodiment, to verify that each account user is "real", in the sense that each user can have access to credit directly, or through another person with credit.

[00122] The product and service offerings are made in both Intranet and Internet based communications. A third party utilizing the third party computer can monitor its product offering and edit the offerings as needed. All product and service offerings may be monitored and pre-approved. The system administrator also has the ability to limit the product and service offerings offered to the account users.

[00123] hi conclusion, while various examples have been shown and described employing the invention, it should be understood that the above description is only representative of illustrative embodiments. For the convenience of the reader, the above description has focused on a representative sample of all possible embodiments, a sample that teaches the principles of the invention. The description has not attempted to exhaustively enumerate all possible variations. That alternate embodiments may not have been presented for a specific portion of the invention, or that further undescribed alternate embodiments or other combinations of described portions maybe available, is not to be considered a disclaimer of those alternate embodiments. It can be appreciated that many of those undescribed embodiments are within the literal scope of the following claims, and others are equivalent.

Claims

What is claimed is:

1. A method for providing ride sharing information to a user's computer or network using a programmed computer and a communications link, said method comprising:

receiving a request from a user;

authorizing use for access of the user;

establishing a connection between the programmed computer and the user's computer;

receiving a response from the user's computer concerning personal preferences;

storing the response in a database;

matching the personal preferences of the user from the stored response to personal preferences from other user responses stored in the database;

generating ride share information containing the matched personal preferences;

sending ride share information to the user's computer in the appropriate format; and

sending confirmation and reminder information concerning the ride share information to the user in the appropriate format.

2. The method of claim 1 wherein the information includes data and software application resident at the user's computer.

3. The method of claim 1 further including sending user verification information in response to a log-on request from a device; and authenticating the user to permit access to a controller.

4. The method of claim 1 further includes providing for rating riders that travel on a ride.

5. The method of claim 4 further including the storage of rating information in the database for access by future riders.

6. The method of claim 1 , wherein the information provided includes availability of multiple riders.

7. A computerized system for providing ride share information, comprising:

a memory device; and

a processor disposed in communication with the memory device, the processor configured to: send user verification information in response to a log-on request, authenticate the user to permit access to a controller, receive personal preference information from the user, store the personal preference information in the memory device, match the personal preference information to personal preference information from other users, said personal preference information stored in the memory device, generate ride share information containing the matched personal preferences, and send the ride share information to the user.

8. A computerized system for providing ride share information, comprising:

means for sending user verification information in response to a log-on request,

means for authenticating the request to permit access to a controller,

means for receiving personal preference information from the user,

means for storing the personal preference information in a memory device, means for matching the personal preference information to personal preference information from other users, said personal preference information stored in the memory device,

means for generating ride share information containing the matched personal preferences,

means for sending the ride share information to the user in an appropriate format.

9. A computer readable medium for providing ride share information, comprising:

code for receiving a request from a user;

code for receiving personal preference information from the user;

code for storing the personal preference information from the user in a memory device;

code for matching the personal preference information to personal preference information from other users, said personal preference information stored in the memory device;

code for generating ride share information containing the matched personal preferences; and

code for sending ride share information.

10. The computer readable medium of claim 9 further including code for applying a rating system for riders.

11. The computer readable medium of claim 9 further including code for maintaining secure communication.

12. The computer readable medium of claim 9 further including code for tracking the history of rides posted and accepted.

13. A method for providing ride sharing information, which uses a computer program and links to establish and communicate with a network or user's computer, said method comprising:

receiving a request from a user searching for ride sharing information;

authorizing use for access of the user;

establishing a connection between the programmed computer and the network or user's computer;

receiving a response from the user's computer concerning personal preferences selected from the group consisting of:

an expense sharing arrangement, a nonsmoking or smoking preference, a drive sharing or non-sharing preference, a gender or mixed gender preference, departure time, pick-up and drop off points, music preferences, allergy concerns, disabilities, special needs, and any combination thereof;

storing the response that includes the personal preferences in a database;

determining ride share information for the user by using the personal preferences of the user from the stored response matched to personal preferences from other user responses stored in the database in accordance with a percentage threshold of possible matched personal preferences;

further determining ride share information by using a user selected quality rating of available previous ride sharing reviews of the other users that had matched personal preferences; generating ride share information containing the matched personal preferences and

selected quality review rating;

14. The method of claim 13 wherein ride share information is for a ground vehicle, aircraft, water vessel, or any combination thereof.

15. The method of claim 13 further includes displaying reviews of previous ride share ratings of other users in a searchable manner to allow the user to search for ride share information based on the previous ratings.

16. The method of claim 13 wherein the ride share determination further includes calculating radii about departure and destination points of the user based on user selected parameters.

17. The method of claim 13 further includes sending an alert to the user concerning specific ride requests later posted by other users that match the user's personal preferences.

18. The method of claim 13 further includes issuing a credit to the user if no ride sharing information is determined.

19. The method of claim 13 further including verifying a user's identity for security purposes.

20. The method of claim 13 further includes allowing the user to modify a ride listing at any time up until the ride listing is accepted by another user.