METHOD AND APPARATUS FOR REACHING SMALL MARKETS WITH A CULTURE SPECIFIC ON-LINE COMMERCE SERVICE

Abstract

A method is described that comprises providing a cultural specific on-line commerce experience for an end user by translating an action of the end user into a standard format used by an on-line auctioneer and by causing the translated action to be sent over a network. The action is taken through a cultural specific end user interface. The standard format is used by an on-line commerce service's back end application software to recognize end user actions originating from experiences that include the cultural specific on-line experience as well as experiences other than the cultural specific on-line experience. The action that is translated into the standard format is to be sent into a network so that it can be received by the on-line commerce service's back-end resources and recognized by the back-end application software.

Description

This application is a continuation of U.S. application Ser. No. 10/741,092 filed Dec. 19, 2003, entitled, “METHOD AND APPARATUS FOR REACHING SMALL MARKETS WITH A CULTURE SPECIFIC ON-LINE COMMERCE SERVICE,” which claims the priority benefit of PCT Application No. PCT/US03/31735 filed Oct. 6, 2003, which applications are incorporated in their entirety herein by reference.

FIELD OF INVENTION

The field of invention relates generally to on-line commerce; and, more specifically, to a method and apparatus for reaching small markets with a culture specific on-line commerce service.

BACKGROUND OF THE INVENTION

FIG. 1 illustrates a prior art on-line commerce service architecture in which the principle manner of commerce is auctioning. According to the architecture of FIG. 1, the on-line auctioneer provides the ability for an individual to list an item for sale on the Internet 103; and, for those having interest in purchasing the listed item, the ability to submit a bid for the listed item over the Internet 103. The on-line auctioneer further resolves multiple bids for a same item and determines which bidding party is deemed to be the purchaser of the item. The application software of the on-line auctioneer that is responsible for listing the items to be sold and determining the winning bid for each listed item can be viewed as part of the on-line auctioneer's Information Science (IS) resources 109. Such IS resources are often referred to as the on-line auctioneer's “back-end” resources.

Because of the high volume of both listed items and submitted bids that is achievable through the Internet 103, the on-line auctioneer's back-end resources 109 are apt to include clusters of high performance computing systems (e.g., mainframes and/or workstations). By contrast the equipment 110 used by an end-user 101 (e.g., an individual who lists an item to be sold and/or submits bids for a listed item) is apt to be lower performance computing system (e.g., a personal computer (PC), notebook/laptop, or handheld device). The prior art mechanics of the communications that take place between the end-user 101, the end-user's equipment 110 and the on-line auctioneer's IS resources 109 are depicted in the architecture of FIG. 1.

According to the depiction of FIG. 1, the end-user makes keystrokes and mouse clicks (or the equivalent thereof) that are interpreted by an end user interface 102. In a typical approach, the end user interface 102 is a modest software routine that is downloaded to the end user's equipment 110 over the Internet 103 by the on-line auctioneer's IS resources 109 in response to the end-user 101 having made an HTTP request to the on-line auctioneer's home page. The end user interface 102 is responsible for converting the end-user's keystroke and mouse-click sequences into appropriate messages 107 that are sent over the internet 103 toward the auctioneer's application software 104.

Typically, the application software 104 can be viewed as having an application programmer's interface (API) 116 at the network interface; where, the API includes commands dedicated for communication between the end-user and the auctioneer (e.g., “Bid”, “Sell”, “Register”, etc.). As such, the messaging 107 sent by the end user interface 102 corresponds to network communications (e.g., one or more packets) that describe the end user's activity in API compatible terms. For example, the specific sequence of keystrokes and mouse clicks that correspond to the user's attempt to make a bid invokes the “Bid” command. Invocation of the Bid command (and perhaps associated information) is effectively packetized by the end-user interface 102 and sent over the Internet 103 to the auctioneer's application software 104.

