Method and system for conducting commerce over a wireless communication network

Abstract

Described herein is an enabling product that facilitates implementation of an m-commerce business solution. According to an embodiment of the present invention an m-commerce solution includes: a content provider or merchant site that provides products and goods to be purchased; a payment system allowing online authorization of funds to purchase the goods; and a wireless network for all customer interactions. Embodiments described herein perform at least one of the following three functions: 1) protocol conversions; 2) customer information reposing, and 3) payment authorization system interfacing.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method and system for conducting commerce over a wireless communication network. The present invention further relates to a system and method for using radio-based wireless devices such as cell phones and personal digital assistants to conduct business-to-business and business-to-consumer transactions over an electronic commerce system.

2. Description of Related Art

With the explosion of the Internet as a new indispensable worldwide medium, the web is becoming an integral part of our daily personal and working lives. Electronic commerce continues to see phenomenal growth, but so far most e-commerce developments have involved wired infrastructures.

In this new knowledge economy that puts increased demands on every individual's time, mobility will become an essential, relevant and important tool. While the Internet allows real-time communication and transactions, online accessibility has been restricted to PCs. With the advancement of wireless network technologies, electronic commerce through the Internet has extended itself to incorporate new business opportunities in the arena of mobile commerce (m-commerce).

In the field of m-commerce, there are significant restrictions on the efficiency and variety of m-commerce transactions that are available. Current technology is either limited to off-line payment or to restricted merchant specific on-line mobile payment through a mobile phone using a smart card, wherein the mobile phone must contain a dual slot smart card reader. Other m-commerce payment processes include dialing a premium rate number, e.g., 900-number, which has a call charge equivalent to the product price, dialing a prefix plus a premium rate number to indicate that the product should be charged to a different number for billing, and developing a pre-standing agreement for credit card payments, wherein a PIN has to be entered at the time of purchase to validate the user. These payment solutions offer no variety in payment methods and are limited to participating vendors, e.g., off-line vending machines. Further, m-commerce payment limitations affect mobile shopping, mobile retailing, and mobile ticketing. While electronic shopping, retailing, and ticketing have been available for some time, there are additional steps required to complete a mobile transaction. On-line mobile payments, shopping, retailing, ticketing, etc., require language recognition and or conversion in order to complete transactions with electronic merchants and payment authorization systems. Consequently, there is a need for a system and method of performing mobile commerce which facilitates interaction between mobile and electronic components which utilize differing protocols and languages.

BRIEF DESCRIPTION OF THE DRAWINGS

In the Figures:

FIG. 1 illustrates a mobile system according to an embodiment of the present invention;

FIG. 2 illustrates a first system and method for conducting mobile commerce according to an embodiment of the present invention;

FIGS. 3 a and 3b illustrate second and third systems for conducting mobile commerce according to embodiments of the present invention;

FIG. 4 illustrates a fourth system for conducting mobile commerce according to an embodiment of the present invention;

FIGS. 5 a-5b illustrate message formats according to an embodiment of the present invention;

FIGS. 6 a-6b illustrate message formats according to an embodiment of the present invention;

FIGS. 7 a-7b illustrate message formats according to an embodiment of the present invention;

FIG. 8 a-8b illustrate message formats according to an embodiment of the present invention;

FIG. 9 a-9b illustrate message formats according to an embodiment of the present invention;

FIG. 10 illustrates a fifth system for conducting mobile commerce according to an embodiment of the present invention;

FIG. 11 illustrates a sixth system for conducting mobile commerce according to an embodiment of the present invention; and

FIG. 12 illustrates a seventh system for conducting mobile commerce according to an embodiment of the present invention.

BRIEF SUMMARY OF THE INVENTION

The present invention is an enabling product that facilitates implementation of an m-commerce business solution. According to an embodiment of the present invention an m-commerce solution includes: a content provider or merchant site (e.g., an eMall, financial institution, etc.) (hereafter “merchant site”) providing the products and goods to be purchased; a payment system allowing online authorization of funds to purchase the goods; and a wireless network for all customer interactions. Preferred embodiments of the present invention perform at least one of the following three functions: 1) protocol conversions; 2) customer information reposing, and 3) payment authorization system interfacing.

The protocol conversion aspect of the present invention, according to at least one embodiment, converts content (e.g., messages) developed in one of a multitude of languages, such as, HTML (hyper text mark-up language), compact HTML (CHTML), or XML (extensible mark-up language) to an appropriate language for a receiving device, such as, Wireless Markup Language (WML), HDML (handheld device mark-up language or UP Browser), CHTML and vice versa. The customer information repository aspect of the present invention, according to at least one embodiment, contains various customer information such as a preferred shipping address; a list of credit cards, debit cards, and/or other payment vehicles, including, but not limited to, credit card types and card numbers that may be used for a purchase transaction; and a customer identifier, such as, a mobile device subscriber identification (“ID”) number.

The payment authorization system interface aspect of the present invention, according to one embodiment, provides interface logic with a payment authorization system to facilitate the authorization of a commerce transaction.

