WO2006011847A1

WO2006011847A1 - Internet based system and method for commerce and financial transactions

Info

Publication number: WO2006011847A1
Application number: PCT/SE2005/001181
Authority: WO
Inventors: Imad Agi; Tomas Wedberg
Original assignee: Imad Agi; Tomas Wedberg
Priority date: 2004-07-27
Filing date: 2005-07-26
Publication date: 2006-02-02
Also published as: SE0401947D0; SE0401947L

Abstract

The present invention relates to a method and a internet based system for commerce and transactions, including: a server (2:50), a communication device (X), a system part to via said communication device (X) allow a user to connect to said server (2:50) via the internet, a database (2:41) which includes information about articles available in the system, a system part to via said communication device (X) allow a user to order an article, wherein said database (2:41) is common for users belonging to B2B and B2C respectively.

Description

INTERNET BASED SYSTEM AND METHOD FOR COMMERCE AND FINANCIAL TRANSACTIONS

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention concerns a method and internet based system for commerce and transactions comprising: a server, a communication device, a system part to through the mentioned communication device allow a user to connect himself to the server mentioned through the internet, a database including information on available articles in the system, a system part by means of which said communication device allow a user to order an article.

2. Description of the Related Art

Trading over the Internet, known as e-commerce, has become more and more common. Today several systems exists, tying multiple corporations to a single website, in purpose to ease the customers use of the internet in searching for a product and/or a merchant, to thereby ease e-commerce, and in doing so also making managing easier for the merchants.

Through US 6556975 is for example previously known an e-commerce system aiming to offer an on-line mall, e.g. a mall accessible through the internet. Thereby the potential buyer may access multiple attached stores through the internet and the specific website. The system is however divided into communities containing the stores, which means a limitation in extent. In addition the system is distributed over specified hardware which arise yet another limitation. The system also shows limitations in other aspects, which is a probable cause to why the system has not become widely known.

Through US 2002/0023007 is also known an e-commerce system aiming at creating mall functionality. This system is intended to host multiple separate stores and puts focus on the system managing several stores managed by their respective owner rather than integrating the shops into a common mall. Thereby also this known system presents limitations.

Also WO 02/031243 concerns a system to create a sort of internet mall, but here in the form of a portal based on third parts websites. The system is built in such way that it needs a third parts webshop or other IT-system. Thereby is also this kind of system marred by some limitations.

SUMMARY OF THE INVENTION A purpose of the present invention is to eliminate or at least minimize the above mentioned problems, which is accomplished by the use of a method and an internet based system for commerce and transactions, comprising: a server, a communication device, a system part for through the mentioned communication device allow a user to connect to the mentioned server through the internet, a database comprising information concerning articles available in the system, a system part for through the mentioned communication device allow a user to order an article, wherein said information is available in at least one database concerning users belonging to B2B respective B2C.

Due to the invention and centralization of the information the e-commerce will become easier, safer, more attractive and efficient for all parts involved, e.g. Suppliers, retailers and end customers.

In a most preferred embodiment according the invention, the following aspects are worth mentioning: • The invention is primarily a complete tool for existing stores who also wants to offer e-commerce, B2C.

• The invention comprises more components than other concepts; B2B, C2C, CRM, PR and marketing, payment engine, distribution control, etc.

• Common registers, a customer is not dedicated to one store etc. • All suppliers, retailers and end customers are components and are included in the integrated system.

• All user components can be grouped and has access to and can participate in different content determined forums.

• Administration and support towards the end customers are cooperative tasks shared by the invention, the suppliers and the retailers.

• The end customer buys from the proprietor of the system according to the invention, who is also responsible towards the end customer.

• The system according to the invention is dynamic and has an open resource management. A module is not tied to certain hardware or reverse, although it is possible to dedicate hardware to certain modules. To achieve normal resource distribution the system should run on three server clusters for security reasons.

• The payment module manages B2B, B2C, C2C and both products and services. According to further aspects according to the invention, the following applies:

- that said information is available in a common database, which results in the advantage that security and accessibility can be substantially improved.

- that said database is common also for users belonging to C2C, which results in the advantage that certain payment routines can be simplified, and it also brings about a more effective entrance for new users. system components organized to permit that each user connected to the system, can configure the part of the database which he is authorized to configure, which results in the advantage that the information in the database can be kept updated in an efficient way. system components organized to permit that each user connected to the system, gets a purpose adapted visualization, which results in simplified operation and maintenance of the system. It also increases the systems user-friendliness. system components organized to permit that tools in the system are related to the task performed, which makes it easier for the user to use.

- system components organized to permit that users connected to the system, can register payment commissions. This results in the advantage that payment commissions can be managed in a flexible way through the system, e.g. a small retailer can accept card payments through the system and the stores internet connected computer, instead of investing in expensive card terminal equipment and subscription..

- system components permitting creation and maintenance of projects for users connected to the system, which results in the advantage that users can unite to cooperate, e.g. to achieve common goals.

- system components organized to permit that some users connected to the system, can use a local tool provided by the system provider, to perform simpler tasks off-line, which results in the advantage that internal administration tasks (e.g. stock maintenance, purchase) for a user (e.g. store manager) can be simplified and more cost effective.

- system components organized to permit that every corporate user connected to the system, can be allotted its own communication identity, especially in the form of a sub domain, which results in the advantage that the users in a simple and cost effective way can provide their own information, e.g. in addition to the information concerning articles comprised in the system. - The table construction for at least some table in the database is based on both server identity and post identity, which results in the advantage that the operation in a distributed network can be continued even in an unsynchronized condition.

BRIEF DESCRIPTION OF THE FIGURES

The figures are explained with references according to the format figure .symbol.

A reference to several symbols are designated comma separated according to the format figure: symbol, figure:symbol. A reference to a series of symbols are designated with a hyphen according to the format figure.-symbol -figure: symbol.

Several references to the same subject/process are separated by + according to the format figure-.symbol + figure:symbol.

The figures commonly designate a preferred embodiment. The system commonly has several alternative processes/methods to manage a situation. The figures describe the most common, most important or most describing version, in purpose to simplify the description.

In the text everybody employed by the systems owner to operate the system, are denoted as "system administrators" to simplify the description. We use the word user in a pluralistic sense and refers to one or several individuals from one or several user groups, e.g. system administrator, supplier or their employees, a retailer or their employees, etc.

We use the words "payment" and "approved payment" in a pluralistic sense and refers e.g. payment in advance, direct bank transfer, approved credit, gift voucher, etc. If someone or something is left out in purpose to simplify the explanation, it doesn't necessarily mean that the person or subject left out is excluded. With "internet based system" we refer to a communication network which connects geographically remotely located users, e.g. not limited to the world- wide- web system of today, which is mostly based on TCP/IP communication. In other words it is understood that future system development is included in our concept "internet based system", including the use of new technology and protocols. With "articles" we refers to products, services, etc. available in the system.

Explanation of some terms which can ease the interpretation of the figures: • B2B Business-to-business, contact/trade between supplying corporations. • B2C Business-to-customer, contact/trade between a corporation and end customer.

• C2C Customer-to-customer, contact/trade between end customers.

• S2B System-to-business, contact/trade between the system and connected corporations.

• Format: A defined way to structure stored data.

• Interface: Contact area, can be visual or structural.

• Black box: An element with known interface but unknown content.

• Object orientation: Structuring of logic in objects which are assigned properties, and methods for affecting and reading of those. OO in short.

• OOP Object oriented programming.

• Object: A logic component with properties and methods.

• Module: A grouping of and/or an interface to one or several objects.

• Heritage: An object can inherit properties and methods, from another. • Process: A series of actions to achieve a result.

The figures and texts are based on a object oriented way of thinking, and black box- methodology.