The on-line auctioneer's application software 104 controls the end-user's presentation experience (as suggested by presentation manager 116). In so doing, messaging 108 describing changes to the user's presentation experience (e.g., a new web page for viewing) are sent over the Internet 103 from the auctioneer's application software 104 to the end-user's equipment 110. The messaging 108 may be implemented as one or more packets that are formatted to describe the presentation changes as API compatible information. The end-user interface 102 (which typically includes a graphical user interface (GUI)) presents visual content 106 to the end user so as to make the presentation change(s) visually apparent. As discussed in more detail below, emails 109 may also be exchanged between the end-user and the auctioneer's application software (noting that functions such as an email server 111 may be deemed part of the auctioneer's application software 104 for purposes of convenience).

FIGS. 2a through 2c demonstrate some prior art process flows that can be executed by the auctioneer's application software. FIG. 2a shows a registration process that can be viewed as being executed by the “add user” component 112 of the application software, FIG. 2b shows a bidding process that can be viewed as being executed by the “bidding” component 113 of the application software; and, FIG. 2c shows a listing or selling process that can be viewed as being executed by the “listing” component of the application software. Each of these components 112, 113, 114 are drawn as being coupled to some form of database resources 115.

According to the registration process of FIG. 2a, the standard course of procedure is to have an end user send a ‘filled out’ registration form 201. If the form has an error 202, presentation change messaging 203 is sent to the end user that notifies the end user that the registration attempt was unsuccessful and should be retried. If the registration form is filled out properly an inquiry 204 is made to see if the particular end user has already been “email registered”.

Email registered means that a file exists within the archives of the auctioneer for the end-user which includes the user's email address. If the user is not email registered (i.e., if no email is recorded for the end user) an unconfirmed user file that includes the user's email address is created 205 (note that, in one embodiment, the user's email address is found in the properly filled out form). If the user is email registered an inquiry 206 is made to see if the end-user is “email confirmed”. Email confirmed means that a code that is specific to the end-user is successfully received by the auctioneer via email from the end user.

If the user is also email confirmed, presentation change messaging 208 is sent to the end-user indicating that the registration process has previously been successfully. If the user is either not email registered or not email confirmed the auctioneer sends 207 an email to the end user that asks the end user to send his/her code via email (in one embodiment, the password is first included in the filled out form and the email exchange is performed to confirm the code). Upon receipt of the return email from the end-user 209, an inquiry 211 is made to see if the code is correct. If not, another email is sent to the end-user requesting the code 207. If so, a confirmed user file is created 212.

Referring to FIG. 2b, if a bid is received from an end user and is correctly referenced to the end-user's code 213, the bid is entered in a database 214 and an email is sent to the end-user that confirms that the bid has been entered in the auctioneer's system 215. Referring to FIG. 2c, if a sales listing is received from an end user and is correctly referenced to the end-user's code 216, the sales listing is entered in a database 217 and an email is sent to the end-user that confirms that the bid has been entered in the auctioneer's system 218.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not limitation, in the Figures of the accompanying drawings in which:

FIG. 1 (prior art) shows on-line auction service architecture;

FIG. 2a (prior art) shows a registration methodology;

FIG. 2b (prior art) shows a bidding methodology;

FIG. 2c (prior art) shows a selling methodology;

FIG. 3 shows an on-line auction service architecture that lends itself to reaching peoples of different cultures in their native language;

FIG. 4a shows a registration methodology that can be implemented with 3^rd party translation;

FIG. 4b shows a bidding methodology that can be implemented with 3^rd party translation;

FIG. 4c shows a selling methodology that can be implemented with 3^rd party translation;

FIG. 5 shows a possible architecture for a 3^rd party translation service;

FIG. 6 shows an embodiment of a computing system.

DETAILED DESCRIPTION

While the exemplary embodiment of the present invention is described below in the context of an on-line auction system, it will be appreciated that at least certain aspects of the invention (e.g., registration processes among possible others) may of course be implemented as part of any electronic, network-based, or automated commerce system, which may or may not support an auction-style price sitting mechanism. As such, the present application discloses matter directed more generally to commerce systems as well as in particular to on-line auctioning.

With respect to the prior art on line auctioning service architecture observed in FIG. 1, note that the messaging 107 sent by the user interface 102 describes “standard format” key strokes and mouse clicks 105; while, the messaging 108 sent by the auctioneer's application software 104 describe “standard format” presentation change(s). Here, the phrase “standard format” invokes the notion that only a single type of presentation experience is provided to an end-user. For example, the “standard format” presentation experience may describe all communications, menu options, instructions, etc. in the English language.

A single, “standard format” presentation experience neglects the full potential of the Internet's reaches, however. That is, as the Internet 103 is able to reach different peoples of different languages and cultures, having a “standard format” user presentation tends to eliminate as potential users of the on-line auctioning service those individuals who cannot read or write in the language employed by the “standard format” (e.g., English). Being able to provide a presentation experience that is tailored for a particular culture or other demographic (e.g., as measured by language, presentation design, etc.) should help to expand the potential user base of the on-line auctioning service.

However, managing a wealth of different presentation experiences with the application software's presentation manager 110 may complicate the design and complexity of the application software 104 (e.g., the presentation manager component 110) to the point where supporting cultural specific experiences causes a bottleneck in the performance of the overall on-line service. FIG. 3 shows an architecture that distributes translation services 322 towards those end users who seek to interface with the on-line auctioneer 309 through an interface other than the standard format. By translating between a non standard user presentation experience and the on-line auctioneer's standard presentation experience, the “3^rd party” translation service 322: 1) helps to reach those who would not use the on-line auctioning service were it not for the non standard experience; and, 2) keeps the additional burden placed on the on-line auctioneer's application software 304 manageable (because the application software maintains operation through its standard API).