More particularly, an embodiment of the present invention is directed to a mobile commerce system that comprises at least one mobile device for transmitting and receiving data in a first language, a platform for transmitting and receiving data in the first language and data in a second language, at least one merchant site for transmitting and receiving data in the second language, and a payment authorization system for transmitting and receiving data in the second language.

Another embodiment of the present invention includes a method for conducting mobile commerce. This method comprises: transmitting in a first language a request message for merchant website information from a mobile device; receiving the request message in the first language at a platform and identifying the first language; translating the request message at the platform from the first language to a second language that is recognizable by a merchant website; communicating the translated request message in the second language from the platform to the merchant website; receiving at the platform the requested merchant website information from the merchant website in the second language; recognizing the second language at the platform; parsing the requested merchant website information in the second language into translatable pieces; translating the translatable pieces of the requested website information into the first language so as to form a reply message containing the requested merchant website information in the first language; and transmitting the reply message to the mobile device.

These and other aspects and embodiments of the present invention are set forth below with details.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS OF THE PRESENT INVENTION

For purposes of this disclosure, the terms mobile commerce (m-commerce), mobile electronic commerce, and wireless electronic commerce may be used interchangeably. The term m-commerce represents a subset of all e-commerce transactions, both in the business-to-business (B2B) and the business-to-consumer (B2C) area.

The present invention provides a mobile system for facilitating mobile commerce among multiple parties. In the preferred embodiments of the present invention, the mobile system performs at least one, and preferably all three of the following three functions: 1) protocol conversions; 2) customer information reposing, and 3) payment authorization system interfacing. The mobile system achieves these functions using at least one of the following components: a state manager; parsing agents for parsing e.g., XML and HTML; translation agents for translating to and from e.g., WAP, CHTML and HDML; communication agents for communicating between e.g., HTTP (HyperText Transfer Protocol) and HTTPS (Secure HyperText Transfer Protocol); server and database configurations; and settlement systems.

In facilitating protocol conversions, the mobile system enables the delivery of a single sourced web content to a wide range of wireless devices or mobile devices (hereafter “mobile devices”) and vice versa. The mobile system is capable of presenting a transmission from a mobile device to participating Web servers as a standard Web client, thus performing a gateway/protocol conversion function between a mobile device and a merchant site or sites. To accomplish this, the mobile system allows users of mobile devices to communicate through the web with merchant site applications running on web servers using, for example, HTTP or HTTPS protocols. According to the embodiments of the present invention, the mobile system dynamically performs the required translation between the merchant site webpages encoded in, for example, HTML, CHTML, XHTML or XML to WML, CHTML or HDML for the mobile device.

According to further embodiments of the present invention, the mobile system also manages the state and associated context information between the merchant site and the associated mobile device(s). This information includes, for example, HTTP session state, cookies, links and/or universal resource locators (URLs) referenced during the session and control information for each HTML page. As most mobile devices currently do not support cookies, the mobile system manages the persistent store associated with each cookie on behalf of the mobile device.

According to embodiments of the present invention, the mobile system is integratable with existing merchant sites, such as, an eMall for m-commerce applications or Citibank Direct Access in the case of banking transactions. The merchant site operations experience very little interruption. For example, the merchant sites continue to receive and transmit HTTP and HTTPS messages for incoming requests and continue to dictate screen flow.

As described further below, the mobile system offers a scalable architecture, allowing concurrent access by mobile users to HTTP and HTTPS pages served on merchant sites. In an embodiment of the present invention, the scalable architecture is developed on Windows 2000 using COM+ services and at least one Microsoft SQL Server in order to support high numbers of concurrent mobile users on a single server, and includes the ability to add more servers as business requirements dictate. The mobile system can use standards such as COM (Component Object Model), SSL (Secure Sockets Layer), HTTP, WAP, HDML, CHTML, XML and HTML. Using SSL communications, every transmission between the client and the server is encrypted.

Referring to FIG. 1, the component architecture of a mobile system 10 includes the state manager 15 which is responsible for creating and coordinating activities among the translation agents 20, the parsing agents 25 and communication agents 30. The communication agent is the last component of the architecture prior to the merchant site 40. Additionally, all state information, such as session states, cookies, mobile identifications, links and control information on each HTML page is stored in a relational database 35 for ease of access and manipulation by the state manager 15.

In order to perform merchant site format translation to mobile device format, the mobile system insures that all communication between the merchant site and the mobile device occurs through the mobile system architecture. Using the mobile system's link/URL management feature, this is insured by dynamically converting all Hyperlink (Href) information on the page published by the merchant site to the URL (universal resource locator) of the mobile system (e.g., URL of the company offering the services of the mobile system). The mobile system saves the original, unconverted URLs within a relational database 35. In this manner, all user interaction from the mobile device is intercepted and interpreted by the mobile system prior to being forwarded to the merchant site.