Fig. 1 illustrates a simplified overview of the parts and markets involved, Fig. 2 illustrates a, more detailed, extract of Fig. 1, and the main functions of the system, Fig. 3 illustrates the payment engines integration into the system and connects third parts services,

Fig. 4 illustrates simplified the steps involved in the systems product management from the beginning in B2B, all the way through to the end in B2C,

Fig. 5 illustrates how product information from B2B, is revised and complemented to

B2C-format,

Fig. 6 illustrates the process of navigating with the B2C-interface, Fig. 7 illustrates the payment process with the B2C-interface, and the integration with the payment engine,

Fig. 8 illustrates the order management from a system administrators point of view, Fig. 9 illustrates how different parts of the systems B2B-tools work together, Fig. 10 illustrates how the forum as an example of the tools, has been integrated in different user interfaces, Fig. 11 illustrates the CRM-module as an example on how related modules are reused. Fig. 12 illustrates the C2C-module which is intended to supply different services to consumers. Fig. 13 illustrates the retailers local tool, providing a selection of services.

DETAILED FIGURE DESCRIPTION

In Fig. 1 we illustrate how the system according to the invention, recreates a virtual version of a trade, contact and communication network based on real relations.

Traditional e-commerce is performed in a B2C-systemi_:2 intended to virtually reflect the B2C-relationi:i₆ between stores_1:5 and their customers^. As illustrated, is each user in the system connected by the use of a communication device X, which can be in any shape suitable for the purpose, e.g. a PC, a cellular phone, a PDA, etc. There are also systems reflecting B2B-relationsi_:I2ii_:I3ii_:19 between corporationsi_:5, _{1:6i ]:9}. In traditional commerce (not e-commerce), the B2B and B2C markets seldom cooperates. This has resulted in that the markets often use different systems which seldom can cooperate. In some cases data can be exported and then imported. It is time-consuming processes which easily introduces errors and often presents restrictions.

The system according to the invention, intends to bridge the mentioned problems and separations, as well as to offer more efficiency and more expansion possibilities. What is unique about the invention is the integration of B2B_1:1 and B2Ci_:2 and the optimization of all links_1:i_2-i_:24 and tools (illustrated with only an except)_2:26-₂:3o into one single system.

By using one system comprising all the linksu, _h2 and tools_2:26-2:3o₅ one gains both resource, time and workload benefits, all at once. For not to mention that there is no need to export and import data between different applications and systems. By gathering all (traditionally separate) systems into one, a lot of the information can be reused without processing, to fulfill several purposes.

An advantage that the B2C part of the system^ benefits from is to make use of the confidence the end customers has in their local retailers, to reduce the end customers^ feeling of insecurity concerning e-commerce. This is achieved by integrating geographical navigation^ as one of the degrees of Iiberty_6:3._6:8 (dimensions) in the navigation system, which is described in figure 6.

In Fig. 2 we illustrate, in a simplified form, a preferred embodiment of how the system connects the B2B_2:24 and B2C_2:25 markets. It also shows examples on some of the most common connection tasks_2:26-2_:3o performed by the system. The system solves most of its tasks_2:26._2:3o by combining and sorting available information^ based on the users_2:5-2:8 selections. The users_2:5.₂:s process the results which then are stored in revised form.

All information is stored in the systems database_2:4i which also simplifies the task of securing the information. As shown in fig. 2, the systems database^ can be integrated into one server _2:so , but it is understood that the system just as well can be distributed, e.g. comprise a cluster of servers, managing different parts of the systems functions, e.g. in purpose to improve the performance of information retrieval/updating/etc, from/of the database. Of the database and the system is operated from multiple servers, the system is constructed to synchronize itself, which is preferably, but not necessarily, performed in real-time.

A problem with the internet of today, is that parts of the net suddenly gets overloaded or in some other way cease to function. We refer to it as that a part of the net has "gone down" or "dropped out". It means that a server serving a website easily becomes unreachable. The solution is to operate two servers at different locations and redirect the traffic. This how ever means that some new problems arise, such as that the information on these servers often must be synchronized. In operating real-time systems this is a critical task which easily creates problems, especially in indexing and iteration. The system can use a specially designed table construction to secure a close to error safe operation even when the system is served from unsynchronized servers if parts of the net drops out.