According to the architecture of FIG. 3, the end-user makes “native language” keystrokes and mouse clicks 305 (or the equivalent thereof) that are interpreted by an end user interface 302. In a typical approach, the end user interface 302 is a modest software routine that is downloaded to the end user's equipment 310 by the 3^rd party translation service 322 (e.g., note that networking infrastructure is not shown in FIG. 3 between the end user interface 302 and translation service 322 for illustrative convenience) in response to the end-user 301 having made a request (such as an HTTP request) to the 3^rd party translation service 322.

The end user interface 302 is responsible for converting the end-user's “native language” keystroke and mouse-click sequences into appropriate messages 320 that are sent to the 3^rd party translation service. Note that the end-user interface and overall “native language” presentation need not only employ another language besides the standard format language but may also provide a unique color scheme and/or visual design as compared to the standard format presentation. As such, a complete culture-specific experience can be crafted for the end-user. For convenience the phrase “culture specific”, “cultural specific” and the like should be understood to mean “targeted for peoples of a specific demographic”. Also, the phrase “native language” will be used to refer to language aspects of a culture-specific experience.

The 3^rd party translation service 322 is responsible for translating the “native language” messaging 320 into “standard format” messaging 307. The “standard format” messaging 307 is then sent, over the Internet 303, to the on-line auctioneer's application software 304 though its API. By communicating to the on-line auctioneer's application software 304 through the “standard format” API, the on-line auctioneer's application software 304 is able to efficiently control the end-user's presentation experience “as if” the presentation were being rendered in a standard format. As a consequence, only modest overhead or re-design should be introduced to the already existing and functional application software 304.

Likewise, messaging 308 describing changes to the user's presentation experience (e.g., a new web page for viewing in standard API format) are sent in standard format over the Internet 303 from the auctioneer's application software 304 to the 3^rd party translation service 322. The third party translation service 322 translates the standard format messaging 308 into messaging 321 that is sent to the end user interface 322 that describes presentation changes in the native language format. The end user interface 322 presents the natural language visual content 306 to the end user 301 so as to make the presentation change(s) visually apparent. As discussed in more detail below, emails 309 may also be exchanged between the end-user and the on line auctioneer by embedding email content through the application software's API flow 307, 308.

Due to the presence of the 3^rd party translation service 322 for those engagements between the on-line auctioneer and an end user interfacing through a cultural specific presentation, basic methodologies (e.g., registration, bidding and selling) will be different than previously implemented. FIGS. 4a, 4b and 4c respectively illustrate exemplary methodologies for registering, bidding and selling through the third party translation service 322. Each of these methodologies may be compared with their prior art counterparts provided in FIGS. 2a, 2b and 2c respectively. Also, due to the fact that the architectural approach of FIG. 3 is different than the architectural approach of FIG. 1, efficiencies in implementation can be gleaned by modifying the standard format API so as to include additional functional calls (“AddUser” and “RegCode”) that were heretofore not present in the standard format.