In another feature of the present invention, since most mobile devices currently do not provide support for cookies, the state manager component manages the persistent store associated with each cookie on behalf of the mobile device. For instance, if the target HTML page on the merchant site writes a cookie, that cookie is stored on the mobile system on behalf of the mobile device and is returned only when the response is posted to the appropriate merchant site. The mobile system's cookie management insures integrity of the cookies by insuring proper domain association as well as lifetime expectancy.

The parsing agents 25 of FIG. 1, are responsible for parsing the webpage on the target merchant site 40. The supported encoding are web-based mixed text and image languages, such as, HTML and XML. The parsing agent 25 parses the entire webpage and effectively builds a document tree according to the supported tags, such as those listed in the Table below for HTML and XML. Translation agents 20 use a set of rules to determine the best way to render webpages generated by a merchant site 40 on a mobile device screen. Translation agents 20 emulate an HTML session and provide equivalent translation to the respective mobile device format (e.g., CHTML, WML or HDML) based on individual language syntax. Finally, communication agents 30 are responsible for communication with the merchant site 40. Supported agents are HTTP and HTTPS. The communication agent establishes and monitors connections and manages time outs. The following state table contains an exemplary list of all supported HTML and XML tags and the attributes associated therewith by the mobile system. This table also describes the associated support for each translator type as currently implemented.

TABLE 1
		Attributes
Tag Name	Name	supported	WAP	HDML	Imode	Comments
A	Anchor	Href				All Translators also support the
						“Tel” attribute to allow the
						mobile device to initiate a
						voice call.
B	Bold
BR	Break
BODY	Body					All Translators: This tag is a
						non-operational (“NOP”).
FRAME	Frame					Imode Translator: This tag is
						a “NOP”.
						The <FRAME> tag is newly
						introduced tag for the invented
						mobile system to handle
						encapsulation of unit of UI
						representation on a mobile
						device (e.g.
						HDML/WMLCard)
CENTER	Center
DIV	Division					All Translators: Treat “DIV”
						tag as a “P” tag.
FORM	Form	Name,
		Action
HEAD	Header					All Translators: This tag is a
						“NOP”.
H1	Heading 1					WAP and HDML
						Translators: This tag is a
						“NOP”.
H2	Heading 2					WAP and HDML
						Translators: This tag is a
						“NOP”.
H3	Heading 3					WAP and HDML
						Translators: This tag is a
						“NOP”.
H4	Heading 4					WAP and HDML
						Translators: This tag is a
						“NOP”.
H5	Heading 5					WAP and HDML
						Translators: This tag is a
						“NOP”.
H6	Heading 6					WAP and HDML
						Translators: This tag is a
						“NOP”.
HR	Horizontal	Align				WAP and HDML
	Rule					Translators: This tag is a
						“NOP”.
HTML	Html					All Translators: This tag is a
						“NOP”.
IMG	Image	Align,
		Src
INPUT	Input	Name,				WAP and HDML
		Type,				Translators: Only support
		Value				“text”, “password”, “hidden”
						and “submit” types.
Option	Option	Value,
		Selected
P	Paragraph	Align,				HDML Translator: Only
		Mode				supports “nowrap” mode. All
						other attributes are ignored.
Pre	Preformatted
Select	Select	Name,
		Default
TextArea	Text Area	Name,				WAP and HDML
		Rows,				Translators: Handles as an
		Cols				Input tag with Rows attribute
						of “Text” and no support for
						“Cols” attribute.
Title	Title

According to an embodiment of the present invention, an exemplary interaction between a merchant site and a mobile device through the mobile system for displaying a single webpage is as follows. Referring to FIG. 2, initially, a user or customer (hereafter “customer”) hits the mobile systems URL using the customer's web enabled mobile device 45. This request is delivered to the phone gateway 50 and the Active Server Page (“ASP”) component 55, S1 of the mobile system 10 which performs an HTTP post to the state manager 15 within the mobile system S2. The HTTP post includes the type of mobile device 45 communicating with the mobile system 10, particularly, the language used in the communication, e.g., CHTML, WML or HDML and, if available, a mobile identification number. The state manager component 15 engages the appropriate translation agent 20 based on the type of mobile device identified S3. If existent already, the state manager 15 restores all session information from the persistent store through the relational database 35 on behalf of the identified mobile device through a received mobile identification number 45, S4. If not already existing in the relational databases 35, session information is saved therein, including a mobile identification number for the device S4. The session information includes session state, cookies, links and other control information. By way of example, session information is utilized in a situation wherein the interaction between the mobile device 45 and the merchant site 40 is a continuation of an existing interaction (e.g., an ongoing Direct Access customer session), such that previous session information exists for of the mobile device 45.