In Fig. 3 we illustrate, in a simplified form, a preferred embodiment of how the payment engine_3:i is integrated into the system.

To manage online payments safely is a difficult task, which is needed in several trade areas. Most traditional e-commerce systems have a cash registry routine and there are many different solutions presented. Some systems avoid the whole problem and choose to give out a bank account into which the customer deposit the payment. Some systems leaves the task to the delivering transporter, e.g. cash on delivery, to ensure limited losses. Other sends the customer and a payment order, to another corporation which is specialized in e-payments. With few exceptions a group of system remains which manages the payments themselves. The system according to the invention belongs to the latter group, but differs from the lot because the payment engine not only performs payment tasks for the e-commerce web page, but manages all payment tasks throughout the entire system^^? and payment tasks for external assigners_3:8. In the system according to the invention, the payment engine_3:1 fulfills all the needs through different interfaces. Most payment tasks are performed automatically, the only human intervention needed is to check the stored data from time to time. All failed payments are logged to be able to give support to customers who have failed. The same data is used for tracking sabotage attempts. The system connects itself, if possible, to the bank, payment, credit, etc. service in question₃..₂.

Occasional corporations and governments have not yet achieved to automate their services which then may demand manual management of certain steps of the task also from the systems side. This type of tasks are commonly placed in a errand queue and handled in turn by one or more system administrator. All information necessary concerning the errand is comprised in one administration page designated for the task. When the errand is handled, the payment is marked and the task is managed automatically again. Ih the system according to the invention the normal cash registry functionality (B2C)_3:4, which are commonly present in traditional e-commerce, only for a part of the tasks_3:3-3:8 performed by the payment engine_3;1.

The payment engine_3;i performs quite common processes, and automatically manages e- payments against banks and credit companies, performs on-line credit checks, creates invoices and sends application forms of different kinds. The payment engines_3:i ability to also perform external tasks_3:8 for systems belonging to customers who are not connected to the system according to the invention, makes it possible to offer smaller companies, and even private persons the ability to receive on¬ line payments sporadically, without large fees.

In Fig. 4 we illustrate, in a simplified form, a preferred embodiment of the most important steps in a products path from the time a supplier^ enters a product into the system (which is described in detail in figure 5_4:6) until it is delivered_4:5, _+4:29 to the end customer^ after which it is handed over to support managements ₊^₅₅. (which is described in detail in figure 1 l_4:I0). Figur 4 intends to visualize the coherence between action*! and process_4:2. It also illustrates which part of the process_4:2 that is repeated_4:3 when an update_4:56-4:65 of the suppliers^ assortment _4:34 with the aid of a file_4:32 or table_4;32 from a supplier_1:6, is performed.

After the suppliers_1:6 products_4;34 has been entered into the system, the detailers connected to the supplier, can select products_4:i_{3 +4:37} into their own assortment. Before or during this phase, the products_4:34 goes through an import process_5:3 as described in figure5_4:6, which can be performed either by a system administrator^, a retailer^ or a supplier^. There is also a optional processes_4:32-4:39 which covers the case where a retailersi_:5 supplier don't wants to supply any information^^ to the system. Alternative processing can be performed by both a retailer_1:5 and a system administrator,^. After choosing a product_4:i₃, the retailer_1:5 can adjust_4:15 certain information about the product and place the product in departments_4:15. Selection of or automatic placing₅..5₄ of the product can also be based on the suppliers_1:6 product informations^, but may in that case be overriderxj.is by the retailer^.

The product is now ready for sale_4:S and is normally displayed^_{? +4:4]} for end customers^. End customerSi_:S can now see the products