By incorporating these additional function calls into the standard format API, pre-existing non cultural specific information flows should not be effected (i.e., as they successfully engaged the auctioneer without referencing the new calls there is no need to cause them to do so after the calls are made available); while, the cultural specific information flows are efficiently engaged. In a sense, the new function calls amount to an upgrade of the API that is downward compatible with its pre-existing uses. Each of the new function calls reference a body of information (a filled out form in the case of the AddUser command and a user specific code in the case of the RegCode command); and, each of the new function calls indicate whether or not there is an error or if the function was successful (i.e., in the case of the AddUser command: if the new user was successfully added to the on-line auctioneer's database resources 315; in the case of the RegCode command: if the registration code matched its looked for value).

Referring to the registration methodology of FIG. 4a, the culture specific end user interface forwards to the 3^rd party translation service 422 messaging 401 that describes native language key strokes and mouse clicks indicating a new user has submitted a registration form (or, that the new user has submitted information from which the 3^rd party translation software can create filled out registration form). In response to this messaging 401, the 3^rd party translation service 422 invokes the AddUser command 402 over the Internet 423 through the standard format API. Note that the AddUser command may refer to a translated version of the newly submitted form (i.e., the 3^rd party may perform native language to standard format language translation for a form field requiring it—although typical registration information (e.g., user name, email address, etc.) typically do not require translation).

The on-line auctioneer's application software 424, in response to cognizance of the AddUser command, checks to see if the filled out form referred to by the AddUser command contains any errors 403 (e.g., as just one instance, checks to see if all required fields have been filled out). If the form has errors the application software 424 sends an AddUser function call output back to the 3^rd party translation service 422 that indicates an error condition. In response, the 3^rd party translation service 424 directs a native language compatible “retry” presentation change 404 to the end user interface that informs the end-user the registration form must be re-submitted due to error.

If there is no error in the registration form the application software 424 inquires to see if the new user is email registered 405. If the user is not email registered an unconfirmed user file is created 407. If the user is email registered a second inquiry 406 is made to see if the user has been email confirmed. If so, the application software 424 sends an AddUser function call output back to the 3^rd party translation service 422 that indicates the end-user is presently formally recognized by the auctioneer. In response, the 3^rd party translation service 424 directs a native language compatible “success” presentation change 408 to the end user interface that informs the end-user that the end-user is formally recognized by the auctioneer.

If the user is not email registered or is not email confirmed, content for an email to be sent to the end user from the 3^rd party translation service 422 and that requests the end user to send his/her confirmation code is sent to the 3^rd party translation service 422 by the application software 424 through the API. For example, according to the specific embodiment of FIG. 4a, an .XML file is sent 409 to the third party translate service 422; where, the .XML file includes a message written in the standard language format that asks the user to send his/her confirmation code. In response to receipt of this file, the 3^rd party translation service 422 translates the message from the standard format language to the native language and sends an email to the end user having the native language message 410.

In response to the reception of the email, the end-user sends an email to the 3 party translation service 422 that includes the user's confirmation code. In response, the 3^rd party translation service invokes the RegCode command 411 (which includes as an operand the user supplied confirmation code) through the application software's API. In response, the application software 424 checks if the submitted code is the correct code 412 (e.g., as compared to that submitted in the form). If not, content for another email requesting the code 409 and a RegCode command output that indicates the code conformation was not successful is sent to the 3^rd party translation service 422 through the API 409. If the submitted code is the correct code, a RegCode output indicating success is sent to the 3^rd party translation service 422 over the API; which, in turn, causes a native language compatible “congratulations” presentation change to be presented to the end user 414. Since the registration code sequence is part of the add user sequence, a correct code also causes an outstanding AddUser command output indicating success to be sent back to the translation service 422.

FIG. 4b shows an exemplary process for making a bid through a 3^rd party translation service. According to the process of FIG. 4b, messaging 430 describing native language key strokes and mouse clicks that indicate a bid for an item for sale is being made through a native language interface. The 3^rd party translation service converts 431 the natural language bid into a standard format bid that is sent through the application software 424 API. Upon being cognizant of the bid's reception 432, the application software enters 433 the bid into a database where records of bids for items for sale are stored; and, sends 434 content through the API (e.g., an .XML file) to the translation service 422 that informs the end user in the standard language format that the bid has been entered 434. In response, the translation service 422 translates 435 the standard format language content into native language content that is embedded into an email and sent to the end user.

FIG. 4c shows an exemplary process for making a listing (or sale) through a 3^rd party translation service. According to the process of FIG. 4c, messaging 436 describing native language key strokes and mouse clicks that indicate a listing of an item for sale is being made through a native language interface. The 3^rd party translation service converts 437 the natural language listing into a standard format bid that is sent through the application software 424 API. Upon being cognizant of the listing's reception 438, the application software enters 439 the listing into a database where records of items for sale are stored; and, sends 440 content through the API (e.g., an .XML file) to the translation service 422 that informs the end user in the standard language format that the listing has been entered 434. In response, the translation service 422 translates 441 the standard format language content into native language content that is embedded into an email and sent to the end user.

FIG. 5 shows an exemplary architecture for a 3^rd party translation service. The 3^rd party translation service includes presentation manager logic software 501 which controls the sequence of presentation changes made to an end-user (e.g., as observed in FIG. 4a with respect to sequences 404, 408, 414) as well as controls the standard format API signaling. The presentation manager software 501 is communicatively coupled to email logic software 506 which performs email content translation services in both directions. The email logic software 506 is likewise communicatively coupled to an email server 507 which constructs email messages and sends them to the end user 504; and, receives email messages from the end user 504 and forwards their content to the email logic software 506.

Note that the email logic software 506 has access to a database 505 where email templates 503₁ through 503_N, 504₁ through 504_N can be stored. Email templates can be used as a tool during the translation process. Specifically, the translated version of a specific message may be stored in the database 505 and called upon as needed. For example, the templates 503₁ through 503_N may include: 1) a first template having native language content for an email asking the user to send his/her confirmation code; 2) a second template having native language content for an email informing the user that a bid was entered; 3) a third template having native language content for an email informing the user that a listing was entered;, etc. Thus, for example, if an email needs to be sent to user that informs a user that a bid was successful, the email logic software 506 fetches the second template from the database 505.