After retrieving the session information, the state manager 15 engages the communication agent 30, S5. An HTTP or HTTPS Post is performed to the merchant site 40 based on existing link (e.g., HREF) information in the state tables (See Table 1) S6. The merchant site webpage response is returned to the communication agent S7. Based on the webpage content, the communication agent 30 determines the encoding thereof, e.g., HTML or XML, and engages through the state manager 15, the appropriate parsing agent 25 to parse the response S8a, S8b. For each item parsed in the merchant site webpage, the parsing agent 25, in conjunction with the translation agent 20, dynamically performs the associated translation to the predetermined mobile device format S9. This step is repeated until the entire merchant site webpage has been parsed and translated to the predetermined mobile device format. For example, from HTML to WML for a WAP mobile device. All session information is saved to the persistent store, i.e., relational database, on behalf of this mobile device under a mobile device ID (e.g., alphanumeric identifier) S10. As described above with reference to S3, this session information is later retrievable during the next interaction between the mobile device 45 and the merchant site 40. The translated response is returned to the ASP thread S11 through an HTTP response and on to the mobile device 45 through the phone gateway 50, S12.

Referring to FIGS. 3a and 3b, network architectures for deployment of the mobile system according to embodiments of the present invention are illustrated. Examples of the various telephone networks and associated gateway infrastructure have also been included in FIGS. 3a and 3b. In FIG. 3a, the network architecture includes at least one server 60 which contains, for example, the state manager component and the parsing, communication, and translation agents (see FIGS. 1 and 2). In this particular embodiment of the present invention, the server 60 is located in the DMZ (“Demilitarized Zone”) so that the company hosting the mobile system can do so without sacrificing unauthorized access to the company's private network. The DMZ sits between the Internet and an internal network's line of defense which is usually some combination of firewalls and bastion hosts. The persistent data store, i.e., relational database 35, resides on an SQL server 65 which is inside a firewall and on a private network, such as a GRN (“Global Routed Network”). FIG. 3a also illustrates examples of three different telephone gateways 50a, 50b, and 50c through which mobile devices 45a, 45b, and 45c communicate with the mobile system and ultimately with the merchant sites 40a, 40b, and 40c. By way of example, telephone gateway 50a is a Imode network, 50b is a WAP gateway and 50c is an HDML gateway.

FIG. 3 b illustrates the enhanced scalability available with the mobile system of the present invention. Although the mobile system is capable of handling a high number of concurrent mobile users 45a-45c on a single server, the mobile system includes the ability to add more servers as business requirements dictate. This enhanced scalability is optimized through the use of services such as, Microsoft's COM+services. The mobile system supports a multi-tiered architecture, separating the application logic and data components. This allows for greater scalability based on the projected requirements. In FIG. 3b a farm of servers including servers 60a and 60b is created to support high concurrent volume requirements. The system data is committed to persistent store on SQL servers 65a and 65b, which can be expanded to a cluster of SQL servers 70 through replication to support high concurrent volumes. High availability can be addressed similar to the manner outlined above, where either of several servers 60a and 60b can perform the necessary processing on behalf of a mobile device 45a-45c. Replication of SQL servers 65a and 65b also allows for higher availability of data in the event that one SQL server 65a or 65b is inaccessible.

According to an embodiment of the present invention, the mobile system is designed to provide hosting support for multiple entities (e.g., businesses) within the company providing the mobile system, while utilizing the same physical hardware. For example, hosting multiple mobile system URLs on the same physical server provides the foundation for this capability. The persistent store associated with each business within the company is preserved in different database tables and is indexed by the ID of the current entity being serviced for each mobile device interaction.

Referring to FIG. 4, the architecture associated with the multi-entity hosting mobile system and the process for using the multi-entity mobile system are illustrated. Initially, a user or customer (hereafter “customer”) hits the mobile systems URL using the customer's web enabled mobile device 45a, 45b. In FIG. 4, there are two mobile system URLs, illustrating the ability of the mobile system to handle the needs of two separate entities. This request is delivered to a phone gateway 50a, 50b and then HTTP Posts to the ASP components 55a and 55b of the mobile system are performed S20. The type of mobile device communicating with the mobile system 10, more particularly, the language used in the communication, e.g., CHTML, WML or HDML, is identified to the mobile system S21. Further, within this step, a business identification (ID) associated with the URL is identified and passed on to the mobile system as a parameter that is considered during all processing of messages involving the business ID. The state manager component 15 engages the appropriate translation agent 20 based on the type of mobile device 45a, 45b identified S22. If existent, the state manager 15 restores all session information from the persistent store through the appropriate relational database 35a, 35b on behalf of the identified mobile device and business ID S23. The session information includes session state, cookies, links and other control information. In a particular embodiment, session information is utilized in a situation wherein the interaction between mobile device 45a, 45b and merchant site 40 is a continuation of an existing interaction (i.e. an ongoing direct access customer session), such that previous session information exists for of the mobile device 45a, 45b.