and place it in one of their baskets_4:i_{9 + 4:43}, just as in a real-life shop. When the customer^ has found the wanted merchandise, he/she_1:S goes to the cash registry_7:3, which is described in figure 7_4:g, and orders_4:2] the products. The system inserts copies of the products the customer has selected into the order system. This is done to ensure that the customer gets exactly the products he has ordered if the specifications should change before the order is processed. Order processing is described in figure 8_4:9.

The products are delivered_4:5i_+4:29 to the customer_1:8 and then becomes available in the CRM-module_4:55 which in the B2C-interface, organizes commerce related communication and support between the retailer^ and the customer_1:8, which is described in figure 1 l_4:i₀.

In Fig. 5 we illustrate a preferred embodiment of the process which fills the system with products, e.g. stores/updates information concerning certain articles in the database

2:41-

It is easiest described in three steps; updating_5:b cleaning_5:2 and imports^. The first two steps₅..i, _5:2, are performed by a supplier^-, retailer^ user or a system admim^"stratori_:7, with import administrator access.

During updating_5:1 the system is fed with raw data_5:4 about products from a supplier_1:6.

The system reads_5;6 information about a product according to a supplier specific format_5:7 and sorts_5:10 out new_5;i₅ and present_S:2o products against the systems product IiSt₅₃₃. New_5:i5 products are placed_5:i₆ for import_5:3 and present_5:2o products are updated_5:2i according to a supplier specific set of rules_5:7.

This is then repeated_5:27 until every product in the list_5:4 have been processed and the system proceeds to step two_5:2 which practically performs a reverse process of step I₅.,.

The system is cleaned from outdated products which can't be delivered_4:5i any more. Outdated products_5;23 in the systems productlist_5:23 are identified_5:34 as they now are missing_5:36 in the suppliers_1:6 productlist_5:n and are marked_5:37 as hidden for end customersi_:8. Hidden products_5:23 are still available for CRM_4:55 and similar tasks but can't be bought_4:i₉. Step 2 is repeated_5:42 until_5:4I all products_5:23 from the supplier_1:6 have been processed.

Prices and assortments in all stores^ which sells products_5:23 from the supplier_1:6 in the system are now updated_5:2i. NeW₅₁I₅ products_5:n are queued for import in step 3_5:3. Imports* of products_5:π is a separate process which means a change of format and completion of the suppliers _l:6 information^. In this context it should be clarified that with the term "available articles" is meant also the products (mm) which aren't imported in the system, but are available in the database ₂-_ΛI in their original format, so that e.g. retailers (with import administrator rights) are able to process this information, e.g. for eventual later import or direct orders to the store.

It is often performed by one or more users with import access, whether they are suppliers_1:6, retailers_1:5 or system administrators^.

The user loads_5:45 an import product_5:π which is reformated_5:48 according to supplier specific rules_5:7, and can see_5:52 what needs to be changed and completed_5:54 before the product is entered into the systems productlist_5:23. Here_{5:48> 5:54} is also where the retailer selects in what or which deparments_6:3 the product fits. Depending on the suppliers^ raw data_5:4, this can be performed either automatically at reformatmg_5:48, and/or manually_5:54. When all adjustments_5:54 are done, the result is inspected_5;60 and approved_5:62 before it is made available for sale in the shop_1:5. Adjustments_5:54 can without problem be made several times to complete or improve the information and placement.

Step 3_5:3 is repeated_5:7o once per import product_5:n, and the process can be aborted_5:69 between the repetitions_5:70 without any consequences. Abruption in another state only means that the work done on the current import product_5:n is lost.

In Fig. 6 we illustrate a preferred embodiment of the navigation process. A problem which e-commerce systems are confronted with is how huge quantities of products are to be organized to be rapidly retrievable, visible and yet not make the system difficult to handle. Many systems chooses solutions which limits the customers freedom to achieve a simpler structure.