Here the templates may include not only natural language content but also fields for entering custom/per-user information (such as user name, user code, etc.). Note also that, by looking up email templates as described just above, the language content sent through the API from the auctioneer to the 3^rd party translation source may be replaced by a reference number that identifies which type of message is to be sent to the end user. By looking up the proper template with the reference number, translation is effectively performed. Templates having standard format language content may also be used to construct emails flowing into the on line auctioneer's application software.

The presentation manager software 501 is also observed to be communicatively coupled to a presentation database 502 that stores the culture specific/natural language web pages that can be presented to an end user. Here, note that the architecture of FIG. 5 is efficient in that it can support different cultural specific experiences. For example, a collection of IS resources orchestrated into the architecture of FIG. 5 could serve each of a number of proximately located regions having their own unique culture. For example, in area such as the Balkans or thereabouts where multiple small markets having a complex mix of cultures and corresponding languages (e.g., Croatian, Serbian, Bulgarian, Greek, Albanian) and alphabets (Latin, Cyrillic, Greek, Arabic) are found, the architecture of FIG. 5 could be used to simultaneously serve each of these small markets by having a family of templates for each unique experience (e.g., a Croatian family of templates, a Serbian family of templates, etc.).

Because various methodologies described herein can be implemented with software routines it is to be understood that aspects of this invention may be used as or to support a software program executed upon some form of processing core (such as the Central Processing Unit (CPU) of one or more computing systems) or otherwise implemented or realized upon or within a machine readable medium. A machine readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine readable medium includes read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.