After retrieving the session information, the state manager 15 engages the communication agent 30, S24. An HTTP or HTTPS Post is performed to the merchant site 40 based on existing link (HREF) information in the state tables (See Table 1) S25. The merchant site response (e.g., Webpage) is returned to the communication agent S26. Based on the response content, the communication agent 30 determines the encoding thereof, e.g., HTML or XML, and engages through the state manager 15, the appropriate parsing agent 25 to parse the response S27a, S27b. For each item parsed in the response, the parsing agent 25, in conjunction with the translation agent 20, dynamically performs the associated translation to the predetermined mobile device format S28. This step is repeated until the entire response has been parsed and translated to the predetermined mobile device format. For example, from HTML to WML for a WAP mobile device. All session information is saved to the appropriate persistent store, i.e., relational database 35a, 35b, on behalf of this mobile device using the mobile device identification number for the business ID S29. As described above with reference to S22, this session information is later retrievable during the next interaction between the mobile device 45a, 45b and the merchant site 40. The translated response is returned to the ASP thread S30 through an HTTP response and on to the mobile device 45a, 45b through the phone gateway 50a, 50b, S31.

As described generally above with reference to the mobile system components, protocol converters are used within the mobile system in order to reformat received content or messages (hereafter “messages”). The reformatted messages can then be sent from and to different types of mobile devices. This enables content providers to deliver a single marked-up message to a wide range of wireless devices. The phrase “mobile device” is not intended to be limited to telephones, but rather this phrase encompasses all mobile or portable communication devices which communicate over wireless phone lines. The protocol converter converts website messages (e.g., from merchants) to a specific mobile device message format and vice versa. The protocol converter converts, by way of non-limiting example, content developed in HTML, Compact HTML, or XML to Wireless Markup Language (WML), HDML (UP Browser), CHTML or Imode. Any source message, e.g., message received, can be converted to any of the possible target message formats, target messages being the messages that are being sent.

In a first protocol conversion example, existing source HTML messages are initially reformatted in order to support XML specifications. Referring to FIGS. 5a and 5b, an exemplary HTML message in its source format FIG. 5a and its counterpart viewable browser format FIG. 5b, prior to reformatting are illustrated. These formats cannot be read and understood by a mobile device. In an embodiment of the present invention, existing source HTML as shown in FIGS. 5a and 5b, is modified from the source HTML shown in FIG. 6a, to the modified HTML shown in 6b by the merchant site in order to support the XML tags which identify the message to the mobile system. In an exemplary embodiment, a mobile system includes a <script TYPE=“MOBILE”> tag and <card> tag, wherein the body of code encapsulated within the <script> tag is only interpreted by the mobile system of the present invention. The body of code encapsulated within a <card> tag represents to the mobile system that the message represents a single user interaction on a mobile device. Once the message is recognized and read by the mobile system, the mobile system is able to convert the code so that the message contents can be recognized and read by the mobile device to which the message is directed. FIGS. 7a and 7b show the pre-conversion HTML/XML language from FIG. 6b and the post-conversion HDML language as converted by the mobile system. Similarly, FIGS. 8a and 8b show the pre-conversion HTML/XML language from FIG. 6b and the post-conversion WML language as converted by the mobile system and FIGS. 9a and 9b show the pre-conversion HTML/XML language from FIG. 6b and the post-conversion CHTML language as converted by the mobile system. These embodiments are intended to be merely exemplary and non-limiting. One skilled in the art recognizes the multiple language conversions that may be performed as dictated only by the receiving language of the mobile device. Other conversion embodiments are contemplated by this invention and are incorporated herein by reference as they are known and understood by those skilled in the art.

The customer information repository is stored and provided in order to minimize the amount of input that a customer has to enter while conducting an m-commerce transaction. Minimizing the amount of customer input increases the speed and simplicity of m-commerce transactions, which is very much in keeping with the fundamental idea of mobile commerce. In addition, wireless phone devices are not generally equipped with a robust keypad interface. Therefore, it is important to minimize the amount of information collected from a customer during a transaction. The information stored within the customer information repository, includes, but is not limited to, billing addresses, shipping addresses, a list of credit cards or payment vehicles that may be used for a purchase transaction and a mobile device subscriber ID. The information is gathered during one of multiple m-commerce service registration processes that are available. For example, the information can be gathered during the customer self-registration process through a web site facility or via staff-assisted registration. Alternatively, customer registration may be accomplished via a batch facility wherein a batch file containing registration information for all customers is updated and accessed. The information is linked to the customers mobile device ID (e.g., number, alphanumeric) so at a later time when the customer chooses to make a transaction, the system of the present invention is able to access the customers' personal information. Instead of requiring, for example, a customer to enter the credit card number of the credit card they would like to use during a transaction, the system will prompt the customer to choose which of their pre-registered credit cards they would like to use. Additional required customer enrollment fields can be added based on individual business requirements.

Payment gateways or settlement systems are provided to manage the interface with the payment authorization systems. The payment gateway generates payment authorization requests to the payment engine and then returns the results of the authorization request to the merchant for order fulfillment. The present invention can support a variety of interfaces to the payment authorization system, including, but not limited to, an HTTP(s) post to a secure website payment system or a Microsoft COM-based interface to an ECS payment engine and the CitiConnect system used by, for example, the Global Cash and Trade organization.