Our method is based on reflecting how a lot of real malls are working. As a customer one don't want anybody else to determine where one should go or how to get there. Usually one wants to decide it self and also to be able to change during the process. Our navigation system strives to let the customer self determine which possibilities are to be limited. We have even involved geographic navigation, which gives certain advantages. E.g. to be able to take care of the customers who wants to support their local retailers, and customers who feels insecurity concerning shopping at unknown companies over the internet. That a customer might find products that he/she didn't know a local retailer had for sale, and that stores in a geographic area easily can cooperate with campaigns and promote their area through the system, etc.

A customer_1;8 can sort out interesting products_{4:17i 4:4}i by a repetitive_6:23 process which for each completing choise₆:3_-6:8 adds more restrictions_6:io when filtering the information. It can be compared with reducing the freedom degrees of a coordinate system; from volume to a plane, to a line and finally to a point, and the customer is the one who decides which axle to limit.

In addition there is a search tool which can search in all these dimensions. Certain choices do not only limit the amount of data, but also changes the design.

In Fig. 7 we illustrate a preferred embodiment of the cash registry process as an example of the systems use of the payment engine_7:2. The cash registry is an important component in most e-commerce systems. There are many different solutions with different levels of security. We have chosen to design and build our own payment engine_7:2 (and economic administration) as modules directly in the system. System administrators can control which alternatives the customer, or groups of customers, can choose from.

The cash registry process is initiated_7:3 by the customers^, which have placed_4:19 products in their baskets. A first demand_7:5 that must be fulfilled is that the customer^ must be logged in. If that's not the case_7;6 the customer is asked to login_7:U or to create an account_7:i₂.

The customer then selects who the receiver is_7:i7 or enters information about a new receiver.

Now the system calculates_7:2i which delivery options the customer^ can choose and displays_7:23 the result. When the customer has selected a delivery method_7:255 the system calculates_7:29 which payment options the customer^ can select and displays_7:3i the result. The customer^ selects a payment method_7:33, and writes any eventual comments concerning the order, and then confirms the chosen information. Orders can now be divided into two groups_7:36; payments with_7:3g and without_7:37 a process.

Orders without a process_7:37 are unpaid_8:6 and are placed under surveilance_8:Ii. Payments with a process_7:38 first goes through the payment engine_7:2 which depending on the selected payment service's routines and conditions_7:39, prepares_7:43, _7:45 and encrypts data_7:45 concerning the payment.

If the payment is aborted or fails₇.₅₈, the customer is informed_7:59 of the status, then sent back_7:60 and gets the opportunity to select_7:33 an other payment method. Before the cash registry process is finished, all essential information concerning the selected products, and information about the customer, is copied_7:66 to the order table, to guarantee that the correct products are delivered and that correct customer stands responsible. The cash registry process is ended by displaying an information page_7:68 which e.g. informs the customer about the order, the payment, support and current conditions.

In Fig. 8 we illustrate a preferred embodiment of how an order is managed further in the system. With the administration tool are e.g. orders, payments, credits and deliveries controlled and monitored. Related elements are linked to each other. E.g. a payment is linked to an order.

When orders arrives_8:3 the system sorts_S:5 out the ones that are paid_8:13. These awaits a manual control_8:i₄ that all ordered products can be delivered according to the specifications and within reasonable time. If not, the problems are investigated and attended_8:16 before the order is approved and locked_8;19. The system administrator who approves and locks_8:i₉ an order is responsible for that the order is treated correctly further in the system.

Those payments that aren't finisheds^ are either put under surveilance_8:n or handled manually_8:9, depending on which payment method the customer_I:8 chose_7:33. The system automatically tracks the orders waiting for payment a determined amount of days, and sends a reminder informing that the order is due if the payment isn't received within a determined amount of days.

When an order is approved and locked_8:i₉, the system creates delivery orders_8:2i from the order and sorts_8:23 out who is to deliver what products to the customer and then places the respective delivery orders_8:25₊₈:₂₇. Each product in the order is marked₈._9 with e.g. status and the order date.

When a delivery have been sent_8:42, the sender_8:43 is credited. When all products are delivered the order is closed_8;45.