FIG. 6 shows an embodiment of a computing system 600 that can execute instructions residing on a machine readable medium (noting that other (e.g., more elaborate) computing system embodiments are possible). In one embodiment, the machine readable medium may be a fixed medium such as a hard disk drive 602. In other embodiments, the machine readable medium may be movable such as a CD ROM 603, a compact disc, a magnetic tape, etc. The instructions (or portions thereof) that are stored on the machine readable medium are loaded into memory (e.g., a Random Access Memory (RAM)) 605; and, the processing core 606 then executes the instructions. The instructions may also be received through a network interface 607 prior to their being loaded into memory 605.

In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims

1. A method comprising:

receiving a native language interaction sequence from an end-user interface, the native language sequence comprising key strokes;

generating, using one or more processors, a provider-format interaction sequence based on the native language interaction sequence, the provider-format interaction sequence including one or more application programming interface (API) commands that enable the native language interaction sequence to be recognized by a provider application; and

providing the provider-format interaction sequence to the provider application, the provider application to process the provider-format interaction sequence in a provider language.

2. The method of claim 1, further comprising analyzing the provider-format interaction sequence with respect to a provider-format user presentation.

3. The method of claim 1, further comprising tailoring the end-user interface to a particular demographic.

4. The method of claim 1, further comprising tailoring the end-user interface to a particular culture.

5. The method of claim 1, further comprising uploading the end-user interface to a device of the end user.

6. The method of claim 1, further comprising:

receiving, from the provider application, a message indicating a presentation change to a provider-format user presentation; and

generating a corresponding presentation change in the end-user interface based on the message.

7. The method of claim 1, wherein at least one of the one or more API commands are added to an API based on a pre-existing provider-format information flow.

8. The method of claim 1, wherein at least one of the one or more API commands refers to a provider-format form having a plurality of provider-format fields.

9. The method of claim 1, further comprising:

receiving, from the provider application, a provider-format message to be displayed at the end-user interface;

selecting a native language template from a plurality of native language templates, the native language template being a translation of the provider-format message; and

generating a native language message based on the selected native language template.

10. The method o f claim 1, wherein the native language interaction sequence further comprises one or more mouse clicks.

11. A method comprising:

receiving a provider-format message from a provider application, the provider-format message being in a provider language and to be displayed in a user presentation in a provider-format; and

generating, using one or more processors, an end-user interface in a native language based on the provider-format message, the end-user interface being able to receive a native language interaction sequence including keystrokes.

12. The method of claim 11, further comprising:

receiving the native language interaction sequence from the end-user interface;

generating a provider-format interaction sequence based on the native language interaction sequence, the provider application to process the provider-format interaction sequence in the provider language; and

providing the provider-format interaction sequence to the provider application.

13. The method of claim 12, wherein the provider-format interaction sequence includes one or more API commands.

14. The method of claim 11, further comprising tailoring the end-user interface to a particular demographic.

15. The method of claim 11, further comprising tailoring the end-user interface to a particular culture.

16. The method of claim 11, further comprising adding at least one API command to an API of the provider application based on a pre-existing provider-format information flow.

17. The method of claim 11, further comprising:

selecting a native language template from a plurality of native language templates, the native language template being a translation of the provider-format message; and

generating a native language message based on the selected native language template.

18. The method of claim 11, wherein the native language interaction sequence further comprises one or more mouse clicks.

19. A non-transitory machine-readable medium comprising instructions, which when executed by one or more processors perform operations comprising:

receiving a native language interaction sequence from an end-user interface, the native language sequence comprising key strokes;

generating, using one or more processors, a provider-format interaction sequence based on the native language interaction sequence, the provider-format interaction sequence including one or more application programming interface (API) commands that enable the native language interaction sequence to be recognized by a provider application; and

providing the provider-format interaction sequence to the provider application, the provider application to process the provider-format interaction sequence in a provider language.

20. A non-transitory machine-readable medium comprising instructions, which when executed by one or more processors perform operations comprising:

receiving a provider-format message from a provider application, the provider-format message in a provider language to be displayed user presentation in a provider-format; and

generating, using one or more processors, an end-user interface in a native language based on the provider-format message, the end-user interface able to receive a native language interaction including keystrokes.