Additionally, the mobile system of the present invention may be integrated and can co-reside in business installations with other m-commerce related services, such as the financial transaction and event notification systems (hereinafter “notification system”) described in U.S. patent application Ser. No. 09/832,863, entitled “METHOD AND SYSTEM FOR NOTIFYING CUSTOMERS OF TRANSACTION OPPORTUNITIES” the entirety of which is incorporated herein by reference. The notification system, in conjunction with the mobile system, provide, by way of example, the following additional services: specific account notifications, such as past-due-date reminders, overdrafts, credit limits, specific credit charges (e.g., single amount charges, location charges), credit fraud warnings (e.g., based on unfamiliar pattern of charges, location of charges, amount of charges) direct deposits (e.g., of salary, dividend, etc.), balance, credit card due dates, automatic bill payments, check clearing alert and ATM withdrawals; shipment of goods notification; stock price notifications, and the like. This list is not intended to be exhaustive, but merely exemplary.

The following embodiments of the present invention disclose non-limiting specific, exemplary configurations of the present invention which incorporate some or all of the various aspects of the invention described above.

Referring to FIG. 10, a specific embodiment of the present invention provides an m-commerce solution by allowing a customer to purchase a venue ticket such as a concert or sporting event using a WAP enabled phone. For purposes of this particular embodiment, the merchant site is the Ticket Pro WML merchant site while an existing payment authorization system, e.g., JuicePay, performs the payment authorization.

Further to this embodiment, the WAP enabled phone 45, communicates directly with a telephone company, i.e., the wireless carrier who offers the service, which we refer to herein as a phone gateway 50. In this embodiment, the phone gateway 50 is comprised of a Short Message Service Controller (SMSC) 47, a WAP gateway 48, and a specialty server (i.e., BMG server) 49. Data information is carried over the airwaves via, for example, a GSM (Global System for Mobile Communications) network 46, which uses narrowband time division multiple access (TDMA), allowing eight simultaneous calls on the same radio frequency. In a first information configuration of this particular embodiment, data information is collected from the WAP phone 45 by the phone gateway 50 which is connected to the mobile system 10. The data information is communicated between the phone gateway and the mobile system via at least one of a group of first line networks 51 including, leased lines, dial-up, and Internet which support TCP/IP (Transmission Control Protocol/Internet Protocol), HTTP, WML, etc.

The mobile system 10 communicates with both merchant sites 40 and payment gateways 75 through at least one of a group of second line networks 61 including, but not limited to, dial-up and Internet which support TCP/IP, HTTPS, HTML and XML. By way of example, the merchant, Ticket Pro, maintains an inventory of concerts and sporting events, as well as, seating arrangements, costs, etc. The mobile system 10 is in electronic communication with the Ticket Pro website either directly, or through a merchant webpage provider such as eMall 40. In this particular embodiment, the messages provided by the eMall are formatted so as to be recognized and read by the phone authorization system and consequently, the WAP phone 45, without the need for any type of protocol conversion by the mobile system 10. As discussed further herein, in alternative embodiments of the present invention, there is a need for protocol conversion by the mobile system in order to facilitate communication between the merchant site and the mobile device.

Further to the embodiment illustrated in FIG. 10, the payment authorization system 75, E-pay (also known as “Juicepay”), is in electronic communication with both the mobile system 10 and the merchant site 40. The payment authorization system 75 determines what types of payment vehicles may be used by a customer to complete m-commerce transactions. The types of payment vehicles (e.g., debit cards, credit cards, financial accounts) available to customers is dependent on the ability of the payment authorization system to authorize transactions from those payment vehicles. The mobile system 10 communicates the payment vehicle information to the payment authorization system 75 for authorization, and returns a confirmation notice (i.e. whether the transaction was approved or denied) to the customer via the customer's mobile device 45.

Another aspect of the embodiment illustrated in FIG. 10, is the ability to interface simultaneously with a notification system 90, such as that described above with reference to U.S. patent application Ser. No. 09/832,863. Having the ability to simultaneously make m-commerce purchases and receive financial event notifications, allows a customer to have immediate, pre-requested information regarding accounts either as a result of, in conjunction with, or in addition to the m-commerce transaction. As a specific example, a customer using the system of FIG. 10, who has set up a virtual credit card (i.e., a payment vehicle linked to a bank account) that maintains a minimum balance of funds, is alerted by the notification system when an m-commerce purchase facilitated through the mobile system resulted in additional money been added to the virtual credit card in order to maintain the minimum balance. The messages received by the customer from the notification system are routed through the BMG server 48 and the SMSC 47 to the customer's mobile device. SMSC utilizes short message service (SMS) to transmit short text messages to and from a mobile device, fax machine and/or IP address. These particular SMS messages are no longer than approximately 160 alpha-numeric characters and contain no images or graphics. In alternative embodiments, other messaging services and protocols are supported in conjunction with the notification system such as application program interfaces and e-mail. In this embodiment, the mobile system 10 and the notification system 90 are part of the same enabling platform 5. This enabling platform 5 is managed by the same host (e.g., financial institution).