All payments, orders and deliveries are monitored by system administrators, to ensure the systems quality. The delivery system is variable and depends on current agreements, the use of cross- stocking, etc. In Fig. 9 we illustrate an example of how a preferred embodiment of the B2B_9:I module, helps corporations_9:5__9:7 to find, communicate and trade with each other. It integrates e.g. the payment engine_9:2, the CRM module_9:3 and connections from a retail tool_9:4 that the stores can operate locally. A thought scenario perhaps gives the easiest description of the benefits of the system.

A supplier_9:5 adds a new product to their assortment and wants to promote it. They consults the systems marketing service_9:9 which presents a plan. The supplier_9:5 invites tenders on transport to its retailers_9:6 from connected conveyors _9:7 and sends the product for testing by a connected magazine_9:8, which performs and publishes the test. The result is also published in a newsletter^ ₁₂ to the retailers_9:6 who are connected to the supplier_9:5, together with an offer on reduced freight when ordering the new product.

The supplier_9:5 also puts up their new product on the trade exhibition_9:!0 together with the test result. The retailers_9:6 connected to the supplier_9:5 easily adds the new product to their assortment with a few mice clicks, by using a link in the newsletter_9:12. They also select a wanted quantity in a order from the supplier_9:5 to take advantage of the freight offer. Some retailers_9:6 contacts the supplier_9:5 through the CRM module_9:3 and request support information concerning the new product. The errands are automatically directed to the suppliers_9:5 selected support administrator for the product group in question.

From the trade exhibition_9:10 comes three new retailers_9:6 who have found the supplier_9:5 through the new product.

Through the payment engme_9:2 the supplier_9:5 performs an on-line credit control and can immediately determine if the retailers_9:6 can place an order paid by invoice. One of the retailers_9:6 gets good creditability and gets to pay by invoice directly from the supplier_9:5. The second retailer_9:6 more insecure and are served through the payment engines_9:2 factoring service. The third retailer_9:6 is small and newly started. They don't get any creditability and the supplier therefore suggests the retailer to pay their order in advance through the payment engine_9:2.

In Fig. 10 we illustrate a preferred embodiment of interest related forums as an example on how a integrated tool module links and are used by several of the systems user types; here represented by a extent consisting of system adrninistratorio:3, supplieri_0:4, retaileri_0:5 and end customeri_0:6. The tools layout and behavior depends on the interface's configuration. Different interfaces links different user types. In Fig. 11 we illustrate a preferred embodiment of how the CRM tool links and are used by several user types. The CRM module can seem identical to the forum module, but it is more advanced and integrates relations between support errands and the order, delivery, return, product, errand, etc., that the errand is related to.

In Fig. 12 we illustrate a preferred embodiment of the C2C-module_12:i which is intended to serve different services for private personsi_2:3-i_2:5. E.g. a market^s for private ads, to let connected

trade with each other. The customersi_2:3-i_2;5 can buy and sell their own goods and take advantage of the secure paymentSi_M via the systems payment enginei_2:2. The buyeri_2:3-12:5 knows that he can get his money back if the merchandise don't meet the information stated. The selleri_2:3-12;5 on the other hand, is guaranteed that the merchandise is paid for before it is sent. The system also manages return errands between customersi₂:_3-[_2:5. There is a discussion forumi_2:7 and a calendar i_2:6 for announcing of public events, that are arranged by e.g. organizations and clubs. The module can be extended as needed and be integrated with e.g. mini cinema_I2:I0 and other servicesi_2:π-i_2:i₃.

In Fig. 13 we illustrate a preferred embodiment of a local tool_U:3 that the retailers^ can use to automate their administration with e.g. stock_13:6, order^s, salei_3:7 and marketmgi_3:9 management. The tool can also be completed with bookkeeping_13:10 or export data_I3:21-i_3:24 for import into the bookkeeping software^_H, which the retailer prefers.

The fact that the tool_I3:3 is operated locally, means that the retailer don't have to invest in an expensive connection to the internet.

