EP1671265A4 - Culture specific on-line commerce - Google Patents
Culture specific on-line commerceInfo
- Publication number
- EP1671265A4 EP1671265A4 EP03818976A EP03818976A EP1671265A4 EP 1671265 A4 EP1671265 A4 EP 1671265A4 EP 03818976 A EP03818976 A EP 03818976A EP 03818976 A EP03818976 A EP 03818976A EP 1671265 A4 EP1671265 A4 EP 1671265A4
- Authority
- EP
- European Patent Office
- Prior art keywords
- user
- action
- line
- application software
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/08—Auctions
Definitions
- 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.
- Figure 1 illustrates a prior art on-line commerce service architecture in which the principle manner of commerce is auctioning.
- 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.
- IS Information Science
- Such IS resources are often referred to as the on-line auctioneer's "back-end” resources.
- 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).
- 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 end-user makes keystrokes and mouse clicks (or the equivalent thereof) that are interpreted by an end user interface 102.
- 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.
- 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.).
- 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.
- API application programmer's interface
- the on-line auctioneer's application software 104 controls the end- user's presentation experience (as suggested by presentation manager 116).
- messaging 108 describing changes to the user's presentation experience e.g., a new web page for viewing
- 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.
- GUI graphical user interface
- emails 109 may also be exchanged between the end-user and the auctioneer's application software (noting that functions such as an email server 1 11 may be deemed part of the auctioneer's application software 104 for purposes of convenience).
- Figures 2a through 2c demonstrate some prior art process flows that can be executed by the auctioneer's application software.
- Figure 2a shows a registration process that can be viewed as being executed by the "add user" component 112 of the application software
- Figure 2b shows a bidding process that can be viewed as being executed by the "bidding” component 113 of the application software
- Figure 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.
- the standard course of procedure is to have an end user send a 'filled out' registration form 201.
- 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.
- 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.
- Figure 1 shows on-line auction service architecture
- Figure 2a shows a registration methodology
- Figure 2b shows a bidding methodology
- Figure 2c shows a selling methodology
- Figure 3 shows an on-line auction service architecture that lends itself to reaching peoples of different cultures in their native language;
- Figure 4a shows a registration methodology that can be implemented with 3 rd party translation;
- Figure 4b shows a bidding methodology that can be implemented with 3 rd party translation;
- Figure 4c shows a selling methodology that can be implemented with 3 rd party translation
- Figure 5 shows a possible architecture for a 3 rd party translation service
- Figure 6 shows an embodiment of a computing system.
- 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.
- Figure 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.
- the "3 rd party" translation service 322 By translating between a non standard user presentation experience and the online 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).
- the end-user makes "native language” keystrokes and mouse clicks 305 (or the equivalent thereof) that are interpreted by an end user interface 302.
- 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 Figure 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.
- 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.
- culture specific “cultural specific” and the like should be understood to mean “targeted for peoples of a specific demographic”.
- 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.
- 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.
- messaging 308 describing changes to the user's presentation experience 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.
- 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.
- Figures 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 Figures 2a, 2b and 2c respectively.
- 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.
- 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).
- 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).
- the 3 rd party translation service 422 invokes the AddUser command 402 over the Internet 423 through the standard format API.
- 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 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.
- 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.
- 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.
- 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.
- 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.
- the end-user sends an email to the 3 rd party translation service 422 that includes the user's confirmation code.
- 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.
- 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.
- FIG. 4b shows an exemplary process for making a bid through a 3 rd party translation service. According to the process of Figure 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.
- the application software 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.
- 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.
- Figure 4c shows an exemplary process for making a listing (or sale) through a 3 rd party translation service.
- 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.
- the application software 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.
- 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 Figure 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.
- the email logic software 506 has access to a database 505 where email templates 503 ⁇ through 503N, 504 ⁇ through 504N can be stored.
- Email templates can be used as a tool during the translation process.
- the translated version of a specific message may be stored in the database 505 and called upon as needed.
- the templates 503 ⁇ through 503N 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.
- the email logic software 506 fetches the second template from the database 505.
- 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.).
- custom/per-user information such as user name, user code, etc.
- 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.
- a presentation database 502 that stores the culture specific/natural language web pages that can be presented to an end user.
- the architecture of Figure 5 is efficient in that it can support different cultural specific experiences. For example, a collection of IS resources orchestrated into the architecture of Figure 5 could serve each of a number of proximately located regions having their own unique culture.
- the architecture of Figure 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 Wegn family of templates, a Malawin family of templates, etc.).
- a machine readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer).
- 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.
- Figure 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).
- the machine readable medium may be a fixed medium such as a hard disk drive 602.
- 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.
- RAM Random Access Memory
Landscapes
- Business, Economics & Management (AREA)
- Finance (AREA)
- Accounting & Taxation (AREA)
- Marketing (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Description
Claims
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/US2003/031735 WO2005045722A1 (en) | 2003-10-06 | 2003-10-06 | Culture specific on-line commerce |
Publications (2)
Publication Number | Publication Date |
---|---|
EP1671265A1 EP1671265A1 (en) | 2006-06-21 |
EP1671265A4 true EP1671265A4 (en) | 2008-01-23 |
Family
ID=34748430
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP03818976A Ceased EP1671265A4 (en) | 2003-10-06 | 2003-10-06 | Culture specific on-line commerce |
Country Status (1)
Country | Link |
---|---|
EP (1) | EP1671265A4 (en) |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2002001400A1 (en) * | 2000-06-28 | 2002-01-03 | Qnaturally Systems Incorporated | Method and system for translingual translation of query and search and retrieval of multilingual information on the web |
WO2002033618A1 (en) * | 2000-10-16 | 2002-04-25 | Ebay, Inc. | Listing items globally and regionally, and customized listing according to currency on shipping area |
WO2002088977A1 (en) * | 2001-04-30 | 2002-11-07 | Blue Martini Software, Inc. | Methods for creating a multilingual web applications |
US20030005159A1 (en) * | 2001-06-07 | 2003-01-02 | International Business Machines Corporation | Method and system for generating and serving multilingual web pages |
WO2003040951A1 (en) * | 2001-10-11 | 2003-05-15 | Ebay, Inc. | System and method to facilitate translation of communications between entities over a network |
-
2003
- 2003-10-06 EP EP03818976A patent/EP1671265A4/en not_active Ceased
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2002001400A1 (en) * | 2000-06-28 | 2002-01-03 | Qnaturally Systems Incorporated | Method and system for translingual translation of query and search and retrieval of multilingual information on the web |
WO2002033618A1 (en) * | 2000-10-16 | 2002-04-25 | Ebay, Inc. | Listing items globally and regionally, and customized listing according to currency on shipping area |
WO2002088977A1 (en) * | 2001-04-30 | 2002-11-07 | Blue Martini Software, Inc. | Methods for creating a multilingual web applications |
US20030005159A1 (en) * | 2001-06-07 | 2003-01-02 | International Business Machines Corporation | Method and system for generating and serving multilingual web pages |
WO2003040951A1 (en) * | 2001-10-11 | 2003-05-15 | Ebay, Inc. | System and method to facilitate translation of communications between entities over a network |
Non-Patent Citations (1)
Title |
---|
See also references of WO2005045722A1 * |
Also Published As
Publication number | Publication date |
---|---|
EP1671265A1 (en) | 2006-06-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20110197208A1 (en) | Method and apparatus for reaching small markets with a culture specific on-line commerce service | |
US10275291B2 (en) | API and business language schema design framework for message exchanges | |
US9477584B2 (en) | System and method to test executable instructions | |
US10031929B2 (en) | Techniques for maintaining compatibility in database schemas | |
US10198764B2 (en) | System and method for message-based purchasing | |
TWI245201B (en) | Interactive search process for product inquiries | |
AU2002240354B2 (en) | Method and apparatus to facilitate a transaction within a network-based auction facility | |
US20070283273A1 (en) | System, Method, and Computer Program Product for Internet Tool | |
US20230214414A1 (en) | Item matching | |
US11636142B2 (en) | Item matching | |
AU2017331599A1 (en) | Mobile service applications | |
US20080168131A1 (en) | Platform for defining single-page web signup facilities | |
US20100082623A1 (en) | Item clustering | |
TW486673B (en) | Method and apparatus for conducting data transactions between multiple programs | |
US20220076813A1 (en) | Immunization registry integration system | |
EP1671265A1 (en) | Culture specific on-line commerce | |
JP2004318379A (en) | Merger and acquisition support system | |
US7636786B2 (en) | Facilitating access to a resource of an on-line service | |
US20090276354A1 (en) | Method and system for transaction processing | |
KR20070025713A (en) | Server of providing auction state information by using message service and method for operating the server |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20060406 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR |
|
RIN1 | Information on inventor provided before grant (corrected) |
Inventor name: DALTON, TOLA Inventor name: SAWANOBORI, MASAKI Inventor name: HOFER, PETRA Inventor name: SOMAYAJULA, KRISHNA Inventor name: JOHNSON, PETER Inventor name: LUAN, CHENGGANG |
|
DAX | Request for extension of the european patent (deleted) | ||
RIN1 | Information on inventor provided before grant (corrected) |
Inventor name: SOMAYAJULA, KRISHNA Inventor name: SAWANOBORI, MASAKI Inventor name: LUAN, CHENGGANG Inventor name: DALTON, TOLA Inventor name: JOHNSON, PETER Inventor name: HOFER, PETRA |
|
A4 | Supplementary search report drawn up and despatched |
Effective date: 20071228 |
|
17Q | First examination report despatched |
Effective date: 20080620 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R003 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED |
|
18R | Application refused |
Effective date: 20120710 |