According to this particular embodiment of the invention, customers register with an account set-up and maintenance portion of the payment authorization system 76 in order to access the m-commerce configuration. Similarly, customers register directly with the notification system 90 in order to participate in the alert portion of the enabling platform 5. Registration is performed online, e.g., over the Internet 80 via a personal computer 85 or other acceptable device. During this registration process, the customer repository information, described above, is obtained and stored in a relational database of the mobile system 10.

In yet a further aspect of the embodiment illustrated in FIG. 10, the enabling platform 5 also includes a settlement service 95 for facilitating settlement with the payment authorization system 75. The settlement service 95 manages the interface between the payment authorization system and the enabling platform 5. Referred to as “embedded settlement,” the settlement service 95 is integrated directly with the software that powers the marketplace to provide seamless payment and settlement capabilities. The settlement service 95 operates in conjunction with the enabling platform 5 and the payment authorization system 75 in order to settle the transaction. Through, for example, a batch feed process, push account and bill notification information is directed through the settlement service 95 in order to complete the entire transaction online, thereby reducing transaction costs and labor requirements.

The settlement system employs, for example, Secure Socket Layer (SSL) technology with standard Public Key Infrastructure (PKI) and digital signatures for each message exchange, providing a highly secure transaction processing environment. A user registers with the settlement service 95 prior to conducting m-commerce transactions. Registration may be provided through the payment authorization system 75. As discussed further below, the payment authorization system 75 and the settlement service 95 may be provided by the same host (e.g., Citibank) or as in this embodiment, these services may be offered by different hosts, but are linked for the purposes of the m-commerce transactions described herein. Depending on the payment authorization system configuration 75, the messages communicated between the payment authorization system 75 and the settlement system 95 are formatted differently. For example, in this embodiment and the embodiment described below with reference to FIG. 12, the messages are formatted as an HTTPS post. Alternatively, the messages in the embodiment illustrated in FIG. 11 are formatted using, for example, the IBM MQ Series.

Referring to FIG. 11, an alternative embodiment of the present invention provides an m-commerce solution that allows customers to purchase various household items using at least one of multiple mobile device languages. In this particular embodiment, the mobile devices supported are WAP and CHTML enabled phones 45a-45c. Further to this embodiment, the merchant site 40 is the Fujitsu eMall (also know as the “Daiei eMall”) site and the payment authorization system 75 for payment authorizations is Enhanced Card System (ECS).

In this particular embodiment, at least three different phone companies, each of which uses a different language for its customers, are utilized. Further, while the entire implementation, including information from all three phone companies, could be accomplished using one mobile system server 60 (see FIG. 3a), three separate servers 60a-60c are used for added security. Data from the mobile devices 45a-45c is captured by the respective phone gateway 50a-50c and then routed to the appropriate mobile system server 60a-60c. The phone gateways 50a-50c may be selected from any one of many companies offering mobile device services. For example, in Japan, companies include DDI, JPhone, Imode, and DoCoMo. As described above, the mobile system servers 60a-60c translate the data coming from the mobile devices 45a-45c into a language that is understandable by the merchant site 40 and then retrieve the customer requested information from the merchant site 40. As stated above, in this particular embodiment, the merchant site is actually a merchant webpage provider, also known as an eMall. Similar to the traditional shopping mall, an eMall is a grouping of many online vendors on one site. The eMall 40 may require supporting hardware, such as server 66. The servers 60a-60c perform the necessary protocol conversion on the information from the merchant site 40 and send that information to the customer's mobile device. Since a separate server 60a-60c is used for each phone gateway 50a-50c, the appropriate server anticipates which wireless protocol language to expect from the phone gateway and the appropriate protocol conversion required.

As previously discussed, the embodiment described with reference to FIG. 11 is configurable using only a single server for all phone gateways. In this alternative embodiment, each phone gateway has a separate IP (“Internet Protocol”) address on the single server. Thus, when incoming data is sent to the single server from the phone gateway each separate protocol has a different starting point on the single server so that the single server knows the appropriate conversion protocol required for each phone gateway.

Further, with respect to FIG. 11, when the customer is prepared to make a purchase from the merchant site 40, the payment information is sent to the payment gateway 75 for authorization. Confirmation from the payment authorization system 75 is then sent back to the customer's mobile device 45. Confirmation is also sent to the merchant site 40 for order fulfillment. FIG. 11 illustrates additional hardware and services, such as, an NT server 62 and a credit card processing service (e.g., Daiei OMC) 63, which are useful in facilitating payment authorization. As in the embodiment described with respect to FIG. 10, this embodiment also includes the optional settlement service 95 described above. Repository information in this configuration is held on an SQL server 65 (i.e. relational database server) that is connected to both the servers 60a-60c and, optionally, the notification system 90. In this embodiment, the notification system 90 communicates with the SQL server 65 in order to provide and update customer repository information. The notification system of the current embodiment utilizes a SMTP (Simple Mail Transfer Protocol) server 67, separate from servers 60a-60c and 65 in order to facilitate wireless notifications to the customer's mobile device 45a-45c via network 100. One skilled on the art recognizes the various server configurations which could be used to facilitate the data transfers and manipulations described herein. This specification incorporates by reference the knowledge of one skilled in the art.