The minimum requirements to be able to use the tool, and a computer. We also recommend connecting a modem and a printer.

The tool operates optimally by connecting to the system according to the invention^_! via the internet_I3:2, and download their suppliers_1:6 information^. This will provide the tool_I3:3 with the information needed to use it for e.g. stock_13:6 and salei_3:7 management.

On connection to the

can get updates_4:64 from their connected

then also can charge customers,_;8 on-line_{13:8 + 13:}i₂ co_rresp_onding 4:₂₃ by using the systems payment engine₉.₂, place purchase ordersi_{3:5 +9;23} and even buy more cost effective marketing services_13:9+9:9.

The tool gives well presented reportsi_3:4 about e.g. purchasers, stocki_3:6 and sales_13:7.

With a printer connected these also can be printed. A complete tool can be downloaded from the system^_!, but can also be supplied on preferred media, e.g. a CD. Tool support is included to the systems_13:1 connected retailersi_:5. The invention is not limited to what is disclosed and described above but can be varied within the frames of the patent claims. The specialist realizes e.g. that instead of tables with both post and server identity, a server system where a poll server prevents conflicts can be used, that instead of displaying of a retailers products, an information page without possibilities to direct purchase can be used, that instead of a forum can newsgroups, email lists, etc. be used, and combinations of these.

Claims

PATENT CLAIMS

1. Internet based system for commerce and transactions, including: a server (2:50), a communication device (X), a system part to via said communication device (X) allow a user to connect to said server (2:50) via the internet, a database (2:41) that includes information on available articles in the system, a system part to via said communication device (X) allow a user to order an article, characterised in that said information is available in at least one database

(2:41) regarding users belonging to B2B and B2C respectively.

2. System according to patent claim 1, characterised in that said information is available in a common database (2:41).

3. System according to patent claim 2, characterisedin that said database (2:41) is common also for users belonging to C2C.

4. System according to patent claim 1 -3, characterised by system components arranged to allow that every user who is connected to the system, can configure the part of the database to which the user has authorization to configure.

5. System according to any of the patent claims above, characterised by system components arranged to allow that users who are connected to the system, receive an interface adapted for the purpose.

6. System according to any of the patent claims above, characterised by system components arranged to allow that tools in the system are related in relation to the task.

7. System according to any of the patent claims above, characterised by system components arranged to allow that a user who is connected to the system, can register payment commissions them selves.

8. System according to any of the patent claims above, characterised by system components arranged to allow creation and maintenance of projects for users connected to the system.

9. System according to any of the patent claims above, c harac teri s e dby system components arranged to allow that certain users connected to the system, can use a tool (13:3) provided by the system supplier, to perform simpler tasks off-line.

10. System according to any of the patent claims above, characterised by system components arranged to allow that every user can be provided their own communication identity, preferably in the form of a sub domain.

11. System according to any of the patent claims above, characterisedin that the table construction for at least some table in the database is based on both server and post identification.

12. Method for internet based commerce and transactions, including: provision of a server (2:50), which via a communication device (X), allows a user to connect to said server (2:50) via the internet, and thereby gaining access to a database (2:41) which includes information about articles available in the system, and allows said user to via said communication device (X) order an article, characterised in that users belonging to B2B and B2C respectively have access to a common database (2:41).

13. Method according to patent claim 12, characterised in that users who are connected to the system, can navigate freely in the system, and chose to limit their navigation them selves.

14. Method according to any of the patent claims 12-13, characterised in that essential system parts are built dynamically, whereupon preferably necessary program parts are available for the user via the internet.

15. Method according to any of the patent claims 12-14, characterised in that interfaces included in the system are adapted to different duties.

16. Method according to any of the patent claims 12-15, characterised in that updating of said database (2:41) is done in real time.

17. Method according to any of the patent claims 12-16, characterised in that a modularization is done geographically in dependence of an existing system of rules, whereupon preferably every geographically limited system of rules are included in at least one module.