In the embodiments described above, because all the wireless protocols being used are not considered secure, leased lines may be used, where available, so that data coming from each of the phone gateways is encrypted. In these configurations, the servers 60a-60c decrypt all incoming data before performing the appropriate protocol conversion and encrypt all outgoing data after performing the appropriate protocol conversion. Any encryption technique known to one of skill in the art may be used, including but not limited to, secure socket layer (SSL) or public/private key (PKI) encryption.

Referring to FIG. 12, in still another embodiment of the present invention, an m-commerce solution provides customers with rapid transactional capabilities (i.e., bill payment, transfer, account information, etc.) through the customer's mobile device 45 via the host of the mobile system. In the previous embodiments, the payment authorization systems and the host of the mobile system are separate entities. Referring to FIG. 12, the payment authorization system 75 is part of the mobile system 10 and consequently, as with the notification system 90, these are part of an enabling platform 5 which is managed by a single host (e.g., Citibank). The interoperation of the components of FIG. 12 is similar to that described with reference to FIG. 10. By using the protocol conversion aspect of the present invention, customers can have direct access to transactional information already available on the Internet.

The embodiments described herein are exemplary of the inventive concept set forth, said examples including the best mode of practicing the inventive concept. This disclosure is in no way intended to be limiting. One skilled in the art recognizes the various other embodiments that fall within the scope of the invention and though not explicitly recited herein, are in fact covered by this disclosure.

Claims

1. A method for conducting mobile commerce comprising: transmitting in a first language a request message for merchant website information from a mobile device;receiving the request message in the first language at a platform and identifying the first language;translating the request message at the platform from the first language to a second language that is recognizable by a merchant website;communicating the translated request message in the second language from the platform to the merchant website;receiving at the platform the requested merchant website information from the merchant website in the second language;recognizing the second language at the platform;parsing the requested merchant website information in the second language into translatable pieces;translating the translatable pieces of the requested website information into the first language so as to form a reply message containing the requested merchant website information in the first language; andtransmitting the reply message to the mobile device;transmitting a purchase request in response to the reply message in a first language to the platform;receiving the purchase request in the first language at a platform and identifying the first language;translating the purchase request at the platform from the first language to a second language that is recognizable by the merchant website;communicating the translated purchase request in the second language from the platform to the merchant website;receiving at the platform a purchase request response from the merchant website in the second language, wherein the purchase request response includes a payment authorization request;forwarding the purchase request response in the second language from the platform to a payment authorization system for a payment authorization response;receiving at the platform, the purchase request response, including the payment authorization response, in the second language from the payment authorization system;parsing the purchase request response in the second language into translatable pieces;translating the translatable pieces of the purchase request response into the first language so as to form a purchase request response in the first language; andtransmitting the purchase request response in the first language to the mobile device.

2. The method according to claim 1, wherein the first language is a wireless language.

3. The method according to claim 2, wherein the wireless language is selected from the group consisting of wireless markup language (WML), handheld device mark-up language (HDML), Imode, and compact hypertext markup language (CHTML).

4. The method according to claim 1, wherein the second language is a web-based language.

5. The method according to claim 4, wherein the web-based language is selected from the group consisting of extensible markup language (XML), compact hypertext markup language (CHTML), extensible hypertext markup language (XHTML), and hypertext markup language (HTML).

6. A system for conducting mobile commerce comprising: means for transmitting in a first language a request message for merchant website information from a mobile device;means for receiving the request message in the first language at a platform and identifying the first language;means for translating the request message at the platform from the first language to a second language that is recognizable by a merchant website;means for communicating the translated request message in the second language from the platform to the merchant website;means for receiving at the platform the requested merchant website information from the merchant website in the second language;means for recognizing the second language at the platform;means for parsing the requested merchant website information in the second language into translatable pieces;means for translating the translatable pieces of the requested website information into the first language so as to form a reply message containing the requested merchant website information in the first language; andmeans for transmitting the reply message to the mobile device;means for transmitting a purchase request in response to the reply message in a first language to the platform;means for receiving the purchase request in the first language at a platform and identifying the first language;means for translating the purchase request at the platform from the first language to a second language that is recognizable by the merchant website;means for communicating the translated purchase request in the second language from the platform to the merchant website;means for receiving at the platform a purchase request response from the merchant website in the second language, wherein the purchase request response includes a payment authorization request;means for forwarding the purchase request response in the second language from the platform to a payment authorization system for a payment authorization response;means for receiving at the platform, the purchase request response,including the payment authorization response, in the second language from the payment authorization system;means for parsing the purchase request response in the second language into translatable pieces;means for translating the translatable pieces of the purchase request response into the first language so as to form a purchase request response in the first language; andmeans for transmitting the purchase request response in the first language to the mobile device.